Friday, February 18, 2011

Google Latitude support on aprs.fi

It's now possible to upload your position to aprs.fi from Google Latitude. Latitude, in turn, supports uploading position from a large number of mobile devices (Android, iPhone, Blackberry, Nokia/Symbian, Windows Mobile) using Google's Maps and Latitude applications.

See the user guide section on Google Latitude support for instructions.

If you don't see your position immediately on aprs.fi, please wait for a few minutes, and check if Google Latitude has your position on it's own web site. If it isn't shown there, the problem lies with your mobile application's configuration or lack of accurate position information on the phone. aprs.fi currently rejects positions with an accuracy that is worse than 4000 meters.

The web stations page in the user guide is a new thing, too. In addition to Latitude support, it documents the manual updating (point-and-click) and Geolocation API (web browser with GPS support on a mobile device) methods for position updating.

Feedback welcome, as usual!

Wednesday, February 16, 2011

POCSAG encoder and Arduino modem published

Last spring I wrote a bit about our POCSAG paging network project, and published a Youtube video showing a 200W POCSAG transmitter being driven by my POCSAG encoder and an Arduino-based modem.

Well, I finally got around to documenting and publishing the code a couple weeks ago, open source. The answers to the FAQs are:
  1. I've run it on Linux and Mac OS X only, but it should run on any operating system with a Perl interpreter, including Windows, maybe. But I can't help you if it doesn't run on Windows - please find someone with Windows programming experience if you run into trouble.
  2. The POCSAG message encoding happens within the POCSAG::Encode Perl module. On the computer. Not within the Arduino modem. The Arduino modem software is not useful on it's own, the perl code is required to send POCSAG messages.
  3. The Arduino modem is needed because (1) my computers don't have serial ports any more, and (2) bit-banging synchronous 512/1200/2400 bit/s FSK using handshaking pins of a serial/parallel port, like the Baycoms did, is not possible using an USB serial adapter cable (the timing is too strict). The Arduino is a convenient and relatively low-cost platform with a good bunch of TTL level I/O pins and an USB port, and could be easily programmmed to drive the transmitter. If you wish, you can write a kernel driver to drive the FSK bits generated by the encoder, baycom-style, on a serial port (if you have one) and skip the Arduino part.
  4. If you feel the Arduino Duemilanove/Uno boards are too expensive, you can look at the other boards too. Just get one with enough SRAM. If you're brave, you can also put the CPU and a few necessary components on a breadboard or a custom printed board of your own. Instructions here and here and here.
  5. The POCSAG::Encode module is published on the CPAN, and the Arduino modem on the wiki.
  6. Yes, the POCSAG encoder can be connected to any VHF/UHF radio which has a suitable FSK input. Many radios (including some that do have a 9600 bit/s data input) aren't up to the task. I've tried the Motorola GM340 and the Teknomen POCSAG radio only. The GM340 needed some configuration (using the programming software) to make the data input work the way it should for this application. See the comments on the previous post for wiring tips.
  7. Yes, the POCSAG::Encode perl module should be useful when trying to transmit POCSAG with other kinds of modems.
Happy hacking!

Monday, January 3, 2011

Position ambiguity support

Happy new year!

Today I implemented ambiguous position support in aprs.fi. Many APRS transmitters using MIC-E or uncompressed packets can be configured to intentionally transmit less precise positions. This may seem a bit backward at first, but there are perfectly good reasons to do so. Some people might want to transmit a rough location of their car without revealing the exact parking spot where their expensive radio gear spend their night in. Some might like some aspects of APRS but wish to adjust the level of privacy by hiding their precise location.

Ambiguity is configured by setting the number of digits which will be truncated from the end of the position. Plaintext APRS positions are transmitted in degrees and decimal minutes (DD° MM.mm'), with two decimals of minutes. When ambiguity is set to 1, it'll be truncated to DD° MM.m', 2 will transmit DD° mm', 4 will transmit DD° only, resulting in a resolution of 1 degree.
Stations transmitting ambiguous positions are now shown with a purple dashed border around the callsign label. The precision of the position can be visualized by hovering the mouse pointer on top of the station symbol – a purple rectangle will pop up, showing the area of ambiguity. The station symbol is drawn at a slightly randomized position within that area. Also, the info page now says "Position ambiguous: Precision reduced at transmitter by 3 digits, position resolution approximately 18.5 km."

There is one known big bug in this code: the ambiguity is not yet stored together with each position in the position history database. Only the ambiguity of the most recently received position is stored. If you turn ambiguity on or off, the effects on aprs.fi might be slightly weird when looking up old tracks. I'll fix that later when I next change the position history table schema.

I've been told some Kenwood mobile rig owners have accidentally enabled ambiguous positions in their transmitters without realizing what the setting actually does. This change should make the effect visible in a more meaningful way. On the TM-D710, the setting lives in menu 606 (BEACON INFORMATION), POSITION AMBIGUITY.

Off-topic news: Kukka (FIFE GIC Moosegrove Orqideas Doiradas), our lovely chocolate spotted ocicat, is expecting kittens in late January. The sire is CFA CH Windhaven Salt and Pepper, an immigrant from the USA (family tree). She's gained quite some weight, as can be seen in this photo. Kittens for sale later this spring, details at the cattery site!

Saturday, December 18, 2010

OpenStreetMap.org maps on aprs.fi

Today I added OpenStreetMap maps on aprs.fi. They can be selected using the map type drop-down menu in the top right corner of the map.

OSM support has been on my things-to-do list for a couple years, but since then, it had become much easier to do, and the map coverage of OSM had increased greatly.

The OSM maps have data in many places where there's no Google Maps coverage at all (for example, take a look at Tbilisi, Georgia). Around my home there's more accurate coverage of walking paths in addition to roads.

If you'd like to improve the OSM maps in your area, just go to openstreetmap.org and click on Edit. Please see the wiki for more information on how to get started. If you feel the Google Maps aren't so good in your area, editing OSM maps can become a nice long-lasting hobby project!

Thursday, December 9, 2010

Heard & Gated statistics: 6 months of history accessible

The "who heard who" statistics on the info pages of APRS igates and digipeaters now have a pull-down selection for the past 6 months of data. The same selector was also added for the gated and heard maps. The feature had been requested by quite a few users in the past, and it's been on my mind from the moment I added these statistics in the first place. The data was there in the database, I just hadn't gotten around to adding the user interface for jumping between months before now.

Sunday, December 5, 2010

Tracking multiple stations in embedded map

A little Sunday morning coding brought the embedded map up to par with the real-time map's callsign search code. Embedded maps allow you to put a real-time aprs.fi map on your own web page.

To track multiple stations, separate them with a comma (','):

he_track = 'CALL1,CALL2';

This now uses the same search routine as the real-time map. If there are tracking targets in different target classes (APRS, AIS, web) having the same name, you might have to add the class prefix:

he_track = 'a/aurora'; // APRS object Aurora, not the AIS ship Aurora

Saturday, December 4, 2010

Sharing your position on the map without GPS

The aprs.fi site now supports sharing your current position from the convenience of your web browser by simply pointing at the map, without using a GPS or web browser Geolocation API support.
  1. Sign up to the service, if you haven't done so already. Your account's nickname will, by default, be used to mark your position.
  2. Log in!
  3. Find your current position on the map.
  4. Zoom up close for more accurate pointing.
  5. Right-click the position and select Upload my position. On a Mac, press ctrl to simulate right mouse button. Left-handed mouse setup will probably use the left button, but if you have one, you know better.
  6. If you didn't get the position quite right, simply move the symbol image by dragging and dropping it.
  7. When you've moved, right-click and upload the position again.
To change the symbol icon, the web station's name, or the comment text, click on the Favourites (star) tool button in the top right of the screen, and select My stations and bookmarks, and then Settings from the default My web stations item.

I also upgraded the web server software to a new major release. Nice surprise – it didn't require any configuration changes, it just worked. Or so it seems.