How do I correctly clamp the SN75468 with a zener
Luc Small
I'd like to use the SN75468 as a nixie driver in my next clock.
According to earlier posts, the key thing to ensure is that the common
pin (pin 9) is clamped to a voltage below the ic's darlington
transistor rating of 100V.
Looking at some earlier designs (some of which are based on the
similar but lower voltage rated part, the ULN2003), this clamping has
been achieved with a zener in one of two ways. I've illustrated these,
which I call options A and B, pictorially here:
http://lucsmall.com/2011/07/19/using-the-sn75468-as-a-nixie-tube-driver/
Can you tell me what the right approach to take is or, if things
aren't so cut-and-dry, the relative merits of each approach?
Here are the earlier designs to which I refer:
http://www.cathodecorner.com/nixiewatch/theory/nwrf-schem.pdf
http://web.jfet.org/nixie-1/
http://joule.bu.edu/~hazen/Nixie/
Many thanks,
Luc
David Forbes
Luc,
Circuit B guarantees that the other cathodes are pulled up to 91V by the
clamp diodes in the driver chip.
Circuit A depends on stray current flowing from the anode to the unlit
cathodes to energize the Zener diode. This current may be very small, in
the microampere region, since these cathodes are unlit. The Zener diode
therefore may be operating at a much lower voltage than 91V, resulting
in white dots or other unwanted artifacts. Depends on the Zener diode,
of course.
Short answer: B is guaranteed to work, A is try-it-and-see.
--
David Forbes, Tucson AZ
Joe Croft
flog the dying horse once more ;).
No rose colored glasses here. Except for the PDP 8E in HS, I was fortunate
enough to cut my teeth on micros. The 6800 in fact using a derivative of MDOS.
I remember the pain quite well, assembly language is fun, but I'm glad to be
using C++. Not to mention a command line less usable than CMD.EXE. Thank God
we had a batch like program, but a far cry from a bat file and, and mothing
like make or bash at our disposal. Pretty archaic, don't want to go back for
sure! I have always had a decent editor, never had to suffer the pain of
edlin or the unix version of it (ed?).
I'm just saying there are editors for programmers and there are what we get
today. I am thankful that I found a modern editor with code completion,
colorization with many of the really good features of Brief, minimal screen
real estate to scroll bars, very flexible selection tools and multiple files
showing at the same time without chewing up the screen with scroll bars for
each file.
This last week or two has taught me why folks use cmake, don't like it, but I
at least understand the reasons. I'll probably grow to like it in time.
Visual Studio is still something I would just as well do without. I rarely use
the debugger and that is the only real benefit it buys from what I see. It
chews up too much of the screen to edit 3 files at once. And yes I almost
always have two files open at once and quite often have 3 or 4 open at the
same time. My short term memory sucks. It's start up and shut down times are
way too slow as well!
Vi is a great little editor for when you want to make a quick change or a
whole bunch of like changes. I can't code with it though, not for long. It
wears me out, though I have seen others who did wonders with it, just a quick
as anyone.
My point is, there are many good tools out there which are not IDEs and are a
far cry from "programming with a magnetic needle and a steady hand".
For the AVR I find that my editor and a good make file is all one needs for a
decent development world. I wish I had a debugger once in a great while, but
it is rare. They can always tell me where I am and where I am going, but they
never tell me how I reached my break point .
I do use a bash script for programming my AVRs in bulk, but that is more a
manufacturing environment than a development one.
-joe
Luc Small
Many thanks for your very informative answer. Now that my SN75468's
have arrived from element14, I look forward to experimenting with
circuit B!
Regards,
Luc