I-CUBE-LRWAN : Why is my node not sending data according to APP_TX_DUTYCYCLE?

[GErze]

Hey,

APP_TX_DUTYCYCLE doesn't really do its job. I set it to 1s and my messages are being sent so that it always skips one.

Example:

1st message sent, 3rd message sent, 5th mesage sent..

Upon increasing the DC parameter it works fine. What is causing this?

I have turned duty cycle off so that isn't the problem. Message's TOA should be around 120ms according to LoRa calculator, so I should be able to lower APP_TX_DUTYCYCLE even more.

Also when sending 70 bytes of payload or above it sends data only once and then never again.

[sergug]

From "LoRaWAN 1.1 Specification":

"Following each uplink transmission the end-device MUST open two short receive windows. The receive window start times are defined using the end of the transmission as a reference."

"The first receive window ... RX1 opens RECEIVE_DELAY1  seconds (+/- 20 microseconds) after the end of the uplink modulation. "

"The second receive window RX2 ... opens RECEIVE_DELAY2 seconds (+/- 20 microseconds) after the end of the uplink modulation. "

By default -  RECEIVE_DELAY1 = "1 sec" and  RECEIVE_DELAY2 = "2 sec"

Thus if the end-device comforms LoRaWAN standard => it is impossible to send data more frequently than once every 3 seconds

[GErze]

True, I know this and I changed values of RX windows too. RX1 is opened 100ms after TX and RX2 200 ms after TX but this does not do anything.

I also changed max duration of RX window to 100ms,

[sergug]

You changed these settings only in the I-CUBE-LRWAN code?

If you use Over-the-Air Activation, then maybe the gateway changing them when sending a "Join-accept message"?

[GErze]

Yes, only in the I-CUBE-LRWAN code. I am not using OTAA because it doesn't work. I keep getting endless join requst - join accept loop.

[jg_spitfire]

Hi, did you solved the problem?, i have the same problem now, thanks

[GErze]

Hello.

No I havent. Which version of FW are you using?

[jg_spitfire]

STM32CubeExpansion_LRWAN_V1.2.1, somebody told me this could help but i havent tried it yet:

Please, see lines 152..160 of RegionEU868.h file 
 
/*! * Join accept delay 1 */ 
 
#define EU868_JOIN_ACCEPT_DELAY1 5000
 
 /*! * Join accept delay 2 */ 
 
#define EU868_JOIN_ACCEPT_DELAY2 6000

the answer is in this LoRa Workshop video from ST

[GErze]

Hey, I think the version you have works for me regarding duty cycle. And yes, you should change these values I think.

The version V1.2.1 is the one currently available on their website correct? If so does your node send good data or is the data you get from your node corrupted?

Whenever I send any message with my node with version V1.2.1 of firmware all characters in the message are random. I made a separate post about it: Link

Do you have the same issue with messages too?

[jg_spitfire]

Hi, yes is the v1.2.1 is the latest,and i havent made tests sending my own data yet, but i suggest you to check the battery level function (because is the only one that is enable by default and i get the data ok in TTN) and use it as a guide to send your own data, for now i am just trying to learn how to get reads from my sensor, after that i will try to send it