So I spent the last 2 days testing a setup with 2 android tablets with ATAK and official ATAK Meshtastic plugin, 2 T-Beam supremes and a TinySA ultra to monitor the frequency (indoor, everything laid down on the same table, WiFi and MQTT disabled), and I have some results that make me want to write this feature request.
I tried all modem presets in LoRa configuration, and then went into custom config and best results I got were with 250 bandwidth, 8 spread factor and 8 coding rate (honestly, why most presets use 5 is beyond me).
So with best setup:
Chat in ATAK works most of the time.
Sending single markers in ATAK works most of the time.
Sending routes made up of 2 points works most of the time.
Sending routes made up of 3 points or more gets very unreliable, and unreliability increases the more points you add.
Sending hand drawn lines on the map is basically non-functional, you can maybe get one through after dozens of attempts but thatâs it.
Signal strength between nodes as reported by Meshtastic app is at -15 dBm and about 12.0 SNR so clearly radios have no problem hearing each other. I draw a path of many points or a few hand drawn lines in ATAK, I hit send, I see the transmission start and end on tinySA, and then nothing appears on the other tablet. If I keep trying maybe after 10 or 20 times it will get through, but I also have no way of knowing if it did. In actual outdoors I have to use some separate comms channel to ask the other side if they received it.
I also conducted some other outdoor tests with just the Meshtastic app and a friend driving around countryside in a car, and a similar pattern emerges, where at some point nodes can monitor each other, but messages stop getting through (even though my chat shows the checkmark cloud receive confirmation, but my friend doesnât get the message). Does this mean that a receiving node sends acknowledge without even checking a hash/checksum of what it received?
Watching youtube I learned that the situation in UK is also similar. Beaconing works, messaging - not so much. I understand that ATAKâs data packets are not optimized for low data rate, but what I donât understand is the extreme focus on range of receiving signals while data itself gets garbled. From the behavior I observed, it seems like receiving device acknowledges reception even if it got garbled and unusable data, which prevents even the 3 rebroadcasts from happening if I understand correctly. I donât know how 100% overhead coding rate is implemented, but empirically it improves the situation only slightly.
We live in a world of reliable data transfer over radio waves. ELRS exists and is reliable. A multitude of data integrity and error correction techniques exist and are successfully used. This is something that can be achieved with software. I remember in the days of very slow dial-up internet downloader software learned to âresume downloadâ, and from then on you could download even large files with their integrity preserved, even if it took multiple sessions and a long time. Meanwhile ATAK plugin exists, and even offers the ability to send files and voice memos, but with no data integrity protection I have no idea how any of that would actually work.
Please consider implementing this into Meshtastic. All the amazing link budget and 200+ kilometers of distance with beacons donât matter if a messaging app canât get messages through, and the same packet needs to be retransmitted 20 times between devices 2 meters apart to maybe get through. So please implement more reliability and data integrity measures. Iâm sure I donât need to tell anyone how important this is for the future of this amazing tech.