MQTT message and "datr" JSON item

Home › Forums › Lora Network Server › MQTT message and "datr" JSON item

Tagged: 

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • October 5, 2017 at 10:31 am #21092
    Dave
    Participant

    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.

    October 5, 2017 at 10:58 am #21094
    Jason Reiss
    Keymaster

    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.

    October 5, 2017 at 11:03 am #21095
    Dave
    Participant

    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.

    October 5, 2017 at 11:11 am #21096
    Jason Reiss
    Keymaster

    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.

    October 5, 2017 at 11:21 am #21097
    Dave
    Participant

    That’s great! Thanks again for your help.

    October 5, 2017 at 12:19 pm #21099
    Chris Friedel
    Participant

    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!

    October 5, 2017 at 12:49 pm #21101
    Jason Reiss
    Keymaster

    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.

    October 5, 2017 at 12:57 pm #21102
    Chris Friedel
    Participant

    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!

    October 5, 2017 at 1:05 pm #21103
    Jason Reiss
    Keymaster

    mLinux configuration info

    Conduit mLinux: Advanced LoRa Configuration

    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 #21105
    Chris Friedel
    Participant

    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!

    October 5, 2017 at 3:00 pm #21106
    Jason Reiss
    Keymaster

    51 is at SF12BW125
    66 is at SF12BW500

    NA downlinks use 500kHz.

    October 5, 2017 at 5:04 pm #21115
    Chris Friedel
    Participant

    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.

    October 6, 2017 at 6:36 am #21117
    Jason Reiss
    Keymaster

    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.

    October 6, 2017 at 5:07 pm #21122
    Chris Friedel
    Participant

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

    Have a great weekend.

  • Author
    Posts
Viewing 14 posts - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.