Class C Downlink Issue

[Khaled Aljehani]

Posted on January 31, 2018 at 19:15

Hi,

I have B-L072Z-LRWAN1 board from ST running I-CUBE-LRWAN software for LoRaWAN, and RHF0M301 gateway from RisingHF.

I am testing a class C and I have an issue in downlink, here is the scenario:

1. Node transmit an uplink to server, then a delay for 30s to transmit the next packet.
2. During that time I send a packet from server, it is received by gateway ( INFO: [down] a packet will be sent in �immediate� mode)
3. But it is not sent to node immediately, node receives the packet before the timeout, then process the next uplink immediately. (For example, at 28s it receives the packet, at 30s it process the next uplink)

So, what is the reason of this problem? How can I solve it?

In my viewpoint, It could be caused by the gateway (no immediate transmit), or configurations in node.

Best regards.

#lora #lorawan

[Khaled Aljehani]

Posted on February 05, 2018 at 17:49

Update:

I disabled Tx in node, and enabled only Rx. Then, I sent multiple downlinks and were received without any issue (except it takes almost 4 seconds till the action is executed, using default RX2 - SF 12) 

Any ideas about the problem?

[Khaled Aljehani]

Posted on February 05, 2018 at 18:22

Hi

Turvey.Clive.002

‌

Any thought about my problem?

[Tesla DeLorean]

Posted on February 05, 2018 at 18:45

You should perhaps use the Semtech LoRa Calculator to determine the flight time of the data packet being sent.

There are a lot of delays in the LRWAN code, one needs to be wary of timeouts, and that the node isn't listening in TX and IDLE modes.

[T J]

Posted on February 05, 2018 at 21:54

the software in the concentrator may not be top level.

Maybe you should try a different concentrator brand, not from china

'the time of flight'  I calculated yesterday:

I use 9600 baud to send the packet to the module:

and then 2400 baud ' air rate'

time of flight =  {Packet length} *10 / 9600;      // 10 bits to a byte, transmit to module

time of flight +=  {Packet length} *12 / 2400;      // 12 bits per byte, over the air.  // includes bit stuffing

[Tesla DeLorean]

Posted on February 06, 2018 at 16:11

Not really in a position to analyze the problem further. You can better instrument the LRWAN code to understand the state it is in. The concentrator is a black box, you could change for a multitech or laird box which would likely have more robust and trustworthy firmware.

[Khaled Aljehani · Accepted solution]

Posted on February 06, 2018 at 21:25

I found out my mistake and solved the problem. 

I added a delay function in 

OnTxNextPacketTimerEvent function for scheduling next packet transmissions. What is correct is to modify 

TimerSetValue instead of modifying in other functions.

case DEVICE_STATE_SEND:

{ if( NextTx == true ) { PrepareTxFrame( ); NextTx = SendFrame( );

}

if( ComplianceTest.Running == true ) { // Schedule next packet transmission as soon as possible TimerSetValue( &TxNextPacketTimer, 5000); /* 5s */ TimerStart( &TxNextPacketTimer ); } else if (LoRaParamInit->TxEvent == TX_ON_TIMER ) { // Schedule next packet transmission TimerSetValue( &TxNextPacketTimer,

50000

); // add delay here TimerStart( &TxNextPacketTimer ); }

DeviceState = DEVICE_STATE_SLEEP;

break; }

[Khaled Aljehani]

Posted on February 06, 2018 at 21:30

Turvey.Clive.002

‌

Marsh.Nick

I really appreciate your help and effort.

As I mentioned above, I did a mistake and solved it.

Now, I want send MAC commands from node. Any idea or reference code?

Also, I face another problems in the code, is there another place in ST where I get a support other than community?

Best regards.