As you may remember from my previous blog, when I purchased a 1953 International pickup truck, I decided to add a digital speedometer. I elected to use Nixie tubes because they have an appropriate vintage feel and bring a warm, fuzzy feeling to the party. Furthermore, I decided to use a GPS unit that would let me determine my speed without hacking into my speed cable or cobble Hall effect sensors and the like together.
My version of the project ended up using the parts shown below. You can substitute other parts as you wish, but I ended up with these either out of convenience or because I happened to have them lying around in my treasure chest.
* One high-voltage DC 115-235V Nixie tube driver ($18 on eBay)
* Two K155ID1 Nixie tube drivers ($2 each on eBay)
* Two Nixie tubes ($10 each on eBay)
* One PmodGPS GPS receiver ($45)
* One Basys2 Spartan-3E FPGA board ($50)
As I noted before, you can find cheaper GPS receiver modules and make your own DC-DC converter, but if you already have something at hand, you might as well use it. This project works with high voltages, so please be careful.
Decoding the GPS
The Pmod GPS plugs right into the BASYS2 connector. This module was not easy to integrate, and the documentation is lacking. All I needed was the speed-over-ground message. Before I get too far, the physical interface is 3.3V signalling, 9600baud, start bit, stop bit. The GPS blinks a LED once a second until it locks on the satellites. However, I discovered that serial data was always flowing from the module, even without a lock.
Five ASCII messages come out of the module every second, each one commencing with a $ character. To obtain the speed value, I needed to decode a data stream that looks like this.
In this example, the speed is 0.06km per hour. This example is not as helpful as it could be. What about when the speed is 10 or 100kph? By trial and error, I discovered that the message is variable. For 10 and 100kph, it will look something like this (it would have been nice if someone had told me):
The trick to finding the speed from the five messages is to look for the sequence $GPVTN,SPEED. To help me debug the data stream, I inserted a 4k FIFO that stores the GPS data and is displayed every second or so to the rightmost pair of seven-segment LED digits on my FPGA board. This was very helpful. Remember that the message is in ASCII; we have to subtract hexadecimal 30 from each numerical digit to obtain the decimal equivalent. Also, look for that decimal point delimiter, because the speed could have one, two, or three digits. This snippet of VHDL shows some of the decoding.
KPH to MPH
After the speed is located and decoded from the GPS message, the next step is to convert it from kilometers to miles per hour. I decided to use a lookup table, as illustrated below.
I also have a smaller version of this design that fits into a CPLD—I'm too cheap to stuff this FPGA board into my truck. For the purposes of this exercise, though, I used a lookup table. This output is by nature in BCD format, so it mates up nicely with the K155ID1 Nixie tube drivers. It's simple and fast. Since I wish to display my speed only in miles per hour, and since my truck will never go faster than 99mph, two Nixie tube digits will suffice. If you wish to display your speed in kilometers per hour, you will need three Nixie tubes. The accuracy of the speedo is about ± 1mph, and the update rate is one second. GPS is sensitive to drift, bridges, etc., but this setup works well as an overall speedometer.
Driving the Nixies
Each Nixie tube will have at most one digit turned on at any particular time. The tubes sink 2ma and require approximately 160V. The anode is driven by the high voltage, and the FPGA will pull it low to close the circuit. I purchased a simple DC-DC converter to generate the high voltage. To reduce the input/output count in the FPGA, I purchased two K155ID1 chips. To keep the current at 2mA, we need a ~10kΩ resistor in series on the anode side. The K155ID1 chips are specifically designed for Nixie tubes. They have a BCD input and a 10-digit output. Below is the pinout diagram for these chips.
Remembering that the Nixie tubes came from a Russian source, their pinout chart seems so Cold Warish and makes me want to yell, "Tear down this wall!" Anyway, in the case of my tubes, we are interested in the HH-12B pinout on the right-hand side, as illustrated below.
All you have to do is turn the tube over and find the arrow symbol, which is the anode (+) 160V side. Going clockwise, pin 2 is digit 0. Pin 3 is digit 9. Then we have digits 8, 7, 6, ..., 1.
Driving a single digit in the Nixie tube is easy. Just wire the anode up to the + high voltage and the cathode of the digit you wish to light to the ground.
Driving the seven-segment LED displays
As illustrated below, the seven-segment LED displays on my FPGA board are multiplexed, which reduces the I/O count for the FPGA. Possibly we could have done something similar with the Nixie tubes, but maybe the strike factor time for a Nixie would have prevented that.
The idea here is persistence of vision. Some displays change so fast that your eye and brain will merge the images. If we light the first seven-segment LED digit for 1/10th of a second, and then we do the same for the second, the third, and the fourth, it will appear to the observer as a single display in which each digit is constantly illuminated. In addition to reducing the number of FPGA pins, this lowers power consumption, thereby making everybody happy.
Of course, the data feeding the display cannot change faster than four times the sample rate, or digits will change in midstream. I made my refresh rate around 600µs. This number is not critical—it just has to be fast enough.
Following our exploration, now it's time to pull everything together...
Pulling it all together
By default, my FPGA board uses a 50MHz clock, so that is our clock rate. Power to the board is 5V, which is provided over the USB connector. I also jumped off the 5V battery connector to power the K155ID1 chips. The DC-DC converter needs 12V, but that can easily be found in a vehicle. Having said this, my truck has a 6V battery, so I had to perform one more conversion, which was no big deal and is not shown here.
I did this design the hard way with a soldering iron, wire, and a glue gun but no printed circuit board—manly crafting at its best. Due to time constraints, I did not create a schematic, but it's easy to see how everything goes together using the data sheets. The best I could do was the quick drawing below.
The DCBA ports are the BCD outputs to the K155ID1 chips. Make sure the K155ID1s have +5V and GND connected correctly, and wire the 0-9 digit outputs to the corresponding pins on the Nixie tubes. The GPS module just plugs right into the JD connector on the FPGA board.
Our first test drive used just the seven-segment LEDs on the FPGA board to verify that I was accessing the GPS correctly.
It worked great. Given a choice, I would like the update rate to be a little faster. When you are accelerating or decelerating, it takes a few seconds to catch up. Nevertheless, the end result is still really cool—a noncontact speedometer.
And here is the finished product:
This ended up being a really nice and fun project. I hope you enjoyed it as much as I did. I'm starting work on a new project that I think will blow your socks off, but I'll tell you more about that in a future blog. In the meantime, do you have any questions about this project?
Reference design
The design and reference documents for the speedometer can be accessed for free on my website, theFPGAexpert.com. The design is free to share and modify, so long as you include proper attribution to the FPGA Expert and link to theFPGAexpert.com.
One final word of warning: This design is for demonstration purposes only. It is not road worthy, and it has not been approved or tested by any authority. Use it at your own risk.
文章评论(0条评论)
登录后参与讨论