[Shankar Jayagopi]

Looks like when choosing join by personalization the laird RM186 board generates wrong sequence numbers. I have sent an email to the support team.
Under OTA it seems to generate fine.

[Shankar Jayagopi]

Ahhh, Is this something i should consult with the Laird board developers? Coz they don’t really give us a way to increment sequence numbers (LORAMACTxData), i would imagine this to be part of their firmware. (documentation)

But at the same time, I tried running sample program that came with the board, and it seems to be incrementing the sequence number (except a couple of times it failed). When i run my program sometimes it is a hit and sometimes miss.

[Shankar Jayagopi]

I was looking at the logs and i saw the following:

Nov 11 20:24:09 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:c4:c9 Chan LC1 127.0.0.1:35817)  Seq# 1f
Nov 11 20:24:09 mtcdt user.info lora-network-server: Check response size: 00000004 sf: 7 bw: 0 dur: 56 < tm: 66 wnd: 1
Nov 11 20:24:09 mtcdt user.info lora-network-server: TransmitQueue canIncreaseDuration 0 66 0
Nov 11 20:24:09 mtcdt user.info lora-network-server: Band: 1 Time off air: 6100 ms
Nov 11 20:24:09 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 197 bytes
Nov 11 20:24:42 mtcdt user.info lora-network-server: Parsing 1 rx packets
Nov 11 20:24:42 mtcdt user.info lora-network-server: SeqNo: 00000001 PrevSeqNo: 00000008 Duplicate: no^M
Nov 11 20:24:42 mtcdt user.info lora-network-server: Addr: 00:00:00:04 MIC Check: passed
Nov 11 20:24:42 mtcdt user.info lora-network-server: Packet accepted from Node 00:00:00:04  GW 00:80:00:00:00:00:c4:c9  (127.0.0.1)  Seq# 1  ADR enabled SF7BW125
Nov 11 20:24:42 mtcdt user.info lora-network-server: Schedule TX Time on air: 56 ms
Nov 11 20:24:43 mtcdt user.info lora-network-server: Queue app data 7 bytes
Nov 11 20:24:43 mtcdt user.info lora-network-server: Scheduled 12 bytes payload
Nov 11 20:24:43 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:c4:c9 Chan LC1 127.0.0.1:35817)  Seq# 20
Nov 11 20:24:43 mtcdt user.info lora-network-server: Check response size: 00000004 sf: 7 bw: 0 dur: 56 < tm: 61 wnd: 1
Nov 11 20:24:43 mtcdt user.info lora-network-server: TransmitQueue canIncreaseDuration 0 61 0
Nov 11 20:24:43 mtcdt user.info lora-network-server: Band: 1 Time off air: 5600 ms
Nov 11 20:24:43 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 190 bytes
Nov 11 20:25:02 mtcdt user.info lora-network-server: Parsing 1 rx packets
Nov 11 20:25:02 mtcdt user.warn lora-network-server: Recv'd frame failed CRC check
Nov 11 20:25:10 mtcdt user.info lora-network-server: Parsing 1 rx packets
Nov 11 20:25:10 mtcdt user.info lora-network-server: SeqNo: bee27ba0 PrevSeqNo: 00000001 Duplicate: yes^M
Nov 11 20:25:10 mtcdt user.info lora-network-server: Addr: 00:00:00:04 MIC Check: passed
Nov 11 20:25:10 mtcdt user.info lora-network-server: Duplicate Packet accepted from Node 00:00:00:04  GW 00:80:00:00:00:00:c4:c9  (127.0.0.1)  Seq# 1  ADR enabled SF7BW125
Nov 11 20:25:10 mtcdt user.info lora-network-server: Schedule TX Time on air: 56 ms
Nov 11 20:25:11 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:c4:c9 Chan LC3 127.0.0.1:35817)  Seq# 21
Nov 11 20:25:11 mtcdt user.info lora-network-server: Band: 1 Time off air: 4100 ms
Nov 11 20:25:11 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 166 bytes
Nov 11 20:26:59 mtcdt user.info lora-network-server: Parsing 1 rx packets
Nov 11 20:26:59 mtcdt user.info lora-network-server: SeqNo: bee27ba0 PrevSeqNo: 00000001 Duplicate: yes^M
Nov 11 20:26:59 mtcdt user.info lora-network-server: Addr: 00:00:00:04 MIC Check: passed
Nov 11 20:26:59 mtcdt user.info lora-network-server: Duplicate Packet accepted from Node 00:00:00:04  GW 00:80:00:00:00:00:c4:c9  (127.0.0.1)  Seq# 1  ADR enabled SF7BW125
Nov 11 20:26:59 mtcdt user.info lora-network-server: Schedule TX Time on air: 56 ms
Nov 11 20:26:59 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:c4:c9 Chan LC3 127.0.0.1:35817)  Seq# 22
Nov 11 20:26:59 mtcdt user.info lora-network-server: Band: 1 Time off air: 4100 ms
Nov 11 20:26:59 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 166 bytes

The first time it sent the data, downlink worked. The next two times it didn’t.
Started saying “Duplicate: yes” . Why and how does it mark it as duplicate?
Why does it stop working suddenly like this.

[Shankar Jayagopi]

That really helped with the Duty cycle aspect of it.

But for a while when we were sending data to the server, we kept getting back empty packets in port 0.

LoRa Received downstream data on port 0
RSSI: 0SNR: 0data:

Why would server respond in port 0?
Btw, i had also reduced the nodeQueueSize to 1, coz we had some old response being sent out.

regards
Shankar

[Shankar Jayagopi]

Hi Jason,

Thanks for your response.
I was trying to use the test":{"disableDutyCycle":true} but i was not able to add this via
https://AEP-IP/api/loraNetwork?method=PUT&data={"test":{"disableDutyCycle":true}}
it said

{
   "code" : 400,
   "error" : "[test] property is not set",
   "status" : "fail"
}

I tried adding to lora-network-server.conf, but when i restart the server and try to check the values shown by https://AEP-IP/api/loraNetwork, it goes missing.
What is the right way to add this configuration to lora server?

[Author]

Posts