Further thinking: - perhaps I don't need all those levels, perhaps just 5 levels of fade might be appropriate - in which case the outer loop is 5 iterations, each one 40mS if the overall fade process is to last 200mS, therefore the inner loop has to last for 40mS.
The inner loop emulating a PWM frequency of 500Hz then has 20 steps. Does that sound any better? RIchard On Saturday, 2 May 2020 05:05:07 UTC+1, Richard Scales wrote: > > I can see the concept just ahead of me - I'm still working out how to > grasp it though! > > If the fading process is set to run over say - 200mS , the fade completes > after 200mS and would therefore leave the static displayed digit (for the > 'seconds') displayed for 800mS before the fade to the next digit - this is > a random guess - it may be a shorter period. > > Then, I can see that during that 200mS, a digit that stays the same has to > be on all of the time, A digit that is fading out has to have a 'duty > cycle' that is going from full on to full off over that period and a digit > that is fading in will have a 'duty cycle' that is going from full off to > full on. > > > Then lets say that the actual fade process will occur over a number of > steps - say 20 for example. > > The logic that you describe in your first reply would be used to determine > the duty cycles for each fade step > > > An outer loop would determine the duty cycles for each fade step > An inner loop would then perform the 'PWM' for the current step > > Assuming a digit that was changing from '0' to '1' and that there will be > 20 fade steps, duty cycle for the fading out digit will go from 100% to 0% > in steps of 5% (assuming a linear fade). Similarly the duty cycle for the > fading in digit would go from 0% to 100% in steps of 5%(assuming a linear > fade). > > > In the first iteration of the 'PWM' loop - let's say that the '0' is on > 100%, the '1' is on for 0% > The iteration has to last for total fade duration (200mS) divided by the > number of iterations (20) - so 10mS. > > For 10mS a PWM kind of signal at a given frequency (490Hz Arduino default > so I chose 500Hz) has to be generated with the given duty cycles for the > digits. > > The '0' has 100%, the '1' has 0% > > For the inner loop - which has to last 10mS and based on an assumed 'PWM' > frequency of 500Hz. > > The inner loop would have only 500 x 0.01 = 5 steps > > For each of these steps, the '0' would be on and the '1' would be off > > During each step - send the required digits to the shift register > depending on their on/off state from the required duty cycle then wait the > required number of mS - in this case 10ms / 5 = 2mS. > > 25% of the way through the outer loop - the '0' would be on for 75% and > the '1' would be on for 25% (assuming linear fade) > 75% of the way through the outer loop - the '0' would be on for 25% and > the '1' would be on for 75% (assuming linear fade) > > Am I still on the right track? > These numbers all seem very small - should I be working in uS with more > steps? > Is the 500Hz 'PWM' frequency appropriate? > > Thank you > Richard > > > > > > On Friday, 1 May 2020 04:56:06 UTC+1, Richard Scales wrote: >> >> Hello everyone, >> >> I am contemplating having a go at implementing some form of digit cross >> fade effect of which I have zero experience, knowledge or understanding and >> I am hoping that someone could point me in the right direction. >> >> I can see that there are established designs using HV5622 drivers which >> are capable of cross fading digits that change and I'd like to implement >> this myself. >> >> I already use the blanking signal via a PWM signal to perform overall >> fading of the display (all tubes) though the trick must be maintaining full >> brightness for the digits that stay static whilst varying the brightness of >> the incoming and outgoing changing digits. >> >> If this assumption is correct then I'm also going to assume that, even >> for the digits that remain static - they cannot be on all the time and >> there must be some 'off' time during which the changing digits can be >> faded. >> >> This all makes use of the persistence of vision thing that makes us think >> that the display is static. >> >> If I'm still on the right track then I am guessing that there will be a >> sufficient 'off' time for the static digits to allow the fading digits >> (incoming and outgoing) to be presented at varying degrees of 'brightness'. >> >> In a very rough pseudo code kind of thing: >> >> >> :start of transition >> Set shift register for static digits, turn all digits on, wait long >> enough for the 'full display' effect', turn all digits off >> Set Shift register for outgoing digits only, turn on, wait long enough >> though reduce this period during the course of the transition, turn all >> digits off. >> Set Shift register for the incoming digits only, turn on, wait long >> enough for the digits to start appearing and increase this period during >> the course of the transition, turn all digits off >> Loop back to start until transition is complete >> >> Am I anywhere near close with this? >> >> Is there any published method? >> >> I have yet to point my scope at a working clock to investigate this >> further - I currently have an inherent reluctance to do this following a >> recent episode of clumsy probing resulting in the premature expiration of >> the device that I was investigating :-( >> >> It's really just the concept that I would like to fully grasp, I find >> that I can stare at sample code segments all day long and not make any >> meaningful progress, though code segments are most welcome. >> >> All pointers gleefully received. >> >> Richard >> >> -- You received this message because you are subscribed to the Google Groups "neonixie-l" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/d03aea95-0301-4ccb-9921-09468a8a28f9%40googlegroups.com.
