That is great news thank you. I'm starting small and building up, still reeling with excitement having just produced a square wave at 250Hz. Richard
On Sat, 2 May 2020, 11:58 Paul Andrews, <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/neonixie-l/d03aea95-0301-4ccb-9921-09468a8a28f9%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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/71930188-C736-45BB-8CEA-D71DCAADC8B2%40gmail.com > <https://groups.google.com/d/msgid/neonixie-l/71930188-C736-45BB-8CEA-D71DCAADC8B2%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CA%2B9r3s_Zq-8SfpkDWJ-JaF18zvgUx8j-KxYLQRuoRBvmOTVXEg%40mail.gmail.com.
