Recent changes seem incompatible with RegionUS915 requirements

#1

Two recent LoRaWan changes appear to be incompatible with RegionUS915 LoRaWan requirements. Unless the developer changes these within the runtime, applications using these versions within RegionUS915 will not work.

  1. The first:
    Change to the default Data Rate within the Lora library

Commit Note:
set default dr to dr5, set default min sf to sf11
Commit: af14d8b5d9da545ccb1cb1ef95dd9a5024ba0064
Date: May 7
File: libraries/LoRa/src/LoRaWan_APP.cpp
Change:
#define LORAWAN_DEFAULT_DATARATE DR_5

RegionUS915 concern:

DR_5 is not valid for US915

There is a LoRa document that says DR_5 is either “Reserved For Future” use or “Not Defined”.
https://lora-alliance.org/sites/default/files/2020-06/rp_2-1.0.1.pdf

Is there an override or work around other than changing the #define within the runtime? file LoRaWan_APP.cpp?

  1. The second:
    Change to RegionUS915 radio preamble

Commit Note:
modified default min Tx Dr. modified tx preamble length
Commit: f314b1ceb9771e660758e67a518026c09b9e8f94
Date: Jul 9
File: cores/asr650x/loramac/mac/region/RegionUS915.c

Change: preamble length changed from 8 to 14

From: Radio.SetTxConfig( MODEM_LORA, phyTxPower, 0, bandwidth, phyDr, 1, 8, false, true, 0, 0, false, 3e3 );

To: Radio.SetTxConfig( MODEM_LORA, phyTxPower, 0, bandwidth, phyDr, 1, 14, false, true, 0, 0, false, 3e3 );

RegionUS915 concern:
The same LoRaWan document seems to say preamble length should be 8, where does the change to 14 come from?

 [https://lora-alliance.org/sites/default/files/2020-06/rp_2-1.0.1.pdf](https://lora-alliance.org/sites/default/files/2020-06/rp_2-1.0.1.pdf)

There does not appear to be any override/work around other than changing the runtime. What is the resolution to this?

#2

We have updated this question recently. please git pull.

7U1%7D%7BUIE%404%245U%242RRKKRA%7BT

HTCC-AB02S Set Lora Datarate / ADR off
#3

We modified this “14” to “16” (in order to adapt to our new product M00). We have passed the test and will not affect the normal use of the node. You can change it back to “8”

#4

jasonXu, thank you for your response.

Regarding default Data Rate:

While this does help in the short term, it:

  • still requires a separate modification of the runtime if the application/network traffic would benefit from a different data rate setting.
    For example application 1 has a packet size of 10 where DR_0 is ok, application 2 has a packet size of 15 which requires DR_1 or above is required, we must modify the runtime separately or keep two copies.

It seems it would be more benefit to allow an override that does not require runtime library changes,

  • either via a -D file compile time option:
    -D LORAWAN_DEFAULT_DATARATE=DR_4

    along with a corresponding change to the #define as in:

   #ifndef LORAWAN_DEFAULT_DATARATE
   #if defined(REGION_US915) || defined(REGION_US915_HYBRID)
   #define LORAWAN_DEFAULT_DATARATE                    DR_3
   #else
   #define LORAWAN_DEFAULT_DATARATE                    DR_5
   #endif
   #endif
  • or perhaps better still a dynamic change via a LoRaWan API call:
    LoRaWAN.setDataRate(int8_t dataRate);
#6

jasonXu,

I guess I should have asked this already, it does make a difference:

Is this LoRaWan implementation intended to be a “reference” implementation only, or is it intended to become a robust implementation suitable for production environments?

In other words, if these types of issues are flagged can the community, rely on them being resolved or is the runtime intended to be used “as is”, users will need to implement non critical changes as they see fit?

I guess the answer to this is important for my understanding of how to resolve some things.
Thanks

#7

hi,

we have updated the code. please git pull.
0_J(%4076J6)AL8QCOL%7B2%25E%5BY

#8

This update does help, it gives the app developer the opportunity to set the data rate, thank you.

Just a comment regarding the change and a follow up question:

You still have the data rate defaulting to 5 for all regions, which can be somewhat confusing.
The LoRaMac layer will compensate and set the next lower valid rate, which for US915 is DR_4.
So if we do not override (existing app coding compiling against updated runtime) we get DR_4, is this the intended implicit default?

Follow up question:
Relates to this, is the intention to eventually support the dynamic data rate (Adaptive Data Rate) where the network suggests to the end device an optimal data rate? Either via automatic DR changing within the runtime or exposing the network suggested data rate to the application via some sort of getNetworkSuggestedDataRate() API where the application could then decide to change DR or not?

#9

RE: Radio.SetTxConfig()
It is my understanding, and I could be wrong on this, that the LoraWan specification calls for a packet frame preamble of 8 rather than 14 or 16, is this not the case?

This is for LoRaWan, I don’t know what the “LoRa” , non Wan spec might be.

Again, we could manually update the runtime but I don’t think that is a good idea.

#10

I have pulled down the latest version that does have preamble set to 16 (rather than previous 14). I can confirm that when set to 16 it does indeed work for LoRaWan, one need not set to 8.

I’m confused as to why it works with 16, but that’s ok as long as it does.
Thanks

#11

We set it to 16 to adapt our gateway M00，it also works well with gateway using SX1301 or SX1302. We tested and then did that change.
The reason for 16 work well is that, when gateway with rx preamble receive the packet from cubecell, it get a sync timeout at first 8 preambles and then get OK at the second 8 preambles.

#12

Thanks for the explanation.