Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

For discussion: ! vs =, DST-call with SSID #24

Open
dl9sau opened this issue Apr 3, 2021 · 0 comments
Open

For discussion: ! vs =, DST-call with SSID #24

dl9sau opened this issue Apr 3, 2021 · 0 comments

Comments

@dl9sau
Copy link

dl9sau commented Apr 3, 2021

For discussion:

  1. 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.

  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant