APRS PATH error about lora_aprs_tracker

[Mane76]

Hello jranma, at LoRa no path is needed from technical point of view.

Ricardo and I decided to use the WIDE1-1 as checkmark that the packet could (!) be digipeated (as it also OE5BPA does). A frame with an empty path will not be digipeated. This is needed to avoid ping-pong if several digipeaters receive the same frame.

If you want to save airtime you can just leave the path empty.
If you want to ensure that the packet could be digipeated just add "WIDE1-1". More is not necessary.

May I ask, how do you figure out that the message (I assume a position packet) is not forwarded to the aprs-is ?

BR
Manfred

[jranma]

Thanks for the infos Manfred,

I'm not an APRS specialist, but shouldn't the physical medium (LoRa or FM VHF) be transparent, and routing work on the same principle, whatever the medium? One can imagine a LoRa network where it takes two or more hops to reach an i_gate!

I understand that in practice, almost all fixed LoRa points are connected to the Internet, and that it's unlikely that you'll need to make any "hops" to have your packets formwarded to the internet, but conceptually, shouldn't we apply the same routing logic as on classic VHF?

One day, when I have time, I'm going to propose a help file that specifies the meaning of all the confguration parameters, and that gives such information about PATH, for example. I think it could be useful to many OMs

I juste figured out because my position would not be updated with "WIDE1-1, WIDE2-1" and will with "WIDE1-1". I didn't dig any deeper than that.
I changed various options and ran several tests until I understood which change produced the problem.

You guys are doing an excellent job with this LoRa-APRS. Congrat. I think that a growing proportion of VHF traffic will switch to LoRa in the future (TX autonomy, reduced power, very inexpensive equipment, weight, etc.).

[Mane76]

Hello jranma,

thanks for your feedback, I really appreciate this.
May I answer or comment your sentences above:

• I agree that the physical medium should be transparent, but I disagree that routing must work on the same principles. I want shortly explain and add two links with more information on it.

• APRS on VHF has to be seen different to APRS via DMR or APRS via LoRa.
  Comparing APRS on VHF to via LoRa you have a completely different underlaying layer (VHF is AFSK with 1200 Baud, needs good SNR, usually 5-10 Watts ERP or more, special equipment like TNCs or Transceivers, ax25 built-in carrier detection, usually exposed locations, and so on.
  In contradiction LoRa is more than 4 times slower, works with negativ SNR, usually 100mW, cheap hardware and so on).
  For APRS on VHF it was essential to have digipeating because in the early days exposed locations were chosen next to repeaters, which were offline from the internet. Fill-in digis were used to reach exposed digis or at least an iGate with access to internet.
  For APRS via LoRa it is almost vice versa. Almost everyone can operate a RX iGate with internet access, a tight net of RX igates is no illusion and at exposed locations you may encounter problems because of overlapping transmissions.

• For APRS via LoRa the basic idea must be "the less bytes the better it is" and "less traffic on the frequency is better". ON4AA has described this very good here, just as an excerpt, a frame containing 113 bytes (including Headers, PATH, ...) needs at least 4,4s (!) of TX time. In order to decode properly you need to receive the full frame. In comparison, 45 bytes need 2,1s of TX time. Due to the protocol has no carrier sensing a overlapping in crowded areas is not the exception. Imagine, during movement a tracker is sending in an interval if 30sec to 2mins, if you have 10 trackers in the RX area a overlapping will happen, even without digipeating.

Therefore the Software from Ricardo aims to have a compromise between reduction of airtime AND functionality. With stock config you have 40 bytes in total, with omitting WIDE1-1 in path you can come down to 32 bytes.

• In ideal APRS via LoRa, where you have no need for digis (if you have a close net of RX iGates), there is no need for a PATH variable. This is also described from ÖVSV here. The path variable should be used to distinguish if (!) the frame should be digipeated or not. Generally when using digipeating, split frequency digipeating should be used.
  Therefore Ricardo and I decided to follow the approach to enable digipeating (preferred mode 4, split frequency, every frame will be digipeated independent of the path. You need a dedicated iGate which RX on the upper frequency, usually 433.900 OR mode 3 , same freq, but now only frames with PATH WIDE1-1 will be digipeated on the same freq and the PATH will be cleared by digipeating. This ensures that no ping-pong happens which locks the frequency) for only 1 hop.
  Regarding your described problem with WIDE1-1, WIDE2-1 in path. This will passed to aprsis in mode 1 and 2, I have one example tracker here in my region. Please check on the serial console output if it is passed or blocked, only looking at aprsis will not tell the whole picture.

So to sum up, this piece of software for tracker and igate aims the target to have a compromise between reduction of airtime and functionality. The parameters in config allows a freedom in customizing within borders. With stock parameters you are on the good side.

Any feedback is highly appreciated.

BR
Manfred

[jranma]

Thank you, I understand the usefulness of minimizing the number of bytes sent and your choices are very reasonable.

One risk I see with the development of LoRa-APRS is that we risk gradually losing the "two-way" operation of APRS, because most stations are only in RX (mainly for legal issues... the same question arises for VHF), and APRS was designed as a two-way system....
But is it better only RX, or no coverage at all?

Anyway that's another question, not directly related to this topic.
I think we can close this topic ?
73, julien HB9HRD

[Mane76]

Hello Julien,

I fully agree to you that two-way operation is a option we need to promote. But I disagree that we are loosing it because at APRS via LoRa we did not have it before. OE5BPA and Ricardo do implement and spread it since a short period of time for ESP32 based hardware and we have to make it also interesting to others like trackers which can receive messages or wx reports and so on. Development must go on.
As you say, RX only is better than noting, and TX should be implemented carefully where it is allowed from legal point of view and senseful from location point of view.

BR
Manfred

[jranma]

Let's say that being able to install cheap RX I-Gates so easily is a double-edged sword, it both increases coverage, but lowers the proportion of the number of stations that are QRV TX.

But previsously said, this question is not directly related to LoRa-APRS and there is not much we can do about it. Maybe remind operators that the messaging function depends on the TX/RX I-Gates TX/RX. We must make operators aware of the richness of the APRS, which is richer than just the reception of localizations.

[Mane76]

But previsously said, this question is not directly related to LoRa-APRS and there is not much we can do about it. Maybe remind operators that the messaging function depends on the TX/RX I-Gates TX/RX. We must make operators aware of the richness of the APRS, which is richer than just the reception of localizations.

100% agree ! Therefore we applied the "red rhombus with white L" to a TX iGate, or the green digi-L also to easy identify it on the map and make operators curious about.
As said, we are working on some more features to both, iGate and Tracker, and Ricardo does an incredible job with programming all this stuff.

Also here the call, if you or a reader of this post appreciates the work Ricardo does and wants to value this, pass a donation to him e.g. via a sponsorship or via the paypal link on the github page.

BR
Manfred