Skip to main content
RThib.1
RThib.1
Associate
April 14, 2020
Question

I-Cube & B-L072Z-LRWAN1 : Strange behaviours on startup and running

  • April 14, 2020
  • 1 reply
  • 685 views

Hi,

I tried to play the I-Cube 1.3.1 / B-L072Z-LRWAN1 example in "End Node" mode but I noticed some strange behaviours. I leted the DUTY_CYCLE configured at 10 seconds and I'm playing on private network with Chirpstack Network Server and App Server. The gateway is a Multitech MTCDT.

  • At launch time, the LoRa Join and the first Up Link is OK but the twelve or thirteen following "Send" aren't sent (and I don't find why) :
APP_VERSION= 01.03.00.00
MAC_VERSION= 04.04.02.00
OTAA
DevEui= ***
AppEui= ***
AppKey= ***
TX on freq 868500000 Hz at DR 0
 1s607: PHY txDone
RX on freq 868500000 Hz at DR 0
 8s447: PHY rxDone
 8s460: APP> MlmeConfirm STATUS: OK
JOINED
SEND REQUEST
TX on freq 867300000 Hz at DR 0
 11s792: PHY txDone
RX on freq 867300000 Hz at DR 0
 14s140: PHY rxDone
 14s144: APP> McpsConfirm STATUS: OK
 
 14s144: #= U/L FRAME 1 =# Class A, Port 2, data size 16, pwr 0, Channel Mask 00FF
 
 14s145: APP> McpsInd STATUS: OK
 
 14s145: #= D/L FRAME 0 =# RxWin 1, Port 0, data size 0, rssi -76, snr 9
 
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
SEND REQUEST
TX on freq 868300000 Hz at DR 5
150s223: PHY txDone
RX on freq 868300000 Hz at DR 5
151s276: PHY rxDone
151s280: APP> McpsConfirm STATUS: OK
 
151s280: #= U/L FRAME 2 =# Class A, Port 2, data size 16, pwr 1, Channel Mask 00FF
 
151s281: APP> McpsInd STATUS: OK
 
151s281: #= D/L FRAME 1 =# RxWin 1, Port 0, data size 0, rssi -72, snr 7
 
SEND REQUEST
TX on freq 868300000 Hz at DR 5
160s217: PHY txDone
RX on freq 868300000 Hz at DR 5
161s271: PHY rxDone
161s275: APP> McpsConfirm STATUS: OK
 
161s275: #= U/L FRAME 3 =# Class A, Port 2, data size 16, pwr 3, Channel Mask 00FF
 
161s276: APP> McpsInd STATUS: OK
 
161s276: #= D/L FRAME 2 =# RxWin 1, Port 0, data size 0, rssi -64, snr 7
 
SEND REQUEST
TX on freq 868500000 Hz at DR 5
170s217: PHY txDone
RX on freq 868500000 Hz at DR 5
171s271: PHY rxDone
171s275: APP> McpsConfirm STATUS: OK
 
171s275: #= U/L FRAME 4 =# Class A, Port 2, data size 16, pwr 5, Channel Mask 00FF
 
171s276: APP> McpsInd STATUS: OK
 
171s276: #= D/L FRAME 3 =# RxWin 1, Port 0, data size 0, rssi -67, snr 7
 
SEND REQUEST
TX on freq 868500000 Hz at DR 5
180s217: PHY txDone
RX on freq 868500000 Hz at DR 5
181s271: PHY rxDone
181s275: APP> McpsConfirm STATUS: OK
 
181s275: #= U/L FRAME 5 =# Class A, Port 2, data size 16, pwr 6, Channel Mask 00FF
 
181s276: APP> McpsInd STATUS: OK
 
181s276: #= D/L FRAME 4 =# RxWin 1, Port 0, data size 0, rssi -68, snr 6
 
  • Next, all is OK during a certain time :
SEND REQUEST
TX on freq 868500000 Hz at DR 5
180s217: PHY txDone
RX on freq 868500000 Hz at DR 5
181s271: PHY rxDone
181s275: APP> McpsConfirm STATUS: OK
 
181s275: #= U/L FRAME 5 =# Class A, Port 2, data size 16, pwr 6, Channel Mask 00FF
 
181s276: APP> McpsInd STATUS: OK
 
181s276: #= D/L FRAME 4 =# RxWin 1, Port 0, data size 0, rssi -68, snr 6
 
SEND REQUEST
TX on freq 867300000 Hz at DR 5
190s217: PHY txDone
RX on freq 867300000 Hz at DR 5
191s250: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
192s453: PHY rxTimeOut
192s454: APP> McpsConfirm STATUS: OK
 
192s454: #= U/L FRAME 6 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF
 
  • To finish, I noticed that multiple Tx are sometimes done but I don't know why. This behaviour seem to happen after a downlink. 
SEND REQUEST
TX on freq 868300000 Hz at DR 5
610s212: PHY txDone
RX on freq 868300000 Hz at DR 5
611s246: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
612s448: PHY rxTimeOut
612s449: APP> McpsConfirm STATUS: OK
 
612s449: #= U/L FRAME 48 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF
 
SEND REQUEST
TX on freq 867900000 Hz at DR 5
620s212: PHY txDone
RX on freq 867900000 Hz at DR 5
621s265: PHY rxDone
621s269: APP> McpsConfirm STATUS: OK
 
621s270: #= U/L FRAME 49 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF
 
621s270: APP> McpsInd STATUS: OK
 
621s271: #= D/L FRAME 5 =# RxWin 1, Port 0, data size 0, rssi -64, snr 6
 
SEND REQUEST
TX on freq 867900000 Hz at DR 5
630s217: PHY txDone
RX on freq 867900000 Hz at DR 5
631s271: PHY rxDone
631s275: APP> McpsConfirm STATUS: OK
 
631s275: #= U/L FRAME 50 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF
 
631s276: APP> McpsInd STATUS: OK
 
631s276: #= D/L FRAME 6 =# RxWin 1, Port 0, data size 0, rssi -66, snr 7
 
SEND REQUEST
TX on freq 867300000 Hz at DR 5
640s217: PHY txDone
RX on freq 867300000 Hz at DR 5
641s250: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
642s453: PHY rxTimeOut
TX on freq 868500000 Hz at DR 5
642s545: PHY txDone
RX on freq 868500000 Hz at DR 5
643s578: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
644s780: PHY rxTimeOut
TX on freq 867500000 Hz at DR 5
647s438: PHY txDone
RX on freq 867500000 Hz at DR 5
648s471: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
649s673: PHY rxTimeOut
649s674: APP> McpsConfirm STATUS: OK
 
649s674: #= U/L FRAME 51 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF
 
SEND REQUEST
TX on freq 868500000 Hz at DR 5
650s212: PHY txDone
RX on freq 868500000 Hz at DR 5
651s246: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
652s448: PHY rxTimeOut
TX on freq 867500000 Hz at DR 5
654s654: PHY txDone
RX on freq 867500000 Hz at DR 5
655s687: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
656s889: PHY rxTimeOut
TX on freq 868500000 Hz at DR 5
656s976: PHY txDone
RX on freq 868500000 Hz at DR 5
658s009: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
659s211: PHY rxTimeOut
659s212: APP> McpsConfirm STATUS: OK
 
659s212: #= U/L FRAME 52 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF

If you have any ideas on these behaviors, I would appreciate it.

Regards,

Thibaud

This topic has been closed for replies.

1 reply

RThib.1
RThib.1Author
Associate
April 15, 2020

Hi,

I did some additional tests with a duty cycle set at 300 seconds (5 minutes). The behaviours are a little bit different :

  • The first messages who were not send are now OK (I will try with shorter duty cycle to see what happens)
  • I always have a serie of txDone/rxTimeOut after a downlink with mac command. The detail is above :

Frame 209 OK :

SEND REQUEST
TX on freq 868500000 Hz at DR 5
62700s212: PHY txDone
RX on freq 868500000 Hz at DR 5
62701s246: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
62702s448: PHY rxTimeOut
62702s449: APP> McpsConfirm STATUS: OK
 
62702s449: #= U/L FRAME 209 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF

Frame 210 OK with a downlink :

The downlink contains a Mac Command defined in fOpts with the value "A1f/AAI=" (0x 03 57 ff 00 02) ==> LinkADRReq :

Extract from the LoRaWAN 1.0.3 specification : 0x03 : LinkADRReq => Requests the end-deviceto change data rate, transmit power, repetition rate or channel

SEND REQUEST
TX on freq 867700000 Hz at DR 5
63000s212: PHY txDone
RX on freq 867700000 Hz at DR 5
63001s265: PHY rxDone
63001s269: APP> McpsConfirm STATUS: OK
 
63001s270: #= U/L FRAME 210 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF
 
63001s271: APP> McpsInd STATUS: OK
 
63001s271: #= D/L FRAME 22 =# RxWin 1, Port 0, data size 0, rssi -58, snr 7

Frame 211 OK with a downlink :

The uplink contains a Mac Command defined in fOpts with the value "Awc=" (0x 03 07) ==> LinkADRAns :

The downlink contains a Mac Command defined in fOpts with the value "A1f/AAM=" (0x 03 57 ff 00 03) ==> LinkADRReq :

SEND REQUEST
TX on freq 867900000 Hz at DR 5
63300s217: PHY txDone
RX on freq 867900000 Hz at DR 5
63301s271: PHY rxDone
63301s275: APP> McpsConfirm STATUS: OK
 
63301s275: #= U/L FRAME 211 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF
 
63301s276: APP> McpsInd STATUS: OK
 
63301s276: #= D/L FRAME 23 =# RxWin 1, Port 0, data size 0, rssi -52, snr 7

Frame 212 with strange behaviour :

The uplink contains a Mac Command defined in fOpts with the value "Awc=" (0x 03 07) ==> LinkADRAns :

SEND REQUEST
TX on freq 867500000 Hz at DR 5
63600s217: PHY txDone
RX on freq 867500000 Hz at DR 5
63601s250: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
63602s453: PHY rxTimeOut
TX on freq 868300000 Hz at DR 5
63602s545: PHY txDone
RX on freq 868300000 Hz at DR 5
63603s578: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
63604s780: PHY rxTimeOut
TX on freq 867100000 Hz at DR 5
63607s439: PHY txDone
RX on freq 867100000 Hz at DR 5
63608s471: PHY rxTimeOut
RX on freq 869525000 Hz at DR 0
63609s673: PHY rxTimeOut
63609s674: APP> McpsConfirm STATUS: OK
 
63609s674: #= U/L FRAME 212 =# Class A, Port 2, data size 16, pwr 7, Channel Mask 00FF
 

The same behavour is noticed on frame 213, 214, 215, 216... About 15 or 16 frames have the same behaviour after the downlink.

I don't really undestand what happens in the LoRaMac layer when this downlink arrive. If you have any idea ;)

Regards,

Thibaud

Terms & ConditionsAccessibility statement