Home › Forums › Conduit: mLinux Model › mLinux 3.3.13 corrupt downlink messages
EG.
EGAfter flashing mLinux 3.3.13 on my Conduit, I’m seeing an occasional corrupt downlink message detected on my node. I get either an invalid mic or a mismatch on node address. My node handles this fine, but it’s wasting bandwidth. These are class A acks.
I also updated my network server, packet forwarder, and libmts to the latest version and still see the issue. I never saw a single error such as this with 3.2.0, and I can run the same node with one of two Conduits, one on 3.3.13 and one on 3.2.0, and see the problem only with the later version.
Has anyone seen anything like this?
I tried to downgrade to 3.2.0, but I wound up with missing filesystems, so I flashed back to 3.3.13.
I have reported this to Multitech support as well.
Jason ReissDoes your node enable CRC for downlink packets? It should not be enabled.
The network server has changed to send downlinks without CRC enabled per Lorawan in version 1.0.26.
EGThanks for your response.
No, It does not. I get these errors on the order of once every 10 minutes when sending 1 msg/sec, BTW.
Jason ReissAre you using the default network server version 1.0.8 in mlinux 3.2.0?
Or did you update to latest packages in both conduits and only see issues with 3.3.12?
What is the distance between gw and node?
What datarate is used?
EGI was about to reply that I hadn’t updated the network server, but I went to check and I have version 1.0.13 running on my mlinux 3.2.0 gateway. I don’t remember upgrading it, but I guess I must have.
The gateway and node are 1-2 meters apart. This is with DR4.
On the 3.3.13 gateway, the reason I flashed it originally was that I messed up the network config and bricked it (it wouldn’t complete boot), so I flashed 3.3.13 using uboot. I can’t tell you what version the network server was before that. I saw I was having the mic/address problem (which actually hung my node sw because I had a bug when handling the bad acks, so I’m sure I’ve never gotten them before on either gateway), so then I tried to downgrade (which didn’t work), then went back to 3.3.13.
Jason Reiss1.0.13 will have crc enabled on downlink packets.
I have only seen corrupt packets when the crc settings are mismatched between gw and node. Perhaps try enabling crc on the node to experiment.
Have you tried swapping cards to rule out hw issue?
Jason ReissCheck also the frequency accuracy of the node. 15-20 Khz off can cause bad packets.
EGJust to make sure I understand – the crc setting changed as of network server version 1.0.26, which changes the packet format. I’ll certainly double check my code and versions, but I would think that I would get more than sporadic errors if there were a header format mismatch, no?
I’ll double check the network server version on the 3.3.13 gateway. It’s in my lab and I won’t be there until Monday. I’l also play around with the crc setting.
Would flashing the mlinux-factory-image update the network server? If I’m reading this (http://www.multitech.net/mlinux/images/mtcdt/3.3.13/analysis/ipklist.txt) correctly, the package I flashed would install lora-network-server – 1.0.41-r1.0? So it does seem the two network servers in question have different crc settings.
I haven’t swapped cards because the problem started happening on a sw update. I can try that, though.
How would I check the frequency accuracy?
EGIt looks to me like explicit header mode is used and thus only the downlink header crc bit is relevant.