After many hours head scratching and fiddling with scopes and logic
analysers etc, I found the issue. Both drivers now working perfectly, daisy
chained, with bit banging or SPI. Embarrassed to say was my error on the
silk screen on the breakout board I made for the PLCC HV5530. I had
transposed DO and POL labels.
Thanks everyone for your help.
On Thursday, 27 March 2025 at 21:48:22 UTC JBro63 wrote:
> Thank you for this.
>
> I'm still getting my head around shifting bits in general so examples are
> really useful; there looks to be a lot going on here! digitalWrite(DATAPin,
> !!(_val & ((uint64_t)1 << (i))));
> I'm making two prototypes, one with only 4 IN12 tubes and 2 INS1 neons
> individually driven from an ESP32 using 4 x K155ID1 and 4 x LTV-851 plus
> one MJE340 for PWM dimming. This is complete and works well but one flaw
> is having had to scrimp on pins meaning tubes 1 & 3 will only go as high as
> 2 & 5 respectively. I intend to connect them all on V2 so will likely need
> the 74HC595 or similar.
>
> The second will have 6 IN14 tubes and 4 IN3 neons hence the 5530. Having
> dropped the frequency today, a basic blink sketch is working using SPI or
> shifting bits manually but only on the first driver. Adding a second breaks
> everything. Both drivers work ok in isolation so I think the issue here is
> with the breakout boards or breadboard joining everything together so will
> be troubleshooting this next.
>
> Thanks.
>
> On Thursday, 27 March 2025 at 11:36:54 UTC Ian Sparkes wrote:
>
>> My hint would be to stay away from SPI until you have done a bit banged
>> version. I have drivers for everything, basically, so if you need some
>> code, I'm happy to help you out. Also be careful of the implicit type
>> conversions that come with bit twiddling and shifting out.
>>
>> This is for the ESP8266 with HV5622 or 5530 drivers:
>>
>> // ************************************************************
>> // Perform the parallel shift out to the registers
>> // ************************************************************
>> IRAM_ATTR void shiftOut64(uint64_t _val) {
>> uint8_t i;
>>
>> // Top 3 digits
>> digitalWrite(LATCHPin, LOW);
>> for (i = 0 ; i < 32 ; i++) {
>> digitalWrite(DATAPin, !!(_val & ((uint64_t)1 << (i))));
>> digitalWrite(CLOCKPin, HIGH);
>> digitalWrite(CLOCKPin, LOW);
>> }
>>
>> // Bottom 3 digits
>> for (i = 0 ; i < 32 ; i++) {
>> digitalWrite(DATAPin, !!(_val & ((uint64_t)1 << (i + 32))));
>> digitalWrite(CLOCKPin, HIGH);
>> digitalWrite(CLOCKPin, LOW);
>> }
>> digitalWrite(LATCHPin, HIGH);
>> }
>>
>> // ************************************************************
>> // Perform the parallel shift out to the registers
>> // ************************************************************
>> IRAM_ATTR void shiftOut64Off() {
>> uint8_t i;
>>
>> digitalWrite(DATAPin, LOW);
>> for (i = 0; i < 64; i++) {
>> digitalWrite(CLOCKPin, HIGH);
>> digitalWrite(CLOCKPin, LOW);
>> }
>>
>> // Latch in
>> digitalWrite(LATCHPin, HIGH);
>> digitalWrite(LATCHPin, LOW);
>> }
>>
>> I kind of guess you are 74HC595s if you are using K155ID1s, so here's a
>> similar piece of code for using 595s:
>>
>> // ************************************************************
>> // Perform the parallel shift out to the registers
>> // ************************************************************
>> void IRAM_ATTR shiftOut64(uint64_t _val1) {
>> uint8_t i;
>>
>> #ifdef INVERT_595_OUTPUTS
>> uint64_t bout = ~_val1;
>> #endif
>>
>> #ifdef NORMAL_595_OUTPUTS
>> uint64_t bout = _val1;
>> #endif
>> digitalWrite(LATCHPin, LOW);
>> for (i = 0; i < 64; i++) {
>> digitalWrite(DATAPin, !!(bout & ((uint64_t)1 << (63 - i))));
>> digitalWrite(CLOCKPin, HIGH);
>> digitalWrite(CLOCKPin, LOW);
>> }
>> digitalWrite(LATCHPin, HIGH);
>> }
>>
>> // ************************************************************
>> // Perform the parallel shift out to the registers
>> // ************************************************************
>> void IRAM_ATTR shiftOut64Off() {
>> uint8_t i;
>>
>> digitalWrite(LATCHPin, LOW);
>> #ifdef INVERT_595_OUTPUTS
>> digitalWrite(DATAPin, HIGH);
>> #endif
>>
>> #ifdef NORMAL_595_OUTPUTS
>> digitalWrite(DATAPin, LOW);
>> #endif
>> digitalWrite(DATAPin, LOW);
>> for (i = 0; i < 64; i++) {
>> digitalWrite(CLOCKPin, HIGH);
>> digitalWrite(CLOCKPin, LOW);
>> }
>> digitalWrite(LATCHPin, HIGH);
>> }
>>
>>
>> Of course, you'll have to adapt to your use case, but it shows the way
>> you have to twiddle the clock and the latch pins.
>>
>> Once you have that working, you can move over to SPI if you need - I have
>> never found it necessary, because I practically always work with interrupt
>> driven displays (hence the IRAM_ATTR) in the signature.
>>
>> Hope that helps.
>>
>> On Wednesday, 26 March 2025 at 21:56:54 UTC+1 JBro63 wrote:
>>
>>> Thanks Richard.
>>>
>>> Spent most of the day on this with little progress. Was able to blank
>>> the display using SPI but unexpected results when enabling and much flicker
>>> of the LEDs evident.
>>>
>>> Out of curiosity I swapped out the ESP32 dev board for a C3 mini and
>>> also tried a ESP82666 D1 which has much improved matters. Alas, ran out of
>>> time. I'll re-visit on Friday.
>>>
>>> Thanks again.
>>>
>>> On Tuesday, 25 March 2025 at 14:24:07 UTC Richard Scales wrote:
>>>
>>>> Hello,
>>>> Firstly, the reason (and I am NO expert) for expressing it that way was
>>>> to remind me that I wanted to store data for 12 x 8 bit elements - ie. 96
>>>> bits - as that was enough bits for what I wanted to control - which - in
>>>> this case was a bunch of 7 segment panaplex displays with DPs. so,
>>>> needing
>>>> 8 bits for each character (7 x segments plus DP) I could control 12 digits.
>>>>
>>>> You could just as easily put:
>>>>
>>>> unsigned char BitArray[12];
>>>>
>>>> To write any one bit in that array I use:
>>>>
>>>> void bitArrayWrite(const unsigned int index, const boolean value)
>>>> {
>>>> if (index > 96)
>>>> return;
>>>> bitWrite(BitArray[index / 8], index % 8, value); // write the right
>>>> bit of the right char
>>>> }
>>>>
>>>> This works out which bit of which byte actually gets set. Once you have
>>>> worked out your strategy for knowing how all your display elements are
>>>> mapped to the outputs of the shift registers then you could set any one
>>>> bit
>>>> on or off as follows:
>>>>
>>>> bitArrayWrite(10,1); // set bit 10 on
>>>> bitArrayWrite(10,0); // set bit 10 off again.
>>>>
>>>> Once you have got all the bits set for the display you want then call
>>>> the SPI transfer function:
>>>>
>>>> SPI.transfer(&BitArray, sizeof(BitArray));
>>>> digitalWrite(LEpin, HIGH);
>>>> digitalWrite(LEpin, LOW);
>>>>
>>>>
>>>> If you are using 2 x HV5530 then change the 96 to 64
>>>>
>>>> Additionally, you will want to include the SPI library and have this in
>>>> void setup()
>>>>
>>>> SPI.begin();
>>>> SPI.setFrequency(10000000L);
>>>> SPI.setBitOrder(MSBFIRST);
>>>> SPI.setDataMode(SPI_MODE1);
>>>>
>>>> - Richard
>>>>
>>>> On Tuesday, 25 March 2025 at 07:37:32 UTC JBro63 wrote:
>>>>
>>>>> @gregebert
>>>>> *Are you driving the HV5530's with the correct signal levels?* I
>>>>> believe so - using a CD4504BE set to CMOS.
>>>>> *Secondly, are you giving enough dead-time before-and-after wiggling
>>>>> the clock signal ?* I'm not including any delay in code but will
>>>>> revisit the datasheet and experiment.
>>>>>
>>>>> @Richard
>>>>> Does that help? - Yes, thank you. I won't be able to check until later
>>>>> but I think I'm setting the latch low before shifting data in. I have a
>>>>> couple of queries please..
>>>>>
>>>>>
>>>>> unsigned char BitArray[96 / 8];
>>>>> What is the significance of 96/8 or is this good coding practice?
>>>>> (ChatGPT called it 'clarity of intent :)) What was the reason for
>>>>> choosing
>>>>> 12 8 bit elements? Are you able to share how you populate the array with
>>>>> data for a digit?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> On Tuesday, 25 March 2025 at 04:19:51 UTC Richard Scales wrote:
>>>>>
>>>>>> I am using SPI with multiple HV5522's (these work the same as
>>>>>> HV5530's as far as this example goes) with total success.
>>>>>>
>>>>>> The point about the 12V logic supply to these devices is based on the
>>>>>> fact that the specification clearly states that they need 12V logic and
>>>>>> whilst many have run them at 5V logic with complete success - for the
>>>>>> sake
>>>>>> of a level shifter I have always played it safe and stuck with 12V. I
>>>>>> see
>>>>>> that you are using a CD4504BE which I guess would be fine, I use
>>>>>> CD40109B
>>>>>> with total success.
>>>>>>
>>>>>> Why use SPI at all? Whilst i am no expert, simply put - instead of
>>>>>> you performing the bit bashing via Shiftout or some similar routine, the
>>>>>> SPI process leaves the job to the processor which takes the pressure off
>>>>>> your code a little - which is never a bad thing. I use Wemos Mini D1's
>>>>>> (ESP8266) so not as beefy as ESP32 and on the D1 you are restricted to
>>>>>> using only certain pins for the SPI transfer, I believe it may be
>>>>>> different
>>>>>> for the ESP32.
>>>>>>
>>>>>> When using SPI transfers I just point the SPI transfer command to the
>>>>>> buffer that contains my data and the micro does the rest. So far I have
>>>>>> driven 4 x HV55xx devices in a row transferring 128 bits in one fell
>>>>>> swoop
>>>>>> with total success.
>>>>>>
>>>>>> There is also a 'thing' about when the latch signal should be
>>>>>> toggled. My understanding is that the Latch signal should be generally
>>>>>> low
>>>>>> and when you want to latch the data to the outputs, set it High then Low
>>>>>> again.
>>>>>>
>>>>>> Here is a snip of my code for sending data out to 3 x HV55xx devices
>>>>>> in a chain, note the commented out ShiftOut commands which are all
>>>>>> replaced
>>>>>> by the single SPI.transfer command:
>>>>>>
>>>>>> // send data out
>>>>>> SPI.transfer(&BitArray, sizeof(BitArray));
>>>>>> /*
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[11]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[10]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[9]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[8]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[7]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[6]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[5]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[4]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[3]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[2]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[1]);
>>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[0]);
>>>>>>
>>>>>> */
>>>>>>
>>>>>> digitalWrite(LEpin, HIGH);
>>>>>> digitalWrite(LEpin, LOW);
>>>>>>
>>>>>>
>>>>>> Then after the data has all been sent, send the latch pin High and
>>>>>> then Low to latch the data to the output pins.
>>>>>>
>>>>>> In the above example, BitArray was defined as follows:
>>>>>>
>>>>>> unsigned char BitArray[96 / 8]; // space for 96 bits
>>>>>>
>>>>>>
>>>>>> ... so it is a char array with 12 elements.
>>>>>>
>>>>>> All signals going to the HV55xx are at 12V logic levels (CLK, DATA,
>>>>>> LATCH and POL).
>>>>>>
>>>>>> Does that help?
>>>>>>
>>>>>> - Richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tuesday, 25 March 2025 at 01:25:30 UTC gregebert wrote:
>>>>>>
>>>>>>> Are you driving the HV5530's with the correct signal levels ? Per
>>>>>>> the datasheet, they should be 0 or +12V, but many have been able to run
>>>>>>> them at TTL-levels and that can lead to intermittent problems.
>>>>>>>
>>>>>>> Secondly, are you giving enough dead-time before-and-after wiggling
>>>>>>> the clock signal ? If not, there could be a race condition, which can
>>>>>>> get
>>>>>>> worsened if not running at 12V logic levels.
>>>>>>>
>>>>>>> On Tuesday, March 25, 2025 at 4:52:13 AM UTC+7 JBro63 wrote:
>>>>>>>
>>>>>>>> Hi all.
>>>>>>>>
>>>>>>>> Ok so some progress. First PCBs have arrived and the K155ID1 IN12
>>>>>>>> based clock is almost complete. I also knocked up a very basic
>>>>>>>> breakout
>>>>>>>> board for a PLCC 44 pin socket to allow me to start testing with the
>>>>>>>> HV5530
>>>>>>>> with a breadboard and am having mixed results.
>>>>>>>>
>>>>>>>> To learn how to use the HV5530 I'm using LEDs connected to the
>>>>>>>> outputs, each with a 220 ohm resistor in series in place of the nixie
>>>>>>>> tubes
>>>>>>>> and the connections from an ESP32 go through a CD4504BE with VDD at
>>>>>>>> 12v.
>>>>>>>> The LEDs have a common +5V and the POL pin on the HV5530 is tied to
>>>>>>>> +12v
>>>>>>>>
>>>>>>>> https://reboots.g-cipher.net/time/ disusses how to write data to
>>>>>>>> the driver.
>>>>>>>>
>>>>>>>> With only a single HV5530 connected and using digitalWrite() I'm
>>>>>>>> able to blank / light all outputs reliably or target a single output.
>>>>>>>> There
>>>>>>>> is some flicker if I 'disturb' the wires on the breadboard but
>>>>>>>> otherwise
>>>>>>>> seems good. Adding a second driver (shared clock & latch pin, DO on
>>>>>>>> driver
>>>>>>>> one connected to DIN on driver two) causes all LEDs to flicker
>>>>>>>> randomly and
>>>>>>>> those on the second driver are not in the correct sequence.
>>>>>>>>
>>>>>>>> Using a separate set of pins for each driver improves things - the
>>>>>>>> LEDs on driver two light as programmed - but there is still some
>>>>>>>> flickering
>>>>>>>> evident on all LEDs.
>>>>>>>>
>>>>>>>> Is there anything obvious I can change in the above to improve
>>>>>>>> matters? I've seen several references to SPI but am 1) unsure why one
>>>>>>>> would
>>>>>>>> choose SPI over digitalWrite() and 2) it seems more difficult to
>>>>>>>> implement.
>>>>>>>> If anyone has a very simple example how to use SPI with the HV5530 and
>>>>>>>> ESP32 I would be grateful.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> On Monday, 10 March 2025 at 11:49:58 UTC JBro63 wrote:
>>>>>>>>
>>>>>>>>> Thanks Ian, that's really helpful.
>>>>>>>>>
>>>>>>>>> On Saturday, 8 March 2025 at 08:33:06 UTC Ian Sparkes wrote:
>>>>>>>>>
>>>>>>>>>> They work fine at 5V. Never had a problem with one at 5V.
>>>>>>>>>>
>>>>>>>>>> But attention: ESP uses 3V3 and you might need to use a lever
>>>>>>>>>> shifter (e.g. CD40109) to make it work.
>>>>>>>>>>
>>>>>>>>>> On Monday, 3 March 2025 at 20:39:00 UTC+1 newxito wrote:
>>>>>>>>>>
>>>>>>>>>>> I use the HV5622, which goes up to 220 V, I think there is also
>>>>>>>>>>> a PLCC version. The disadvantages are the price and that it should
>>>>>>>>>>> be
>>>>>>>>>>> operated with 12V according to spec. However, I never had any
>>>>>>>>>>> problems
>>>>>>>>>>> using the chip with 5V.
>>>>>>>>>>> JBro63 schrieb am Montag, 3. März 2025 um 19:02:56 UTC+1:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> Group noob here, about to start build on a few different types
>>>>>>>>>>>> of display using Nixie tubes and ESP32.
>>>>>>>>>>>>
>>>>>>>>>>>> Planning to use K155ID1 initially (as I have a bunch) with some
>>>>>>>>>>>> IN-12 and IN14 tubes but want to also try HV driver such as the
>>>>>>>>>>>> 5812 or
>>>>>>>>>>>> 5530 so would welcome any comment on which is the best one to go
>>>>>>>>>>>> for or an
>>>>>>>>>>>> alternative. I don't intend to multiplex. Any driver would need to
>>>>>>>>>>>> be DIP
>>>>>>>>>>>> or PLCC.
>>>>>>>>>>>>
>>>>>>>>>>>> Have spent many hours looking at the schematics and designs of
>>>>>>>>>>>> others, I'm grasping the basics but one frustration and evident
>>>>>>>>>>>> gap in my
>>>>>>>>>>>> knowledge is how to pick / calculate the correct component and its
>>>>>>>>>>>> size or
>>>>>>>>>>>> rating for anything other than the most basic circuit.
>>>>>>>>>>>>
>>>>>>>>>>>> For example, with a 180v supply, calculating the anode resistor
>>>>>>>>>>>> for a tube based on the datasheet is straight forward enough as
>>>>>>>>>>>> the
>>>>>>>>>>>> maintaining voltage and current are known.
>>>>>>>>>>>>
>>>>>>>>>>>> When looking at something like the HV5812, many seem to use a
>>>>>>>>>>>> 60 or 70V zener diode with a resistor to keep below the max for
>>>>>>>>>>>> the chip
>>>>>>>>>>>> but how do you determine the current needed for the driver, diode
>>>>>>>>>>>> and load
>>>>>>>>>>>> to be able to calculate the current limiting resistor? The diode
>>>>>>>>>>>> datasheet
>>>>>>>>>>>> is simple enough but I'm lost with the sheet for the HV5812.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>>
--
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, visit
https://groups.google.com/d/msgid/neonixie-l/81009f93-38d2-49d4-ae2c-c8ebf9ae7339n%40googlegroups.com.
