Second Transmission Fails

Hello All,

I’ve run into a strange problem. My devices join with no problem. The first transmission after joining occurs with no problem as far as I can tell. However, the second transmission call (LoRaWAN_Send()) never completes. Assuming I use the M4_WaitActive wait mode, the program gets stuck at:
while (coreArguments.status.system.isBusy) {} (line 130 in OnethinxCore01.c)…

This behavior is happening consistently with multiple devices.

Any idea what could be happening here? Note that joining and the first transmission are always successful. Things only go wrong on the second transmission. I should also mention that my stack version is BA.

Paul

Hi Paul, can you try with M4_WaitDeepSleep and let us know?

Tom

Tom, essentially the same happens regardless of the wait mode (other than M4_NoWait). If I specify one of the sleep modes, the code hangs at the statement:
while (_FLD2VAL(CPUSS_CM4_PWR_CTL_PWR_MODE, (*cpussCm4PwrCtlAddr)) == CM4_PWR_STS_RETAINED); (line 3006 of cy_syspm.c).

I also tried using M4_NoWait wait mode. After the first LoRaWAN_Send call, the packet was received by the server and the coreArguments.status.system.isBusy flag eventually became false. After the second call, the coreArguments.status.system.isBusy flag stayed true forever and the packet was never received by the server. Both of these calls returned coreArguments.status.system.errorStatus value of system_ok.

When using M4_NoWait wait mode, the system doesn’t hang, but the third and all subsequent calls to LoRaWAN_Send return coreArguments.status.system.errorStatus value system_BusyError. And of course, only the first packet is received by the server.

At first, I thought there might be a problem with the modules that I am currently using in the lab. However, this problem appears to have surfaced in devices that previously worked fine. While I did update their code, I don’t believe any changes I made had anything to do with the communications.

Just to be sure, I programmed a device with code that was several months old. This new behavior, which never occured before, now occurs even with old code.

I’m dumbfounded and stuck. Any suggestions would be appreciated.

Paul

Here’s an update. I can successfully send to TTN V3 if I change the LoRaWAN version (in the TTN V3 console) from MAC V1.0.3 to MAC V1.0.2. I don’t know if the problem is with TTN or if my stack (B4) doesn’t work with MAC V1.0.3. Any information about this would be appreciated.

I consider this a workaround, not a solution, because MAC V1.0.2 (in the US) doesn’t supply a CFList, thereby requiring fixed sub-band in the end device. However, this does give me a path forward.

Paul

Hi Paul,

you have done this with B4 version? Did you try with BA version?

Tom

Oops. I meant BA.

Paul

Onethinx module is made according to 1.0.2 revB regional parameters found here:
https://lora-alliance.org/resource_hub/lorawan-regional-parameters-v1-0-2rb/

This is why you need to select 1.0.2 version

Hi Tom,

Thanks for the information. Do you know if newer stack versions either support 1.0.3 or at least won’t hang up if the server uses 1.0.3?

Paul

Here’s an update:

While I can successfully communicate with TTN V3 if the server uses MAC 1.0.2, I still have the same problem (stuck after 1st transmission after joining) with another network (MyDevices), even though the server is expecting 1.0.2 with my sensors. Watching the LoRaWAN frames, I discovered that, after the first unconfirmed uplink, with the ADR flag set to False, the MyDevices server responds with an unconfirmed downlink with the ADR flag set to true. TTN does not return a downlink after I send an unconfirmed uplink.

Could this unsolicited downlink be the cause of coreArguments.status.system.isBusy never clearing and therefore, causing my code to hang? If so, is this a bug in the stack (BA) or is the server doing something wrong?

Paul

Hi Paul,

Can you please let me know if the same happens if you register the device with pre selected Onethinx settings as shown on the image?

Hi Tom,

The screenshot is from TTN. I don’t have a problem with TTN, so far. The problem is with another network, MyDevices. The profile they set up for my sensors expects MAC 1.0.2, Regional Parameters Rev B.

While watching uplink/downlink traffic, I noticed that TTN has not been sending downlinks. However, after the first uplink, MyDevices sends a packet back to the sensor. I previously called this an unsolicited downlink. MyDevices didn’t like my nomenclature. This was their reply:

Our network server is not sending an unsolicited downlink message. In fact, it is sending a Mac Command that the device should at least interpret. The downlink our network server is sending is a MAC Command on fPort 0 indicating that ADR is enabled on the server and the device should comply. If the device doesn’t support ADR, it shouldn’t stop working and instead refuse the ADR requests. We have a handful of devices that receive unsupported ADR requests from the server, but continue to send uplink data.

I’m attaching the logs from our server to send to device manufacturers for review.

Here’s the log they sent (.json):
[
{
“downlinkMetaData”: {
“txInfo”: {
“gatewayID”: “AACAApz1CcA=”,
“frequency”: 925100000,
“power”: 20,
“modulation”: “LORA”,
“loRaModulationInfo”: {
“bandwidth”: 500,
“spreadingFactor”: 7,
“codeRate”: “4/5”,
“polarizationInversion”: true
},
“board”: 0,
“antenna”: 0,
“timing”: “DELAY”,
“delayTimingInfo”: {
“delay”: “1s”
},
“context”: “t3YPSw==”
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “UnconfirmedDataDown”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“fhdr”: {
“devAddr”: “01f4e1fa”,
“fCtrl”: {
“adr”: true,
“adrAckReq”: false,
“ack”: false,
“fPending”: false,
“classB”: false
},
“fCnt”: 0,
“fOpts”: [
{
“bytes”: “AwAAAHADMAD/AQ==”
}
]
},
“fPort”: null,
“frmPayload”: null
},
“mic”: “da33519b”
}
},
{
“uplinkMetaData”: {
“rxInfo”: [
{
“gatewayID”: “AACAApz1CcA=”,
“time”: null,
“timeSinceGPSEpoch”: null,
“rssi”: -35,
“loRaSNR”: 9.5,
“channel”: 3,
“rfChain”: 0,
“board”: 0,
“antenna”: 0,
“location”: {
“latitude”: 0,
“longitude”: 0,
“altitude”: 0,
“source”: “UNKNOWN”,
“accuracy”: 0
},
“fineTimestampType”: “NONE”,
“context”: “t3YPSw==”,
“uplinkID”: “fp+zpKk2Sq60Tpt52DiARQ==”,
“crcStatus”: “CRC_OK”
}
],
“txInfo”: {
“frequency”: 904500000,
“modulation”: “LORA”,
“loRaModulationInfo”: {
“bandwidth”: 125,
“spreadingFactor”: 7,
“codeRate”: “4/5”,
“polarizationInversion”: false
}
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “UnconfirmedDataUp”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“fhdr”: {
“devAddr”: “01f4e1fa”,
“fCtrl”: {
“adr”: false,
“adrAckReq”: false,
“ack”: false,
“fPending”: false,
“classB”: false
},
“fCnt”: 0,
“fOpts”: null
},
“fPort”: 20,
“frmPayload”: [
{
“bytes”: “S+iqKg==”
}
]
},
“mic”: “38ad024c”
}
},
{
“downlinkMetaData”: {
“txInfo”: {
“gatewayID”: “AACAApz1CcA=”,
“frequency”: 925100000,
“power”: 20,
“modulation”: “LORA”,
“loRaModulationInfo”: {
“bandwidth”: 500,
“spreadingFactor”: 10,
“codeRate”: “4/5”,
“polarizationInversion”: true
},
“board”: 0,
“antenna”: 0,
“timing”: “DELAY”,
“delayTimingInfo”: {
“delay”: “5s”
},
“context”: “to0HjA==”
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “JoinAccept”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“bytes”: “Ut72loh7XJ+ABZWT”
},
“mic”: “56d96546”
}
},
{
“uplinkMetaData”: {
“rxInfo”: [
{
“gatewayID”: “AACAApz1CcA=”,
“time”: null,
“timeSinceGPSEpoch”: null,
“rssi”: -34,
“loRaSNR”: 10.5,
“channel”: 3,
“rfChain”: 0,
“board”: 0,
“antenna”: 0,
“location”: {
“latitude”: 0,
“longitude”: 0,
“altitude”: 0,
“source”: “UNKNOWN”,
“accuracy”: 0
},
“fineTimestampType”: “NONE”,
“context”: “to0HjA==”,
“uplinkID”: “xyzA9FbFSY2vDBCVnbo+wQ==”,
“crcStatus”: “CRC_OK”
}
],
“txInfo”: {
“frequency”: 904500000,
“modulation”: “LORA”,
“loRaModulationInfo”: {
“bandwidth”: 125,
“spreadingFactor”: 10,
“codeRate”: “4/5”,
“polarizationInversion”: false
}
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “JoinRequest”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“joinEUI”: “425249474e4f4c45”,
“devEUI”: “70b3d5068000178f”,
“devNonce”: 14010
},
“mic”: “d742b72e”
}
},
{
“downlinkMetaData”: {
“txInfo”: {
“gatewayID”: “AACAApz1CcA=”,
“frequency”: 927500000,
“power”: 20,
“modulation”: “LORA”,
“loRaModulationInfo”: {
“bandwidth”: 500,
“spreadingFactor”: 10,
“codeRate”: “4/5”,
“polarizationInversion”: true
},
“board”: 0,
“antenna”: 0,
“timing”: “DELAY”,
“delayTimingInfo”: {
“delay”: “5s”
},
“context”: “tYH85A==”
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “JoinAccept”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“bytes”: “VWG4v49AMBoihzDg”
},
“mic”: “1d567d76”
}
},
{
“uplinkMetaData”: {
“rxInfo”: [
{
“gatewayID”: “AACAApz1CcA=”,
“time”: null,
“timeSinceGPSEpoch”: null,
“rssi”: -35,
“loRaSNR”: 11.3,
“channel”: 7,
“rfChain”: 1,
“board”: 0,
“antenna”: 0,
“location”: {
“latitude”: 0,
“longitude”: 0,
“altitude”: 0,
“source”: “UNKNOWN”,
“accuracy”: 0
},
“fineTimestampType”: “NONE”,
“context”: “tYH85A==”,
“uplinkID”: “to0xcUPiRl6U44bHzy2gog==”,
“crcStatus”: “CRC_OK”
}
],
“txInfo”: {
“frequency”: 905300000,
“modulation”: “LORA”,
“loRaModulationInfo”: {
“bandwidth”: 125,
“spreadingFactor”: 10,
“codeRate”: “4/5”,
“polarizationInversion”: false
}
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “JoinRequest”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“joinEUI”: “425249474e4f4c45”,
“devEUI”: “70b3d5068000178f”,
“devNonce”: 3431
},
“mic”: “77d2b45c”
}
},
{
“uplinkMetaData”: {
“rxInfo”: [
{
“gatewayID”: “AACAApz1CcA=”,
“time”: null,
“timeSinceGPSEpoch”: null,
“rssi”: -34,
“loRaSNR”: 10.8,
“channel”: 6,
“rfChain”: 1,
“board”: 0,
“antenna”: 0,
“location”: {
“latitude”: 0,
“longitude”: 0,
“altitude”: 0,
“source”: “UNKNOWN”,
“accuracy”: 0
},
“fineTimestampType”: “NONE”,
“context”: “tHbwjA==”,
“uplinkID”: “YbW/YXtsRXKgA2RZX6ihCQ==”,
“crcStatus”: “CRC_OK”
}
],
“txInfo”: {
“frequency”: 905100000,
“modulation”: “LORA”,
“loRaModulationInfo”: {
“bandwidth”: 125,
“spreadingFactor”: 10,
“codeRate”: “4/5”,
“polarizationInversion”: false
}
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “JoinRequest”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“joinEUI”: “425249474e4f4c45”,
“devEUI”: “70b3d5068000178f”,
“devNonce”: 26111
},
“mic”: “59112f39”
}
}
]

Paul

More Info:

After looking more closely at TTN gateway data and device data in verbose mode, I see that TTN also sends messages/commands downstream. So now the question is, why does the module process TTN messages/commands, but get stuck in a “busy” state after receiving from MyDevices?

Any ideas?

Paul

Hi Paul,

I will test with BA on ADR. Will get back to you as soon as I know more.

Hi Paul,

I have found (and confirm) there is a problem with version BA and ADR. I will contact you by email for solution.

Tom

Hi Tom,

I am now using modules with stack BF. The problem seems to be gone.

I also noticed a nice new “enhancement” (or bug fix). When using stack BA, every time I loaded new code, the flash blocks used by LoRaWAN_FlashRead() and LoRaWAN_FlashWrite() would be cleared. Now, with stack BF, data that I’ve stored in those blocks remains after I load a new program. Excellent!

I don’t understand how changes to the M0+ code can affect the programmer. No matter. I’ll just take the benefit and be happy.

Paul