POCSAG encoder and 200W transmitter

Lately I've been writing some more code for the amateur paging network project. On Sunday morning I wrote a new POCSAG encoder module in Perl, and on Sunday evening and Monday evening I wrote a simple "modem" for an Arduino card to drive the encoded messages at 512 (or 1200, or 2400) bit/s to an FSK transmitter.

I intend to release most of the bits and pieces as open source, starting with the POCSAG encoder and modem bits. Here's a little video showing the working setup:

As you can see, I haven't grown up enough to not put too many blinking LEDs in my designs. Unfortunately my electronics design skills are mostly limited to calculating the series resistor needed for the LED, so I have to focus my efforts in driving the LEDs from the software in a fancy way. The blue LED does serve a purpose - it shows that the FSK keying timer interrupt routine is working, and indicates it's state. Here's a photo of the Arduino card:


The Perl POCSAG encoder module (POCSAG::Encode) takes one or more messages and encodes them in a binary string. Unlike the other encoders we've found, this one can actually create a long burst with a number of messages, saving a lot of channel time. Only a single preamble is needed, and a lot of idle codewords can be saved between the messages, too.

The burst string is transmitted over USB serial to the Arduino board (the board has an USB-serial chip between the USB port and the Atmel chip) using a protocol which, in theory, resembles the KISS (Keep It Simple Stupid) protocol used with AX.25 packet radio. There are some differences so I've named it PISS, for POCSAG.

The "modem" software on the Arduino waits until the channel is clear, keys the transmitter, and simply sends the bits out through the transmitter's TX data (FSK in) pin. It currently has the usual txdelay and txtail settings hard-coded in the source code. It sends a report back to the host software when the burst string has been received by the modem, and when it has been transmitted, so that the host knows to send the next burst. The Arduino board costs some 20-30€ - if that's too much per transmitter, it's straightforward to just put the Atmel chip on a board alone with an RS-232 or USB transceiver. There are some plans to do just that and design a custom board for the purpose.

The traditional method would have been to drive the FSK out on one of the RS-232 or parallel port handshaking pins. During these days of multitasking and multi-user operating systems it requires a kernel driver, and I didn't quite feel like doing that right now.

The transmitter is a surplus 200W paging transmitter with real FSK keying, configured to run on 144.975 MHz. It happens to have TTL I/O pins, so it can be directly attached to the Arduino.

Erik, OH2LAK, the local repeater builder and coordinator, is also writing about the paging project in his blog. Check out the D-star repeater from a surplus VHF base station radio!

UPDATE 2010-01-31: I finally finished packaging and releasing the software last weekend, and documented it a bit.

Easy map links with labels, dynamic AIS site list, linking enhancements and API terms updated

You can now easily create a link to a position with a label. Right-click a spot on the map, select Add marker to create a temporary marker, drag the marker to the correct spot if it's not there yet, click the marker to open the info balloon, and click on Link to this position. At this point you can edit the label - the shown link will be updated to contain the label (with the correct URL encoding for special and international characters).

Multiple temporary markers are also supported, if you want to mark spots in the map. They only live in the memory of your browser, and are lost as soon as the map view is reloaded or the browser is closed.

The real-time map loading is now much faster by several seconds, or even tens of seconds in some cases. The speed-up was accomplished by not really initialising the date browsing menu before it's actually clicked and opened. The downside is that it now always shows the current and previous year, even if there is no data available for the previous year.

The AIS sites list is now generated automatically. There is a bug in there, causing some stations to not show up in the list. Still investigating that one.

When linking to a callsign, you can now add a parameter others=1 to show other stations, too.

When linking to coordinates, you can now specify a label, which will cause a marker to be shown at the coordinates, and a pop-up balloon showing the label to open.

The API terms have been updated, and a new FAQ item in the end describes the conditions for downloading data from aprs.fi.

Receiver range estimations, colour gradients and AIS receiver list updates

Here's a little summary of changes done during the past weekend and week.

I've changed the colour scale of activity maps to a logarithmic one. This makes the receiving and gating activity maps much more readable:

http://aprs.fi/heard/OH2RCH, http://aprs.fi/gated/OH2RCH, and http://aprs.fi/heard/hkiais - be sure to zoom well out to get the full picture!

The estimated receiving range is now shown for igates and digipeaters. For example, the info page for oh2rch says:

Normal receiver range estimate: 80 km (Updated: 2010-04-12 19:36:27 UTC)

This means that OH2RCH doesn't usually hear packets transmitted much farther than 80 km away. It does hear something from 80-90 km away, and maybe very rarely from much farther away. These statistics have 10 km resolution for up to 200 km, 100 km resolution until 2000 km and 500 km resolution from there on. A monthly receiver performance graph can be seen on the graphs page, with a dotted vertical line marking the estimated normal receiving range. The longest distances are usually caused by bad GPS fixes or corrupted packets. The range is only calculated when the receiver has directly heard at least 3000 packets during the month, so that the estimate is somewhat accurate. This is a new algorithm which will require some fine tuning after some experience is gained.

Last heard a station directly: 2010-04-12 19:36:27 UTC (31s ago)

This indicates that the receiver of the igate is currently working - it has added it's callsign to the path of some APRS packets recently. Please note that because of APRS-IS duplicate filtering only some packets received by the given igate will update this timer.

Owners of AIS receivers can now update their receiver location strings and also configure a home page URL in their user account's AIS settings. These will be used in a new automatically updating page which will replace the old AIS sites list.

On the testing front, I've add system-level tests for the API and the KML interfaces, so that their basic operation is tested every time before building the software installation package.

aprs.fi API, optimisations and rate limiting

The programmers out there might want to try out the aprs.fi API. The code has been there for a while, but I've now polished and documented it a bit. As usual, feedback is welcome.

This evening I've added some optimisations which should make the site load faster, especially over slow connections. It will still be slow on slow mobile devices, I'm afraid.

I've also added rate limiting to protect the service against automated queries by unknown spiders and harvesters. Please let me know if it hits you during normal use. Right after it's installation on Tuesday afternoon it hit all users for a few minutes due to a little installation-time quirk, but that was, sort of, expected. :)