General question on calculating resistor sizes

[JBro63]

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.

[newxito]

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. 

[gregebert]

Similar here, except I use the HV5530 which is rated for 300V. I strongly discourage using zener diodes, or the nixie-tube itself, to drop-down the voltage to CMOS parts, because even the tiniest amount of leakage thru the diode/nixie will cause the voltage drop to be less than expected, and overstress the CMOS device. You could use an appropriately-sized bleeder resistor to ground, but it's still not rock-solid. Another approach is to use a zener as a clamp at each output but that is wasteful because it requires 1 zener per pin.

On the other hand, if you are using bipolar parts, such as NPN transistors or 7400-series TTL parts, exceeding the voltage is OK as long as the current is limited to a few uA or less. Bipolar devices do not have oxide-insulated structures like CMOS, so they are not inherently destroyed by over-voltage.

[Ian Sparkes]

I started using ULN series devices during the supply chain problems after Covid and won't be going back. Many "specialist" parts were not in stock and so I decided to use "jelly bean" parts with multiple suppliers. A driver circuit with ULN2003 or ULN2008 with appropriate clamping works well. I clamp to 68V, and while this is above the specification for the ULN device, I have still to see a single failure after many hundred units sold.

Many people think that because you have 170V or whatever across the tube that the driver has to stand this. This is not right. The tube digit has two modes: off or on. When the digit is off, there is practically no potential across driver because there is no current flowing. When it is on, you're pulling the cathode to ground and it has practically no potential across the driver.

The reason that the above statement is not quite true and the reason therefore for the clamp is to sink parasitic currents between a lit digit and the unlit ones. If you don't do this, you can get way out of spec voltages at the cathodes and this causes the output stage on the driver to break down and let the tiny currents through. It rarely breaks the device, but the display is "foggy".

The principle for the HV5812 is the same. In this case you have to take the VPP pin to some voltage that will not cause the digit to fire, but will also drop the parasitic current via the body diode of the top MOSFET in the output stage to VPP. The red is the path when the digit is on, the green is the path for the parasitic current to VPP when the digit is off.

I've seen people just using a potential divider for the derivation of VPP, but I think I would prefer a Zener clamp. 

Having said all that, if you want a direct drive and don't want to go full design nerd, the HV5622 and HV5530 drivers are dead easy to use and give good results with little effort.

[Ian Sparkes]

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.

[gregebert]

All good, though the ULN parts are bipolar devices, so there should not be any fear of them getting damaged by over voltage, unless it's an extreme over voltage that punctures the field oxide (way, WAY thicker than gate oxide in MOS devices).

The 2 diodes on the HV series parts  (CMOS) are actually parasitic devices that are part of how the IC is manufactured. They provide ESD protection as long as there is some sort of path between VPP and GND, and they will protect you from inductive loads, though I don't expect a lot of Ldi/dt on those parts because they are rather low current compared to the ULN devices.

I think a zener clamp on VPP is a good idea because it will rapidly bleed-off any excess voltage better than resistors. However, the zener wont bleed-off voltage to zero so I usually put a 1-10Meg resistor across them. On my clocks I put bleeder resistors from every power supply to chassis GND to protect from any potential ESD and to ensure every supply gets fully discharged when powered-off, and stays fully discharged. I've only had 1 Raspberry Pi fail, presumably from ESD, because it had an unknown history from the person who gave me several of them.

[Ian Sparkes]

All good points.

"The 2 diodes on the HV series parts  (CMOS) are actually parasitic devices that are part of how the IC is manufactured."

That's part of the reason I give the HV5812 the hairy eyeball. At least in the ULN the diode is there as part of the design, specifically for inductive loads. I *know* it's going to be OK, but... I'm probably retrofitting a justification to a decision I made for other reasons: I'm a cheapskate and I can get the ULNs from a dozen competing suppliers.

:D

[JBro63]

Thanks Ian, that's really helpful.

[JBro63]

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

[gregebert]

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.

[Richard Scales]

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

[JBro63]

@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.

[Richard Scales]

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

[JBro63]

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.

[Ian Sparkes]

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.

[JBro63]

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.

[JBro63]

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.