Nixie things

With my missus’s birthday rapidly approaching, I have decided to manufacture her something neat.

To that end…

“Nixie” tubes are a brand-name for a cold cathode glow discharge device used for a relatively short period around the 80’s to display numbers, letters and symbols (before LED technology reached maturity). They are only in production by a few die-hard enthusiasts, but ex-Soviet stock is reasonably readily available on the Internet.

They look something like this:


The purpose of this post however, is as follows.
As a byproduct of the majority of available Nixies being Soviet-made, their datasheets are Cyrillic.

And I have translated the one for an INS-1 ‘indicator’ point (not a true Nixie lamp, but a start).

So here it is, take from two documents- one that ships with each batch (firing voltages and current), the physical properties taken from another:


Gas discharge lamp unit is designed to display information in the form of a point in the information display.
The body is cylindrical glass. Weight no more than 1.5g

Cathode marked with a dot (NOTE- this contradicts most of what I have read on various forums! However,  the datasheet clearly has “анод”  (anode) and “катод” (cathode) marked, with the dot on the cathode)


Instructions for Use

Firing voltage, V, Min (Max) .  .  .  .  .   .  .  .  .  .  .  .  .  .  65 (90)

Sustaining Voltage, V, Max .  .  .   .  .  .  .  .  .  .  .  .  .  .  .  .  .  55

Current, mA .  .  .  .  .  .  .  .  .  .   .  .  .  .  .  .  .  .  .   .  .  .  .  .  0.5

Vibration loads:

Frequencies, Hz  .  .  .  .  .   .  .  .  .  .  .  .  .  .  .  .  .   .  .  . 1-1000
Acceleration, m/s² (g), no more  .  .  .  .  .  .  .  .  .  .  .  .  98 (10)

Multiple impacts:

Acceleration, m/s² (g), no more  .  .  .  .  . .  .  .  .  .  .  .  147 (15)
Impact duration, m/s  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 2-15

Single shock:

Acceleration, m/s² (g), no more   .  .  .  .  .  .  .  .  .  . 1472 (150)
Impact duration, m/s  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 13

Temperature (environment), ° C.  .  .  .  .  .  .  .  .  .  . -60 /+ 85
Relative humidity,%, not more   .  .  .  .  .  .  .  .   .  .  .  .  .  .  98
The increased air pressure, Pa (kg/cm²) .  .  .  .  .  .294 198 (3)


And again with the coding…

Here’s a little Arduino code I’ve cooked up for the purposes of providing a nice crank signal to the FPGA-based ECU, for the purposes of bench testing the output. It’s a simulation of a nicely cleaned up, digital signal generated by a 36-1 toothed crank wheel on your typical Ford engine.

Essentially, a little throttle position sensor (read, potentiometer) is hooked up to adc pin 5. This is purely to give me something to twiddle to see if the FPGA is reacting quickly enough to the change in frequency (Not that I have any fear of this, really- damn thing is pretty fast- but alas, I must have something to fiddle with while testing, or it’s no fun!).

The LED flashing part is purely for visual effect; an ‘is it working’ before I had chance to hook it up to an oscilloscope for testing.

The code is simple enough, my written code is starting to look more user-friendly, and- importantly- it works. Onward with the FPGA testing, then?

Maybe after my exams; this was put together in my ‘evening off’. (Oh, ninjaedit- it only ‘works’ when debug = 1)

#include <Wire.h>
// Calibration Values for TPS
float minimumReading = 48;
float maximumReading = 919;
//Setttings for TPS
int analogPin = 5; // Throttle Position Sensor Wiper Pin
int throttleRead= 0; // variable to store the value read
int throttleCorrected= 0; // variable to store the corrected value
//LED flashy bit setup
const int ledPin = 13; // The number of the onboard LED pin
int ledState = LOW; // Used to store the LED state
//Variables for Pulse Generator
long pulseLength = 0; // Variable to store the generated pulse length
long gapLength = 0;
int toggle = 1; // Variable to act as a toggle
long lastMicros = 0; // Variable to act as timer function
int count = 1; // Variable to store the current tooth count
int calibrate = 92.59259259259; // Calibration for top speed = appx. 9k rpm
int rpm1 = 1; // Variable to store the RPM number
int debug = 1; // Debug setting- changes output from RPM & pulse length to counter & gap indicator
void setup()
Serial.begin(9600); // Setup serial
pinMode(ledPin, OUTPUT);
void loop()
tpsRead(); // Run TPS Read loop
void tpsRead()
throttleRead = analogRead(analogPin); // Read the input pin
throttleCorrected = ((throttleRead-minimumReading)/maximumReading)*100; // Subtract minimum from TPS. Calculate percentage of max
if (throttleCorrected<1)
if (debug == 0)
rpm1 = 60000000/(pulseLength*36);
Serial.print("Simulated RPM :");
Serial.print("RPM; Pulse Width :");
void pulseGenerate()
pulseLength = (throttleCorrected*calibrate); // Calculate length of 'high' pulse (in microseconds)
gapLength = pulseLength*3;
if ( (micros() > (lastMicros + pulseLength)) && (toggle==HIGH) && (count <= 35) )
lastMicros = micros();
toggle = LOW;
if ( (micros() > (lastMicros + pulseLength)) && (toggle==LOW) && (count < 35) )
lastMicros = micros();
toggle = HIGH;
count += 1;
if (debug == 1)
Serial.print (count);
Serial.print (",");
if ( (micros() > (lastMicros + gapLength)) && (toggle==LOW) && (count == 35) )
lastMicros = micros();
toggle = HIGH;
count = 1;
if (debug == 1)
Serial.println ("GAP");
Serial.print (",");

ECU Project- Entry the First

Worthy of note, is that this is -not- the first effort I’ve made in this field.

In short, the reason behind this project is that I have an MGB GT; after the second B-series engine gave up the ghost (they don’t really seem to like 20,000 motorway miles and 12,000 ‘other’ miles a year), I got fed up- and the car sat languishing in the garage for 6 months.

So, my birthday rolled around- and my mother made me a little purchase…


As it turns out, this gave me some bad ideas. As there are several people in my group of friends and acquaintances- not least of which, my father- who are very much into the Ford Capri, I’d heard of a little engine swap that can be performed relatively simply, into that vehicle- the Cosworth 24v V6.

The block length of which would just about fit. As would the gearbox- assuming I’d switch the auto ‘box that comes bolted to the engine, with an MT75 5-speed manual. Naturally, I prefer the sound of carburetors  and this is as standard a fuel-injected, ECU-controlled engine…

A solution was needed; off-the shelf solutions, as usual, too expensive… this is my first step along the route to achieving it.

The purchase of an FPGA (Field Programmable Gate Array) is my first step along the line- inspired by an interview with a gentleman who suggested that experience using them would aid my future employment prospects.

It’s a nice little device, and very clever- anyone familiar with logic circuitry will understand the basic concepts- AND, NOT and OR gates arranged in specific ways to achieve outputs that are desired.

The software we were using (Quartus II) also incorporates megafunctions- effectively, complex logic-based designs in premade ‘blocks’.

Logic Layout

Pictured above is an (admittedly, relatively complex) LED flasher. Connected to the ‘input’ on the left of the image is one of the internal clock pins on the FPGA- more on this later- and the other is connected to an included LED.

Now, to start with, I had no real idea what to expect- and other than making sure that the board was properly functional, did nothing, until I had a little backup; enter Iain, stage right, for “beer and a curry, honest”.

Further, we were not able to confirm the clock frequency of pin on the FPGA I was using. They appear to be variable, and my board turns out to have a few idiosyncrasies (including relatively poor user manuals). So, having read somewhere that it was either 12, 24, or 48 Mhz, for my trial design we set up a little counter-comparator pair- counting clock pulses, at 6000, turn LED on, at 12,000, reset the counter.

pin assignment

Pin association is given in the above image- pin 66 is one of the onboard clock sources, and pin 35 is the pin for the LED output on my board.

And… it worked! the LED flashed at a steady rate of on for half-second, off for half-second. Telling me that the frequency of the CLK source that we used was 12Mhz.

Some issues we ran into- when assigning the values for the constant values, I mistyped on no less than 3 occasions (easy to do, when you’re typing out a 32-bit binary number), omitting a digit, or duplicating another. This took a surprising length of time to rectify (when you’re not sure your design is going to work, it’s often easy to overlook something obvious). Also, we had a little fun with having to re-design the circuit at various points- the LPM_compare function required a 32 bit number to ‘compare’, up to that point everything had been working on 25 to save space… back to the drawing board!

End of Step One.

And the winner is…

Despite a 14-day top end for delivery, the Hobbyking parcel arrived this morning. Only been unboxed so far- here are a few pics:

The postcard is for scale. That’s a 12-inch diameter, 3 bladed prop. The prop fitting kit is very nicely machined and the spinner is a nice finishing touch; not bad for an extra $3 on top of the cost of the motor.

Sadly, batteries don’t have a connector compatible with the charger (despite being the same brand), and I forgot to order the connectors for the speed controller, so more than just a little assembly will have to wait.

Signing off.

… And then 3 come along at once!

Gentlemen, start your engines!

It’s a race between Germany and Hong Kong!
The flight electronics for the Bormatec have now been ordered from HK-based stockists, Hobbyking.

2x 4000 mAh, 14.8 volt, 4S1P (4 series, 1 parallel) Lithium-Polymer cells, for main power.
An NTM Prop Drive Series 42-38 brushless motor, rated at 750kv*
Along with a 70 Amp ESC and the servos required to operate the aircraft.
Oh, and a LiPo charger. ‘Cos I was lacking one.

The combination of these, using one battery at a time (for better at-the-field testing times), should allow flight times of approximately half an hour. For propeller choice, I have gone for a scale-ish 3-bladed unit from Master Airscrew; 12 x 6 inch.

Running cost at this point, is now c. £350, including the original Arduino electronics and sensor modules. Significantly less, it’s worth noting, than any comparable equipment you could buy… Let’s say a comfortable factor of 10. At the minimum.

And now the waiting begins…

* KV in the sense of brushless RC motors, means RPM per Volt. (so max RPM 11,100)

Introducing… the Bormatec Vamp


After careful consideration, I’ve decided to invest in a Bormatec Vamp as a flying UAV-Testbed. It’s got a 1.8m wingspan, and an all-up maximum weight of 2.5kg; plenty of room for around a kilogram of payload. After doing a little math, it’d cost me about 3x as much as this to purchase the equipment to manufacture an airframe to the standards that I’d like.

At a cost of about £130 delivered to the UK from it’s German manufacturers, it’ll arrive as a kit of parts; assembly will be documented herein.


More pictures and information as soon as it arrives!

For more information on the Vamp, please refer to it’s manufacturer website, listed below- also the source of the included image.

UAV, Finally

Above are a few pictures of things as they stand at present.

This project, as previously stated, is largely an experiment to improve skills, and produce something tangible. The aim is to produce an autonomous aerial vehicle; capable of flying to a destination co-ordinate, performing a task, and returning to base. (Likely, taking a picture or dropping a tennis ball to wind up Iain’s dogs).

The arduino control board was knocked together quickly to make it more robust than having a proto-board with all the components plugged into it.

In essence, the small red stick visible on the board to the right of the picture is a 9-DOF (Degrees of Freedom) sensor stick, incorporating an accelerometer, a  gyro, and a magnetometer. They communicate with the control board (the blue Arduino Pro Mini) via a two-wire protocol known as I2C; these in turn communicate with a base computer using two XRF modules.

Left to it’s own devices, at present the little ‘Duino will talk to the Accelerometer and, working with a little clever 3-D math, ascertains the direction ‘down’. From this, it then outputs ‘pitch’ and ‘roll’ calculated values over a serial data bus, which is transmitted through the XRF daughterboard, up to a range of 2km, back to the PC via the second XRF, to the left of the picture. Note the little yellow and green LED’s; these flash to show data transmission and reception on each of the boards- Though I have forgotten which is which… it’s in the schematic somewhere if it becomes an issue.

It’s yet to be seen how well this responds to the G-forces generated during flight- Some thought as to an appropriate solution is required. Ideas, on a postcard…

The magnetometer and gyro are currently unused. The magnetometer will eventually determine the direction of the board relative to magnetic north; ‘yaw’. It will also use the gyro to increase the accuracy of the calculated P, Y, R angles.

I have also been working on a fuselage mould; Having discovered that none of the filler types I have access to will adhere reliably to expanded polystyrene, I have decided to change contsruction method for the fuselage of this drone; Likely at this point I will make use of vacuum moulding of ABS plastic, or a moulding made of fibreglass. Wings are to be made of extruded polystyrene- think foam fast food containers, but denser. A CNC machine will be made to produce wing sections.


That’s all for now; More as soon as my student loan allows!

(Please ignore the deliberate PCB error of filed down LED’s; I made the footprint wrong, and was too impatient to wait for more to be cut!)