Questions from a Nixie newbie (raspberryPI project)

[Nobutaka]

Hello people. 

I recently discovered the Nixies, and instantly falled in love.

I decided to make my first Nixie clock, so I bought 6 IN-18 Nixies, a Nixie tester/Healer from fleabay and a Nixie clock kit from PV Electronics.

The idea is to quickly build a Nixie clock (I've gotta have one!) so that I can start toying around with the Nixies.

At the same time I would like to design my own clock device, so I already started to devour information about Nixies, and then, oh man, is when questions arise.

First I will try to explain my objectives and backgrounds, and I will leave the questions to the end.

I plan designing a clock:

• using IN-18 tubes (the largest that I know of, if you don't take into account the ones made by Dalibor, which are unfortunately out of my reach).
  
• using a RasberryPI to control everything, including NTP time synchronisation and even creating a web-based configurator for the clock. I feel very confident using linux and C/C++ as I use them (not R-PIs) on a daily basis.
• Nixie tube lifespan is an absolute priority. I would like to design the watch so that it wouldn't require periodical tube changes, as they are very valuable and getting harder to source.

I studied electronics in university (20 years ago) and since then I basically worked with computers (banking, nothing to do with electronics), but I liked very much electronics (digital electronics better), and I thought doing Nixie projects could something cool and rewarding.

So, after some reading, I got some questions:

• Direct drive or multiplexing? Multiplexing seems to be the most common solution; it uses lower power consumption, but on the other side some people complain about 'noises' and  nixie flickering. Direct power supply means more power consumption and brighter Nixies, but lifespan should be reduced as well, so I think my design should use multiplexing too. I think this is an eternal debate in these forums that now I will have to face too. I think multiplexing/direct drive is not as important as...
• power supply? For what I read, even though IN-18 are rated to be cathode powered with 180V, some recommend lower voltage ratings (170V or even 160V) in order to improve lifespan. Also there seems to be a dramatically importance in the mA constantly supplied by the power source.  For what I could learn, an insuffient power supply that could not provide a stable amperage, would lead Nixies to cathode poisoning problems. I would like to control the powersource voltage from the raspberry (to increase/reduce voltage to make the Nixie brigther/dimmer), any hints on where to start looking would be appreciated.
• Other big size Nixie recommendations? As I found trouble finding IN-18, maybe there is a better Nixie alternative, specially if I want to test and abuse the nixies. Something that can be easily found and that is not going to have supply shortage in the near future...

I hope my questions don't offend anyone. I tried to answer them by myself but got a bit stuck here.

[Tomasz Kowalczyk]

Direct drive or multiplexing - I would vote for direct drive. It is just simpler to control, as you need to set the GPIOs only once a second.

As far as I 've heard, controlling GPIO of a RPI is problematic, so you could use shift registers or I2C I/O expanders. With those you aren't really limited when it comes to amount of pins used.

The main advantage of multiplexing is less pins needed to control the tubes. With 6 tubes you need at least 60 outputs for direct drive and only 16 for multiplexing.

Also, I do not know if RPI has timers working in same way as they work on standard microcontrollers, and executing the multiplexing routine is critical for non-flickering display.

Both displays can achieve same brightness. In real designs, multiplexed displays used higher current per tube to achieve an average current similar to direct driven tube. Most hobbyists tend to use lower currents in hope of increasing lifespan of a tube, however I'd advise to stay over the minimum current, if it is provided in the datasheet.

Power supply - the problems with IN-18 and infamous blue spots do not come from the power supply voltage itself. 180V is perfectly fine as long as you use decend high voltage cathode switchers (Supertex HV shift registers, MMBTA42s or other 200+V transistors). Stay away from 74141 or their soviet counterpart. These devices are poorly constructed, consume alot of power compared to modern ICs and are old - no one guarantees that they will work after so many years. Poor transistor technology from these years is the reason why people are having troubles with blue spots.

I do not know how the voltage can decrease life of the tube - you still need a current limiting resistor. Tubes die faster from incorrect current (peak and average).

RPI doesn't have its own analog to digital converter. This means you cannot directly check the voltage at the output without an external ADC. I suggest using a standalone power supply unit, preferably with an Enable pin, so you could make some power saving routines.

Other big nixies - within similar price range, Z566M/Z5660M. Very beauftiful, with thin and sharp digits. Durable, with long life time. Still avaible on the market in reasonable amounts, so getting a spare tube shouldn't be a big problem*.  Datasheet has clear information about minimum average current, maximum average current and peak current per cathode. It also uses a more popular socket. 

*of course, no tube will be ever as avaible as russian tubes - Soviets produced alot more than needed ;) 

BTW. I've started my journey with ESP8266 very recently and I'm a newbie to the NTP topic. How often can I check the time at a server to be not considered a spammer? Is once per hour okay?

[Paul Andrews]

One quick point: Nixie tubes are current driven. It is important to keep the current within the limits defined for the tube. The voltage just has to be large enough to initiate the glow. It is typically somewhat larger so that a suitable current-limiting resistor can be put in series with the anode and still have enough potential to initiate and maintain the glow. Using a higher voltage and s higher resistor value allows for a more stable current, given variations in output voltage.

A number (cathode) is lit by pulling it to ground so the current can flow. Other cathodes are either left floating or pushed up to a high enough voltage to stop the flow of current, e.g. 75V

To control the brightness, you need to switch the current on and off quickly. This is typically done using some kind of PWM of whatever is controlling current flow.

If you still want a power supply that allows you to control the voltage from software, I recommend the Taylor HVPS power supplies, or you can incorporate my design if you want to build it from scratch (it also allows voltage control from software) http://www.nixies.us/projects/nixie-tube-power-supply/

Good luck!

[Paul Andrews]

Also, I would recommend using IN-12 tubes for experimentation. They are cheap and very tolerant. I have breadboard adapters for both them and IN-18 (and more) that you can buy from OSHPark: http://www.nixies.us/resources/resources/

[gregebert]

My 8-tube b7971 clock is powered by a RasPi; I posted a video several months ago before I built the case.

Using the WiringPi library, you can get decent GPIO speeds; I've measured about 2Mbits/sec when serialized completely by software.

The problem is that the Pi runs Linux, so there are random time-slices the OS needs for housekeeping, so there will occasionally be gaps of a few milliseconds.

For a clock, this shouldn't matter. This particular clock stores the segment data in a shift-register, and the Pi serializes the bit stream for 8 tubes * 16 bits/tube = 128 bits total.

I update the time every second, and I've never observed any display glitches.

Why use a RasPi ? Many reasons.

• 10USD cost. OK, yeah, that doesn't include a 4GB micro-SD card or a power supply
• Onboard WiFi, which means you can update software without opening-up or moving the clock. Just login and patch.
• Full goodness of Linux, and the zillions of apps you can install
• Remote access via VNC
• Low power
• No need to set the time - Automatically obtains it from your network (unless your network or internet service goes down)

As long as you are aware of the pitfalls of a RasPi, you can easily work around them. In a few years I will find out if the  OS causes the micro SD card to 'wear-out' , or if my clock gets hacked by a cyber terrorist.

https://www.youtube.com/watch?v=OjQeW67viXw

[Paul Andrews]

That’s a monster clock Greg! We can’t even see you standing next to it for scale ;-)

I’m just waiting for the day a cyber terrorist tries to hack in to my networked clocks :-)

--
You received this message because you are subscribed to a topic in the Google Groups "neonixie-l" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/neonixie-l/WIK2UWjMHPI/unsubscribe.
To unsubscribe from this group and all its topics, 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/0c50a801-a80f-4b3c-8d04-8590764b72bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gregebert]

I can see it now...

     cyber terrorists hack into our clocks and cause cathode-poisoning, microSD wearout, obscene messages, inaccurate time

Admittedly, I've put on a few pounds since my college days so the clock might not look so big if I stood next to it    :< (

My only wish is that there was some kind of magic nixie tube that could display each ASCII character in full-form like the traditional non-segmented 0-9 tubes.

The 7971's are not beauties, but they are just so enormous I could not resist.

I have a 6-tube NIMO clock in development, and it is RasPi controlled as well. No pictures or boards yet, but lots of schematics, RTL code, and simulation waveforms.

After that comes the electroluminescent clock (also to be RasPi). Jumbo IEL displays about the size of 7971s with weird segment layout for cryllic symbols. See link below; the units I have are pictured on the far right. 

http://www.155la3.ru/electroluminescent.htm

[Nobutaka]

Assuming my nixie clock won't be hacked by cyberterrorist, and that the RPI isn't affected by the Intel-gate (LOL), I continue my investigation.

In order to increase the lifespan of the Nixies, I would like to include a 'cathode poisoning' prevention routine. People usually refer at it as the 'jackpot machine'....

What would be (the idea) of such an algorithm and what time would it be necessary to be doing this. I guess at night I could just simply switch it off, or maybe increase the frequency of this anti-poisoning prevention routines. I know the ideal is to use all the digits the same amount of time, but if using a 12 hour time, or a 24 hour time, the digit indicating the tens of hours will be always off, marking 1, or 2 (for example)... 

Any advice on this point?

[Paul Andrews]

The idea is that the tubes are run at full brightness for a while, every so often to drive off deposits from the cathodes.

I haven’t seen any experimental results indicating how successful this is. However I have certainly witnessed complete glow coverage being restored when cathodes are driven at a greater than normal current (in the space of minutes), so there might be something to it.

--

You received this message because you are subscribed to a topic in the Google Groups "neonixie-l" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/neonixie-l/WIK2UWjMHPI/unsubscribe.
To unsubscribe from this group and all its topics, 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/130f2c0e-53c4-429c-afff-84b76c2894dc%40googlegroups.com.

[gregebert]

My 18-tube IN-18 clock has been running for over 2 years now; the date is displayed on 8 tubes in MM.DD.YYYY format, and those are basically static. Time is on the other 6 in HH:MM:SS format, so not all of them are fully cycled. Each night, at 11PM, the clock does a depoisoning routine for 1 hour, then shuts off. In the morning, if we want the clock on, there's an ON button I made from a 'Tomorrowland' souvenir pin. This clock was inspired by the IN-18 clocks in the 2015 movie.

• all tubes that are cycled 0-9 multiple times during the day are simply shut off
  
• all tubes that cycle 0-6 multiple times during the day are cycled 6-9 for 1 hour.
• all tubes that are static during the day are cycled 0-9. I should have put some smarts in the FPGA code to skip the digit that was displayed that day

So far, no tubes show abnormalities. One tube has a slight dark region at the very bottom of a few digits, and I've been watching that very carefully fir the past 6 months. So far, it's not degrading any further. Someday I will retrofit out the FPGA and replace it with a RasPi, and fix the depoisoning routine and add a PIR sensor. Yeah, someday.....

The RasPi-based 7971 clock uses a PIR sensor, so it's mostly off except when I turn over in my sleep or walk into the room. I do plan log the runtime for each segment of each tube, down to the second, and balance-out the usage. I know it's overkill but I like the programming challenge.

My big clock (pictured in my google icon) has been up for over 4 years, and has static display on the tubes with no depoisonong. 2 have died, and it took awhile to depoison a third one.

[Nobutaka]

Thank you for sharing this explicit info.

Are you the person that explained how to depoison a Nixie by running a higher-than-normal amperage current during several hours? I had a Nixie-reading overdose so I remember the facts but not the authors :-(

I didn't buy the PIR sensor of the PV Electronics kit because I didn't find any real-size picture of the sensor, and it looked quite big (and aesthetically ugly). At least I couldn't imagine any way to have the PIR sensor concealed anywhere... However I would like to include one somehow in my RPI clock because I think it would very important for the tubes lifespan.

[gregebert]

I cant take credit for depoisoning; lots of collective experience from this group and we all chip-in what we learn.

I've had minimal success running at high current to depoison a dirty tube. But, why not try it ? You have nothing to lose.

• Some tubes just wear-out or leak. I have several Burroughs 5031's that simply wont improve.
• Some tubes just dont seem to die. I have yet to see a 5092 die in any of my clocks (6 years * 4 clocks * 6 tubes = 0 failures)
• Some tubes will wear-out if you display a single character 24/7 [A very bad thing to do; but that clock looks so cool...] I've lost 2 Burroughs 6091's, and partially rejuvenated a third tube.
• Some tubes fail in a different manner. I've had bad experiences with cathodes of IN-1's shorting internally with metal whiskers. Others have not.
• When all else fails, there always the microwave oven:  https://www.youtube.com/watch?v=AYUMy0P560k

The PIR sensors have an ugly hemispherical dome, roughly 5/8" diameter. Looks like the eyeball of gigantic house-fly. But they will protect your expensive tubes.

[Terry S]

I have an early Pete Hand FLW clock, to which I added the PIR sensor. It's actually positioned outside the acrylic case, along side the feet. Very inconspicuous. Since it's essentially black in color, you will not notice it until you look for it. I don't even think it's visible in this picture:

https://www.flickr.com/photos/32165280@N02/6327922052/in/album-72157628062875880/

I'd have preferred to have placed it inside the case, below the PCB, but it did not function thru the plastic. Drilling a hole would have made it very conspicuous.

It does seem to activate the clock from about 20 feet away.

Terry

[newxito]

Explicit "random" word generator :-)

[Paul Andrews]

You could try this instead of a PIR: rcwl-0516. It works through some materials.

[Terry S]

Yes.... unfortunate timing on my part.

[Paul Andrews]

On Thursday, January 4, 2018 at 6:22:45 AM UTC-5, Tomasz Kowalczyk wrote:

...SNIP...

 

BTW. I've started my journey with ESP8266 very recently and I'm a newbie to the NTP topic. How often can I check the time at a server to be not considered a spammer? Is once per hour okay?

Hi Tomasz,

I recently came across this code for using NTP: https://github.com/victor-chew/espclock/blob/master/espclock.ino

It uses WiFiManager to set up the connection from the ESP to a router (I strongly recommend WiFiManager, Actually I use ASyncWifiManager because I use the ASyncTCP libraries). In doing so, it gets the user's location from the browser and then uses google's location APIs to get the timezone data. The net result is that it uses NTP to get UTC time, and then automatically adjusts it for the timezone/DST in the user's location.

It looks like the user can override the location if they want to.

- Paul 

[Paul Andrews]

Just tried this approach. It was a bit of a saga:

1. The google maps API insists on using SSL.
2. To use SSL I had to upagrade to the latest esp8266 arduino code (2.4.0).
3. I ran out of heap trying to connect.

So back to my current solution which involves calling out to my own web server. I guess I could get that to proxy for google maps...

[Paolo Cravero]

 

It uses WiFiManager to set up the connection from the ESP to a router (I strongly recommend WiFiManager, Actually I use ASyncWifiManager because I use the ASyncTCP libraries). In doing so, it gets the user's location from the browser and then uses google's location APIs to get the timezone data. The net result is that it uses NTP to get UTC time, and then automatically adjusts it for the timezone/DST in the user's location.

It looks like the user can override the location if they want to.

For a product to be sold I would not rely on public and free APIs exposed from a single vendor, since they are always subject to change (or disappear). How would you deal with those changes once your devices are deployed around the world?!

Different story if you're implementing on a Linux-based system like the Raspberry PI, that will then use the embedded NTP daemon "ntpd" to keep the clock in sync and also take care or clock skew/drift over time. NTP is a worldwide standard part of the Internet infrastructure, and won't go away.

As for DST switching I went for a static way, hoping that governments won't change the rules (but that's more bodies that have to agree rather than a single business whose name begins with G). In just 100 bytes of static memory I hardcoded DST switchover days for the next 100 years (up to 2116). Explained here http://ik1zyw.blogspot.it/2016/10/cheating-on-dst-calculation.html and here http://ik1zyw.blogspot.it/2016/10/100-years-of-dst-dates-for-europe-2016.html you've got the resulting array for Western Europe and the Perl script used to generate it.

BTW, the code of espclock linked above checks the time every 90 seconds, which is way too often! Unless you're running some mission critical application out of your clock, once a day is enough.

Paolo

[Paul Andrews]

Unfortunately my experience with governments changing time zone data is that it changes pretty frequently too. Three times in 2017 and ten times in 2016 for example (http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html). That is way more often than the rate at which google’s map API changes.

Even the raspberry pi solution would require updates to be applied to keep up with this.

I am still waiting for the standards world to come up with a solution to this, in the meantime we all have to figure which trade offs are worth it. For example I am a big fan of browser-based control solutions for my clocks, but browsers change too.

[Paul Andrews]

An interesting read (I think): https://data.iana.org/time-zones/tz-link.html

[gregebert]

I just logged into my RasPi-based clock this morning, and got some runtime info:

After running for 55 days, the software has used only 17 minutes of CPU time, which is roughly 0.02%

Notice that the load "spiked" to 0.37 when I logged-in and created a window. Typically, the load is almost zero.

greg@rpi0w002:~ $ uptime

 08:55:38 up 55 days, 20:10,  1 user,  load average: 0.37, 0.14, 0.03

greg@rpi0w002:~ $ ps -elf | grep raspi

4 S greg       393   376  0  80   0 -   474 wait    2017 ?        00:00:00 /bin/sh -c /proj1/pigpio_b7971clk/src/raspi0w_b7971

0 S greg       396   393  0  80   0 -   737 hrtime  2017 ?        00:17:33 /proj1/pigpio_b7971clk/src/raspi0w_b7971