firmware
firmware copied to clipboard
meshtastic
[Bug]: Meshtasticd not populating node list
Category
Other
Hardware
Linux Native
Firmware Version
2.5.5
Description
Trying to direct message between two devices, fresh factory reset and nodes deleted from app on both sides. Node A (RAK4631) sees Node B (Waveshare LoRa hat, sx1262 on RPi Zero W) in node list, Node B never sees Node A. Trying to direct message from Node A to Node B fails quickly and tapping on the cloud/slash icon says Error: Unknown Public Key. Both nodes are on 2.5.5 and the app is 2.5.0 (Android)
On Node B, debug panel never shows any packet to or from Node A.
On Node A, after attempting to send a direct message to Node B, it shows the packet to Node B with the correct nodeid, and the payload (message). However, the next packet says from Node B to Node A (reply), and payload is "\030#" (not sure what that means).
Basically, Node B which is running on meshtasticd on RPi never seems to add other devices to its node list, even after messaging in shared channels or forcing discovery broadcasts by rebooting other devices. And because the devices never appear in the node list, direct messaging is broken.
Relevant log output
No response
To update and clarify this more, I am now using three devices to test this. Node A (RAK4631), Node B (Waveshare RPi hat), and Node C (Heltec v3). Node A populates Node A and C in its node list, Node C populates Node A and C in its list, and Node B populates nodes A B and C in its list. But Node B never appears in the other devices' lists. In the debug panel, I can see its nodeid in channel messages, but its like there is zero acknowledgement of an attempted direct message when I attempt to message A or C from B.
Bumping with additional info:
I am even seeing NodeInfo packets from Node B in the debug panel of Node A. Still doesnt populate into the nodedb of Node A.
Your device has the long message problem. Some of these Waveshare hats have a problem with sending moderately long messages. You can check by trying to send regular channel messages of varying length. I'd guess somewhere around 50 characters, the messages will start getting spotty.
To verify, put your devices on the ShortFast LoRa preset and see if things work as expected. In my testing, messages sent with ShortFast don't keep the TX circuit powered long enough to run into this problem.
I previously had it on MediumFast and it worked flawlessly. I switched it to LongFast and it has problems, however I didnt think to connect the two as I had also updated to >2.5.0 at the same time.
Are you tracking any potential fixes or workarounds to this?
Actually, after some digging I saw somebody with a potentially related issue say that they were able to get long messages to send by lowering TX power, so I just lowered it from 30 to 10 and it works! I will let you close this issue if you want, as the solution is a workaround.
I'm about 98% sure this is due to this hat using a crystal oscillator, and not a TCXO. Semtec's documents suggest that any packets with over 400ms of transmit time will be iffy with a XTAL design like this one.
This sounds similar to an issue I've been having with the Waveshare SX1226 LoRa hat on a Pi3B+ Like @joshbowyer suggested, I lowered the Tx power and now my RAK4631 and T-Echo can finally get the public key from my Pi after a couple of requests.
