Raspberry PI controlled Nixie display

[okniew]

Hello everyone!

 

I’m new to this group and this is my first post.

I’m looking forward to design & build a particular project with Nixie display, but since I’m really not an expert and just starting, I would very much appreciate your help & feedback. I do have some specific questions (in the end), but if you look at project goal & design principles and think of better way to do things – please comment as well!

 

Project goals:

A Raspberry PI controlled Nixie display, with some additional LED indicators for weather conditions. Nixie display will be used to display the time or temperature or humidity, depending on settings.

Main assumptions:

1. 6 lamps: IN-19V ("+"/"-"), 4 x IN-14 ("0" - "9" + 2 dots), IN-19A ("C"/"%")

2. Ability to control Nixie brightness (by Raspberry PI)

3. LED RGB back-light under each tube, with color & brightness controlled (by Raspberry PI)

The look I want to achieve:

 

Design principles:

1. As much as possible – use the components available on the market. I’d like to avoid designing PCBs, avoid designing custom circuits, minimize soldering, etc. I understand I’ll have to do those things to some extent, but being a newbie, I want to minimize room for failure or issues.

2. A single visible power supply for the whole thing, from 230V AC outlet, driving all 6 nixies (180V, 30mA), Raspberry (5V, 3A) and the LEDs.

3. All components should be ideally driven by Raspberry I2C bus interface, using which I could control separately: displayed value of each tube, brightness of each tube, color & brightness of each LED. I think this is the easiest and most versatile approach (but again – looking for confirmation / other suggestions)

 

Questions to start with:

1. Are there any available to be purchased components, which you could recommend, fulfilling above design principles & goals? Right now, I have the Raspberry & the tubes, but nothing “in between” J

2. Do you think my idea of controlling all components via I2C bus is a good idea? I want to go for the easiest and most versatile approach.

3. Are there anywhere existing sockets for IN-14 / IN-19 tubes? Or will I have to solder to tubes to whatever components I select?

 

Thanks a lot for your help!

[Nick]

The following may be useful:

http://www.instructables.com/id/Nixie-Driver-HAT/ 

https://www.kickstarter.com/projects/36162341/raspberry-pi-nixie-tube-driver/description 

There are others out there too...

I use RPis all over the place - several as media clients running max2play,  some running IP cams and DNS, some with valve/tube hats as headphone amps...

...but I don;t have any running nixies (yet)! One thing that may simplify matters is to supply the Pi's power from the hat as the hat will be consuming most and you can power it through the GPIO connector, thus meaning you only need one PSU for both your nixie hat and the RPi - this is what most RPi-based media clients with on-board hat amplifiers do, e.g. those from IQaudIO (whose amps I use and love).

Regards

Nick

[Alic]

Hello,

Does it have to be RPi? There are many options available for arduino, but for some reason not many for the RPi (that I know of).
I think all options already include the 5V/3.3V and HV power-supply.

Here someone uses an RPi 0 with the Arduinix shield/HAT :
https://hackaday.io/project/16467-raspberry-pi-zero-nixie-clock

Concerning the power supply:
I have never seen a nixie-object where more than one voltage supply was outside.
Especially the HV supply is always close to the board.

I am still searching for a universal nixie (direct) drive board which has just connections for the cathodes, 5V or 12V supply, HV supply control (output enable?) and one of the serial interfaces compatible with arduino and RPi.
Swissnixies Sunix - S comes very close :

http://www.swissnixie.com/index.php?go=sunixs

[Tomasz Kowalczyk]

Unfortunately there aren't any original IN-14 sockets. But there are good news: you can easily buy IN-14 to 2,54mm adapter from OSH park. I don't know if there is any existing project like this, but for me it is really short work and I could make gerber files for such PCB*. OSH makes three PCBs in one order, so you'd have to buy exactly 2 sets. PCBs would be dirt cheap - probably about 5$ for all 6 PCBs. So if you won't find them in OSH park database, just e-mail me.

I don't have any experience with Raspberry PI, but looking at its price I suggest considering any microcontroller family - in a Nixie Clock project you need mostly I/Os and timekeeping accuracy. Unless you are going for IoT project, RPI is going to be expensive and most of its calculating power won't be ever used.

There are possibilites to extend I/Os by I2C bus, for example with MCP23008 (http://embedded-lab.com/blog/expanding-the-number-of-io-lines-using-microchip-mcp23008/). You could use four of them, three controlling two 74141 drivers and one controlling 6x optoisolators (TLP627)**. This way you would be able to do ALL nixie controlling via I2c, but it would require many chips, fortunately all avaible in DIP packages. I have never personally used any I/O expander, so all what I wrote is a concept, not a tested idea.

If all of your sensors and RTC module (if you are planning to use 4 tubes as a clock, too) use I2C, then you could end up with a project using only those I/Os of your RPI :) I personally prefer using as many I/Os as I can.

If you want RGB lightning, I'm sure there are I2C chips capable of controlling them by current sinking. 

To change brightness of nixies you should "PWM" them. This is the best method of dimming nixies - changing HV supply voltage will eventually lead to undercurrenting tubes, and in that state they do not light a full digit. It is easiest to apply when multiplexing the display, as you need some dead time to avoid ghosting - so to change brightness you just make the dead time longer.

For a power supply I would recommend some dual voltage wall wart - 3A for RPI + 12,5mA x6 for 74141s + other modules... you will quickly require high current on 5V line, and to get HV from a switching supply, you will require at least 9V (12V preferably). If you won't find a 5V4A + 12V1A wall wart, then you probably have to either get a transformer and wire it to your liking or make a two-stage boost converter to make 180V out of 5V***.

I recommend making a HV PSU basing on NE555 with 12V supply - I made my unit for nixie testing and it was tested for 200V 40mA, reaching 83% efficiency (could be better if I used bigger resistors for feedback). 

*in fact, I already made such adapter a week ago as a part of bigger board, which had some unused space, but I deleted it and made a LC-531 adapter, because I lost an auction for IN-14s.

**all my 74141 which I tested didn't allow to turn a nixie off by sending a value bigger than 9 to it, there was a slight glow around all digits. So to be 100% sure that a nixie is turned off, you might use either a transistor anode switch or use a transoptor (optoisolator).

***there are possiblities to get 200V out of 5V, but they aren't easy or they provide little current - first one is a switching PSU with a pulse transformer, the other one is making a boost converter to ~60V and use a series of voltage doublers. I find the second one a viable choice only if you want to make a multiplexed clock powered from USB.

[Nick]

I wonder.... just wondering, if anyone has made a RPi hat that adapts to an Arduino header so that you could use an RPi with any (well, most) Arduino shield as there are 1000's of Arduino shields and only a few 100 (maybe) RPi hats...

Just a thought...

RATS! Someone else thought of it first - https://www.amazon.com/Raspberry-Arduino-Shields-Connection-Bridge/dp/B00F4S13FE (not cheap, though...)

Nick

[Alic]

Tomasz,
Tayloredge offers a HV power supply which gives up to 23mA @ 180V for a 5V input :
http://www.tayloredge.com

[Alic]

The eBay seller vfdclock also sells many different 5V to 170V or higher supplies (his eBay store is closed for a few days right now) :

http://www.ebay.com/itm/131846790948?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

http://www.ebay.com/sch/vfdclock/m.html?_nkw=&_armrs=1&_ipg=&_from=

[Ian Vine]

Well, yes but $102 !

IanV

--
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+unsub...@googlegroups.com.
To post to this group, send an email to neoni...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/a0e53346-0539-433f-a048-30993f66c80f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tomasz Kowalczyk]

Yeah, but this is costly due to custom transformer used. I'd prefer a 12V supply and cheap NE555 converter or 5V + voltage doublers, as this is just cheaper than those 'ready to use' modules from ebay. On USB you are heavily limited with current anyway, so the clock has to be multiplexed or driven with <100% duty cycle. And I see no other point in using 5V power supply than making USB powered clock. USB 2.0 standard gives 500mA, which will be not enough to really use that converter fully :) Of course, cell phone chargers provide more current, but I think that if a clock is designed to have USB type supply, it should be possible to drive directly from a PC.

The only reason I see for going with transformer converters is making a battery powered clock. But then I'd recommend using flash lamp cap charging transformers - generally very small and made exactly for converting battery voltages to high voltages.

[gregebert]

I chose the RasPi zero-W (the newest Pi, for $10 US) because it has built-in WiFi to do periodic time-sync, and it will allow me to update my clock software remotely, rather than taking the clock apart each time to update FPGA code.

My concern is the limited GPIO speed of the Pi, so I will have the Pi drive an FPGA, which in-turn drives the 7971 boards.

For now, the FPGA is strictly for remapping ASCII character data into segment info, then serializing. If I see other issues, such as "wobbly" data on the seconds, I may load-up more work on the FPGA.

Since I literally just taped-out my board last night, it's going to be several weeks before I have any idea how the Pi performs. Though I have another Pi for my 3D printer, I've never done any GPIO experimenting with it. 

[Ian Vine]

Not sure if we are getting wires crossed. The $102 price was for the Rpi hat to arduino shield adapter

IanV

--

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/bbaec5c1-f189-4fa0-8bf8-c8e947c5fa87%40googlegroups.com.

[okniew]

It took me some time to answer, been quite busy with my work.

Still, thanks a lot for all your answers!

@Nick - nice suggestions, thanks for sharing the links.

@Alic - yes, it has to RPI, main reason for this is - I already bought it :)

@Tomasz Kowalczyk - thank you for all the information, indeed there are IN-14 and IN-19 boards at OSH park. As for the remaining part of the answer - lots of information to digest :) As I mentioned initially, I prefer to use ready and available on the markets elements, but surely your answer is inspiring ;)

Lots of information to process.

Any other recommendations and ideas will be much appreciated!

[okniew]

I also found 1 more place having exactly what I was looking for, although at a rather steep price..

https://switchmodedesign.com/collections/arduino-shields/products/smart-nixie-tube

Have you ever had any experiences with those kits? 

W dniu poniedziałek, 20 marca 2017 10:42:24 UTC+1 użytkownik okniew napisał:

[Dylan Distasio]

Although it will not address the +, you may want to look at these.  I have not used these personally but on paper I think they may be close to what you want:

http://cathodecreations.com/index.php?route=product/product&path=59_61&product_id=53

--

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+unsubscribe@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/c135c889-7a03-41a4-87d7-78c96b2f245e%40googlegroups.com.

[Dave]

These work great.

If anyone wants to try one, I have some extra PCBs I can sell.

[gregebert]

UPDATE: I have my RasPi Zero W running nicely as a headless system w/ Raspian.

WiFi range seems adequate, especially considering the antenna is integrated into the PC board.
I run VNCserver on the Pi, and connect from one of my systems (no monitor or keyboard on the Pi)
Power consumption w/ AC adapter is quite low, perhaps 1watt based on my low-resolution AC-line monitor.

GPIO speed, using wiringPi and a compiled C program gave a max frequency of 5Mhz on a single pin.
I'm going to explore speeds using serial and parallel modes in the coming days.
At first glance, it seems to be adequate for use with serial driver chips like the HVxxxx series family.
It took very little effort to install wiringPi and get the GPIO working; worked on my first attempt!

I'm satisfied to the point I wont pursue Arduino anymore.
Having a $10 Linux-based platform that I can log into wirelessly & remotely is really incredible.

[Mitch]

I'd like to give this a try, too. Greg, what IDE and language are you using? C++? Are I2C and SPI libraries available? Can more I/O be added without too much trouble? Better debug tools would be great.

Starting with an environment reasonably similar to Arduino would make an easier and more comfortable learning curve.

[gregebert]

I'm just using C, and so far I have not chosen a development tool. The info I found on sparkfun mentions Geany (and it's included in the current raspian image), so I will try that first.

There are sample programs included in the wiringPi distro for I2C and SPI. Have not tried either yet, but will eventually test-out I2C with a DS3232 clock (so I have accurate time in case my internet goes down).

The GPIO connector is 40 pins (some are power and GND), which leaves 28 usable GPIO pins. If you want to use SPI and/or I2C, some of those 28 gpio's are mapped to SPI or I2C so plan your pinout carefully before making a PC board.

I've sidestepped the GPIO pin-count issue by going serial to the nixie drivers (74CH595+NPN current limiter). In the end, though, my b7971 project uses direct-drive.

https://learn.sparkfun.com/tutorials/raspberry-gpio

[GastonP]

<snip>

On Saturday, April 8, 2017 at 4:02:13 AM UTC-3, gregebert wrote:

UPDATE: I have my RasPi Zero W running nicely as a headless system w/ Raspian.

I'm satisfied to the point I wont pursue Arduino anymore.
Having a $10 Linux-based platform that I can log into wirelessly & remotely is really incredible.

<snip>

Just be aware that Linux is not a real time operating system, so anything that is time-sensitive has high risk of those timings eventually not being respected.
I use one of the multiple Pi lookalikes just out of cost considerations (OrangePi).
For tasks that do not require much processing grunt I go for the Texas Instruments family of mixed signal processors, and having AVR being recently acquired by Microchip gives me the sense that Arduino's final day is coming soon.

[gregebert]

I have an FPGA as my 'Plan B', in case the there isn't enough predictability in the Pi to display time down to the second. It wouldn't be much work to modify the Verilog code I did for my previous clock to allow the Pi to handle daylight savings, insert text messages, and possibly correct for time-drift (that DS3232 is really accurate..).

[gregebert]

I ran a few more tests on serializing a 64-bit stream using C-language and the wiringPi library.
Typically, I'm getting around 32usec (measured on a scope) to send the 64-bit burst, which is decent for software-controlled GPIO's.

There are timers available in wiringPi, but I found they are not accurate. A burst that measures ~32usec on my scope is around 22usec per the micros() call.

Despite it's inaccuracy, it's still useful for generating histogram data on transmit times. As GastonP pointed out, timing is non-deterministic in Linux. After numerous runs I did see a case where it took 10msec to complete the transmit. The single outlier really skewed the avg TX time.

Bottom line is that the RasPi is usable for many, but not all, control applications. A clock should be OK; engine controller ? No way.
All of my clocks to-date are at least as reliable as the electric utility (never had logic or FPGA crash on me); not sure if RasPi has similar reliability / availability.

greg@rpi0w001:/proj1/pigpio/src $ ../exe/speedtest_gpio_tx64
400 Loops. Max_time = 10083usec, Min_time = 18usec, Avg_time = 45.69usec
   0 to   20: N = 161
  20 to   25: N = 219
  25 to   30: N = 18
  30 to   35: N = 0
  35 to   40: N = 1
  40 to   45: N = 0
  45 to   50: N = 0
  50 to   60: N = 0
  60 to   70: N = 0
  70 to  100: N = 0
 100 to  150: N = 0
 150 to  200: N = 0
 200 to  300: N = 0
 300 to  400: N = 0
 400 to  500: N = 0
 500 to  750: N = 0
 750 to 1000: N = 0
1000 to 2000: N = 0
Over    2000: N = 1

[Nick]

You could always use a genuine real-time o/s like ChibiOS/RT ..

Nick

[blave]

This is how I did it. https://www.youtube.com/watch?v=9kbrIwxNr9g

have fun,

Dave B.

[Charles MacDonald]

On 17-04-15 02:55 AM, Nick wrote:
> You could always use a genuine real-time o/s like ChibiOS/RT ..

At one time their was a group working on a real time linux kernel...

https://www.linux.com/blog/intro-real-time-linux-embedded-developers

https://wiki.archlinux.org/index.php/Realtime_kernel

would that be close enough?

--
Charles MacDonald Stittsville Ontario
cm...@zeusprune.ca Just Beyond the Fringe
No Microsoft Products were used in sending this e-mail.

[gregebert]

I got my RasPi-based clock to display time last night, so proof-of-concept is done.

Right now, I'm using seven b7971 tubes. All of the compute-related stuff is done via a 'C' program running on the RasPi. I had planned on adding an FPGA to offload the RasPi, but so far I have not seen a need to do that.

Some of the details of the design below. I'll post a photo tonight.

RasPi Zero (yeah, the $10 US board with built-in WiFi), running raspian.

Debian-based tools/env, including gcc, and VNC

Uses wiringPi library to allow software control of the GPIO pins

Two PCB's (each with 4 sockets and current-limited direct-drive b7971 nixies). Easy to cascade more boards if I could afford more tubes.

Serial interface (clk, data, load) via opto-isolators.

Separate +5VDC (isolated), and +185VDC (NON-isolated) supplies

Everything is working as expected; workload on the Pi is low (about 4% on average).

I still need to check supply-margining, signal integrity, add the colons, and run it on the AC-line (right now it's on an isolation transformer).

Hooray, no blue wires on the PCB ! Everything worked as expected the first time.

There's more work to be done with the programming, such as inserting text messages.

And of course, I need to make a case for it.

Being able to remotely access it for software development is really handy; even after it's locked inside the case I can still login and add features.

[blkadder]

Another option for a nixie socket/adapter would be the ones available from our friend Pete over at www.pvelectronics.co.uk.  Pete is very active, and I have used his clock kits to build several clocks.  I have also purchased the adapters you need to fix some of my horrible soldering jobs.  Now when I order a kit, I make to insure I get a few extra adapters.  His page for the adapters can be found here:  http://www.pvelectronics.co.uk/index.php?main_page=index&cPath=4_11

I will be watching this thread as well as the Arduino thread.  Thanks to all for posting excellent information.

Ron

...Semper Fidelis...

[gregebert]

Photo here, and short video posted to YouTube at https://youtu.be/OjQeW67viXw

[Terry Kennedy]

On Tuesday, June 6, 2017 at 1:19:05 AM UTC-4, gregebert wrote:

Photo here, and short video posted to YouTube at https://youtu.be/OjQeW67viXw

Mostly unrelated, but... I've had bad experiences with devices very similar to those 2 10-receptacle boxes you have mounted on the wall behind the clock. It was many years ago and I forget the details, but I would up drilling out the 4 rivets holding the case together and replacing pretty much all of the "guts", including the 5 duplex receptacles with much higher-quality ones (using real screw terminals, not push-in backwire) and then using sheet metal screws in the former rivet holes to reassemble the unit. APC used to use the push-in backwire receptacles in their AP9210/AP9211 strips and I never had a problem with those, so it may be low quality parts in the Belkin units. If you look at the online reviews you'll see that many of the negative reviews are for "worked for a while and then died".

[gregebert]

Thanks for the warning. Generally, I leave everything plugged-in 'forever', which is probably why I havn't had problems yet.

[gregebert]

Thought I would post a follow-up regarding a RasPi as a nixie controller.

So far, using a RasPi Zero W for controlling my latest nixie clock (8-tube b7971) has far-exceeded my expectations:

• No 'helper' FPGA is needed; there is far more than enough horsepower in the Pi to handle all of the compute, timekeeping, and serial communications
• Timekeeping is accurate; the Pi periodically syncs to a time-source on the internet (no idea where). Perhaps it's from my router, which gets the time elsewhere.
• Display updates are done once per second. I have never observed my display 'jump' or 'stall' +/- 1 second based on the random alignment between realtime, and when the clock software updates the display. I did not add any code to attempt to synchronize to realtime.
• CPU utilization is averaging 3-4%, even when running a VNC server, plus all of the Linux housekeeping tasks. There are periodic spikes of ~40% each second when the clock software does it's work. No significant thermal generation (less than 10 degrees F as measure with infrared thermometer)
• Using a cheap passive IR (PIR) sensor has allowed me to shut-down the tubes most of the time; the sensor is sensitive enough that I really cant sneak-up on my clock without it turning on. Nor is it falsely triggering.
• GPIO programming with WiringPi is fairly easy; there were some quirks that I found and fixed when reading a digital input. Also some minor documentation issues about pin-naming.
• Being able to remotely program without attaching/removing cables, power-cycle, etc is very handy. I use 'C' because it's compiled, hence faster execution versus python, perl, etc.
• Only drawback so far is the startup-time (linux boot), which is just under a minute. I have not yet added the clock software into the bootup process so that it auto-starts on power-up; should be easy to do in crontab ? (I've done it before for a remote server; just cant remember where).
• Without an attached RTC module, timekeeping relies on my internet service and WiFi running. I have thought about adding an RTC module as a backup, but it's low priority.

[Paul Andrews]

Good news. I had wondered about using a PI myself but was concerned with lack of realtimeness. BTW, in regular UNIX you would set your app up as a demon that runs at boot up. Crontab would not be the way to go. There should be a bunch of stuff in /etc/init.d or /etc/initd or something like that. You'll have to google the details, you should be able to specify at what stage in the boot process it gets run and as what user.

- Paul

[Mitch]

Greg, is I/O fast enough to support cross fades? For a really smooth fade, I think updates must be 10ms or less.

[gregebert]

If you want 10msec granularity, traditional Linux may not be the right choice.

I did quite a bit of data-gathering (See my April 14 post in this subject), and got 64-bit serial packets to transmit , on average, in 32usec.  Occasionally there is an outlier, on the order of milliseconds, due to system housekeeping tasks. THAT is what may clobber your 10msec fading.

My code is intentionally 'bursty'. Every second, the system clock is queried, then the date or time display-message is composed (message varies, such as time format, day, date). Once the message is composed and translated into segment data, the actual 128-bit serial transmission takes place. It's a 'flattened' subroutine with no loops or calculations that hammers the GPIO pins as quickly as possible to get the data send to the display board. Since I'm running 2 boards, I send 128 bits. The last step is to check the PIR sensor, if that function is enabled, and decide whether or not to keep the display on.

Last night while running a system update, the CPU was pegged at 100% for about half an hour. There was no degradation in the display. Apparently the task swapper in Linux gives my clock software a large enough slice so that it finishes; I believe the default is 100msec.

I dont have fading, but I do plan to add 'dissolving', where segment-changes are staged in 100msec intervals and characters morph from one to the next.

[neoni...@liny.net]

Agree w/Paul - crontab is for periodically running things, not to start a daemon on system startup.

To add a little bit more to what he mentioned, you may want to have a script that accepts a parameter indicating if it's "start", "stop" or "restart" (e.g. stop then start) for the daemon. Then within the /etc/init.d/ dir you put your script. It must have a standard LSB header and you run a command (see 2nd link) so the system knows how to connect all the parts. This way for shutdown (or restart) your clock code can accept a shutdown request (in your clock program C code catch a SIGTERM or other 'signal') and gracefully put any GPIO pins to a safe state before exiting. Restart is handy after you've swapped in a new program version. For that once in a blue moon instance when your program won't shut down gracefully, you can in your script also code a "kill" section that sends a SIGKILL to your program.

In the script you also choose at what run-level you want the clock program to run. Typically, that would be 2, 3 & 5. See http://www.tldp.org/LDP/sag/html/run-levels-intro.html for run-level info, which also talks a little about the /etc/init.d/

A decent RPi example & explanation of what's needed with some shell start/stop code is here: http://raspberrywebserver.com/serveradmin/run-a-script-on-start-up.html I haven't verified it works, but the shell scripting looks OK from my Red Hat perspective.

Good luck and have fun!

- Steve

--
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 an email to neoni...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/6ef0cef0-e433-4ecf-839a-fbd8f98838dd%40googlegroups.com.

[gregebert]

I went the lazy route and used crontab, with @reboot . It runs as me, not root.

The real question now is: How long can a raspi run without crashing ?

Eventually I will start logging usage of each segment, on each tube, and use that for depoisoning. Since it's a micro SD (flash) filesystem, which has limited write-cycles, I have to be careful about how often I store runtime information. Syncing daily to the same file (appending) could cause wearout after several years if the OS doesn't incorporate some form of levelling. Doing it every 3-4 days should get me about 100 years of logging if the flash has 10K write-cycle endurance. Not that I will be around then to do anything with that data.....

[Paolo Cravero]

Hi.
 

The real question now is: How long can a raspi run without crashing ?

As all *ni systems, a RasPI can run for years unless there is a hardware failure or overheating. I've been (silently ;) ) collecting uptimes at work and I've seen servers that haven't rebooted for 1600+ days (enterprise-grade computers have redundand power supplies and hard disks that can be hot-swapped/replaced). A RPi can perform the same.

 

Eventually I will start logging usage of each segment, on each tube, and use that for depoisoning. Since it's a micro SD (flash) filesystem, which has limited write-cycles, I have to be careful about how often I store runtime information. Syncing daily to the same file (appending) could cause wearout after several years if the OS doesn't incorporate some form of levelling. Doing it every 3-4 days should get me about 100 years of logging if the flash has 10K write-cycle endurance. Not that I will be around then to do anything with that

Well, the write-cycle count applies to each single bit of the flash memory. So, if you're just appending data to a file, what has been written won't change on subsequent additions. Your filesystem might have blocks of 2 kiB, 4 kiB or 8 kiB, so that's the amount of data that could change at once if the bucket was full yet. Then there's the filesystem internals and journal ("which blocks form a file" in simple terms, the index), that could change more often.

OTOH Linux systems log stuff all the time to disk, so that part of the flash disk might fail before your clock log sectors.

An option could be to upload your data to some online (free) service, since you have WiFi.

Also, have you though of implementing a purely hardware watchdog to shut down everything in case the software hangs?

Paolo

[gregebert]

I'm not too worried about a hang condition; if it happens I'll just power-cycle. This particular board has been running for a few months now, with no problems. Not continuous running because I've had to remove power, but it's never shown any hint of flakiness even when it ran continuously for several weeks at a time.

After some further reading, it appears microSD cards do implement wear-leveling. I just have to hope that the OS doesn't do a lot of file I/o when it's mostly idle. I'll probably just take my chances with dumping a local logfile every few days, and pulling a copy to my fileserver.

Right now I have to build the case, which is probably the most time-consuming phase of the entire project.

[gregebert]

I created a separate user group https://groups.google.com/forum/#!forum/b7971-driver-board-user-group

for neonixie members who are interested in building a clock with b7971 tubes using my PC board. As of now, I dont have any more PC boards. I have 2 boards running, but we need to have more built & tested to shake-out problems before making any more. All of my extra boards have been given away, but if there is interest another batch can be made in a few months. There will be a charge for the boards (about 10 USD each) and shipping. I dont have any 7971 tubes for sale, and I bought-out my supplier.

For the 4 of you who have received (or will shortly receive) the boards, you should have received an invite to join. 

Although mine is controlled by a RasPi, there's no reason why it cant also be controlled from Arduino, FPGA, etc.

Membership is by invitation only (only to prevent spambots). I will admit any neonixe member.