tracker.json defaults should be more LoRa byte saving

[stroobandt]

An empty "path": "" instead of "path": "WIDE1-1" in tracker.json works perfectly fine if you are only interested in putting your beacon on the map. This saves 7 LoRa Bytes, which increases the chances of an error-free reception of the full packet.

Local WIDE1-1digipeating from LoRa is anyhow very rare and not allowed in most countries without a digipeater license.

The same gains hold true for an empty "message": "" in tracker.json. Currently we are wasting 12(!) Lora Bytes to "message": "LoRa Tracker". In the professional LoRa world, this is considered borderline criminal…
Actually, there should be no option at all for a "message" in a LoRa tracker, and if still, then an occasional (e.g. 1 in 10) APRS Status Report (p.80) stands better chances of being received correctly. APRS-IS takes care of this information in a transparent manner.

Furthermore, sending altitude data should be made optional and false by default. This saves a whopping 9 LoRa Bytes on air, since its format is /A=001234. GPS reported altitude is anyhow prone to errors and for objects on the ground, the altitude can be inferred from a geographical map.

Finally, on the tracker firmware level, the Destination Address could be simplified to a mere AP instead of APLT00. That is another 4 LoRa Bytes saved, or 6 bytes if you let the iGate fill in this information. Limit the marketing of the firmware to the iGate.

"enhance_precision": true adds another 5 Bytes, and because of the addition of a space actually 6 Bytes.

In total, there is an immediate potential to save 7 + 12 + 9 + 6 + 6 = 40 Bytes on air, of which 25 Bytes without any firmware change; only through more sane tracker.json file defaults.
Mic-E APRS compression (pp. 42-56) could shave off still more Bytes…

LESS IS MORE with LoRa,
because LoRa employs forward error correction (FEC) coding on a physical hardware level.

[peterus]

as already written in the PR: the current configuration is just an example to show what the firmware is capable of. please see it as an example configuration and not a "must follow". every ham is responsible for his own data and should minimize airtime as much as possible.
thank you very much for your input, I will link this issue to the documentation to provide more information about this topic.
will close this ticket as soon I was adding the info.