MQTT message and "datr" JSON item
Home › Forums › Lora Network Server › MQTT message and "datr" JSON item
Tagged: mqtt JSON lora lorawan
- This topic has 13 replies, 3 voices, and was last updated 7 years, 5 months ago by
Chris Friedel.
-
AuthorPosts
-
October 5, 2017 at 10:31 am #21092
Dave
ParticipantWhen 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.October 5, 2017 at 10:58 am #21094Jason Reiss
KeymasterThere 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.
October 5, 2017 at 11:03 am #21095Dave
ParticipantThanks 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.
October 5, 2017 at 11:11 am #21096Jason Reiss
KeymasterThere 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.October 5, 2017 at 11:21 am #21097Dave
ParticipantThat’s great! Thanks again for your help.
October 5, 2017 at 12:19 pm #21099Chris Friedel
ParticipantHi 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!
October 5, 2017 at 12:49 pm #21101Jason Reiss
KeymasterIn 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.
October 5, 2017 at 12:57 pm #21102Chris Friedel
ParticipantExcellent, 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!
October 5, 2017 at 1:05 pm #21103Jason Reiss
KeymastermLinux configuration info
AEP see Setup > Lora page
The test setting disableRxWindow1 maybe useful to force the network server to always use Rx2.
October 5, 2017 at 2:56 pm #21105Chris Friedel
ParticipantJason, 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!
October 5, 2017 at 3:00 pm #21106Jason Reiss
Keymaster51 is at SF12BW125
66 is at SF12BW500NA downlinks use 500kHz.
October 5, 2017 at 5:04 pm #21115Chris Friedel
ParticipantAha! 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.
October 6, 2017 at 6:36 am #21117Jason Reiss
KeymasterYou’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.
October 6, 2017 at 5:07 pm #21122Chris Friedel
ParticipantJust wanted to say thanks for all your help on this. It was extremely helpful, and very appreciated.
Have a great weekend.
-
AuthorPosts
- You must be logged in to reply to this topic.