The nice thing about making antennas for Gigahertz frequencies is that they tend to be rather compact. The wavelength of a 1090MHz transmission is approximately 275mm. Since the length of the antenna elements shares a relationship with the wavelength, this means you can make antennas with few materials, very inexpensively.
The newer antennas use F connectors to attach to my ruggedised USB DVB-T dongle, which in turn connects to my ruggedised Orange Pi Zero which runs software to track aircraft.
Here are the relevant calculations:
wavelength = speed of light / frequency
wavelength = 299,792,000 m/s / 1,090,000,000Hz
wavelength = 0.275m = 275mm
half wavelength = 137.5mm
quarter wavelength = 68.75mm
For most antenna’s below, it’s the quarter wavelength measurement that we’re interested in. I round this up to 69mm for convenience.
I think this is a good looking antenna, as antennas go. One 69mm wire forms the antenna, while sixteen 69mm wires bent downwards at 45° form the ground plane. They are soldered to a copper end cap with a hole drilled in the middle for an F-connector. The wire is 1mm solid core electrical cable with the insulation stripped:
Before the 16 radial spider, there was this 8 radial spider built around the lid of a powdered stock tin. The antenna wire is 69mm. And the radials are 69mm long from the edge of the tin to their ends. They are bent downwards at approximately 45°. In the centre of the lid, I drilled a hole to accommodate an F-connector. The wire is 1mm solid core electrical cable with the insulation stripped.
I’m not entirely sure if the 69mm radial length should be measured from the edge of the tin lid (as I have done). Or whether they should be cut shorter to account for the ground plane effect of the tin lid. I’ve read that sometimes antenna radials are “tuned” (i.e. are sized to be resonant at the desired frequency) and at other times they are simply designed to be large with respect to the antenna. I’m not sure what’s best at 1090MHz; fodder for a future experiment, I guess.
Before the 8 radial spider was the 4 radial spider taking inspiration from this post. Very simple construction using a 69mm antenna and four 69mm radials soldered to a bulkhead BNC connector:
I was a bit miffed after making this antenna, because its performance seemed every bit as good as the coaxial collinear antenna I had made earlier, yet it took about a tenth of the time to build!
Wanting something better than the (albeit tuned) original antenna described next, I followed the instructions in my copy of the September 2013 Sillicon Chip Magazine to build this coax collinear (co-co) antenna:
I used a coax stripper to very carefully cut 12 identical lengths of coax. I based the length of the sections (114mm each) on the half wavelength (137.5mm) scaled down by the velocity factor of the Belden RG6 coax cable (0.83) I was using. I assembled, terminated with a BNC socket, and housed the antenna inside electrical conduit.
The co-co antenna was better than the tuned original antenna. But after the very simple 4 radial spider performed just as well, I concluded that homebrew coaxial collinear antennas may just not be worth all the additional effort. That said, with greater accuracy in construction and perhaps different coax, I think they could give results. It’s just hard to achieve this accuracy with fairly basic tools and no network analyser to characterise the finished antenna.
A very similar design is described here.
This was my first custom antenna. Taking the stock antenna and trimming it to 69mm. The improvement after trimming the antenna was noticeable.
The stock antenna is 115mm long meaning it’s tuned for approximately 650MHz. Good, no doubt, for DVB-T broadcasts in many countries, but not an efficient antenna for ADS-B at 1090MHz. In spite of this, the stock antenna’s performance was surprisingly good. I was tracking 4 or so planes from inside my home the evening I first played with SDR. Talk about instant gratification.
]]>I’ve already written about my steps to ruggedise an Orange Pi Zero for outdoor use. In this post, I describe how I did essentially the same thing to the USB DVB-T dongle, so it could be mounted outside, on an antenna mast or tripod.
Here’s the end result:
At one end there’s an F connector for connecting an antenna either directly or via a length of coax. At the other end is a 5-pin GX16 connector carrying USB power and data.
To provide an extra level of protection from the rain, the unit can be shrouded in a section of PVC pipe with an end cap fitted.
I removed the snap together plastic case on the USB DVB-T dongle and performed three mods before mounting it in the enclosure:
First, I used heatsink plaster to attach small heatsinks to the two main chips (the RTL2832 and R820T2) and to the blank areas on the underside of the board. I did not have really small heatsinks on hand, so I used a hacksaw to cut down a larger heatsink held in a vice. These chips run really hot, so heatsinking is a good idea, particularly when used outdoors on a hot day.
Second, I removed the USB connector so I could solder wires directly to the PCB:
Third, I removed IR receiver and LED and support components. The IR receiver is really not needed in this application and would be blocked by the aluminium case. The LED just burns extra energy and again would be blocked by the enclosure:
I drew up, printed and attached the following template to each end of the 1590A style aluminium case:
Drilling template for case sides
Using this template as a guide, I drilled a hole sized for the F connector at one end of the enclosure and a hole sized for the GX16 connector at the other.
I completed the assembly by soldering wires between the 5-pin GX16 connector and the DVB-T dongle to carry the USB power and data signals.
I then connected the coax pigtail to the MCX connector on the DVB-T dongle and bolted the F connector end to the case.
Finally, I used heatsink plaster to secure the heatsinks on the underside of the DVB-T dongle PCB to the case. I then applied 2-part epoxy to further secure the dongle to the case and to hold the wires in place.
The aluminium case will provide good dust protection, but there is still a chance that water could enter the unit through gaps between the lid and the case, or through the connectors. To help prevent this, I used a small length of 50mm PVC pipe and a matching end cap to create a very simple shelter for the ruggedised dongle:
I drilled a hole in the PVC end cap to allow the F connector to pass thru and connect to an antenna. To help centre the hole, I made another template:
Drilling template for PVC pipe end cap
I made up a custom cable using two 5-pin GX-16 plugs and a length of old USB cable, to connect the ruggedised dongle to my ruggedised Orange Pi Zero. Together, the two units make a sturdy setup for SDR.
]]>Here is what I came up with:
The Orange Pi Zero is housed in a diecast aluminium enclosure. Power is provided by a 2-pin GX16 connector at one end, while USB signals are carried over a 5-pin GX16 connector at the other end. I like the GX16 connectors since they are fairly easy to solder, very mechanically robust, and have an old-world aesthetic. Wifi is brought out to an external antenna not unlike one found on the back of a wifi router. All in all, this setup feels pretty solid.
Read on if you’d like further details, including a bill of materials, a connection diagram and a drilling template.
If you’re more interested in the software side of things, I have a complete tutorial about configuring the Orange Pi Zero for tracking aircraft and a basic guide to getting started with the Orange Pi Zero you might like to read.
I used the following materials for this project:
The H2+ chip on the Orange Pi Zero can run pretty warm in operation, so a heatsink is not a bad idea. The chip measures 14mm x 14mm so I hopped onto Aliexpress and ordered some heatsinks to suit.
I glued the heatsink to the H2+ chip using “heatsink plaster”. This is a thermally conductive rubbery substance that eventually hardens (it took like 24 hours to set). An alternative option is to use thermally conductive double sided adhesive tape. Whatever option you choose, this is more easily done before the Orange Pi Zero is mounted in the case.
Next I drilled the case. First, four M3 holes in the base of the case to mount the Orange Pi Zero. Then a 16mm hole at each end for the two GX16 sockets. Then a smaller hole on one side for the wifi antenna reverse SMA connector.
I created the following templates to assist with drilling. Feel free to download, print, and use them:
I wired up the Orange Pi Zero to the connectors according to the following diagram:
A PDF version of this diagram is also available for download.
With the lid off you can see how I used JST connectors and “dupont” connectors to make connections to the Orange Pi Zero’s 13 pin header:
In order to use the ruggedised Orange Pi Zero, I had to create two cables. One was fitted with a 2-pin GX16 plug to supply power to the unit. The other was a USB cable with a type-A socket at one end and a 5-pin GX16 plug at the other.
I wasn’t certain that the integrity of the USB signals would be maintained over the 5-pin GX16 connector, but so far I haven’t noticed any issues in use.
As always, I can think of some improvements:
But for now, the current design works for it’s intended purpose - as a rugged computer for decoding ADS-B signals from aircraft.
]]>The Orange Pi Zero is an attractive choice for this application because:
Wifi support is particularly handy, since you can situate the Orange Pi Zero and the USB DVB-T dongle close to a suitable antenna and relay aircraft tracking data back to other computers on your network using wifi. Indeed, with a weatherproof enclosure, everything could be mounted right next to the antenna on a rooftop. This would minimise attenuation of the signals received from planes by keeping the coax cable run between the antenna and the DVB-T dongle as short as possible. Thanks to wifi, the only cabling required to the system would be to deliver power.
But that’s getting a bit ahead of ourselves. Remarkably, even a very simple setup, with everything including the antenna located indoors can track a surprising number of planes.
In this tutorial I will provide step-by-step instructions to get an Orange Pi Zero working with a USB DVB-T dongle to receive tracking information from aircraft.
As a minimum you’ll need:
You will also need a home network (i.e. a router) with a wired or wifi connection; internet access; and a desktop or laptop computer.
To keep this blog post shorter, I have written a Beginners guide to the Orange Pi Zero which describes step-by-step how to get Armbian Linux installed on your Orange Pi Zero.
Please follow that tutorial before moving on to the next section.
Making the required connections is pretty straightforward:
RTL SDR is software which allows you to use your USB DVB-T dongle as a software defined radio, in our case to receive signals from aircraft.
We’ll install RTL SDR following instructions adapted from this gist.
All the following commands should be entered at the prompt after logging into your Orange Pi Zero using PuTTY or another SSH client.
First we will create a file to prevent Linux from loading the standard drivers (aka modules) for the DVB-T dongle:
cat <<EOF > ~/no-rtl.conf
blacklist dvb_usb_rtl2832u
blacklist rtl2832
blacklist rtl2830
EOF
Next we’ll move that newly created file into the required directory:
sudo mv ~/no-rtl.conf /etc/modprobe.d/
Then we’ll install some dependencies for building RTL SDR:
sudo apt-get install -y cmake libusb-1.0-0-dev build-essential
Now we’ll clone RTL SDR into a new directory called sdr below our home directory:
mkdir ~/sdr
cd ~/sdr
git clone git://git.osmocom.org/rtl-sdr.git
cd ~/sdr/rtl-sdr
And we’ll build RTL SDR:
mkdir build
cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
And install it:
sudo make install
sudo ldconfig
sudo cp ~/sdr/rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/
Now we need to reboot our Orange Pi Zero by typing:
sudo reboot
Your connection to the Orange Pi Zero will be dropped and you’ll need to reconnect after waiting a minute or two for the Orange Pi Zero to reboot.
To test RTL SDR is working correctly:
Ensure the DVB-T dongle is plugged into the Orange Pi Zero’s USB port.
Run the command:
rtl_test
Hit Control + C to quit rtl_test.
Next we’ll download and compile dump1090, a neat piece of software for tracking aircraft using RTL SDR.
dump1090 requires pkg-config, so we’ll install it first:
sudo apt-get install -y pkg-config
We can now clone the dump1090 source code and compile it:
cd ~/sdr
git clone https://github.com/antirez/dump1090.git
cd ~/sdr/dump1090
make
You can start dump1090 by changing to the installation directory and executing it as follows:
cd ~/sdr/dump1090
./dump1090 --interactive --aggressive --net
Within a few seconds you should start to see the details of aircraft tracked:
And if you open a web browser to http://your Orange Pi Zero’s IP address:8080 you should see a map representation of the same data:
Should you wish to quit dump1090 simply hit Control + C at the console.
If you’re not seeing any aircraft data, try moving the antenna to a location with a better view of the sky, for instance near a window.
Wouldn’t it be nice if we could get the Orange Pi Zero to start dump1090 at boot, so we need only to power it up to start tracking planes?
The way I like to set this up is using GNU screen, so let’s install it first:
sudo apt-get install screen
Now let’s change to the dump1090 installation directory:
cd ~/sdr/dump1090/
Create a text file called run.sh using your favourite editor (vim, nano, etc.) with the following contents:
#!/bin/bash
cd "${HOME}/sdr/dump1090/"
./dump1090 --net --interactive --aggressive
Save the file and quit the text editor.
Now set permissions to allow the file to be executed:
chmod u+x ~/sdr/dump1090/run.sh
Next edit your crontab file:
crontab -e
to include the following line:
@reboot screen -d -m -S "dump1090 at boot" ${HOME}/sdr/dump1090/run.sh
Reboot the Orange Pi Zero by typing:
sudo reboot
Your connection to the Orange Pi Zero will be dropped and you’ll need to reconnect after waiting a minute or two for the Orange Pi Zero to reboot. As part of the start up process, dump1090 should start automatically.
Once you’ve reconnected to your Orange Pi Zero, you can “attach” to the dump1090 session by typing:
screen -R
You will see the same listing of tracked aircraft as before.
To “detach” from dump1090 without quitting it, hit Control-A followed by d. You can “re-attach” at any future point with screen -R as above.
Now you have a working aircraft tracking system based on the Orange Pi Zero and a USB DVB-T dongle, you can start to refine your set up. Here are a couple of quick tweaks that really improve things.
The USB DVB-T dongles run really hot. In my experience the hotter they are, the less sensitive they are when it comes to picking up distant signals from planes. I’m not the only one to have witnessed this phenomenon.
One of the easist things you can do to address this is to prise apart the plastic case:
Using the dongle without a case greatly helps with airflow to cool it.
The next refinement is to more closely “tune” your antenna to match the wavelength of the 1090MHz signals from aircraft. One quarter wavelength at 1090MHz is approximately 69mm, so if we trim the antenna to that length, reception should be improved.
First unscrew the antenna from its base and mark 69mm from the end:
Then cut the antenna at the point you marked. A stout pair of pliers will work. But use eye protection and take care since bits can go flying:
Here’s a comparison of the “tuned” antenna to the stock antenna:
Screw the antenna back into its base. With any luck you should experience better reception.
Range will be greatly improved if you position your antenna outside (if possible) and as high as possible.
Enjoy your new aircraft tracking hobby!
]]>In this tutorial I provide step-by-step instructions to get a working Armbian Linux environment on the Orange Pi Zero.
As a minimum you’ll need:
You will also need a home network (i.e. a router) with a wired or wifi connection; internet access; and a desktop or laptop computer.
Although not strictly required, a USB-to-Serial converter designed for 3.3V TTL logic levels can really come in handy. I use the Sparkfun Beefy 3 which features the FTDI FT231X USB to serial chip. Whatever converter you choose, make sure it’s designed for 3.3V logic levels, not for 5V, and certainly not for RS232 signalling levels. You’ll also need three jumper wires to connect the serial converter to the Orange Pi Zero.
This tutorial assumes you’re working on a computer running Windows. We’ll need three pieces of software to complete the set up of our Orange Pi Zero:
The Orange Pi Zero needs an operating system to boot. We’ll use Armbian, which has operating system images for many of the Orange Pi models, including the Zero.
Our next step is to boot the Orange Pi Zero. The following steps assume that:
If these conditions aren’t met, you’ll need to skip to the next section and follow the instructions there.
To boot your Orange Pi Zero for the first time:
Within a minute or two the LEDs on the ethernet port of the Orange Pi Zero should start to flash, indicating network activity. Assuming your router is configured for DHCP, the Orange Pi Zero should automatically obtain an IP address on your network.
In order to log into the Orange Pi Zero, we need to know the IP address it has been assigned. Probably the easiest way to obtain this is to login to the administration interface of your router (usually provided as a web interface). It varies from model to model, but many routers will provide a screen which lists DHCP leases. With any luck it will be possible to identify the Orange Pi Zero in the list of DHCP leases and see which IP address it has been allocated. One approach is to take note of the IP addresses in the list before connecting your Orange Pi Zero to the network. Then connect your Orange Pi Zero to the network and to power, wait for it to boot (a minute or two) and refresh the list of DCHP leases. It should now have an extra entry and that entry should correspond to the IP address assigned to your Orange Pi Zero.
Knowing the IP address of the Orange Pi Zero, we can log into it for the first time. In order to do so, we need to use an SSH client to make the connection. In this tutorial we’ll use PuTTY.
You will immediately be asked to change your password. To do so:
Next you will be asked to create a new account. This is a less privileged account for everyday use:
Within a few seconds you should be presented with a welcome message and a prompt:
Congratulations - you have logged into your Orange Pi Zero for the first time.
Before you forget them, record the details of your root account password and your newly created “everyday use” account somewhere secure.
If you can’t determine the IP address of your Orange Pi Zero based on its DHCP lease, another approach is to connect to it via its serial console.
For more information about the Orange Pi Zero serial header, visit this linux sunxi wiki page.
In order to connect in this fashion you’ll need a USB-to-serial converter with 3.3V logic levels and three jumper wires.
To boot your Orange Pi Zero for the first time:
Within a few seconds, the PuTTY window should be flooded with console output:
You will immediately be asked to change your password. To do so:
Next you will be asked to create a new account. This is a less privileged account for everyday use:
Within a few seconds you should be presented with a welcome message and a prompt:
Congratulations - you have logged into your Orange Pi Zero for the first time.
Before you forget them, record the details of your root account password and your newly created “everyday use” account somewhere secure.
To find out the IP address assigned to your Orange Pi Zero:
Now that you know the IP address, in future you can follow the steps in the previous section to connect to your Orange Pi Zero over the network.
To disconnect your serial console:
Now that the Orange Pi Zero is working, we can do some initial set up. The following assumes you are logged into your Orange Pi Zero using either SSH or the serial console with your everyday account. Remember to hit the enter key after typing in each line of commands.
First we’ll update Armbian to the latest version:
sudo apt-get update
sudo apt-get upgrade
The first time you use sudo in a session, and periodically thereafter, you will be prompted for your pasword. Depending on the speed of your internet connection and the size of the update, the upgrade process can take a while.
Next we’ll set the time zone to match your location. To do so, enter the following command:
sudo dpkg-reconfigure tzdata
Then,
Your timezone will be updated and you will be returned to the command line.
Lastly, we’ll set up wifi. This is super handy because once set up, our Orange Pi Zero can be placed anywhere within wifi range where it can be provided with power. To do so,
Open the file /etc/network/interfaces for editing:
sudo nano /etc/network/interfaces
Add the following 4 lines to the end of the file, substituting the actual network SSID and WPA password for your wifi network:
auto wlan0
iface wlan0 inet dhcp
wpa-ssid <Your Access Point Name aka SSID>
wpa-psk <Your WPA Password>
To save your changes, hit the key combination Control+O.
Bring up your wifi connection with the following command:
sudo ifup wlan0
You can find out the IP address assigned to your wifi connection by typing:
sudo ifconfig wlan0
The assigned IP address should appear immediately after the text inet addr:.
You can observe the signal strength and other details of your wifi connection by entering:
sudo iwconfig wlan0
To monitor the temperature, CPU speed and other interesting details of your Orange Pi Zero type:
sudo armbianmonitor -m
(To quit and return to the command line, hit the key combination Control+C.)
To cleanly exit your PuTTY session while leaving your Orange Pi Zero running, type:
exit
To cleanly shut down your Orange Pi Zero before disconnecting power, type:
sudo halt
To reboot your Orange Pi Zero, type:
sudo reboot
Here are just some things you can do now that your Orange Pi Zero is operational:
Your router could decide to assign a different IP address to your Orange Pi Zero ethernet and wifi interfaces in future. If that happens, you’ll have to rediscover the IP address(es) of your Orange Pi Zero… But many routers have the ability to assign fixed (aka static) IP addresses. To do this, you need to know the hardware address of the interfaces on your Orange Pi Zero. To discover these type:
sudo ifconfig eth0 | grep -i hwaddr
sudo ifconfig wlan0 | grep -i hwaddr
The hardware address will be the jumble of hexadecimal numbers separated by colons, e.g “8c:ff:a3:06:b5:1b”, at the end of the line. In your router configuration you need to add a mapping between the hardware address and the fixed IP address to be assigned to the interface.
Have fun!
]]>What I found captivating about these devices was that each neon bulb had a dual function. Not only does each bulb indicate the count but it also stores the state of the count. Each neon acts as a memory device, holding its state until the next pulse arrives. With a handful of neon bulbs it is therefore possible to create a counter or a divider. And the only other parts required are some readily obtained resistors, diodes and capacitors. No transistors, no integrated circuits, no other tubes. Just neon bulbs.
Enchanted by the simplicity of all of this, I just had to give making a neon ring counter a go; here is the result:
To begin I ordered 200 Russian IN-3 bulbs. These were made in the same factories that made Russian nixie tubes until the collapse of the USSR. Mine came from an ebay seller in the Ukraine as new-old-stock (NOS) in the original cardboard boxes. Each bulb is built of the same components, but visually there is quite a lot of variation from one bulb to the next. Some have a darker, sootier appearance to the glass. Some have a slightly larger volume than the others. And some have the anodes and cathodes positioned higher or lower within the glass envelope. When lit, some have a stable glow, while some have a tendency to “wink”! Some look blurry and some glow in the wrong places, while most present the intended sharp squarish dot of orange glow. Clearly there is quite a lot of variation from tube to tube. Far more than what one might observe in a batch of modern, “Western-style” neons. One could view this as endearing or frustrating or both at the same time.
From Roland Dekker’s page I garnered the importance of selecting neons with similar characteristics when making a ring counter. The salient characteristics are “striking voltage” and “maintaining voltage”. The “striking voltage” is the voltage that must be supplied to the tube to make the gas initially ionise. Once the bulb has “struck”, it will maintain its glow as long as the voltage remains above the “maintaining voltage”. The maintaining voltage is always lower than the striking voltage and the difference between the two can be significant (like tens of volts).
I decided to characterise 50 out of the 200 bulbs, so I’d get a good sense of the spread of striking and maintaining voltages. I made a test fixture using a high voltage power supply with an adjustment range from ~65 volts to 105 volts (I took a gamble that the striking voltage of all the neons would fall within this range), 2 voltmeters, a series resistor, and some sockets to hold a neon tube.
One voltmeter measured the supply voltage, while the other measured the voltage across the neon. The test procedure was:
I carefully labelled my neons so I could link physical neons to recorded measurements. Using gnuplot is was able to plot the spread of striking and maintaining voltages for the 50 bulbs. The variation from bulb to bulb was quite pronounced:
A number of sources suggested that the characteristics of “fresh” neon bulbs differ quite markedly to when they have been in service for some time. Apparently after a couple of days they “settle down” and thereafter the striking and maintaining voltages don’t move around too much. So I built a fixture to subject my neon bulbs to 48 hours burn in. My set up consisted of a high voltage power supply (set to about 150V), 14 series resistors, and 14 sockets to attach neons. With this fixture I was able to burn in 14 neons simultaneously. Consequently, to process all 50 neons took 8 days.
After patiently waiting and swapping neons in and out of the fixture, I repeated the process of recording the striking and maintaining voltage of each neon, as described abpve. Here is a plot of the spread of values now:
Clearly the characteristics of the bulbs have changed. Since I had before and after data for each bulb, I was also able to visualise the change in each bulb’s characteristics as a result of the 48 hour burn in:
Some neons underwent substantial changes, particularly in terms of striking voltage. Interestingly there wasn’t a uniform increase or reduction in voltages after burn in. As can be seen the arrows linking a neon’s before and after voltages shoot off in all directions and gradients.
With all the data at hand it is possible to make a selection of well-matched neons. For this, I regenerated the plot of the measured characteristics after 48 hours burn in, this time with each neon labelled. By visual inspection I identified three clusters of neons with strike and maintaining voltages within a tight range:
I labelled each cluster “Lower”, “Middle” and “Upper” and recorded the approximate striking and maintaining voltage ranges for neons in each cluster:
Two parts of the ring counter circuit are affected by the striking and maintaining voltages of the matched neons. These are the cathode resistor (of which there is one per neon) and the anode resistor (of which there is one per ring counter). The values of these resistors are also affected by the supply voltage and the desired current through the neons. On his page, Roland Dekker presents formulas to determine the value of the cathode and anode resistors, with a lot of valuable details about their derivation. I mechanically applied these formulas to determine the “ideal” resistor values for the “Lower” cluster neons, a supply voltage of 150 volts, and a neon current of 800 micro Amps. I then rounded these to the nearest practical resistor values.
Here are the inputs to the formulas:
For the last value, Vmaint,avg, I took the mid-point between the maximum maintaining voltage (42V) and the minimum maintaining voltage (38V), giving a value of 40 volts.
With these values, I calculated Rcathode:
Rcathode = (Vstrike,min - (0.5 * Vstrike,max) - (0.5 * Vmaint,max)) / Ineon
= (73 - (0.5 * 77) - (0.5 * 42) / (800 * 10^-06)
= 13.5 / (800 * 10^-06)
= 16875 ohms
use 18k resistor
And the value for Ranode:
Ranode = (Vsupply - Vmaint,avg - (Ineon * Rcathode)) / Ineon
= (150 - 40 - 13.5) / (800 * 10^-06)
= 96.5 / (800 * 10^-06)
= 120625 ohms
use 120k resistor
This resulted in a circuit as follows:
Next I designed a circuit to generate pulses to advance the counter. For this I used a 555 timer configured as a monostable. For each button press, the 555 generates a clean ~110 millisecond output pulse. The output of the 555 drives an MPSA42 high voltage NPN transistor which pulls the neon anodes low to advance the count. Following Ronald Decker’s advice, I added a 100nF 250V DC capacitor across the transistor (he used 27nF, but 100nF is what I had on hand).
I soon tired of pressing a button to advance the counter, so I designed this continuous pulsing circuit, using a 555 timer configured in astable mode.
Based on the scope trace it pulses around 12.5Hz give or take:
Making a working neon ring counter was a really interesting exercise. I learned a heck of a lot about neons in the process. Taking the extra effort to characterise the bulbs and select well-matched ones was a strategy which paid off when the counter worked first time!
I’d now like to build more ring counters and chain them to create a clock a bit like the one that initially captured my interest.
Now I’m clear on the methodology for doing that:
[Picture/Video]
The display has 97 pixels and is approximately the size of an A3 sheet of paper. The richness of colour, brightness and responsiveness of the display are quite incredible. An Arduino coupled to a Raspberry Pi 3 feed the LEDs with RGB data. It would be neat to scale up the display to cover an entire wall.
Ping-Pong balls are the ultimate economical, readily available diffuser. In addition to helping spread the light evenly across each hexagon, the spherical shape helps each hexagon keep the right shape. The hexagons were sized such that their inner circumference would accommodate a table tennis ball perfectly. The entire honeycomb structure was created with cardboard and PVA glue. It is remarkably strong. The balls were cut neatly into half spheres using a hotwire cutter, so they form a little cap over the LEDs.
The honeycomb structure sits on a board made of 6mm MDF. The LEDs protrude through 97 holes drilled in the board. They are P9823/PL9823 8mm LEDs. These come in a conventional through-hole LED package with four leads — +5V, GND, data in and data out. Bus bars made of copper tape run along the back of the board to distribute power to each LED. A 100nF decoupling capacitor is mounted close to each LED and a few 680uF electrolytic capacitors further stabilise the voltage rails. A small length of wire-wrap wire connects each LED’s data in to the output of the previous LED. At the end of each row, the connections snake around in a L-R-L-R-L-R-L style pattern. The wires are held captive by generous amounts of hot melt glue. Between the green caps, red copper strips, and the stringy glue the appearance is reminiscent of a pizza.
Only three wires connect to the board. The first 2 heavy duty wires carry +5V and GND. Thicker wires mean less voltage drop at high currents, necessary since worst case the panel will draw 3 (R-G-B channels) x 20mA (per channel) x 97 LEDs = 5.82 amps! The third wire carries the 800kpbs data signal. The cable is terminated with a chunky metal-plastic plug that connects to the control unit.
The control unit consists of a +5V 10amp power supply module, fuses, a mains switch, a Raspberry Pi 3, an Arduino, and a socket to make the connection from the display. The Arduino converts an asynchronous serial bit stream from the Raspberry Pi to the serial format used by the LEDs. This has quite precise (and quite fast) timing requirements, so it makes sense to hand this task over to an Arduino. The Raspberry Pi, meanwhile, makes the control unit incredibly flexible. It has enough power to generate pleasant effects on the display, but its ethernet and wi-fi connections allow it to display patterns generated remotely.
On boot, the Raspberry Pi starts listening for ArtNet DMX512 over UDP packets which are interpreted and sent over hardware serial to the Arduino to be streamed out to the LEDs.
The front panel of the control unit has a status LED and a shutdown button. The LED is hooked to the Raspberry Pi, taking the place of its on board activity LED. When the shutdown button is pressed for two seconds or more the Raspberry Pi shuts down cleanly.
]]>We camped out at the UC Heritage Hack node at the University of Canberra. Tim Sherratt organised the “themed” node to cater to those interested in devising hacks around cultural heritage datasets. He provided a large number of examples demonstrating the fascinating insights that can be gleaned from such datasets. He mentioned that cultural heritage data is often far from “clean”. Instead it contains inconsistencies, ambiguous elements, formatting issues, missing fields, and a blend of structured and unstructured data.
All of this was true of the dataset Jack and I chose to work with. Our stated goal was simple: to visualise convict ship journeys to Australia over time. For this we turned to the State Library of Queensland digitised records of the British convict transportation registers. It lists over 123,000 of the estimated 160,000 convicts transported to Australia. What they were convicted of, what ship (or fleet) they journeyed on, when they departed, and where in Australia they alighted. It is a remarkable resource.
At first, a weekend to work solely on the one project felt like an ample time budget. As a father of two marvellous children, it’s fair to say that time for hobbies is eked out in dribs and drabs. But as the list of tasks dawned on the team, it didn’t take long to realise that time would be exceptionally tight. I detected myself subvocalising the words “minimum viable product” throughout the weekend. (Such things happen to those who find interesting lists on Wikipedia). At several points we narrowed our scope from its initial grandiose vision:
The result was Conviction Currents. No clever interactive slider, no ability to freeze on a journey and unpack each convict’s story. But something, nevertheless, on the internet, nonetheless. And a video to boot:
By the late afternoon on the Sunday, we had submitted; one of 437 hacks. I’m not sure about Jack, but I felt shattered the next day.
Here’s what we used to complete our hack:
grep
, head
, tail
, sort
, uniq
, cut
, awk
. All supremely useful. (How many lines of code could I have avoided writing if as a whippersnapper I had bothered to learn these properly?)git init
, git add .
, git commit -m...
, git push
That’s it. Thanks to all involved. Looking forward to next year.
]]>For more details on configuring a wi-fi dongle under Raspbian, visit this post.
]]>Available from a variety of sellers on AliExpress, this module sells for about US$5 delivered.
]]>Here’s a week’s worth of temperature data from around my home. The blue, pink and red series are indoors. The orange and yellow series are outdoors - one inside a homemade Stevenson screen and the other under a pergola on the eastern side of the house.
The indoor readings were produced by DS18B20 one wire temperature sensors connected to nodemcu (ESP8266) wifi internet of things devices. Each sensor+nodemcu arrangement publishes the temperature once per minute to an MQTT broker.
The outdoor readings come from off-the-shelf WH2 temperature sensors. Their 433MHz radio packets are decoded by an Arduino with an ethernet shield which relays the packets, also to the MQTT broker.
A Ruby script subscribes to the temperature topics and logs each reading to an sqlite3 database.
A cron job generates the plots above every 15 minutes using gnuplot.
The plots tell an interesting story of a week in (southern hemisphere) September getting progressively warmer. The wild oscillations in the red series are when the ducted gas heating was operating. The gas heater has some hysteresis - after reaching its set point, it will cut off and wait for the temperature to cool a couple of degrees before turning on again. When the outside temperature is lower the heater cycles more frequently and the ocillations on the red plot bunch up. The heater is burning gas more of the time, to compensate for losses and to keep us warm!
The rest of the indoor readings are less affected by the gas heater. These are influenced more by a slow combustion wood stove. It produces more and more heat as the evenings wear on and tends to swamp any contribution from the gas heater in those parts of the house.
In the first plot it’s easy to tell that someone was at home during the day, since the gas heater was operating. Ambient data - even something as innocuous as temperature data - can be used for snooping!
The third plot shows a light frost, but by week’s end the outside temperature has warmed sufficiently that heating is only required in the morning.
The Stevenson screen does a better job of recording the outside temperature. One can infer that the pergola is on the eastern side of the house because its temperature sensor reading overshoots in the morning, because it is directly heated by the sun. By the afternoon it tracks closely with the Stevenson screen sensor, since it is now in the shade. But it always reads a little higher because it is sheltered by the house.
The gray/white background shows local sunrise and sunset times. The day length is close to 12 hours since the equinox occurs in September. It’s interesting to observe the outside temperature build a little after sunrise.
Data quality is always an issue. In the third plot, the pink series drops out. Why? It could be the nodemcu device crashing, the wifi dropping out, the connection to the MQTT broker failing… Such is the complexity of the internet of things. Nevertheless, interesting data to explore.
]]>I talk about the code that makes this work, including using a Lua table to create a lookup table mapping characters to hex values that are sent to the shift registers to light the correct segments on the Nixie display.
The Lua code is available as a gist.
See also my B7971 character designer and some notes on using the SN75468 high voltage driver.
]]>Could be quite useful to play a high quality sound effect from an embedded project, such as from an Arduino.
]]>Not really gluing so much as welding, I use dichloromethane (aka methylene chloride) to bond the pieces.
]]>I show the breadboarded configuration, the circuit diagram, and the Lua code needed to drive the shift register.
The Lua code can be found here:
https://gist.github.com/lucsmall/66d9b6539df7a0daa569
]]>I bought this product to solve the problem of not being able to locate my house key on the key chain at night. But I couldn’t resist tearing it down to discover the electronics that make it work.
Unlike most solar garden lights, that use Nickel Cadmium (NiCd) or Nickel Metal Hydride (NiMH) battery technology, this unit is powered by a single LiFePO4 (Lithium Iron Phosphate) cell. These cells produce a nominal 3.2V, which means that with a bit of hacking this unit could probably be used to power a microcontroller such as an Arduino at 8MHz.
]]>The result: I can control my fairy lights over wifi, potentially from anywhere in the world using MQTT. The possibilities are endless, but for now I’ll enjoy the cool glow and shimmering reflections of my “Moroccan” fairy lights…
The Lua code for controlling the fairylights using MQTT can be found here:
https://github.com/lucsmall/Fairylights
]]>I hook up the right combination of pull up and pull down resistors, and demonstrate it turning an LED on and off in response to MQTT messages. I draw up a circuit diagram to show how things connect.
Along the way I discover that GPIO4 and GPIO5 are swapped on the silkscreen of the ESP-12 boards I bought.
The Lua code for controlling the LED using MQTT can be found here:
https://github.com/lucsmall/Fairylights
I used the Nodemcu Devkit v1.0 schematic diagram as my reference:
https://github.com/nodemcu/nodemcu-devkit-v1.0/blob/master/NODEMCU_DEVKIT_V1.0.PDF
]]>The idea was to create a breakout board for a Quectel L80 GPS module (based on the MediaTek MT3339 chip). This module has a 0.1in (2.54mm) pin pitch, which is rare for recent GPS modules. Most have 2mm or even finer pin spacing. This module’s pin pitch is a good match for common 0.1in stripboard.
I run into all sorts of dramas with cold, weak etchant that over-etched in places while under-etching in others. But a second attempt yielded an acceptable result. All’s well that ends well.
Would I use this technique again? Probably not. But it was an experiment worth trying.
]]>