I'm coming over to the US to visit Dayton Hamvention two weeks from now. See you there! If all goes well with the manufacturing, you should be able to recognize me from a nice aprs.fi branded hat & shirt.
For the clothing I had to create a new logo, which can already be seen on this blog and the Facebook page! I'm more of a musician and a programmer than a graphics artist, which is probably visible. :)
I've also been working with the new alerts and map filtering functions. They're quite large improvements and still need a lot of work on the user interface side, although the core functionality starts to take shape already. Stay tuned.
The news of https://aprs.fi/ - new features and interesting attractions found in the APRS and AIS worlds.
Saturday, May 7, 2011
Saturday, April 2, 2011
Map loading problems last night
A memory table containing all of the last position reports for the past 30 hours or so, used for quickly loading the real-time map view, filled up last night on one of the two front-end web servers at around 2010-04-01 23:35 UTC (2010-04-02 2:35 local time). I woke up, noticed the SMS alert and fixed the problem at 2010-04-02 6:50 UTC (9:50 local time).
While the table was full, replication was stopped, and about 50% of real-time map loads (without a station tracked, just an area view) resulted in no stations displayed. Also, 50% of page loads on the site last night returned a bit old data (the stopped frontend continued to display the 23:35 UTC state!).
No data was lost during the incident, APRS-IS data collection continued normally.
While the table was full, replication was stopped, and about 50% of real-time map loads (without a station tracked, just an area view) resulted in no stations displayed. Also, 50% of page loads on the site last night returned a bit old data (the stopped frontend continued to display the 23:35 UTC state!).
No data was lost during the incident, APRS-IS data collection continued normally.
Wednesday, March 16, 2011
Kantronics KPC3+ KISS considered harmful - demonstration videos published
[UPDATE: Do read the comments below the post too, for workaround suggestions.]
If you happen to have a Kantronics KPC-3+ TNC, please do not use it for your APRS igate. It appears to have a software bug which causes delays of over 10 minutes when receiving packets from the radio and then forwarding them to the computer, which then forwards them to the Internet (or possibly retransmits the old packets back to the radio channel, if digipeating).
This is a very bad thing to do, as the greatly delayed packets cause network overload and make moving vehicles jump back and forth between their current positions and the past positions. Looks very funny when aprs.fi tries to draw a track line between the received positions.
For years there have been anecdotal stories and suggestions about a possible problem. Yesterday Alan (radionerd1) has uploaded three videos to Youtube demonstrating the problem. This serves as a nice technical proof that the problem is real, and demonstrably a problem of the KPC-3+. There have been hints that the bug could be in UI-View32 (when using it with the KPC-3+), but Alan demonstrated the problem without involving UI-View.
Alan ran APRSIS32 on a computer, and connected it to two APRS receivers. One used a KPC-3+ and one used AGW packet engine (sound card packet decoder). At first, the two ports received the same packets at the same time. After about a week the KPC-3+ started to misbehave - the received packets were given to the computer only after they had been held as hostage for over 10 minutes. Some people have reported that it can go in this delaying mode within hours or days - it might be due to bad luck, or due to the amount of traffic received. The KPC-3+ did put out a KISS packet to the computer every time a packet was heard from the radio, but it was an old one. When the TNC was reset, it started performing well again.
My guess, as a programmer, would be that the KPC-3+ looses count of the packet it should be transmitting on the serial port. It receives a packet on the radio port, puts it in the received packets buffer, and then prints the wrong packet on the serial port. It might be the oldest packet in the buffer, or thereabouts. The amount of perceived delay would depend on the amount of traffic received in your area.
So, I repeat: If you have a KPC-3+ on your igate in KISS mode, please switch it to something else as soon as possible (KPC-3, OpenTracker, TinyTrak, TNC2 clones, whatever). If you wish to continue using it later, please contact Kantronics at service@kantronics.com and ask them to fix the software bug.
It has been said that the problem only exists in KISS mode. So if you're using the KPC-3+ as a stand-alone digipeater, it should be fine (in this respect). If you're using it as a digipeater in KISS mode, with the digipeating happening on the computer (digipeating enabled in UI-View32 or APRSIS32), the effects are seriously bad, as you're transmitting old packets on the radio channel.
If you happen to be Kantronics, please fix the bug. It's causing a great deal of havoc to the APRS network, and it's messing the contents of the aprs.fi database. Thank you!
If you happen to have a Kantronics KPC-3+ TNC, please do not use it for your APRS igate. It appears to have a software bug which causes delays of over 10 minutes when receiving packets from the radio and then forwarding them to the computer, which then forwards them to the Internet (or possibly retransmits the old packets back to the radio channel, if digipeating).
This is a very bad thing to do, as the greatly delayed packets cause network overload and make moving vehicles jump back and forth between their current positions and the past positions. Looks very funny when aprs.fi tries to draw a track line between the received positions.
For years there have been anecdotal stories and suggestions about a possible problem. Yesterday Alan (radionerd1) has uploaded three videos to Youtube demonstrating the problem. This serves as a nice technical proof that the problem is real, and demonstrably a problem of the KPC-3+. There have been hints that the bug could be in UI-View32 (when using it with the KPC-3+), but Alan demonstrated the problem without involving UI-View.
Alan ran APRSIS32 on a computer, and connected it to two APRS receivers. One used a KPC-3+ and one used AGW packet engine (sound card packet decoder). At first, the two ports received the same packets at the same time. After about a week the KPC-3+ started to misbehave - the received packets were given to the computer only after they had been held as hostage for over 10 minutes. Some people have reported that it can go in this delaying mode within hours or days - it might be due to bad luck, or due to the amount of traffic received. The KPC-3+ did put out a KISS packet to the computer every time a packet was heard from the radio, but it was an old one. When the TNC was reset, it started performing well again.
My guess, as a programmer, would be that the KPC-3+ looses count of the packet it should be transmitting on the serial port. It receives a packet on the radio port, puts it in the received packets buffer, and then prints the wrong packet on the serial port. It might be the oldest packet in the buffer, or thereabouts. The amount of perceived delay would depend on the amount of traffic received in your area.
So, I repeat: If you have a KPC-3+ on your igate in KISS mode, please switch it to something else as soon as possible (KPC-3, OpenTracker, TinyTrak, TNC2 clones, whatever). If you wish to continue using it later, please contact Kantronics at service@kantronics.com and ask them to fix the software bug.
It has been said that the problem only exists in KISS mode. So if you're using the KPC-3+ as a stand-alone digipeater, it should be fine (in this respect). If you're using it as a digipeater in KISS mode, with the digipeating happening on the computer (digipeating enabled in UI-View32 or APRSIS32), the effects are seriously bad, as you're transmitting old packets on the radio channel.
If you happen to be Kantronics, please fix the bug. It's causing a great deal of havoc to the APRS network, and it's messing the contents of the aprs.fi database. Thank you!
Saturday, March 5, 2011
Dayton Hamvention 2011
I'll be coming over to the Dayton Hamvention this year. See you there!
I won't be running an aprs.fi booth or anything, but if you're selling APRS stuff and/or using aprs.fi to demonstrate it in your booth, I'll be happy to stop by and answer questions. Drop me an email – my address can be found in the blogger profile.
I won't be running an aprs.fi booth or anything, but if you're selling APRS stuff and/or using aprs.fi to demonstrate it in your booth, I'll be happy to stop by and answer questions. Drop me an email – my address can be found in the blogger profile.
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!
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:
Well, I finally got around to documenting and publishing the code a couple weeks ago, open source. The answers to the FAQs are:
- 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.
- 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.
- 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.
- 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.
- The POCSAG::Encode module is published on the CPAN, and the Arduino modem on the wiki.
- 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.
- Yes, the POCSAG::Encode perl module should be useful when trying to transmit POCSAG with other kinds of modems.
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!
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.
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!
Subscribe to:
Posts (Atom)