MQTT message and "datr" JSON item

[Dave]

When sending a message via the MQTT server, there is a field I can add to the JSON object called “datr – the LoRa datarate identifier”. How is this field supposed to be used? Do I have to specify it whenever I send a message? What happens if I don’t specify it? If I have to specify it, how can I get the data rate at the time I need to send a message?

Thanks,
Dave.

[Jason Reiss]

There is no need to specify a datr field to a message sent to the network server. This field is provided by the network server on uplink packets received and downlink packets sent. The datarate used is determined by the LoRaWAN protocol and configuration of Rx1 and Rx2 settings.

[Dave]

Thanks for the reply.

So what happens if I try to send a message that is too big for the current data rate? Will it be broken up by the network server and each fragment delivered to the mDot? We have an using the mDot to receive messages. What will the app see? Each fragment or the final, re-assembled message?

Dave.

[Jason Reiss]

There is no fragmentation.
A packet that is too big will have to wait until an time it can fit in the downlink.

Downlink payloads of 51 bytes for EU and 66 bytes for US can be sent at any datarate.

The Rx2 Datarate can be set to ensure a specific datarate.
Although there is then a trade-off of larger size for maximum range.

[Dave]

That’s great! Thanks again for your help.

[Chris Friedel]

Hi Jason,
Thanks for the answer above. I’m trying to understand the implications of that answer.

According to LoRaWAN specification:

“The RX2 receive window uses a fixed frequency and data rate. The default parameters are 869.525 MHz / DR0 (SF12, 125 kHz).”

It sounds like Multitech is instead using SF9BW125 by default for the receive window by default? Or do downlink messages have a completely different set of configuration and constraints from uplink?

(Out of curiosity, is this controlled by the network server or the packet forwarder? )

I think the specific concern we’re trying to address is, if a remote device at long distance is only able to uplink at SF10, and SF9 is not enough to send the downlink to the remote, then
a) does that not mean the downlink will never reach a very distant device in this case?
b) if so, then how do we force the network server to use SF10BW125 for the this specific downlink (or if that granularity isn’t possible, downlinks for this remote device).

I’ve found precious little on any of the nuances of downlinks on LoRaWan (in general, or on the network server multitech uses) – do you have any links to documentation or similar that might help us find some of this?

Thank you so much for the help!

[Jason Reiss]

In EU the Rx2 downlink channel 869.525 can use a higher power (27 dBm EIRP) than the 14 dBm EIRP limit of the rest of the 863-870 band.

The Rx2 Datarate is configurable in Conduit. The Join response will be sent in Rx2 at the LoRaWAN default.

The Rx2 window is a specific frequency and datarate and must be configured on the device, the datarate is sent to the device in OTA join response.

Rx2 settings are not configurable for a single device or downlink.

The best resources are the LoRaWAN specification directly from the lora-alliance or the Semtech reference implementation https://github.com/Lora-net/LoRaMac-node.

[Chris Friedel]

Excellent, that all makes a lot of sense. Thank you.

If I may ask one last question – where / how is the Rx2 datarate configured in the conduit?

Thanks again!

[Jason Reiss]

mLinux configuration info
http://www.multitech.net/developer/software/lora/conduit-mlinux-lora-communication/conduit-mlinux-advance-lora-configuration/

AEP see Setup > Lora page

The test setting disableRxWindow1 maybe useful to force the network server to always use Rx2.

[Chris Friedel]

Jason, sorry, I have one more clarification please.

You mentioned downlinks of 51 bytes for EU and 66 bytes for North America are always possible.

Looking through section 7 of the spec, I can’t figure out where those numbers come from. At SF9BW125 I’d expect EU at 115 Bytes, and NA is 53 Bytes.

Is the downlink being handled in a special way by the conduit that allows for these special sizes? Or am I just misunderstanding the spec?

Sorry for the questions – we want to make sure we get the downlinks right before we ship! Thank you yet again!

[Jason Reiss]

51 is at SF12BW125
66 is at SF12BW500

NA downlinks use 500kHz.

[Chris Friedel]

Aha! Thanks Jason, I missed that the wider bandwidth for NA downlinks (we are primarily operating in NA, so those are the numbers more interesting to us). I see that in the spec now as well.

Sorry to beat this dead horse, but 7.2.6 lists SF12BW500 (DR8) with a max payload as 33 bytes. (This is suspiciously half of the 66 you mentioned)… 7.2.6 also says you can increase this size to 53 bytes if you will never use a repeater. But I can’t figure out how to get that value to 66. Can you add any other insight into how I can get to that 66 byte number?

Thank you so much for your patience; you have been extremely helpful and informative.

[Jason Reiss]

You’re right. 66 is the maximum packet size with header info for DR8.
This is the N value (53) plus 13 bytes for header and MIC.

Just to clarify the EU info too. 51 bytes is payload size without header and MIC. 64 bytes is max packet size for DR0-SF12BW125.

[Chris Friedel]

Just wanted to say thanks for all your help on this. It was extremely helpful, and very appreciated.

Have a great weekend.

[Author]

Posts