Sorry for the very old bump here, but I thought it relevant to post additional information for any future readers.

The voltage divider solution posed above, unfortunately, did not work as expected. I'm not sure why I had thought it was working, but when I moved to a more final build state it was clear that it was not. I had to try something else. I came to the conclusion that the parts I had were simply incompatible, approached the problem in a completely different way, and managed to solve it with confidence.

My solution was to draw the 170V directly and put it through a resistor to get the voltage down to where I needed it in the 'on' state. I then put this through a transistor in order to control it via separate pins. It goes straight to ground from there and completely bypasses the driver ICs for the Nixies. I needed high-voltage transistors, but luckily the Arduinix shield already uses one for this exact purpose internally. I simply got the part number from its spec and ordered those. This has now all been thoroughly tested and confirmed to work properly.

(This method required a lot of extra outputs, so I had to set up a port expander over I2C. But that's beyond the scope of this topic.)

Thanks, all, for the help here. Sorry again for the bump but I hope this helps anyone who comes across the topic in the future.

Grumpy: so I was supposed to leave the other resistors already in series at the same time? Nobody had mentioned that, so I took them out when I tried the 1M parallel.

dc42: Thanks a bunch! That was very helpful. Since the Arduinix board doesn't have much room for expansion and I'm not confident in building an additional power supply, I think I will use your solution. I did some calculations for the resistor values I have on hand (exactly 180K and 390K aren't among them) and found some values that work similarly.

Most importantly, I then tested it and it worked out great!

Thanks to everyone, especially dc42.

No that is impossible. You are missunderstanding something.

Perhaps you could explain further?

dc42, I agree about the voltage not being ideal, but I don't believe I have the expertise to build my own power supply right now.

Your divider solution that sounds like it has some promise. Would you mind explaining it a bit further with how you calculated it?

Thanks!

I was working with series resistance and found that to be unworkable. I hadn't considered one in parallel. (If it works I will need to seek further explanation.)

How would I determine its value? I tried a 1M in parallel and the neon went so bright I was certain it would burn out if left for long. I found with the series resistor that I couldn't just select a value in the normal way -- I suppose I could go for trial and error again.

Yeah, I didn't think parallel made sense. I'd blow the bulb out that way for sure.

You mean in parallel with instead of in series? And do I need one for each bulb?

Thank makes sense, but can it be done? The shield is good for everything else I'm doing (driving 6 tubes).

I had assumed this would be easy since the ArduiNix folks supply code on their site for using the shield directly with bulbs as clock separators, and state elsewhere on the forum that it works great. There's only a simple note about using a bigger resistor for the separators (which so far has only given me a very dim 'on' when it's large enough to blank it when 'off'). I do have a thread on the ArduiNix forum about this, but there's been no activity on the forum at all since I posted it two weeks ago.

Is this not possible? Should I try something completely different? I did assemble my shield with headers that allow me access to the Arduino pins at 0/5V, and I do have one anode from the ArduiNix at 0/170V not being used for tubes. I suppose I could route those to something different and bypass the driver ICs? Something with transistors there? Would that be better?

Where on that site is a schematic so we can tell what we are dealing with, as I said a link would be good.

http://arduinix.com/images/Main/News/2009/3.0Schematic.jpg

Where are you getting this information about 70V being the minimum you can get from the driver, it is not what the 74141 gives.

It's a direct multimeter measurement from my 170V source to one the driver pins in its 'off' state. This is without the bulb or the resistors connected.

Do you understand the fundamentals of neon lamps?

Not in depth, but I know that the 'off' state from the driver IC isn't dropping current enough to shut all the bulbs back off, which is what I want it to do. (Some do go off, but some don't.)

Since I don't have control of that leakage current, I'm trying to figure out what else could be done about it.

Thanks for the continued help.

When talking about a product please provide a link so we know what it is.

arduinix.com

Your problem seems to be with the hardware of a commercial product so it is your supplier who should answer the question.

The chip is working as intended, it's just not designed to drive these small bulbs. My question isn't about the operation of the chip at all. This chip I have is the russian equivalent of the 74141 BCD-to-decimal nixie driver. But I think that's irrelevant... the question is really about how and if I can to control a device with a smaller draw when I only have the capability to switch my input voltage from 170V to 70V. I'm only used to working with a "low" voltage of 0V.

In where and why is it not an option?

Assume we're talking about a single path here, where I can only control the voltage to be either 170V or 70V. I want the bulb to be off when the line is at 70V and on at 170V.

I've already got 200KOhm resistance on it so it lights properly at 170V. If I make that any bigger, (I've tried 1M) the voltage does drop enough to blank it at 70V, but then the bulb is too dim at the "on" voltage of 170V.

I think I've traced this to a problem with an unstable connection between the Arduino and the RTC on the I2C lines. Since that strongly suggests this is not a problem with the Arduino hardware, I'm going to consider this thread solved. It's the wrong part of the forum to discuss my project specifically.

Thanks for the help.

Hi all,

I'm building a nixie tube display using an UNO R3 and the ArduiNix shield (arduinix.com). Things are great with the shield and the nixie tubes I'm trying to drive. The shield is essentially a 170V power supply, which is switchable via the Arduino. On the 'nix shield are two driver ICs that convert BCD signal from the Arduino to one of ten pins (one for each digit in the nixie tube). The drivers control the cathodes of the tubes, so you supply 170V to the anode and then ground one of the cathodes to turn it on. That's all background, really---just how I got where I am now.

Those driver ICs have some leakage when they are supposed to shut the cathodes off. Instead of getting 0V to a pin in the 'off' state, it reads about 70V. 70V is well under the amount needed to even partially light the tubes, but I'm also trying to run some neon bulbs off these. The leakage is more than enough to light a bulb partially. Just putting a bigger resistor in there isn't an option; it works but the 'on' state then becomes very dim.

So, my question is: is there something I can do to prevent the bulbs from getting partially lit at 70V? I'd like to control the on/off state of these bulbs with the same driver IC if possible.

I thought about maybe using a transistor that only switches current on once the base goes above 100V or so, but I'm pretty new to electronics and have no idea how to go about finding one with that exact capability (or, really, if they even exist...)

Thanks!

Thanks.

I'm fairly new to the electronics side of things, so I may not be using the proper terminology. I'm describing a simple "read" from my RTC.

I'm going to do some more testing and debugging on this end. If it's evident that this isn't a problem with how the hardware is working, I'll post some diagrams and code into the proper area of the forum. I don't think this would be the right section to do that.

Okay, here's something interesting I just figured out: polling I2C is causing jitter somewhere. I'm reading data from an RTC over A4/A5. When I read it, I'm getting momentary changes on the tube output pins. If I read data more often, this "crash" happens far quicker than if I poll less often.

Clearly I need to debug what I'm getting for data from the RTC,  but it doesn't really explain the "crash" I'm getting here. Is there a known conflict with other pins when using I2C? I haven't seen it mentioned anywhere.

Thanks-- some good things to think about and clarify.

How long [does it work]?

It appears to depend how much the displayed tube is changing. Sometimes this is only a few seconds, other times it's a few minutes.

Is your code toggling that pin? If your code isn't directly changing the state of the pin, you won't really have much debug information to go on.

The code is multiplexing, so the pin should be rapidly changing state. Result is that the LED is mostly on all of the time. (When I'm describing "on" here, I'm really talking about a quick pulsing, consistent with the multiplexing I'm doing here -- not a constant on.)

(And you do have a current limiting resistor in series with that LED, right?)

Yep!

Pressing just the RESET button and getting back to normal operation, might suggest a code problem.  1) Running out of RAM.  2) not declaring variables for millis() and micros() correctly.  3) Not handling rollover of millis() and micros().  etc.

I'm happy to look into any or all of these, but it doesn't explain why the LED shows normal operation until I've got the tube in place.

How would I go about figuring out if I've run out of RAM?
Not using micros() anywhere.
All vars recording millis() are LONG. I know I'm not handling the overflows on those yet, but I thought I didn't need to worry about that for the first 9 hours or so? I was going to add my overflow handling in later.

There is a poly-fuse on the USB supply line.  However, a simple press of the Reset-button generally wouldn't reset it.  A power cycle (and sometimes a few seconds of power-down) is needed to let the polymer cool down.

Hmm. That does suggest a code problem. Not sure how attaching the tube would alter how the code was running, though? I'm not attempting to use any input here.

Nobody ever complained about someone posting their code and schematic along with their question.

My code is getting pretty complicated; perhaps I can create a reduced sketch that reproduces the problem and post that.