mqtt path for getting lora message

[wkhatch@unimar.com]

I’ve got a few MTC’s, where I normally create an mqtt client app, which then subscribes to lora/+/up to get the incoming, decrypted, base64 encoded message payload from sensors that are associated with the gateways lora network. On the most recent MTC, I’m not getting any messages on that topic, although I do see packets being received. I used mosquitto_sub to test this, and sure enough, I’m not getting anything on …/up. I do get join_request, packet_recv, and packet_sent messages, but do not see anything coming in on lora/+/up. Any ideas on debugging this further? Maybe this path has changed on the latest MTC?

[Jason Reiss]

There has been no change to the path. lora/+/up should be expected.

Perhaps the devices are being joined to another Conduit within range?

If AooEUI and AooKey values are used between Conduits the device could join either. If the session keys do not match then there is no up message shown.

You could check that the DevAddr and session keys of the device match those in the Device session on the Conduit.

[wkhatch@unimar.com]

Thanks, Jason. The deveui and app eui line up, and I can see the join requests and sessions in the web ui. There’s one other gateway, but I don’t see any messages matching the device in question. I am getting all the other messages under lora/#, just not any up messages. I’m seeing this in /var/log/lora-pkt-fwd-1.log, however. Not sure if that’s at all related to the the mqtt publish on the up topic or not.

JSON up: {“rxpk”:[{“tmst”:1017483540,”chan”:3,”rfch”:0,”freq”:904.500000,”stat”:-1,”modu”:”LORA”,”datr”:”SF8BW125″,”codr”:”OFF”,”lsnr”:-13.8,”rssi”:-97,”size”:242,”data”:”3ENhcdwIW3/LJS/LPFDTy
5SVbn5m2ahByPy5hcVV818/3c+gLwUFmedr4U5disLFYi2JBmK9lyjtASXw06oYZ4BT3Tyro5GPddZtkMN/dwKFgi9CbrPN8pm8riCJvi8yWSErwLgtYJH+q/79A/uBclp0FVi1vUUtf4xCRfwwBlRBgom9K9Yvu9+NNRa9YPNIqwVPu5/bxoPD7VwtJQEui
egcUXNF4OyQYeVfWGLUp9AnL1Oytnn942SoGKdjyb72YjRmhJ8nrj8inlT1Dq/SJV+wh/7oSyeG6B2bG2BItJegfZPMkyVgse6Aia5rcr1SkG0=”}]}
INFO: [up] PUSH_ACK received in 0 ms

Any other debugging steps I should consider? Thanks again for the reply.

[Jason Reiss]

Are the device and Conduit set to the same Frequency Sub Band?
The Conduit must be using FSB2 since 904.5 was shown as the freq in the rxpk.

Can you check that the session keys match those that the end-device is using after the join?

That packet looks to be noise. First the CRC failed (“stat”:-1) and the expected coderate is “4/5 (“codr”:”OFF”).

[wkhatch@unimar.com]

Jason, I’m not sure how to confirm the session keys match? Can you summarize that process, if possible? It appears we get a join request each time the device sends data. We were on sub band 2, and previous engineer suggested changing it to 7, while awaiting confirmation from the device developer as to which one we should be using. Changing to 7 hasn’t resulted in any change; still not getting lora/+/up

[Jason Reiss]

What is the mPower version installed on the MTCDT?
Is it different from what you have used previously?

On the LoRaWAN > Devices page the Session table has a details button for each session. The Session details popup shows the session keys.

What is the RSSI/SNR of the received packets. It is possible to receive packets on adjacent channels when devices are close to the gateway. Then the Conduit may try to respond on the wrong downlink channel.

I will be good to confirm with the device developer which channels are being used.

Can you get the session keys from the device?

Are there packet_recv messages after the packet_sent or is the device sending only Join Requests?
Is the device receiving the Join Accept?

[wkhatch@unimar.com]

Conduit is model MTCDT-L4N1-246A, firmware 5.2.1. Lora card model: MTAC-LORA-H-915 with hardware MTAC-LORA-1.5 I don’t see anything specific to mPower anywhere?

From the Packets page, Recent Rx Packets:
SNR: 7.2, and RSSI: -54, which was a JnReq

The developer has no idea what sub band; I’ve requested info on the module/shield used to try and track that down

I cannot get session keys from the device; not possible for me to access it, and not sure there’s any sort of api on the device that would return it to me if I did have access.

The flow on every lora transaction loop is:

join_request
packet_recv
packet_recv
joined
packet_sent
packet_sent
packet_sent

I don’t know if it’s getting the join response from the gateway or not.

For now, I’m debugging this by adjusting the sub band setting, and then deleting any existing session keys, then waiting for the next batch of messages from the sensor; not sure what else I can do

Thanks for the hand on this; much appreciated.

[wkhatch@unimar.com]

I’ve tried all sub bands, and still not getting anything on up. Is there something additional I should be doing when changing the sub channel, to make sure we have a clean reset?

[Jason Reiss]

Firmware 5.2.1 is the mPower firmware version I was looking for.

Has the end-device firmware changed since it was last working?
Do you have a device that is known to work or a Conduit that is working?

What is the JSON of the received and transmitted packets that you see in the MQTT output?

[wkhatch@unimar.com]

I haven’t done anything with respect to firmware updates since getting this gateway.

The device I’m testing against is new to use, and developed using an arduino mkr wan 1310 https://store.arduino.cc/usa/mkr-wan-1310, which is using a murata lora radio, I believe. Previous versions of this sensor were able to connect successfully to a rakk raspberry pi, but what I’m using is a different build of the original. I do not believe this build has been tested against the rakk unit.

I’m going to try using three other sensors, which are identical to this one, to rule out some issue with the sensor itself, or some configuration key mismatch, etc.

I have another MTC, which is dealing with a different set of sensors (netvox mostly), which are in a staging environment, so I can’t really take that one down for this test, unfortunately.

Thanks again.

[Jason Reiss]

Since there is a “joined” message the key must be matching and the Join Request has been validated in order to send a Join Accept.

The question is whether or not the Join Accept is received and if it is received have the keys been generated for the session.

I would expect the Murata firmware to work correctly. If there is no way to enable only the 8 channels supported by the gateway is it possible to take a while for a successful join as the device attempt to join over the 64 channels.

[wkhatch@unimar.com]

It turns out our problem was due to message size exceeding the lora spec limits. The sensor device seems to invalidate the existing session, after it is not able to successfully send a message, and subsequently was rejoining on each iteration. We’ve refactored the sensor code to send raw binary data, and my assumption is that I’ll still get a base64 encoded string off the mqtt topic at lora/+/up, and from there, I can do what I need to convert. Thanks for all the help, Jason

[wkhatch@unimar.com]

Just following up for completeness sake, as I’m sure other people will hit this as well, so hopefully this helps somebody.

We’d determined that an upper safe limit as to over all data message size would be around 40 bytes, but, that this is also dependent on the link speed. We’ve since dramatically lowered that to 11 bytes, which seems to be the lowest, most consistent size where we don’t experience problems. We’re just using standard bit packing to get the message size down. During our testing, we did observe several successful transmissions where we were using protobuffers to package up the message, and the message size was significantly higher than 11 bytes, but this was inconsistent; sometimes it would work perfectly, other times it would silently fail, or worse, take down some of the application stack. I am assuming there is some programatic means of controlling the transmission data rate, on the sending device, or maybe this is a lora network setting on the gateway, but I do not know, and have not been able to find, anything documented along these lines. Bear in mind I’m not an RF engineer and have limited knowledge as to the internals of how lora or any other protocol works, so I’m just assuming that we can somehow do these things, otherwise, why would the spec provide for so much more than we can practically use? Anyway, as of now, we’re limiting to 11 bytes total on the payload, until some time in the future we figure out a better solution that accommodates additional data.

[Jason Reiss]

With ADR enabled the network can increase the datarate when the signal looks good. The end-device will lower the datarate when the signal is bad, realized by periodically missed packets. To enforce a minimum datarate with ADR enabled the end-device application would need to monitor the current datarate of the module. There is no message in the current protocol to control the min datarate the ADR back-off algorithm will reach.

Some application designers may sent different sized packets depending on the available datarate with ADR enabled. Or ADR can be disabled and the device can periodically sent a small 11 byte packet on DR0 and a larger packet on DR1. If the network cannot received the DR1 packet it may still be able to receive the DR0 packet.

[Author]

Posts