You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I hope, LoRa_APRS_Tracker will implement aprs messaging in the future.
But for now, I suggest to send in the first byte of the APRS message (before the position) an '!' instead of '=', because '!' indicates that the sender is not messaging capable. This is a useful information for someone who intends to write you.
In our discussion about digipeating, we talked about Paths, WIDE2-1, or WIDE1-1, and so on.
One interesting solution is in the APRS spec. Because we have to keep our TX data (also the ASCII PATH) short (for lesser airtime) in LoRa, the approach to encode the intended hops with an Destination SSID is nice.
-> msg.setDestination("APLT00-1"); for one hop.
I like to send with msg.setDestination("APLT00-1"). If we don't like users to change the source code, I recommend a configuration optoon.
Btw: A digipeater should always look at both, Digipeaters and DST-encoding.
Due to the spec, if DST-based encoding is used, then there must be no digipeaters in the path. Digis honoring things like DO1DOS>APLT00-7,WIDE7-7 would be fatal for the net.
There's an interesting detail if a digipeater decreases the SSID one by one: if zero is reached AND if there have been digipeaters added, we may are inthe situation that DO1DOS>APLT00,WIDE7-7 is repeated (because the digipeater sees no ssid in the DEST-call).
What do other digipeater software do in that case? Omit digipeating packets like APLT00-7,WIDE7-7 ? Or remove the WIDE7-7 part? Or replace WIDE7-7 to WIDE7-0* ? If the feature is going to be implemented in LoRa digipeater, it's a good Idear to look how other APRS digipeater software deals with that issue.
The text was updated successfully, but these errors were encountered:
For discussion:
I hope, LoRa_APRS_Tracker will implement aprs messaging in the future.
But for now, I suggest to send in the first byte of the APRS message (before the position) an '!' instead of '=', because '!' indicates that the sender is not messaging capable. This is a useful information for someone who intends to write you.
In our discussion about digipeating, we talked about Paths, WIDE2-1, or WIDE1-1, and so on.
One interesting solution is in the APRS spec. Because we have to keep our TX data (also the ASCII PATH) short (for lesser airtime) in LoRa, the approach to encode the intended hops with an Destination SSID is nice.
-> msg.setDestination("APLT00-1"); for one hop.
I like to send with msg.setDestination("APLT00-1"). If we don't like users to change the source code, I recommend a configuration optoon.
Btw: A digipeater should always look at both, Digipeaters and DST-encoding.
Due to the spec, if DST-based encoding is used, then there must be no digipeaters in the path. Digis honoring things like DO1DOS>APLT00-7,WIDE7-7 would be fatal for the net.
There's an interesting detail if a digipeater decreases the SSID one by one: if zero is reached AND if there have been digipeaters added, we may are inthe situation that DO1DOS>APLT00,WIDE7-7 is repeated (because the digipeater sees no ssid in the DEST-call).
What do other digipeater software do in that case? Omit digipeating packets like APLT00-7,WIDE7-7 ? Or remove the WIDE7-7 part? Or replace WIDE7-7 to WIDE7-0* ? If the feature is going to be implemented in LoRa digipeater, it's a good Idear to look how other APRS digipeater software deals with that issue.
The text was updated successfully, but these errors were encountered: