Please add APRS support. #10439

New issue

Open

opened 2025-03-07 02:06:04 +00:00 by Supermagnum · 0 comments

Supermagnum commented

2025-03-07 02:06:04 +00:00

(Migrated from github.com)

The fact that alot of stations, actually transmit Wx "Weather-Data" could be something of great benefit.

It may also be an idea to use the Polaric Server backend. It has a REST API and Websocket interface.

https://polaricserver.readthedocs.io/
Expected behaviour

Maybe it's possible to look at Dire Wolf APRS software or similar, and enable communication with a local installation of LibAPRS or similar software, as this may be the simplest route.
The information received from a APRS receiver should result in APRS symbols and callsigns showing up in the map. The APRS stations visible should be determined by a adjustable range filter(display only units that is inside xx kilometers range.
Some stations that doesn't beacon that often needs to be stored in a database that could expire after a set time. I suggest 3600 seconds.
Alternatives you've considered

NA
Context

More technical information:
https://en.wikipedia.org/wiki/Automatic_Packet_Reporting_System
These links are provided as examples of software:
Here is an open source client:
https://www.ka2ddo.org/ka2ddo/YAAC.html
A open source tracker:
https://hackaday.com/2011/04/20/trackuino-%E2%80%93-an-open-source-arduino-aprs-tracker/
A open source modem:
https://github.com/wb2osz/direwolf
And:
https://github.com/markqvist/OpenModem

For a example of moving stations, go to:
https://aprs.fi/moving/
(Click on any of them to show the map )
Map showing many stations:
https://aprs.fi/#!mt=osm&z=4&call=&others=1&timerange=3600&tail=3600
Documentation on the APRS message format and the APRS symbols that should be used:
http://www.aprs.org/doc/APRS101.PDF
http://www.aprs.org/symbols.html
The APRS symbols are standard for APRS stuff.
Many radios has a KISS TNC built in:
https://en.m.wikipedia.org/wiki/KISS_(TNC)
In its most widely used form, APRS is transported over the AX.25 protocol using 1200-bit/s Bell 202 AFSK on frequencies located within the 2 meter amateur band.
Something about the protocols that some radios may use:
$GPWPL, NMEA generic with only location and name.
$PGRMW, Garmin, adds altitude, symbol, and comment to previously named waypoint.
$PMGNWPL, Magellan, more complete for stationary objects.
$PKWDWPL, Kenwood with APRS style symbol but missing comment.
Many manufacturers use custom fields (Identified with a $P, followed by a three digit manufacturer code, followed by 2-5 digit data type code; In the case of Kenwood, this is a $PKWDWPL for the Kenwood custom waypoint sentence) that fix these oversights in the spec. Unlike the $GPWPL sentence mentioned before, the $PKWDWPL sentence is designed to specify a temporary waypoint, one that gets deleted when the next waypoint from that callsign gets sent.
I think that it should be possible and best to add support for full NMEA as this also may be attractive for the AIS users, and Kenwood sentence and supported the AvMap sentences. Also, some radios speaks that language.
Also, read:
https://tyrellberry.blogspot.com/2013/10/nmea-sentences-kenwood-sentences-and.html?m=1
https://www.reddit.com/r/HamRadio/comments/fg1jys/advice_on_a_aprs_transceiver/?utm_medium=android_app&utm_source=share

The basic requirement is to display objects provided by another application and allow navigation to them. These objects could be in fixed locations or they could be moving. (e.g. car transmitting its location from a GPS receiver) Properties would include latitude, longitude, altitude, speed, direction, name, comment, time last heard, and symbol (house, weather station, car, boat, airplane, etc.) The fact that alot of stations, actually transmit Wx "Weather-Data" could be something of great benefit. It may also be an idea to use the Polaric Server backend. It has a REST API and Websocket interface. https://polaricserver.readthedocs.io/ Expected behaviour Maybe it's possible to look at Dire Wolf APRS software or similar, and enable communication with a local installation of LibAPRS or similar software, as this may be the simplest route. The information received from a APRS receiver should result in APRS symbols and callsigns showing up in the map. The APRS stations visible should be determined by a adjustable range filter(display only units that is inside xx kilometers range. Some stations that doesn't beacon that often needs to be stored in a database that could expire after a set time. I suggest 3600 seconds. Alternatives you've considered NA Context More technical information: https://en.wikipedia.org/wiki/Automatic_Packet_Reporting_System These links are provided as examples of software: Here is an open source client: https://www.ka2ddo.org/ka2ddo/YAAC.html A open source tracker: https://hackaday.com/2011/04/20/trackuino-%E2%80%93-an-open-source-arduino-aprs-tracker/ A open source modem: https://github.com/wb2osz/direwolf And: https://github.com/markqvist/OpenModem For a example of moving stations, go to: https://aprs.fi/moving/ (Click on any of them to show the map ) Map showing many stations: https://aprs.fi/#!mt=osm&z=4&call=&others=1&timerange=3600&tail=3600 Documentation on the APRS message format and the APRS symbols that should be used: http://www.aprs.org/doc/APRS101.PDF http://www.aprs.org/symbols.html The APRS symbols are standard for APRS stuff. Many radios has a KISS TNC built in: https://en.m.wikipedia.org/wiki/KISS_(TNC) In its most widely used form, APRS is transported over the AX.25 protocol using 1200-bit/s Bell 202 AFSK on frequencies located within the 2 meter amateur band. Something about the protocols that some radios may use: $GPWPL, NMEA generic with only location and name. $PGRMW, Garmin, adds altitude, symbol, and comment to previously named waypoint. $PMGNWPL, Magellan, more complete for stationary objects. $PKWDWPL, Kenwood with APRS style symbol but missing comment. Many manufacturers use custom fields (Identified with a $P, followed by a three digit manufacturer code, followed by 2-5 digit data type code; In the case of Kenwood, this is a $PKWDWPL for the Kenwood custom waypoint sentence) that fix these oversights in the spec. Unlike the $GPWPL sentence mentioned before, the $PKWDWPL sentence is designed to specify a temporary waypoint, one that gets deleted when the next waypoint from that callsign gets sent. I think that it should be possible and best to add support for full NMEA as this also may be attractive for the AIS users, and Kenwood sentence and supported the AvMap sentences. Also, some radios speaks that language. Also, read: https://tyrellberry.blogspot.com/2013/10/nmea-sentences-kenwood-sentences-and.html?m=1 https://www.reddit.com/r/HamRadio/comments/fg1jys/advice_on_a_aprs_transceiver/?utm_medium=android_app&utm_source=share

This repo is archived. You cannot comment on issues.