I would also look at the suggestions for 32 bit transfers and the order of 
control over the LE signals that Paul has suggested - I will most certainly 
be doing this when I next visit my code. I know that if its not broken, one 
shouldn't try to fix it but just because I cant see that its not quite as 
it should be doesn't mean that it's right - I certainly remember when 
watching the signals on a scope - it was possible to see a subtle timing 
'glitch' between each 8 bit SPI transfer which I would expect to vanish 
when using the 32 bit approach.

- Richard


On Sunday, 26 July 2020 05:45:39 UTC+1, Owen Crawford wrote:
>
> Hi Richard,
>
> Thank you for the insight on the use of the CD40109. I've ordered a couple 
> Texas Instrument DIP versions off ebay. Once I get them I'll pursue putting 
> some SPI code together using your example you posted earlier.
> As you mentioned, at the moment I'm getting away with using 5v logic from 
> the Arduino, but maybe I won't have as much luck when moving to SPI and 
> I'll just be going around in circles trying to troubleshoot the code 
> because I'm not running the HV5622's to spec :)
>
> I did find a Nixie Arduino shield 
> <https://create.arduino.cc/projecthub/gra_and_afch/arduino-shield-ncs314-nixie-tubes-clock-in-14-20932b>
>  
> which appears to be using SPI and a CD4505BM 
> <https://www.ti.com/lit/ds/symlink/cd4504b.pdf?ts=1595736758290&ref_url=https%253A%252F%252Fwww.ti.com%252Fstore%252Fti%252Fen%252Fp%252Fproduct%252F%253Fp%253DCD4504BM>
>  
> similar 5 to 12v level shifter.
> Do you also use 10 or 100nF caps with the HV5622's VDD and CD40109 VCC to 
> ground?
>
>
>
> On Thursday, 23 July 2020 at 14:07:05 UTC+10 Richard Scales wrote:
>
>> An ESP8266 / Wemos device runs at 3v3 logic levels, the HV5622 
>> specification indicates that it likes to run at 12V logic levels so there 
>> needs to be some conversion between the two for reliable operation.
>>
>> The spec sheet for the HV5622 clearly states that the logic supply 
>> voltage should be between 10.8V and 13.2V and the logic input levels should 
>> be between supply voltage-2 and the supply voltage. Driving them with 5V 
>> logic is way out ot spec, driving with 3V3 logic even more so.
>>
>> I know that many folk run them at 5V logic and I have even had some 
>> success at 3V3 logic but that is way out of spec and there is a risk that 
>> things like manufacturing changes or cable lengths may stop things working 
>> one day. 
>>
>> I was using 2N3906 level shifter circuits until Paul Andrews put me on to 
>> the CD40109 which is a nice compact 8 way level shifter (available in DIP 
>> or surface mount)  which I have now used in several designs and would 
>> highly recommend.
>>
>> Paul, I did look briefly for the 32 bit  SPI 'command' but failed to 
>> find, I should look harder and I didn't see a way of redefining the SPI 
>> pins used :-(  I also found that moving the LE toggle from before the SPI 
>> commands to after made no difference as far as I could tell, both methods 
>> appeared to work equally well  (for me on a WeMos). I should learn more 
>> about this.
>>
>> - 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/ac441ad8-849b-41cd-9b52-21656bd7d86eo%40googlegroups.com.

Reply via email to