Technical details about APRS packets

Status
Not open for further replies.

kg6qgf

Member
Joined
Sep 10, 2018
Messages
10
I am new to this forum; I hope this is correct place to put this post.

I have been thinking about a new open source design for APRS radio; I have bounced idea off Robert Bruninga via email, he thought it might be interesting; I hope I am not embellishing, but he seems to think Hams don't like to build projects anymore and he would like to see more of that.

That said, I have a bunch of technical questions I would like to ask about APRS network and Igates; Being a hardware engineer; I would benefit greatly if I could rely on input from network experts in APRS. ALso need details about using APRS for text messaging and email. Lastly how Igates inter-operate with radios, both polling and pushing data;

Is this the correct forum to ask these questions or might there be a better site (or person)?
 

kg6qgf

Member
Joined
Sep 10, 2018
Messages
10
Thanks for links; This appears to be more of a METOO use of the APRS; GPS tracking, predictive tracking, NMEA packet reporting; I am looking for fringe use of the network; To that end I have a few questions I can post;

1. Is there an accepted method of short messaging service over APRS? I think answer is yes, but really is this a method that emphasizes radio to radio delivery, not radio to Igate to smartphone?

2. Does information that is collected by an Igate have any method of retrieval of the cached data back over the air to another user? For example, If I am in California, and I send a txt message to anther call sign, I presume this message eventually makes it to a Igate and is cached...Can a user in Florida ping his or her Igate and "poll" or "inquire" if any messages are cached in an Igate? Then "pull" the message for rebroadcast from Igate back over the air?

3. Same questions 1 and 2 for short email?

4. In APRS protocol, is there any concept of "packet successful delivery acknowledgement" by a digipeater and/or an Igate? Something that would kill inertial hops or repeats? Or a concept that starts with WIDE 1,1 and increases over time ONLY if not get ACK?

5. In APRS, are there any concept of "remote RSSI" from receiving digipeater or Igate(in other words, can my radio realize it does not need 5 watts to hit nearby digipeater or Igate and turn down TX power)?

6. What about other attributes such as "battery level" or "alarm at transmitter site"

7. What about network wide broadcasts or regional alerts such as "Emergency Alert" message or "Sever weather warning" that a Ham could choose to subscribe to (meaning they select to receive these messages)?
 

kg6qgf

Member
Joined
Sep 10, 2018
Messages
10
I realize my last post may be premature; As I read more of the APRS101 doc I see that some of this have been addressed. For example, NWS-WARN are headers for weather warnings; But do any PORTABLE RADIOS alert to this? Earthquakes are listed, but does not seem to be built out.

Same question for GROUP MESSAGES and GROUP BULLETINS; I see that group messages can be sent, but are there any HANDHELD or PORTABLE RADIO devices that alert to this? Same question for NTS RADIOGRAMS; EXCLUDING SMARTPHONES for all of these, as I can guess that they already can do much of this without ever being connected to over the air traffic....

How much of this APRS protocol reference has been built out and deployed vs only in theory?
 

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Super Moderator
Joined
Jul 18, 2004
Messages
9,293
Location
Central Indiana
1. Is there an accepted method of short messaging service over APRS? I think answer is yes, but really is this a method that emphasizes radio to radio delivery, not radio to Igate to smartphone?

2. Does information that is collected by an Igate have any method of retrieval of the cached data back over the air to another user? For example, If I am in California, and I send a txt message to anther call sign, I presume this message eventually makes it to a Igate and is cached...Can a user in Florida ping his or her Igate and "poll" or "inquire" if any messages are cached in an Igate? Then "pull" the message for rebroadcast from Igate back over the air?

3. Same questions 1 and 2 for short email?

4. In APRS protocol, is there any concept of "packet successful delivery acknowledgement" by a digipeater and/or an Igate? Something that would kill inertial hops or repeats? Or a concept that starts with WIDE 1,1 and increases over time ONLY if not get ACK?

5. In APRS, are there any concept of "remote RSSI" from receiving digipeater or Igate(in other words, can my radio realize it does not need 5 watts to hit nearby digipeater or Igate and turn down TX power)?

6. What about other attributes such as "battery level" or "alarm at transmitter site"

7. What about network wide broadcasts or regional alerts such as "Emergency Alert" message or "Sever weather warning" that a Ham could choose to subscribe to (meaning they select to receive these messages)?
1. Google "APRS email". Here is one link that might provide some insight: Email Services

2. Igates are not servers. They do store some packet history. I've never delved into how the Igates and the APRS-IS reacts when a message recipient is near an Igate, so I can't answer that. There may be something in the APRS-IS documents.

3. Same as #1. Bear in mind that the messages have to be short...very short.

4. I've seen talk of "flexible routing" schemes, but I don't think they've ever been implemented.

5. No.

6. Some APRS hardware can send telemetry packets. Some APRS hardware, especially the Argent Data TNCs, have scripting languages that can, for example, send an APRS email based on an external input.

7. That sounds like the group messaging feature which some APRS hardware can be configured to respond to.

You may want to consider joining the Tuscon Amateur Packet Radio APRS SIG mailing list at aprssig Info Page The guys who wrote and implemented many of the APRS standards hang out in that list.
 

wd9ewk

Member
Joined
Jan 24, 2014
Messages
149
Location
Arizona USA
2. Igates are not servers. They do store some packet history. I've never delved into how the Igates and the APRS-IS reacts when a message recipient is near an Igate, so I can't answer that. There may be something in the APRS-IS documents.

If the message recipient is near an Igate, and that Igate is able to forward messages to RF (not all Igates work as two-way gateways; some are receive-only on the RF side), the recipient may be able to get the message. APRS messages are not stored somewhere in the APRS network, compared to SMS messages which are held by the recipient's provider when the recipient's mobile phone is powered off. If the recipient isn't near an Igate, and the recipient's radio isn't on when the message is sent, that message won't be delivered. Sites like http://aprs.fi will keep track of messages sent between stations for some period of time, if you search for a call sign there and look at the messages to/from that call sign.

73!
 

kg6qgf

Member
Joined
Sep 10, 2018
Messages
10
If the message recipient is near an Igate, and that Igate is able to forward messages to RF (not all Igates work as two-way gateways; some are receive-only on the RF side), the recipient may be able to get the message. APRS messages are not stored somewhere in the APRS network, compared to SMS messages which are held by the recipient's provider when the recipient's mobile phone is powered off. If the recipient isn't near an Igate, and the recipient's radio isn't on when the message is sent, that message won't be delivered. Sites like http://aprs.fi will keep track of messages sent between stations for some period of time, if you search for a call sign there and look at the messages to/from that call sign.

73!

Interesting. I would like to know more about messages to RF.

I presume when you say mobile phone, you mean smartphone. I would like to get the smartphone out of the picture as a required element. I would like to see a device (such as a handheld) that is always on, always listening for packet data and always digipeating even when user has switched off.

It would be great if I could beacon my call sign and receive any traffic directed to me that could be cached. Maybe it expires after 3 days or something....
 

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Super Moderator
Joined
Jul 18, 2004
Messages
9,293
Location
Central Indiana
It would be great if I could beacon my call sign and receive any traffic directed to me that could be cached. Maybe it expires after 3 days or something....
That would require servers and the APRS-IS is specifically not a network of servers. APRS packets hit an I-gate which is logged into node on the APRS-IS and that packet is distributed to other nodes in near real time.

Where some folks maybe get confused is they look at the APRS.fi web site and see all this historical data about their APRS packets. What they may not realize is that the guy who runs APRS.fi is storing all that data from the APRS-IS at his own choosing.
 

wd9ewk

Member
Joined
Jan 24, 2014
Messages
149
Location
Arizona USA
I presume when you say mobile phone, you mean smartphone. I would like to get the smartphone out of the picture as a required element.

A smart phone, or any mobile phone, doesn't have to be involved with APRS. I mentioned it as a comparison to the way messages are handled by APRS. APRS message delivery is attempted in real time, regardless of the recipient's status at the time the message is sent, where SMS messages are held until the recipient's phone is connected to a mobile network capable of delivering the messages.

I would like to see a device (such as a handheld) that is always on, always listening for packet data and always digipeating even when user has switched off.

You could keep a radio on, and - if it is in touch with the APRS network - it could digipeat and receive APRS messages when you aren't actively using it. A handheld APRS-ready radio (Kenwood's TH-D72 and TH-D74, and Yaesu's FT-2DR, are some examples currently in production) could do that, or something smaller like a PicoAPRS:

http://picoaprs.de/index_en.html

The PicoAPRS is smaller than those Kenwood and Yaesu HTs, with a maximum output power of 1W, which could be useful if there is sufficient coverage in your area.

The HTs I mentioned are capable of 5W transmit power. All of these HTs and the PicoAPRS are capable of sending and receiving APRS messages. All of these might need better antennas to work with the APRS network when indoors - especially the 1W PicoAPRS - and a connection to external power to stay on for an extended period.

It would be great if I could beacon my call sign and receive any traffic directed to me that could be cached. Maybe it expires after 3 days or something....

That would be nice. That woudl probably require a rework of the standards for APRS messages, along with infrastructure that holds messages until the radio is visible to a gateway on the APRS network for message delivery. There is already an infrastructure using the Internet supporting APRS with the gateway stations, and the gateways are currently used to route messages to other hams using only a call sign for the destination (if the recipients' radios are on and in range of a gateway station).

Every so often, I go to http://aprs.fi and check the messages sent to the call signs I use for APRS work: WD9EWK for the orbiting digipeaters on 3 different satellites (FalconSat-3, NO-84, and the ISS), and WD9EWK-9 when using the terrestrial APRS network on road trips. I see messages sent when my radios are not on. I could run an app on my mobile phone with either of these call signs now to catch messages sent when my radios aren't on, but I choose not to do that. There are other ways I can be reached, in the event my APRS-ready radios aren't on.

73!
 

scoutcamper

Member
Premium Subscriber
Joined
Jan 8, 2014
Messages
37
Here is my thought, I think it can be done, looking for feedback before I try to build it.

Build a server as a passive cache, it sits on the APRS-IS network and monitors messages between users(aprs.fi already does this so I know it can be done...)

When someone wants to send a "Text Message/email/whatever" make use of the already existing comment field in APRS position beacons. This means no changes needed in the existing APRS framework.

The message would contain a header of some kind(for the sake of this call it aprs3).

The server sees a comment with "aprs3" header and stores the whole beacon, position and comment.

Your aprs client(reciever, whatever you call it) gets a custom program that looks in messages for that same custom header, and if it sees the header it triggers an alert(beep, screen on, whatever) and sends an "ack" comment back to the sender.

The server sees the message went out, cached it, and sees the ack go back, clears the message from the cache.


Now, if the server doesnt see an ack, it waits until the destination comes online and beacons position, then starts hitting igate's working further and further out, incrementing WIDE as it goes until it finds an igate that does TX/RX that gets the message sent to the client, gets an ACK back, and then clears the cache.



From a high level overview I think that would work.

I took inspiration from a weather station in Mt Shasta, CA where you send it a message using APRS with the right words in it and it sends back the weather at your location.




Thoughts? Feedback?
I think I could build this at least from a proof of concept perspective.
 

djeplett

Member
Joined
Feb 19, 2005
Messages
857
Location
NE Wisconsin
Now, if the server doesnt see an ack, it waits until the destination comes online and beacons position, then starts hitting igate's working further and further out, incrementing WIDE as it goes until it finds an igate that does TX/RX that gets the message sent to the client, gets an ACK back, and then clears the cache.

This could generate an awful lot of packets and congest the RF frequency as the server blindly tries to find a way to get the message through.

Isn't some of this functionality you're describing built into the Winlink network?
 

vagrant

ker-muhj-uhn
Premium Subscriber
Joined
Nov 19, 2005
Messages
3,150
Location
California
I wonder it would take, to use the picoAPRS as an iGate.
That is a nice little device. The Version 3 is even smaller. An interface for that would be nice, but would probably increase the size. Still, that one watt of power and whether it would work depends on each geographic location, digipeater build out and a suitable antenna. I wish it was half the price.

Oh! A quick scan of the manual and it does interface with a PC via USB (KISS-TNC). Pretty cool. Now that price seems fair. While my Kenwood D74 could do the same, that device is the "Fun Size" version. :) I need to read this manual in full.

Looks like it could work as an iGate.
 
Last edited:

wd9ewk

Member
Joined
Jan 24, 2014
Messages
149
Location
Arizona USA
That is a nice little device. The Version 3 is even smaller. An interface for that would be nice, but would probably increase the size. Still, that one watt of power and whether it would work depends on each geographic location, digipeater build out and a suitable antenna. I wish it was half the price.

I bought one of the v2 PicoAPRS devices. Nice, flexible device. It can be a full APRS transceiver, to a KISS TNC connected to a computer running software, to a transmit-only APRS tracker. I haven't seen the new v3 version in my local HRO store, but I like the improvements. The GPS improvements in particular, with the new module using both the US GPS and Russian GLONASS systems (like with my Garmin eTrex 20 receiver). Smaller size is nice, and a change to a battery that doesn't use leads to a small plug inside the PicoAPRS.

Oh! A quick scan of the manual and it does interface with a PC via USB (KISS-TNC). Pretty cool. Now that price seems fair. While my Kenwood D74 could do the same, that device is the "Fun Size" version. :) I need to read this manual in full.

Looks like it could work as an iGate.

Yes, with the right software on your computer, a PicoAPRS should be able to function as an iGate. The TH-D74 (I also have one) probably has a better receiver than in the PicoAPRS, but for more than weak signals the PicoAPRS should be able to handle the task of being the radio and TNC for an iGate. I wish the price would drop, but IIRC the PicoAPRS is made in Germany, not the Far East.

If you have other questions about it, e-mail the creator DB1NTO. Taner has been responsive to my questions, even with a concern regarding a firmware update a few months ago that would have been problematic. I explained my concern (switching to act like an APRS tracker in a balloon over 1500m elevation, where there are cities in the western US above that elevation). Taner sent me a new firmware version with that threshold raised to 3000m (almost 10000 feet), and included that change in the next publicly-released firmware version. BTW updating firmware on a PicoAPRS is easy, using either a Windows or Linux PC.

73!
 

prerunner1982

Member
Joined
Apr 7, 2011
Messages
65
Location
Edmond, OK
2. Does information that is collected by an Igate have any method of retrieval of the cached data back over the air to another user? For example, If I am in California, and I send a txt message to anther call sign, I presume this message eventually makes it to a Igate and is cached...Can a user in Florida ping his or her Igate and "poll" or "inquire" if any messages are cached in an Igate? Then "pull" the message for rebroadcast from Igate back over the air?

3. Same questions 1 and 2 for short email?

I have not seen this on APRS messaging user to user.
However the EMAIL-2 server does have caching abilities for 24 hours. You retrieve your messages by sending "get" to EMAIL-2 in an APRS message. This is likely done on a server side linking the APRS world to the Email world and not in the APRS-IS itself.
 

needairtime

Member
Joined
Apr 9, 2018
Messages
383
Location
CO, USA
How prevalent are 9600bps APRS packets? Are most APRS igates/digipeaters able to deal with these? (What mode are 9600bps APRS sent at?)

I would suspect these aren't compatible with the 1200bps AFSK APRS packets, but I occasionally heard some people (inadvertently?) transmitting some kind of digital signal over voice repeaters, and some more experienced hams listening in was claiming that digital signal was some sort of APRS. On the other hand I've been trying to get an APRS packet going through both ways and that the particular sound we heard, at least IMHO does NOT sound like 1200bps AFSK...

I have to suspect the duration of these signals versus the signal qualities may have tipped them off to be APRS versus some sort of digital voice mode (kerchunking?), but I don't know. On the other hand, setting direwolf to transmit at 9600bps indeed makes it sound different but the preamble still seems to sound reminiscent of 1200AFSK...
 

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Super Moderator
Joined
Jul 18, 2004
Messages
9,293
Location
Central Indiana
9600 baud APRS is not very common, in my experience. And, no, it's not compatible with 1200 baud packet.
 

KE5MC

Member
Joined
Dec 19, 2002
Messages
1,235
Location
Lewisville, TX
Interesting thread! I feel one of the reasons APRS messaging does not get used is the lack of efficient input at the RF device. At one time the original Kenwood D710 has the possibility to add a keyboard. I'm aware that short message can be predefined and stored to send later on just about all the APRS mobile and hand held radios. One way to keep messages short is current input method. :)
 
Status
Not open for further replies.
Top