Please consider implementing better data integrity protection

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.

2 Likes

Can you explain if this relates to ATAK or is this about Meshtastic or both. I do not quite understand if your issue (test results) is with ‘normal’ vanilla Meshtastic or an ATAK ‘variant’ (whatever ATAK is). Cheers.

Can’t add much for most, but

Getting the ‘tick’ just means that some node ‘rebroadcast’ it. In theory the packet has entered a ‘mesh’. No guarantee it the ‘right’ mesh for the destination, nor that it will reach destatiation.

Yes, most nodes should retransmit a message, even if they can’t ‘decode’ the message (due to unkown key for the channel) - they just retransmit the raw message.

But as far as a know, it still needs to pass CRC checks to be received, and rebroadcast. The device wouldn’t resend a corrupted packet.

So the tick should mean it was successfully received - not corrupted - by someone. Just no idea if that node is a viable route to the intended destination. It might be the wrong direction, or could potentially not successfully received by the next ‘hop’.

It seems your issues are specific to using it with ATAK, I don’t share your experience when using the Meshtastic apps only.

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.

Note that -15dBm is very high, and it might be the radios will sometimes get overloaded. Try placing them at least a room apart.

(even though my chat shows the checkmark cloud receive confirmation, but my friend doesn’t get the message)

Some other node rebroadcasted the message most likely. If you send a direct message, you need to see the person with checkmark to be sure the intended receiver got it.

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.

Please try this again with the Meshtastic app only and with the nodes in separate rooms. If you don’t get near 100% success ratio, there is clearly a problem with Meshtastic, but I don’t have this issue.

This is correct.

1 Like

Thank you for clarifying this, and I believe this behavior is not very useful. Knowing that a repeater or another node received my message doesn’t really do anything for me. I believe it would be useful if intended recipient(s) receiving the message would sent the actual “acknowledge”, won’t you agree?

To clarify, this discussion for me is a plea to developers and is in no way intended as criticism. I intend no negativity and want Meshtastic to improve.

The intended recricent (if there is one!) should send a specific ACK. The android app at least shows a different tick if received by repricipent. (no idea if works with ATAK integration!)

A cloud+tick, means an implicit ACK from the mesh. (ie someone received it + resent it)

A person+tick, means the destination received it. (obviouslly not available for general broadcasts to a Channel)

1 Like

Meshtastic messages probably will have near 100% success ratio, because they’re short enough, but clearly people in UK have an issue where (due to congestion) messages get lost but beacon (node) info can still be passed through. ATAK’s messages/packets are clearly larger in size, but unfortunately I can’t debug this behavior myself, maybe the developers of official ATAK Meshtastic plugin can, if they see this discussion. I’ll test this more outdoors, but for now the fact remains that despite existence of the official plugin, ATAK communicates very poorly through Meshtastic, and it would be amazing if this was fixed/improved.

I’m looking at one of my direct message chats in Meshtastic app and I can’t see anything other than cloud+tick. I’m not sure if I’ve ever seen the person+tick. BTW, does this mean that if my direct message went through some nodes, I will only ever see cloud+tick, or will I eventually also see person+tick when the recipient receives it?

FWIW dont think the issues we have in the UK with congestion etc, is rooted in ‘corrupted’ messages particularly. Ie its not the that short messages get corrupted less.

The beacon messages are very unreliable too, just that they get repeated a lot. Nodes send periodic beacons, as well as in response to seeing new nodes. Enough are sent, that even a few getting though is ‘enough’, similar with position/telemetry, get repeated often.

Text messages, are instead ‘one shot’. If they fail to hop though the mesh, then likely lost.


… yes, a cloud+tick can turn into person+tick when the individual ACK comes though later.

Perhap the key point is only get ‘person+tick’ on ‘Direct Messages’ - ie with a named destination.

Messages on the general channel, are ‘broadcast’ to everyone. Even if kinda replying to the message above, you still just sending a broadcast, and wont get person+ticks.

1 Like

To increase the chance of them seeing this, you could consider opening an issue here: Issues ¡ meshtastic/ATAK-Plugin ¡ GitHub

Thanks, I’ll do that.