Aprs-on-rpi

From wikipost
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This is the web log for the APRS on Raspberry Pi project.

All this came about when some club members asked me if they could replace their Windows XP box running UI-View32 with a Raspberry Pi computer.


Raspberry Pi Single-Board computer, Model B


Project timeline:


31 October 2013

This is pretty much when things started. Initially I made an inventory of the various bits of APRS software available on the RPi and it all looked promising. I used a Raspbian image as the basis and added some tools like remote access software to the X-Server (using X11VNC).


4 November 2013

The software on the RPi will either be Xastir or aprx. Exchanged some information about which radios to use and pinout diagram for the Kenwood D710 back connector. Managed to configure the soundmodem software to talk to the sound card. But there is a problem. Although it produces what sounds like APRS packets it is very noisy, the signals are not clean and will most likely be corrupted.

CMedia CM106 USB Sound Card

The USB Sound Card I am intending to use is the CMedia CM106. It is an external USB device and retails for about $10 on eBay. This card works reasonably well for an SDR (software defined radio) project I played around with some months earlier.


6 November 2013

Reading up on pre-emphasis and de-emphasis and how it affects the probability of successfully decoding packets at the other end. Best write-up is here: http://www.febo.com/packet/layer-one/transmit.html

To satisfy my curiosity, I managed to get an SDR dongle to work under Windows 7 using SDRSharp to produce the audio heard on 145.175 (the Australian National APRS frequency) and feed it using a 'virtual audio cable' to AFSK1200 (QTMM program). I could see several successfully decoded packets flying by!


12 November 2013

After many hours of configuration changes I am still not able to produce clean-sounding APRS packets. I tried several USB modems and they all produce packets with enormous distortion. I compiled the software from source and tried different sampling rates. All to no avail. The output volume is way too loud and distorted and I can't seem to control its behaviour. Thinking of leaving the soundmodem route for now and focus on RS-232 enabled TNC devices.


18 November 2013

Found some reasonably priced TNC's that have built-in RS-232 ports (some using FTDI TTL-to-UART). The Argent Data OpenTracker-USB and the TNC-Pi (a board, custom made to be placed on top of a Raspberry Pi).


TNC-Pi board
OpenTracker USB TNC



21 November 2013

Ordered myself the Argent Data OpenTracker-USB TNC. At $45 I don't mind the expense as it will probably enable me to get the aprs working quickly and can then focus on getting the software side of things in order.


20 December 2013

With the newly received OpenTracker-USB TNC I was able to make up a simple interface cable and configure aprx on the RPi. Success! It was decoding APRS packets from the radio in a short matter of time. The receiving side can be considered solved using this technique.

The OpenTracker-USB can also be used for generating packets to be sent to the radio.

For my setup this requires an additional circuit since my handheld radio uses a combined line for Microphone signals and PTT and the radio does not feature a VOX (voice operated switch). Most newer handhelds will just have a VOX, which will key the radio into transmit when it hears a packet from the TNC to be transmitted. Most base station radios however will just have separate PTT and Audio-In lines making it fairly easy to use the OpenTracker-USB for transmit. With the success of Receive-only APRS decoding under our belt and the summer holidays upon us it is time to reconvene in the new year..

Edit: The opentracker USB has circuitry on-board that allows for easy interfacing to Handheld Radios that use the shared PTT/MIC/Bias-Voltage technique. In the end I stopped using the Opentracker and moved back to the successfully working USB Sound Card technique and using a GPIO pin on the RPi to trigger PTT.


22 March 2014

Keeping the project alive by refining the RPi software a bit and working on a web-interface to the various controls of the software.


13 July 2014

I've been distracted by other projects that are somewhat related but aren't finished. The idea was to run my aprs-rpi igate experiment off batteries in the shed but I noticed that I didn't have full control over when the battery would need recharging. To that effect I started designing a voltage-datalogger and got stuck in pcb design, FET selection and working with circuit simulation software LTspice. Then I got distracted again by updating my satellite tracking software for Android and now I'm looking at putting together a skew-planar circular polarised antenna for working the satellites. Trying to source sturdy metal wire for the elements is in full swing.

I also finished the transfer of my home server from a (small) SheevaPlug to the (even smaller) raspberry pi. Now that that is running nicely and the financial year has been dealt with I got going again with the aprs-rpi project. A second rpi (the model A version without ethernet and only 256MB memory) is now talking fine to the OpenTracker-USB TNC and I'm now at a stage where the little web-interface I wrote is able to start/stop the services, update configuration and show some logs.


16 July 2014

Aprx version 2.08 (latest version) installed on the APRS-RPi base image. Demonstrated the receive-only capabilities to fellow club members and the web interface (although primitive) is working well.


18 July 2014

Wrote a web page that shows the 'dmesg' log to reveal what the kernel says about inserted devices such as an RS-232 TTL-UART adapter that is used as the serial port for the OpenTracker-USB. Having this information on a webpage makes configuration much easier and doesn't require the end user to know much about Linux internals.


29 July 2014

In another session at the radio club to configure and demonstrate APRS on the RPi I somehow damaged my OpenTracker-USB. It is running very hot when powered on and no lights are blinking. This is unexpected and throws a spanner in the works.. I contacted the manufacturer Argent Data in the USA and the owner agreed to have a look at repairing it. I sent it by air mail a few days later.


31 July 2014

Without my OpenTracker TNC I got back to getting the soundmodem method to work. Lo and behold, after a few more tweaks I was finally able to get a generic USB sound card to work as a modem. Combined with a program called 'Direwolf' i can now reliably decode (and probably send, but I haven't connected PTT nor audio-out to my handheld transceiver) aprs packets. The Direwolf software looks very similar to aprx and also works off a single config file.

I was also able to get the SDR dongle to work on Linux. Using the Direwolf application I could decodes APRS packets. It did lock up a few times though. Not sure what causes it. Even though it can be made to work I will not spend too much time and effort to this method as the SDR dongle is not able to transmit signals. Perhaps ideal for an iGate but not for setting up a full rx/tx digipeater.

Got some feedback from the fellow hams who are interested in this project that they are happy to purchase the TNC-Pi board. This would be another easy route to take as it just connects to the Raspberry Pi GPIO header pins and it has almost everything on there to set up a digipeater with few extra components.


3 August 2014

Almost finished working on putting the RPi, the radio and everything required to run an aprs system inside a metal toolbox. This way it is all neatly contained in a single unit and easy to transport. Also started re-designing the web interface to make it look a bit more coherent.

APRS Control Panel, version 2

3 September 2014

For my 'APRS toolbox' setup I will be using the soundmodem (with USB sound card) setup. Since the radio I wish to use is a 2m handheld (IC-P2AT) and it doesn't have separate PTT and Audio-in lines it needs an additional circuit to use the audio coming out of the sound card to both key the radio into transmit and add the audio signal on top of this line. This technice is often used in handheld radios. I have started gathering some simple VOX (voice operated switch) schematics and attempted to combine them to the Audio-in line.


15 September 2014

My repaired OpenTracker USB arrived in the mail today. It looks like the 4-sided (quad flat package) microcontroller chip has been replaced. I might end up using this tracker in my car or for other purposes as I am fairly confident the soundmodem technique will be a winner.


23 September 2014

The TNC-Pi has arrived at one of the club's members and it is visible from the RPi. We ran out of time today to fully configure it all up but it looks like a neat solution and seems to have all the smarts on-board. There were some errors when accessing the TNC-Pi board from the RPi, but this may be just a simple configuration error. While we were there my receive-only APRS Toolbox was successfully decoding packets all throughout the evening. We also concluded that the 'missing link' is an interface cable that goes between the radio (6-pin mini-din female at the back of an Icom IC-207H) and the TNC-Pi (RS-232 female connector).

Icom IC-207H

The radio that will be used to set up a dedicated digipeater using the TNC-Pi board on a Raspberry pi.


24 September 2014

Added a webpage with details on how to set up a simple reboot/shutdown button for the Raspberry Pi. Full details, schematics and code here: http://www.marcelpost.com/wiki/index.php/Rpi-shutdown-button


30 September 2014

Gathered at the radio club again and made up the interface connecting cable for the TNC-Pi to the IC-207H radio.

Interface cable for IC-207H
Radio and TNC cable pinout


After we fixed up the small configuration error in aprx.conf (it was using the serial port to talk to the TNC-Pi instead of the AX.25 port) the TNC-Pi was able to successfully receive and send packets. Success! All that needs to be done now is to calibrate the TNC's transmit level so that the radio's limiter doesn't kick in for the 2200Hz tones (1200Hz tones will be fine then too). I plan to use another handheld receiver (Baofeng UV-5R) with its audio going to a small digital oscilloscope (XMEGA Xprotolab from GaboTronics).


07 October 2014

Attempt to calibrate TNC-Pi for proper audio TX levels. Looks like the IC-207H (as well as Alinco DR-135, Kenwood TS2000 and D700) does not have a pre-emphasis network. The following website deals with setting the audio levels by using a low tone that is generated on the TNC-X (common ancestor of the TNC-Pi). http://fettechnologies.com/tncx.html

Made a high-pass filter using an opamp that can be used for the Pre-Emphasis. It seems to respond well but it hasn't been tested with live data yet. I also worked out a design for a low-pass filter which is for the De-Emphasis. More information on the designs and LTspice models here: Opamp-filters.


04 November 2014

Tested out the new opamp HPF/LPF circuit. The IC-207H was able to send out APRS data which was successfully decoded on another station. Further testing needs to be done as the overall audio-out level seems fairly low (around 50% volume level) when compared with live traffic (around 70% volume level) from our local digipeater. The TXDELAY option in /etc/ax25/soundmodem.conf worked well to open the radio before sending data. Not sure yet of the influence of the trimpot onboard the TNC-Pi to also tune the TX Delay.

Some other information relates to the APRS digipeater settings themselves. It turns out that a fill-in Digi should have its PATH setting to WIDE1-1 and nothing more. This was confirmed by various documents including one from Bob Bruninga himeself. See my dedicated page on the APRS Path settings here: APRS-path.

There was also the request to find out what SSID could be used for testing and troubleshooting. The list of possible SSID's recommends to use -6 as the SSID for 'special events' including tests.

Several web frontend improvements were also made but these haven't been rolled out yet to a production-image of the Raspbian SDcard. It is planned for our next get-together to roll out the latest version to our testing setup.


18 November 2014

Yesterday’s evening at the club was another one of those ‘two steps forward one step back’ events.

The test setup ran successfully with the new Raspbian version, also running the new Raspberry Pi firmware and the new APRS web gui. With some minor tweaks it all worked well. I’ve started giving version numbers to the gui to keep track of who’s running what. The version Warren is running is v0.02. This version fixes some bugs, adds some control to which services are running at system startup and brings you back to the configuration page after hitting ‘save’ when editing a configuration file. I’ve also identified some more areas where things can be improved.

With the oscilloscope we were able to measure the range of the output volume of the TNC-Pi board when transmitting a packet. Trimpot R7 (10k, near the DB9 connector sets the output volume from 0V (turned fully counter clockwise) to 700mV (turned fully clockwise). Halfway is around 325mV so the trimpot is Linear. Using the scope (and the tone generated when the TNC-Pi is in receive mode) we set the output volume of the TNC-Pi to 400mV PtP. The TNC-Pi has no pre-emphasis so the 1200/2200Hz tones will be at the same level.

TNC-Pi trimpots

This means that the TNC-Pi should now be properly adjusted for the IC-207H and drives the TX audio signal (with or without the opamp filter pre-emphasis circuit) to the radio’s maximum allowable input level of 400mV PtP. We still need to confirm this with another radio to make sure it's not overdriving anything.

Next up we wanted to have a closer look at the TXdelay settings. The AX.25 suite of programs however has a program called kissparms. This should be the right tool to influence the AX.25 network interface parameters but trying out various settings did not reveal any audible change in behaviour. This calls for more investigation and it will be the main point on the agenda until this is understood and resolved.


25 November 2014

Another productive evening at the club last night. With only a few tweaks the latest web-gui version is now properly showing the RX and TX packet counters. We also found out that changing the SSID (the bit after the callsign) needs to be changed in both /etc/aprx.conf and /etc/ax25/axports. Once we did that all successfully received packets (as seen on the interface) were visible in the aprx-rf.log on the web gui front page.

We also experimented with the de-emphasis filter as earlier field tests never succeeded in receiving or decoding any packets. The same was confirmed at the club. With a little bypass cable the de-emphasis filter was taken out of the loop and received packets started rolling in. The conclusion can only be that the de-emphasis filter needs a little more work.. Right now the radio is not applying any de-emphasis but apparently the TNC-Pi is tolerant of these signals. By the end of the evening after running solidly for about 50 minutes we could see that over 90 packets were successfully received, the log was showing the contents of the decoded packets on the screen and the graphs showing the number packets per minute and Bytes per second were updating nicely. The next step here is to hook up the unit in the field and after it has confirmed proper working to configure it as a fill-in digi.

We also measured the output level on the data port of the IC-207H for received packets. We hooked it up to the cro and noticed that most received packets were around 270mV PtP. It is unclear yet whether this is the maximum range as we don't know the drive level of these packets but it gives us a ballpark figure to work with for redesigning the de-emphasis filter.

We had access to an FM Deviation Meter and testing with a handheld transmitting a DTMF signal it clearly showed the deviation.

Wayne-Kerr Automatic-Modulation-Meter AMM-257.JPG


After setting up the RPi and TNC-Pi we then tried to measure the deviation of the aprs packets. Well, wasn’t that interesting.. It turns out that the deviation meter needs some time to properly lock on to the signal before it can measure the deviation. The transmitted packets however were not long enough for the deviation meter to lock on! We tried to increase the length of the packets but could not find an easy way to do this. Apart from using a different technique altogether I can think of two other things we could still try. Firstly, the packet length could be made longer by increasing the ident text string (e.g. change ‘RX-Only iGate’ to ‘RX-Only iGate testing123 testing123 testing123, etc..’). Perhaps with a lot more characters the packet will scale up and be long enough for the deviation meter to properly lock on to the signal. Secondly, we could use the 487Hz tone that is generated on the TNC-Pi board as the reference point. This tone should have 775Hz deviation.


2 December 2014

We increased the contents of the text-field that is shown as a comment when a beacon packet is sent (e.g. ‘Rx-Only iGate’). We added about 100 extra characters and it made the duration of the packet transmission just long enough for the deviation meter to just get a lock on the signal. On receiving the signal the deviation meter would fully deflect the needle and then slowly come back to point to the real value on the scale. It took several attempts and after seeing several packets in a row bring the needle to around 3kHz we agreed that the deviation was within an acceptable range.

The next step was to configure aprx to be a Fill-in Digipeater listening with the WIDE1-1 alias. After a quick google search and hitting the aprx google groups site we tested a configuration that seemed to work pretty much at the first try. We watched the aprx-rf.log for any locally received packets from nearby digipeaters (VK2RTZ, VK2XPT, VK2RTM, VK2RPM, VK2RHR, VK2UNI) and confirmed that none we re-transmitted by our station. We then forced some beacons to be transmitted from a local car’s tracker and they all were heard directly and successfully retransmitted. We also had someone trigger a beacon from the other side of nearby Mount Sugarloaf and although we could hear their packet being re-transmitted from the WIDE2 digi VK2ATZ on Mt Sugarloaf it wasn’t heard directly by us and was therefore not re-transmitted by our station when we heard the WIDE2 repeats. For as far as our knowledge goes this seems to confirm that the Fill-in Digi is listening properly to locally heard direct packets and doesn’t re-transmit any packets from other Digi’s (either other Fill-ins or normal Wide Digi’s). One of the guys had to leave early and switched on the tracker in his car when he left. We could see several of his directs come through our station and they were re-transmitted. When he got further and further and out of range he was starting to be picked up by the WIDE2 digi VK2RTZ. There were a few more spots where we could hear him direct until he was over the hill and only heard by VK2RTZ. This real-world scenario where our station was able to ‘fill-in’ the holes demonstrated the value of a Fill-in Digi.

At the end of the evening one of they guys took the station back to his QTH and connected it all up running his first night as a Fill-in Digi on a Raspberry Pi. He has been running his fill-in digi ever since and it has clocked up thousands of packets and seems to be running perfectly.

This pretty much concludes the blog on this particular station's setup. It has been a great learning curve and the end result is a fully working Fill-in digi that is based on affordable hardware and runs at low power (about 6W when not transmitting).

For more practical information on setting up an APRS station on different hardware, please check the Aprs page on this site.

TODO (some day):

  • Re-design the low-pass (de-emphasis) filter for radios that have 'flat' audio
  • Tune aprx Digipeater settings and filtering
  • Further web frontend improvements
  • Realtime Clock / NTP / GPS