To celebrate my birthday (tomorrow!) I took the liberty to implement a couple of new features. For a long while I've been planning to add tabs to the configuration options window, so that it could be cleanly extended with new options. After I got that out of the way, it was quite straightforward to go on and add a couple of additional options which have been requested several times before:
It is now possible, from Options => Colours, to select the 5 colours used for track lines. You can also tune the track line width to increase (or decrease!) the visibility of each line.
Each station always gets the same track colour (colour 1, 2, 3, 4 or 5) out of the 5 selectable colours. If you find that your car always gets a blue line, and you would want to switch that to red, you'll see that colour 3 is blue by default, so you can switch colour 3 to red. And maybe switch colour 1 to blue to reduce the amount of red track lines. You could also set all 5 colours to red, if that's your favorite.
You can also enable sound effects from Options => Sound. Currently the only supported effect is a "tock" when a tracked station moves to a new position. I'm going to add different sound samples later. If you have other ideas for events which could trigger a sound, please let me know!
The news of https://aprs.fi/ - new features and interesting attractions found in the APRS and AIS worlds.
Tuesday, September 30, 2008
Wednesday, September 17, 2008
OH7RDA digipeater installation
Last weekend we went and installed the OH7RDA APRS digipeater on top of a hospital in Siilinjärvi together with the local hams from my old hometown, Kuopio. The Tarina hospital is located on a hilltop 16 km north of Kuopio, with a pretty good open view in all directions. We used to have a packet radio node at the very same location with 1200 bit/s access on 144 MHz and two 9600 bit/s links on 434 MHz, but the site had been abandoned for quite a while, due to lack of interest by everyone involved.The old 2-meter radio, a modified Finnish mobile VHF radio with an embedded TNC2 clone (OH-TNC v2), was still in working condition, the power supply turned out to be just fine once one lead which should be attached to the rectifier was reconnected, so we just needed to install a vertical antenna, a new cable, and set up the APRS digipeater software.
(On the left: OH7TB attaching an N connector to the cable)I obtained a 3*5/8λ vertical (dual-band, 8*5/8λ for 70cm), the guys in Kuopio had the coax and fixed the power supply. I set up an UIDIGI EPROM for the TNC, and replaced the backup batteries (sealed lead-acid) inside the radio-tnc combination.
I couldn't configure the UIDIGI to properly do WIDEn-N digipeating with callsign prepending (only when digipeating the packet for the first time), so I found a surplus miniature PC to run Linux and digi_ned. Now that the digipeater is already installed, it turns out UIDIGI could, perhaps, be configured to do the Right Thing, OH2NJR has been making some progress on that.
Anyway, I put a 2G CompactFlash card in the PC to make it more reliable - spinning hard disks at sites like this tend to break way too often. I installed Debian Linux on it, removed mostly all extra packages to make the installation small and quick to update, and then made sure it doesn't write on the flash card on a regular basis, since that tends to wear out the flash memory over time. That required 4 things:
- Moving all temporary directories from disk to memory (/etc/fstab: "tmpfs /tmp tmpfs defaults,noatime 0 0", repeat for /var/tmp and /var/lock too)
- Mounting all flash partitions with the noatime option (defaults,noatime in fstab). As an alternative, they could be mounted read-only, but that requires additional tricks.
- Disabling stuff from crontab: see /etc/cron.(hourly|daily|weekly|monthly)/, /etc/cron.d/ - it's no use doing much else than log rotation on a box like this. Updating manual and locate databases is a waste of flash write cycles on an unattended mountaintop PC.
- Moving all log files to /var/tmp and making sure they are rotated quickly enough so that the partition will not fill up. I edited /etc/syslog.conf to make all system logs to go to a single /var/tmp/messages, and disabled all logging on the digipeater software.
I also added a small script, run hourly from crontab, which restarts digi_ned if it would happen to die for reason or another. I haven't been running it anywhere before, so I don't know how stable it is, and on an embedded box with 128 megs of non-ECC memory, anything can happen in a few years.
A couple of hardware pieces needed to be purchased for the PC:
- A CompactFlash - IDE adapter: about 3 USD from DealExtreme - including shipping. Make sure you get the right type for your IDE cable (male/female, correct size - laptop IDE 44 or desktop-style IDE 40 cable)
- An USB serial dongle to connect to the TNC: less than 5 USD from DealExtreme. The Prolific driver in Linux has been written using reverse engineering techniques, and it doesn't support all of the low speeds below 9600 bit/s, but that doesn't matter here.
- The CompactFlash card. DealExtreme sells these too, but they aren't much cheaper there. There are "industrial" versions of the cards which should handle more write cycles, but if you can eliminate all of the periodic write cycles (watch your iostat) which happen after the reboot, it doesn't really matter.
Here, OH7FDN and OH7RJ are attaching guy ropes to the 5-meter-long Diamond vertical. Let's hope it lasts for a few years, and replace it with a proper commercial antenna when it breaks.Some of the DealExtreme stuff doesn't have much quality packed in, but the price is fine. You can't get any better CF adapters anywhere, they're just going to cost more, and they'll still be from the same Chinese factory. Beware, that shop is very addictive. The stuff is just too cheap. I'm suspecting child labor and way-too-low wages for those who do the packing and mailing.
OH7VM and OH7RJ with the installed antenna.Photos by yours truely. There's some more if you're interested.
The digipeater seems to be working fine. There's not much activity on the north side of Kuopio (yet), but you can take a look at the APRS position packets heard by OH7RDA. It seems to work just fine for a mobile in Nilsiä.
I'm also building a PIC-based logic card for the OH7RAA repeater (145.600 MHz, -1.6 MHz, in Kuopio). The board can already send a CW id, but I haven't yet wired the 1750 Hz and DTMF decoder chips. Yes, the voice on the mobile phone video is mine.
Saturday, September 13, 2008
How do guessed time zones really work?
This question pops up every now and then, especially when the timezone guessing goes wrong for someone. So, here are some dirty details, which I just posted on the APRSSIG mailing list.
The aprs.fi service tries to guess where each site visitor is located. It's based on the IP address of the visitor, nothing else. Yes, it could be based on your default map start location, thank you, that's a good idea. Then, it looks up the timezone for the guessed city, which is pretty straightforward and works just fine. The guessing results are stored in a cookie, and you can force a retry by deleting the cookies set by aprs.fi.
For some areas, the visitor location guessing code simply guesses wrong. It works just fine for most people, and for some, it always gets it wrong. For example, it thinks everyone working for Nokia (Corporation) are actually located in the city of Nokia, Finland.
Currently the only real option is to select UTC in the Options window of aprs.fi, which, of course, does not really fix the problem. I should do a proper "pick any timezone" selection, like openaprs has. It's actually been "half done" for about a year now - I have the timezones database loaded in already.
The complication here is that the some of the time formatting happens on the client computer's side (in the Javascript code which runs on your web browser). Over there I can practically only select between UTC and the local time as decided by your web browser / operating system. There are no javascript localtime conversion functions which would take an arbitrary timezone definition (at least I couldn't find them :), and it'd be a pain to reimplement them with the DST stuff and everything. The "guessed" local time will be whatever you have selected in your operating system.
So, to do arbitrary timezone selection properly, I'll have to move all of the localtime conversions from the client-side code to the server side, and that'll make things marginally slower for everyone. Now the server is just giving Unix-style timestamp integers (seconds since 1.1.1970 00:00:00 UTC) to everyone who is looking at the real-time map, and the web browser gets to do the localtime conversion when it's needed. If your operating system knows your proper timezone, you'll notice that the real-time map view (the target info balloons etc.) gets it just right.
Yes, I'm going to do this eventually. The performance hit is marginal, it'll just eat a bit more memory on the web browser's side (to store the text strings for the timestamps in addition to the small integers), and a bit more CPU on the server side (to do the conversions for everyone). I'm trying to keep track of all of these and gain a little bit of extra performance everywhere I can, to keep things running quickly.
PS. I've been in Kuopio this weekend, installing the OH7RDA digipeater together with the local guys from my old home town. Thanks OH7RJ, OH7TB, OH7VM, OH7FDN. It's at a pretty high location, on the roof of a big hospital building, which is on a top of a hill. 3*5/8λ vertical, 20W, TNC2 with JKISS, digi_ned on a Linux PC, with a CompactFlash card instead of a hard drive. I'll try to document the setup with some photos later. It's nice to do some hardware hacking for a change! It'll be interesting to see how the digipeater's heard stations map develops for this new digi. Tomorrow morning, on the way home, I'll offer it some traffic on the south side of the city.
The aprs.fi service tries to guess where each site visitor is located. It's based on the IP address of the visitor, nothing else. Yes, it could be based on your default map start location, thank you, that's a good idea. Then, it looks up the timezone for the guessed city, which is pretty straightforward and works just fine. The guessing results are stored in a cookie, and you can force a retry by deleting the cookies set by aprs.fi.
For some areas, the visitor location guessing code simply guesses wrong. It works just fine for most people, and for some, it always gets it wrong. For example, it thinks everyone working for Nokia (Corporation) are actually located in the city of Nokia, Finland.
Currently the only real option is to select UTC in the Options window of aprs.fi, which, of course, does not really fix the problem. I should do a proper "pick any timezone" selection, like openaprs has. It's actually been "half done" for about a year now - I have the timezones database loaded in already.
The complication here is that the some of the time formatting happens on the client computer's side (in the Javascript code which runs on your web browser). Over there I can practically only select between UTC and the local time as decided by your web browser / operating system. There are no javascript localtime conversion functions which would take an arbitrary timezone definition (at least I couldn't find them :), and it'd be a pain to reimplement them with the DST stuff and everything. The "guessed" local time will be whatever you have selected in your operating system.
So, to do arbitrary timezone selection properly, I'll have to move all of the localtime conversions from the client-side code to the server side, and that'll make things marginally slower for everyone. Now the server is just giving Unix-style timestamp integers (seconds since 1.1.1970 00:00:00 UTC) to everyone who is looking at the real-time map, and the web browser gets to do the localtime conversion when it's needed. If your operating system knows your proper timezone, you'll notice that the real-time map view (the target info balloons etc.) gets it just right.
Yes, I'm going to do this eventually. The performance hit is marginal, it'll just eat a bit more memory on the web browser's side (to store the text strings for the timestamps in addition to the small integers), and a bit more CPU on the server side (to do the conversions for everyone). I'm trying to keep track of all of these and gain a little bit of extra performance everywhere I can, to keep things running quickly.
PS. I've been in Kuopio this weekend, installing the OH7RDA digipeater together with the local guys from my old home town. Thanks OH7RJ, OH7TB, OH7VM, OH7FDN. It's at a pretty high location, on the roof of a big hospital building, which is on a top of a hill. 3*5/8λ vertical, 20W, TNC2 with JKISS, digi_ned on a Linux PC, with a CompactFlash card instead of a hard drive. I'll try to document the setup with some photos later. It's nice to do some hardware hacking for a change! It'll be interesting to see how the digipeater's heard stations map develops for this new digi. Tomorrow morning, on the way home, I'll offer it some traffic on the south side of the city.
Thursday, September 4, 2008
Slovene / slovenščina translation
S56G has started a translation to Slovenian, which I had missed. I have now enabled the partial translation. If you know Slovenian, or any other language with a missing or partial translation, please help with the translation project. Thank you!
Wednesday, September 3, 2008
Digi/igate coverage maps
Last night I finished implementing APRS igate and digipeater coverage maps. They come in two flavors (examples from the San Francisco area):
- A 'heard directly' map: http://aprs.fi/heard/W6YX-5, showing packets which have been (supposedly) heard first by the given igate or APRS digipeater. This map can occasionally show some extra coverage if there are digipeaters with no callsign prepending in the area, but I'm trying my best to catch those. If there is good direct receive coverage by one more igates, those will "eat away" the displayed coverage of the digipeaters in the same area, since the digipeated packets will be filtered as duplicates on the APRS-IS.
- A 'passed packets to the Internet' map: http://aprs.fi/gated/W6DTW. This display shows packets which have been gated to the APRS-IS by the selected igate. This gives a rough idea of the service area of the igate, together with the surrounding digipeaters.
The statistics are currently calculated over the last 48 hours. Links to these are only on the info pages (if applicable), but I'll try to add them in the info balloons on the map. The data was already in the database, I just had to add a single index and implement the user interface. As usual, there are a few new strings to be translated.
The 'heard' map could be useful for fine-tuning the PHG information transmitted by a digipeater.
- A 'heard directly' map: http://aprs.fi/heard/W6YX-5, showing packets which have been (supposedly) heard first by the given igate or APRS digipeater. This map can occasionally show some extra coverage if there are digipeaters with no callsign prepending in the area, but I'm trying my best to catch those. If there is good direct receive coverage by one more igates, those will "eat away" the displayed coverage of the digipeaters in the same area, since the digipeated packets will be filtered as duplicates on the APRS-IS.
- A 'passed packets to the Internet' map: http://aprs.fi/gated/W6DTW. This display shows packets which have been gated to the APRS-IS by the selected igate. This gives a rough idea of the service area of the igate, together with the surrounding digipeaters.
The statistics are currently calculated over the last 48 hours. Links to these are only on the info pages (if applicable), but I'll try to add them in the info balloons on the map. The data was already in the database, I just had to add a single index and implement the user interface. As usual, there are a few new strings to be translated.
The 'heard' map could be useful for fine-tuning the PHG information transmitted by a digipeater.
Google Chrome supported
Google has just released Chrome, their new open source web browser. It seems to work just fine with aprs.fi, and it's blazingly fast too. Windows only, for now. They have a nice cartoon describing the internals of the browser. I'll add it to the list of supported browsers. Their EULA has some issues, though.
By the way, I'm shopping for an used iPhone or ipod touch. I need it for debugging and maintaining compatibility with aprs.fi. If you have one to sell or give away, let me know.
By the way, I'm shopping for an used iPhone or ipod touch. I need it for debugging and maintaining compatibility with aprs.fi. If you have one to sell or give away, let me know.