Issues with downlink after ABP join

Hi @brocaar

I am having a hard time receiving downlink messages after I connect the node via ABP, OTAA works perfectly.

In this test I am using the microchip nodes even if it should not influence much the whole set up.

I start creating the node in the application server.

I start with an ABP join.

(The first that I don’t care much now is that the join doesn’t finish well at all, the Node activation parameters don’t get set, nor I see a join in MQTT.

Anyway I manually generate those parameters and I plug them into my mote)

After that I manually set the Device address, Network session key and the Application session key (the Node activation parameters) I can send messages from the device.

Finally I am able to send a message, both confirmed or unconfirmed.

The messages arrive and their content is correct :+1:

At this point I store 4 times the same message in the downlink queue

$ mosquitto_pub -h mqtt.server.com -t "application/4/node/ffff2222ffff0002/tx" -m "{\"reference\": \"avrecf1234\",\"confirmed\": true,\"fPort\":11,\"data\": \"Q2lhb0NpYW8=\"}" 
$ mosquitto_pub -h mqtt.server.com -t "application/4/node/ffff2222ffff0002/tx" -m "{\"reference\": \"avrecf1234\",\"confirmed\": true,\"fPort\":11,\"data\": \"Q2lhb0NpYW8=\"}" 
$ mosquitto_pub -h mqtt.server.com -t "application/4/node/ffff2222ffff0002/tx" -m "{\"reference\": \"avrecf1234\",\"confirmed\": true,\"fPort\":11,\"data\": \"Q2lhb0NpYW8=\"}" 
$ mosquitto_pub -h mqtt.server.com -t "application/4/node/ffff2222ffff0002/tx" -m "{\"reference\": \"avrecf1234\",\"confirmed\": true,\"fPort\":11,\"data\": \"Q2lhb0NpYW8=\"}" 

Now I send one two confirmed messages and two uncorfirmed, my expectation is that all four should receive the same messages as downlink.

However:

> mac tx cnf 2 48656c6C6F // send as confirmed messages on port 2 the value hex: 48656c6C6F
ok
mac_rx 11 EF869C848A47E610 // receive on port 11 the value hex: EF869C848A47E610

> mac tx cnf 2 48656c6C6F
ok
mac_rx 11 90A70AFBBDC5993D

> mac tx uncnf 2 48656c6C6F // send as unconfirmed messages on port 2 the value hex: 48656c6C6F
ok
mac_rx 11 93470A4F6453829F 

> mac tx uncnf 2 48656c6C6F
ok
mac_rx 11 CC598FF8122706C9

> mac tx uncnf 2 48656c6C6F
ok
mac_tx_ok // do not receive downlink messages OK

As you can see all the received values are different, and no one is correct one.

If the connection is done via OTAA everything works perfectly.

It is me missing something?

Cheers,

What is the firmware version of your RN2483? There should not be any difference in OTAA / ABP from the LoRa Server side. In the first case the node-session gets created during the join-request / join-accept, in the latter case you create the node-session yourself.

If you could send me the firmware version of your node, I can see if I can replicate your issue :slight_smile:

I do agree that they join method should not influence in any way the messages… However…

My firmware is

sys get ver
RN2483 1.0.0 Oct 02 2015 13:07:34

Could you update the RN2484 firmware to the latest version (1.0.3)? You can download the firmware from the Microchip site: http://www.microchip.com/wwwproducts/en/RN2483 (under Documentation).

(The first that I don’t care much now is that the join doesn’t finish well at all, the Node activation parameters don’t get set, nor I see a join in MQTT.

Please note that the correct order is:

  1. Set DevAddr, NwkSKey and AppSKey in LoRa App Server and on RN2483
  2. Perform a mac join abp (RN2483 specific command)
  3. Send data

Step 2 will not cause a join message as the mac join abp does not cause anything to be transmitted. It is just a command to let the node know that it is activated using ABP.

1 Like

With the newest firmware (v 1.0.3) it works without any issue.

What could have caused the problem? We have other devices (namely LoPy) that seem to be affected as well

Great upgrading to 1.0.3 solved the issue :slight_smile:

Hard to guess what is causing this. One idea that came to my mind is that the node was using its internal downlink frame-counter for decrypting and not the counter from the PHYPayload. When performing an OTAA, it would reset all counters so they would be in sync (as long as there is no downlink packet-loss).

Using ABP however, the node might not reset the frame-counters on mac join abp. When using the internal frame-counter rather than the frame-counter from the downlink PHYPayload, it would decrypt with a different counter than that the data was encrypted with, resulting in garbage…

Again this is guessing as I never had this issue. Would you be able to validate this (e.g. comparing the downlink frame-counters when you receive garbage)?

It would take me at least a solid day of working and messing around with those sensors.

I will most likely do it when I can get my hands to the LoPy