The idea is correct, and your calculations look correct. I wouldn’t worry about the exact timing, you can adjust that once you have it basically working.
> On May 2, 2020, at 12:21 AM, Richard Scales <[email protected]> wrote: > > > 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 a topic in the Google > Groups "neonixie-l" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/neonixie-l/UWcm5_T2868/unsubscribe. > To unsubscribe from this group and all its topics, 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. -- 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/71930188-C736-45BB-8CEA-D71DCAADC8B2%40gmail.com.
