Help with HV5622 drivers

[Luka C]

Hi everyone,

I have made a prototype of my nixie clock using HV5622 nixie drivers, 2 of them chaned (DATAOUT of first one connected to DATAIN of the second one). They're both clocked trough the same pulse and also both latched trough the same pulse.
The problem I'm dealing with now is the appearance of random numbers while the data shifts to the register at higher speeds, please take a look here: https://youtu.be/QHljLFrYjss  .
The video was slowed down 50% for you to actually see these glithces.

Now, this is an extremely annoying problem when I do a code that looks like:

void loop
{
   FreezeLatch();
   ShiftDataToHV5622(x, y, z, q);
   ShiftDataToHV5622(x, y, z, q);
   UnfreezeLatch();
}

if I add a delay of >100ms

void loop
{
   FreezeLatch();
   ShiftDataToHV5622(x, y, z, q);
   ShiftDataToHV5622(x, y, z, q);
   UnfreezeLatch();
   delay(100);
}

x, y, z, q - bytes of data

Then I have a situation where the occurrence appears to be pretty rare. Also, if I do both shifts once and don't loop it, it either makes the glitch and stays that way or it doesn't and tubes continue to display normal digits.

Now, for me it pretty much seems to be a problem in which data is incorrectly placed inside the shift registers of HV5622 quite randomly and it causes the outputs of the HV5622 to connect multiple digits and light them up.

This is how everything is connected:

Now, I guess there could be 2 possible problems:

1.) Level shifters are too slow, I'm this type and it could be too slow (TTL): http://obrazki.elektroda.pl/4179751000_1362756714.png

2.) Level shifters output possibly not compliant with CMOS inputs of the HV5622?

What do you think, what are the possible solutions? An IC level shifter of some kind?

Anyway, sorry for the longer post here, would be very thankful for any help.

PS. thanks a lot for the previous advice on power supply, it works like a charm! :)

Luka

[gregebert]

Problems that occur or worsen at higher speeds, and disappear at lower speeds, are usually data-setup-time problems.

On the other-hand, if the problem persists at all speeds, it's a hold-time problem.

As you pointed-out, the level-shifters are slow, so that is another clue.

Have you sketched-out the data and clock paths to the first HV device and analyzed the timing ?

[Luka C]

Thanks for your reply.

I see from the datasheet that data setup time is 25ns and data hold time is 10ns.
I have tried the following:

1. Put clock HIGH
2. Put one bit on the DATA line
3. Wait for 5 microseconds
4. Put clock LOW
5. Wait for 5 microseconds

and repeat the steps again.

At the end of the these cycles, I put latch HIGH, wait for 5 microseconds and put latch LOW.

Then I removed the other delay which was in the main loop and these random flickers started happening like crazy. I guess it should indicate that the time it takes the level shifting circuit to move from HIGH/LOW or LOW/HIGH state is too long, which then shortens the time these impulses stay still on the inputs of the HV5622 and that causes undesired random sequences of bits ending in the register and being moved to the output of the chip? If so, do you think this might be a good level shifter between the Atmega328 and HV5622: http://www.onsemi.com/pub_link/Collateral/MC14504B-D.PDF ?

 

[Spencer W]

I had the same issue with the HV522PJ (which I believe is the same chip but just shifts counter clockwise) with flickering when updating the display.

I found I had to pull OE LOW when updating and HIGH when finished.

Sent from my Verizon Wireless 4G LTE smartphone

--
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 neonixie-l+...@googlegroups.com.
To post to this group, send email to neoni...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/70facb89-8730-4cc7-9cef-a8d1aa0c99b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luka C]

@Spencer

Indeed that probably was the case with your clock because the HV5222 has OE that can either turn all the outputs LOW or push the data from the shift register to them from what I saw in the datasheet, but HV5622 has no such function, the only thing it has is LE (latch) and BL (blank). Correct me if I'm wrong.

[Spencer]

Whoops! All the similar sounding part numbers got me mixed up!

To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/7a107c28-0c2c-4d81-99c9-050f13c92f61%40googlegroups.com.

[gregebert]

With the timing described above, and using the MC14504 for level-translation, you will have plenty of setup margin. Now, it's possible you have a hold-time problem into the second HV5622 device because the 10nsec hold-time requirement. On my design (2 cascaded HV5530's), I have separate clock lines and I sequence them such that the second HV5530 is clocked before the preceding one.

If your design is on a PCB, you cant easily separate the clock lines. But you CAN put some capacitance on the DATAOUT signal from the first device going into the second HV5622. This is not a clean way to solve the problem, but it may suffice. I'd try about 50pF and see if it helps. If you have a scope you can look at the clock vs data timing.

If that doesn't solve the problem, you could also have a noise problem. Is your power-supply bypassed close to the HV5622, ideally a 0.1uF cap for each ?

[gregebert]

I took another look at the level-translator circuit, and I noticed there is a resistive pulldown (10K). This could be the problem, but without any scope traces I cant be certain. You could do a SPICE simulation and get a decent idea what the timing is.

The CLK on the HV5622 is falling-edge, and with a resistive pulldown it will have a slow edge-rate. The datasheet does not specify an input-capacitance, but it's probably around 10pF. With two HV5622 devices and the 10K pulldown, the time-constant is on the order of 200nsec. I've seen two kinds of timing problems with slow edge-rates.

1. Noise susceptibility. With a slow clock-edge, any noise that occurs while the clock is near the threshold point can cause an extra clock edge (ie, a glitch).

2. Timing-skew. Each component will have a slightly different threshold voltage (the point where it distinguishes a '1' from a '0'). With a slow clock-edge, the difference in threshold-voltage (dv) causes a timing-difference (dt). A slow clock-edge has a low dv/dt, and you can actually calculate the timing-uncertainty if you know the variation in threshold voltage. The risk here is that the first HV5622 clocks slightly 'early', and the second one clocks slightly 'late'. If that happens, the serial data being shifted will skip a bit. This is a hold-time violation and also called 'shoot-thru'.

One option as you said is to use an IC level-translator. A possible quick-and-dirty option is to change the circuit so it uses an NPN pulldown, rather than a resistor. If you go that route, you should change the PNP pullup to a resistor unless you carefully simulate the circuit and optimize the design. If you dont optimize, you will get 'crowbar' current between the +12V supply and GND while both transistors are on, and that will create tons of noise at the worst possible time -- when your clock is changing. (Trust me, I've designed I/O pads on ICs before....).

You should be able to get-by with a slow rising-edge on the clock line (remember: the HVxxx device is using the falling-edge, not the rising edge) as long as you dont have any noise. Any significant noise will cause another clock-glitch.

The other signals (LE, DATA) dont need "clean" edges as long as you provide enough setup and hold margin, so you can keep the level-shifter as-is for these signals.

[Luka C]

@greg

Well, I inspected the power line to the HV5622 with the oscilloscope and it shows a straight 12V line, no noises. On the clock line, I do sometimes see to have longer rise so it could be a problem I guess.
I have made the second version of the board with 4505 level shifter, both Vcc and Vdd on it decoupled and separated the clock lines so I guess it should work as expected this time?
Also, since I'm directly driving the tubes and HV5622 gives around 60V on the inactive cathodes, the anode switching circuits shouldn't be needed to blank the tube?

[gregebert]

With separate clock lines, you can eliminate the timing problem between cascaded HVxxxx devices. I attached the timing I use for my clock (havn't had a chance to test it yet; the boards just left the PCB vendor... yes I'm getting anxious to try it out!). 

If you are using direct-drive, there's no need to tie the 'off' cathodes to any voltage; they basically 'float' when they are off. All anodes can stay energized. My projects are not cost-sensitive, so I always use direct-drive. Heck, when I spend hundreds of USD on tubes I'm not going to quibble about a few extra dollars for direct-drive.

Multiplexing, though, is a different story. I've seen designs that tie 'off' cathodes to 1/2 the anode-supply, and there have been a few postings in this forum about ghosting, etc with multiplexing. I have reliability concerns about having to pump additional current when multiplexing in order to get proper brightness.

The exact voltage the cathodes float-to has been debated; my contention is that you can't accurately measure it without a high-impedance meter (> 1Gig ohm), so assume the cathode floats up to the anode supply voltage. Fluke Instruments has some appnotes about 'ghost voltages' that can only be measured with high impedance meters. If your driver device is not rated for the full anode-voltage, it could be risky:

• If your driver is a discrete bipolar device (ie, NPN or PNP transistor), there's little or no risk exceeding the BVceo rating as long as you limit the current. Stated another way, even if there are high 'ghost voltages', no worries. 
• If your driver is a MOSFET, be very careful. The primary breakdown mechanism is thru the gate-oxide, and that is destructive at any current. Always select a device rated higher than your anode supply.
• If your driver is an IC, play it safe and assume it's a MOS device which means dont use a device rated below the anode supply voltage. Even if it's an IC that uses all bioplar circuitry, it's risky because geometries are small and you have no idea what limitations are lurking without closely reviewing the entire layout of the chip. I've seen too many cases where experienced chip designers miss high-voltage or ESD hazards, and the chip has to be redesigned.
  

[JohnK]

re Hi-z meters.

A useful measurement technique is to provide a variable voltage approximating the voltage that you wish to measure.

eg Potentiometer across a bench supply, with a common to the circuit under test..

You connect you meter between the point to be measured in the circuit under test and the variable voltage - adjust the voltage for a zero reading on your meter. THEN measure the value of the variable voltage - it equals the one in the circuit.

[Because there is near-zero volts across your already-high resistance/impedance meter, the load on the circuit is extremely small.]

 

(or, if you are a valve freak, build an electrometer with one of the special valves that are available. )

 

John K

[and if you tube-guys don't know what valves are it is your own fault  :-0   We valve-guys are expected to know what tubes are. ]

 

----- Original Message -----

From: gregebert

To: neonixie-l

Sent: Tuesday, November 03, 2015 5:28 PM

Subject: [neonixie-l] Re: Help with HV5622 drivers

...clip....

The exact voltage the cathodes float-to has been debated; my contention is that you can't accurately measure it without a high-impedance meter (> 1Gig ohm), so assume the cathode floats up to the anode supply voltage. Fluke Instruments has some appnotes about 'ghost voltages' that can only be measured with high impedance meters. If your driver device is not rated for the full anode-voltage, it could be risky:

• If your driver is a discrete bipolar device (ie, NPN or PNP transistor), there's little or no risk exceeding the BVceo rating as long as you limit the current. Stated another way, even if there are high 'ghost voltages', no worries. 
• If your driver is a MOSFET, be very careful. The primary breakdown mechanism is thru the gate-oxide, and that is destructive at any current. Always select a device rated higher than your anode supply.
• If your driver is an IC, play it safe and assume it's a MOS device which means dont use a device rated below the anode supply voltage. Even if it's an IC that uses all bioplar circuitry, it's risky because geometries are small and you have no idea what limitations are lurking without closely reviewing the entire layout of the chip. I've seen too many cases where experienced chip designers miss high-voltage or ESD hazards, and the chip has to be redesigned.
  

--
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 neonixie-l+...@googlegroups.com.
To post to this group, send email to neoni...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/920ec50b-bfa7-485f-9a71-6395019e8347%40googlegroups.com.