mirror of
https://github.com/pyMC-dev/pyMC_Repeater.git
synced 2026-10-30 19:51:59 +01:00
Adverts packets being dropped #18
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/pyMC_Repeater#18
Reference in new issue
Block a user
I have a lot of advert packets being dropped due to being invalid.
Is this normal?
Payload of the top most dropped packet:
D9 A1 67 D1 B1 D3 14 6E C8 F3 A0 36 87 56 C2 76 CF 7F C5 57 B5 94 00 7C 1C 23 4E D9 2F 00 31 AC 33 1A 5D 69 B2 C5 45 63 99 4D C9 DC D8 31 25 DA C0 A3 62 39 7B 25 83 CD 1A 5A 75 5A B8 77 D8 99 6B E7 64 98 56 A8 11 38 DD 68 45 07 CE 6D CB FA B1 05 35 F5 B0 93 80 A0 81 76 98 52 57 4E E4 DD 48 8E FB 0A 92 34 1E 0E 03 39 9A 55 00 56 C7 7A 67 E0 A9 56 2B 7A 6D 9F 02 FC BE 5B 78 C2 68 46 1F 3DNo not normally, if you enable debugs in your config.yaml file it might help pin point the issue, what hat and pi are you running?
With out looking at logs my guess would be RF interference?
That could be the case.
Looking at the RF noise floor, I see it hovering around -100 dBm with quieter periods of -120 dBm, so something is definitely transmitting on the band.
I have quite a few Meshtastic nodes as well, but they are on 869.525 MHz. Not sure if that will interfere.
I'm currently waiting for a new advert packet to arrive, after enabling debug log level. Of course there are none when you need them.
My hardware is pyMC_repeater running in a Docker container on a RPi 4 with a custom-made shield with two SX1262's (https://www.niek.be/meshtastic-satdump-and-sdr-server-box-with-a-poe-powered-raspberry-pi/). One of them is now used by the Meshcore repeater container, the other is still used by a Meshtasticd container. I know my setup is probably far from what you officially support...
Speaking of the devil...
I believe this is the relevant section:
One thing sticks out already, the runtime error.
But some adverts do get successfully decoded, so not sure if that's it.
Oh wow, that's really cool!! .. was not expecting that ha ha, but its good to hear that is a way of doing it! i guess you have done some funky things with docker to pass the SPI/GPIO in?
you should join us in the MeshCore Discord if your up for it!
https://discordapp.com/channels/1343693475589263471/1431414286974189639
I have now seen your logs, i would say the system is detecting corrupt packets, the error only means it could not use the advert data to create a valid identity for the advert.
I run the containers in priviliged mode, as all my attempts to share just a specific
/dev/spidevx.xto one container failed. The next hurdle is the CS pin, as this gets blocked by spidev as soon as you create the dtoverlay, so meshtasticd and pyMC_repeater will complain the CS pin is in use.For meshtasticd, you can simply comment out the CS pin line in the config.yaml, but pyMC_repeater doesn't like that, nor did setting it to -1 work.
For SPI0, you can initiate it without CS pins:
This way the CS pin is free and can be used by meshtasticd or your code.
This trick doesn't work for SPI1, so you can't do this:
I also tried a dtparam of
cs0_spidev=disabled, but then the SPI device doesn't get created at all.What worked in the end was this:
Because for SPI1 I use a non-default CS pin on my shield (GPIO16), I could do this:
Then in the config.yaml I still refer to GPIO16 (the real pin connected to the CS pin of the SX1262).
It's quirky, but it works.
Hmm, so interference from outside?
Will CAD calibration improve this?
All makes sense, I'm not sure the cad calibration will help here, seems like the noice is effecting it, does the noice floor change a lot when transmitting from the the opposite radio on the same pcb? I would monitor via the debugs live.
Debugs don't really show much details as to why it is dropped.
Actually the UI show a lot of info.
This is one that got forwarded:
(Click to open them full-screen. I had to do some trickery to take scrolling screenshots of the div)
This is a packet that got dropped just a minute later:
Similar SNR and RSSI.
Both have similar good noise floors of -115 dBm (from debug log).
Do you spot any issues (other than the wildly incorrect unix timestamps)?
The value 7ce2690d26ebffd0dd5459bbbc3db2ba085d25eef750cc63d45b4880ebfac6c8 represents the first 32 bytes of the packet payload. These bytes are not a valid Ed25519 public key from a cryptographic standpoint.
As a result, the packet is correctly rejected. When AdvertHandler attempts to construct an Identity object using this public key in order to verify the signature, the NaCl crypto library fails because the provided bytes do not correspond to a valid point on the Ed25519 elliptic curve.
Based on the packet flags, the packet appears to originate from a node named RRY24_Rep_Jub (identified as a repeater). Could you please confirm the expected public key for this node? One possibility is that the key was corrupted in transit, for example due to bit errors caused by radio interference.
Pub key for RRY24_Rep_Jub, according to the neighbors page, is
70e2690d26ebffd0dd5459bbbc3db2ba085d25eef750cc63d45b4880ebfac6c8.So it makes sense now that it was dropped: 70 has become 7c.
I've checked some more dropped packets and indeed, there's always a mistake in the public key.
Here's another example:
I don't see this issue with other packet types, but they are a lot shorter of course.
I wonder if the TCXO of the SX1262 can be the reason. It is freezing outside and my Raspberry Pi with SX1262 is in a weatherproof, but metal box... But that's the whole point of the "TC" in TCXO in the end, right? 🙂
BTW, your Discord invite doesn't seem to work:
I've been watching what happens when I send a message with my Meshtastic node vs my Meshcore node (the latter repeated by my repeater).
The two narrow bars are my Meshcore node (T-echo) sending a message, immediately repeated by my repeater node on the roof (your code).
The big bar just covering everything is my Meshtastic node on the roof submitting a message... It's completely overpowering the band. I definitely need to get some distance between the two antennas!
And that made me also discover that I had my Meshtastic node set at 27 dBm, while the sx1262 officially supports just 22 dBm. I'll keep on testing.
Anyway, since this is no longer a software related issue, I'll close this.