I do all the fading in software. Imagine you are running three faders. One 
for overall brightness, one for fading in and one for fading out. When 
you’re figuring out if a digit is one you say:

1. For static digits, if the brightness fader is on, then that digit is on, 
otherwise it is off.
2. For the digit fading in, if the brightness fader is on and the fade-in 
fader is on then the. The digit is on, otherwise it is off.
3. For the digit fading out, if the brightness fader is on and the fade-out 
fader is on then the digit is on, otherwise it is off.
4. Increment the brightness fader.
5. Adjust the fade-in fader so it is a bit brighter.
6. Adjust the fade out fader so it is a bit dimmer.

A ‘fader’ just needs to keep track of whether it is on or off. Like, for so 
many increments it is on, for a different number of increments it is off. 
It is easy to say that there are, for example, 100 increments (or ticks) 
before the cycle repeats. Then for 25% brightness you say it is on for 25 
ticks and off for 75, then you start at the beginning again. This is 
basically how PWM works, so will effectively be PWMing the tubes yourself.

The HV chip series are easily fast enough for you to do this directly from 
the microprocessor.

On Thursday, April 30, 2020 at 11:56:06 PM UTC-4, 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/2d0e8f3d-cb30-4dd7-b416-95f652ec956e%40googlegroups.com.

Reply via email to