ADS-B Range Testing – Part 2

I ordered the Flightaware bundle from WiFi Expert (antenna, USB pro stick dongle, cable and filter) via there eBay store The idea was to compare it my homemade antenna and NooElec dongle setup. While I know this is not the ideal setup with the LNA inside the dongle it is a worth testing to see what the results can be with a simple off the self setup.

I initially set it up in the backyard, to verify that it was indeed in operating order – it was. Always better to find out before you install it on the roof 🙂 Two days running it there indicated that the performance was no worse than my current setup. This was promising as my backyard isn’t ideally suited for line of sight to anything and to pretty much get the same response as the antenna on my roof indicated the results should be good.

Update 2016-06-04 & 06-25

Roof installation happened today. Quite painful with the high pitched roof and plenty of bird shit under the TV antenna. I removed the old home made antenna and replaced it with the Flightaware one. It’s nice to use proper pole clamps and fixings rather than my hacked up pipe clamps and cable ties – the result felt much more solid.

The old antenna also showed signs of rusting at the F connector – I wonder how long it would have survived in working order? Maybe I should tape up the connectors using self amalgamating tape? Something to look into I guess.

So one day later here are the results.

Range: Generally much better, the long range detection stretching out towards 500 km. I still have issues with detection towards the east sue to the hills which is expected. Range isn’t everything of course.

Message Count: The other major difference I can see is many more messages per second.

I have been able to detect planes landing and tacking off Adelaide airport while they are still located within the airport grounds. Previously I wouldn’t detect them until they were much further out/higher in altitude. A similar result can be seen at Parafield airport. The updated ModesDeco2 map really shows the extended range.

adsb-range-2016-06-25 adsb-adelaide-takeoff adsb-range-modesdeco2-2

Conclusion – is it worth it?

If I was just starting and wanted something simple that just works then yes I’d probably pay for the bundle and it would be job done. The range and performance is very good.

However if you prefer to make your own then you can get almost the same results with a $10 dongle, some coax cable and a bit of handy work.

If you add an LNA and ADS-B filter to your home brew setup I think you would get the same if not better results than the Flightaware bundle – and this might be my next test.

ADS-B Range Testing – Part 1

Long ago I set up and ADS-B receiver with the standard RTL SDR dongle and Raspberry Pi. It runs a combination of modesdeco2 and modesmixer2. The default web interface has a nice radar range graph, but each time you reboot the Pi the range data is gone. I have a piece of software that decodes the ADS-B stream and calculates range and azimuth data for current planes (i.e. location data updated within the last 10 seconds) among other things.

I thought I’d add the ability to save this data to a database so I can graph it and perhaps compare different setups, receivers, antenna, LNA’s and filters.

Here is the baseline graph for about a week ending 2016-04-25. My location is on the slope of a plain that runs north to south and up hill to the east. You can clearly see I have less line of sight visibility in that direction. However to the west the range is pretty good.

The setup is

  • NooElec NESDR Mini 2
  • Hand made 12 (or 13?) element coaxial cable antenna located on the roof
  • Perhaps 15 meters of RG6 between the antenna and the Raspberry Pi


UPDATE 2016-05-06

While waiting for parts to arrive I decided to try shielding the dongle with copper tape. To make it look somewhat neat I opened the case of the dongle and put the tape in the inside. The plan worked but the plastic and copper on the bottom of the dongle is quite close to the PCB so I added a layer of normal tape to the bottom of the PCB to stop shorts. The copper connects to the shield of the USB connector and the surround of the RF connector and encases the entire inside of the dongle. (I’ll add a photo of it later)

Anyways does it help with range? Perhaps, its hard to tell with ADS-B here in Adelaide as we don’t see a huge amount of traffic, and week to week variations could account for changes – who knows – anyway here is the update range graph with data up to 2016-05-06 including the baseline data.


In general, a small increase in range in all directions, with a larger increase to the west, pushing out towards 500 km.

UPDATE 2016-05-28

It turns out I forgot to order the new parts … too busy I guess … so it still will be a while before I get the new parts delivered and installed. In the mean time the shielded dongle has been running for almost a month so we can now get an updated range graph. It generally shows the same as the last update but this time you can see the improvement more easily.  For reference I’ve include my current modesdeco2 range so you can get an idea of the area around Adelaide I can see.


Ubuntu LVM Boot Recovery

Just leaving these notes for next time rather than search the interwebs again.

  • Reboot
  • At the boot options screen select the Advanced Ubuntu item, then the recovery item
  • At the menu that appears select root command line
  • mount -o remount,ro
  • fsck.ext4 -y /dev/mapper/appserver–vg-root
  • exit
  • resume boot

I needed to reboot again to get the boot file system check to perform and get back to read write mode. Still not sure how it got into this state in the first place though ..

Touch Switch Hack Part 1

A (long) while ago I did a post on some touch light switches I acquired. The single button one is still running in the office with no problems. I figured I’d have a go at trying to get the 4 button one to work without mains.

The switch has

  • a glass front plate
  • a top PCB with the PIC, LEDs and touch pads
  • a base PCB with the relays and mains terminals

Livolo Assembly

I took it apart to get the top PCB. It has a clear silkscreen with vias labeled with 3V and 12V. The 3V via went to the VDD pin of the PC, so seems like it runs off 3V provided by the base PCB. Knowing the PIC pin out gives us a GND point on what looks like a programming header.

I traced/buzzed out 4 of the other header pins that control the relays.


(1) is the 3V point, (2) is tht 12V point, (3) is GND, The red dots are the control lines for the 4 relays.

First Test

First test is just to apply 3V and GND to the top PCB only – if it works I can just supply power and take the control lines for the relays to my input modules.

So it powered up, but immediately went into a sequence of alternately red/blue LED every 2 seconds. Oh well not much use, but worth a try,

Second Test

Maybe it needs the 12V for something? This time I applied 12V and GND, connected the top and bottom boards together and powered up.

Again it powers up, the 3V rail is generated and the PIC once again works. However the same 2 second sequence occurs, this time with the relays also changing state in time with the LEDs.

Other Tests

Maybe it needs the glass plate installed to calibrate the touch sensors? nope – powered up with it assembled and still the same sequence.

So what to do next. I will reassemble everything and plug it into the mains just to be sure it actually works as expected – maybe its a dud?

If it works with the mains then at least I know its still a function unit and more hacking/testing is needed to run it on my 12V bus.

Ubuntu and USB Serial Devices

So I had to reboot the Linux server today, and I ran into the problem of it randomly assigning /dev/ttyUSB? devices to my two USB serial cables. With randomly assigned devices my CAN and SMS interface serial port names happened to get reversed – grrr.

So the task is to get Linux to assign the same name when rebooting.

First find out the device serial numbers, use this command and serach for the devices. Luckily in my situation the two cables I have are both FTDI cables with different serial numbers. Here is one

Next is to create or edit /etc/udev/rules.d/50-serial-devices.rules, and add a line for each device using the serial number, and in this case create a symlink to ttynasco0/1.

Restart udev, (reload?,  and trigger?) and magically the new files /dev/ttynasco0 and /dev/ttynasco1 will get created and assigned to whatever /dev/ttyUSB? file the kernel assigns.

Lastly I changed my config.ini file to point to the new nasco tty files.


Update 26/12/2014 – I replaced a cable and needed to update the configuration – It didn’t seem to take effect until I rebooted the machine for some reason.


Ubuntu Services

Now that the CAN and SMS MQTT gateways are working on the proper Linux server I figured it would be better to run them as services instead of having to log in and run them both manually.

In the end it was pretty simple (yay for Google). Here is the script template I have used, modified for each app with proper description, paths and user/group settings.

I think it will run the app, if it does crash then only try to restart it after 60 seconds.

So far so good.

Next up is to start decoding the other CAN messages (calls and cancels) and something like a messaging/allocation app that can use the call/cancel messages and push message out to SMS.

Example Use Case

  • Door bell gets pressed
  • CAN app takes the CAN message and puts it into /messages/can/incoming
  • Allocation app takes that message and figures that a message should be sent as an SMS, then SMS message put into /messages/sms/outgoing
  • SMS app takes that message and sends the message


Installing Oracle Java On Ubuntu

I always forget how to do this so keeping a record here


MQTT CAN Gateway Issues

I have been developing my code on in a virtual machine on my development box. But the intention was to deploy the apps to the same Linux server MQTT is running on.

To this end I checked all the code into SVN and checked it out on the other machine. After the pain of remembering all the libraries to install again, and discovering the pain of hard coded paths and command line builds of Eclipse C++ projects – I finally got it running – yay!


After running the app for a little while it would get into a state where I wasn’t publishing any more messages. I added some extra debug logging which indicated that my publishing flag was not getting set back to false. The callback is just a logging a message and setting the variable to false – cant be that. So some changes …

  • I changed the code to make sure I only attempted to publish one message at a time – no idea if you can have more than one outstanding at any given time, but to simplify the issues just have one – nope still problems.
  • I changed the code again to only attempt publishing messages on the main thread – I was publishing the next message using the callback thread, maybe the library didn’t like this tactic? Nope still problems.
  • I changed the code again to use an atomic<bool> thinking inter-thread issues – nope, still problems.

<hair pulling> – Arrg – It can’t be that hard – the code is really simple!

Possible Problem

The problem appears to thread related, and in particular the order in which I set the publishing flag in the main thread, a slight change and all seems to work again.

The code below shows the line I moved.

You can see that, as it was, if the callback function was called before the main thread had a chance to set the publishing flag the sequence would be

main thread(false)->callback(false)->main thread(true)

instead of my intended sequence

main thread(false)->main thread(true)->callback(false).



MQTT CAN Gateway


I mentioned in an earlier post that my CAN Input modules now supported analog input mode on the first 8 inputs. I showed how I could use these analog inputs with NTC temperature sensors to take readings on a wired network rather than wireless.

The next step was to write a gateway that would take these analog readings off the CAN bus and send them to MQTT in order for the existing perl script to pick them up and mash them into RRD databases – as it already does for the radio sensor data.

Other earlier posts provided some details and results while writing the SMS MQTT gateway. Its no surprise I mostly just copied the code for that interface and used it as a starting point.

The only major changes were

  • Removing the SMS specific code and replacing it with the CAN device equivalent.
  • Adding publish ability to my MqttDataProvider class
  • Hard coded decoding of CAN messages into MQTT topics/content publish calls inside this interface. The topic used is in this case is “/sensors/can/<bus id>/<id>/temperature”

In theory (perhaps I’ll do this later) this gateway should just publish all incoming messages into a single topic (e.g. “/messages/can/incoming”) that other “decoder” applications can subscribe to, decode any messages they know how to and then publish new messages to new topics (e.g. “/sensors/can/1/1/temperature”). 


Anyway, with those changes done its time to test. Here we see log showing CAN interface messages coming in.


Following each CAN messages we see an MQTT publish success – in this case there have been 21,100+ published messages since start up.


So CAN to MQTT is publishing, but how can we see the data – easy enough. The old perl script just needed a new subscribe string to take into account the data coming from can and radio, so here it is. Notice the “+/+/+” replacing the old “radio/+/+”

I still have to maunally create the RRD databases and add the extra graph generation script entries but its working.

The infrastructure needed to get CAN messages into MQTT is working, ready for something perhaps a bit more useful.