meshtastic
1.3 Multiple Positions and Telemetry packets are stored on device
Category
Other
Hardware
Not Applicable
Firmware Version
1.3.17
Description
When connecting to a node for the first time if that node has been generating positions, many positions are sent over BLE instead of the one position that is supposed to be stored in the device cache. A user on discord connected a device that had not been connected recently and hundreds of locations were loaded.
Relevant log output
No response
This is back, a ton of positions just dumped when connected to a lora 1.1 that shared location with the mesh
Is that localtions from the connecte node or from (one or several) remote nodes?
mh. going through the startup...
STATE_SEND_MY_INFO STATE_SEND_CONFIG STATE_SEND_NODEINFO STATE_SEND_COMPLETE_ID STATE_SEND_PACKETS
i assume that starts when node db was transmitted? (so after STATE_SEND_COMPLETE_ID when transitioning to STATE_SEND_PACKETS)
Seems like over a few days it keeps storing more and more positions, I have a tbeam that provides 15 positions every time it connects now, factory reset does not clear the positions, had to flash 1.2.60 and factory reset and then re-flash 1.3.23 to get them back to normal for a bit. It also seems like I am getting more position updates over the mesh than I should by default
That's after my latest change to add the telemetry packets into the "sendToPhone" logic, like we did for position? That one was at @andrekir's request. I'm wondering if it's behaving differently on the consumer side of Android vs iOS.
Yes, I agree with the request as it is annoying to not see telemetry or position history on the device that is sending it out, what I am not sure about is the behavior when tons of built up telemetry / position packets come in when connecting to a node via the phone api I would guess these are coming in to android too. In 1.2 only the last position was stored on the device. I am fine with multiple positions / telemetry packets coming in on connection but am a little worried that they never seem to be dropped from the device until it connects to a phone api. I have had devices connect and pass over hundreds of positions, and this seems likely to eventually crash any repeater nodes that are not ever connected to a phone.
i was under the impression the sendqueue was limited in size and the oldest packet would be thrown out when it was full. At least there's a bit of debug logging in my console claiming this.
I do agree that position and telemetry packets should be de-priotized in the to-phone queue in favor of incoming text message packets, if there is contention for space.
same on Android and good catch. I'm in favor of storing only text messages in the tophone queue, especially if other portnums could drop older text messages from the queue. if we can store only the last non-message for each node, even better.
Will test this against the littlefs updates made by @caveman99 do we store a set number of "messages" on the device or is it by size?