mac set ch drrange 1 0 6 return an error

[savnik]

When using the join command to join a network the command "mac set ch drrange 1 0 6" is send to the RN2483 chip. With the new RN2483A the response is an error, "err". After this response the command "mac set ch dcycle 0 799" is send which also fails with error code "alid_param".

The first command, drrange set s the allowed data rate range on channel 1. With min data rate 0 to max data rate 6. Where data rate 0 is SF12 and data rate 6 is SF6. But SF6 is not a part of the LoRaWAN protocol, but only a part of the LoRa phy. Hence the RN2483 is LoRaWAN certified using SF6 is blocked. Same reason the dcycle commands fails.

I know the documentation from microchip says it can use SF6 but this is not consistent with LoRaWAN. I guess it will make sense to remove these commands.

[jpmeijers]

Great catch savnik! I'll try and find a new RN2483A and test the library better on it.

[tftelkamp]

DR6 is not SF6, it is SF7BW250, which is a valid LoRaWAN data rate.

But I don’t now why the RN2483A would not accept it.

On 13 Jun 2017, at 17:11, Peter Savnik notifications@github.com wrote:

When using the join command to join a network the command "mac set ch drrange 1 0 6" is send to the RN2483 chip. With the new RN2483A the response is an error, "err". After this response the command "mac set ch dcycle 0 799" is send which also fails with error code "alid_param".

The first command, drrange set s the allowed data rate range on channel 1. With min data rate 0 to max data rate 6. Where data rate 0 is SF12 and data rate 6 is SF6. But SF6 is not a part of the LoRaWAN protocol, but only a part of the LoRa phy. Hence the RN2483 is LoRaWAN certified using SF6 is blocked. Same reason the dcycle commands fails.

I know the documentation from microchip says it can use SF6 but this is not consistent with LoRaWAN. I guess it will make sense to remove these commands.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/TheThingsNetwork/arduino-device-lib/issues/208, or mute the thread https://github.com/notifications/unsubscribe-auth/ANijYa7Qf33MlNIrlghpw46FO6g_e70hks5sDqajgaJpZM4N4o7M.

[svenhaitjema]

It might be due to serial timing, commands are send very rapidly by the TTN lib, my observation is that the RN2483A serial communication fails, while on the RN2843 the same arduino firmware succeeds.

Kind regards,

Sven-Erik Haitjema

On Jun 13, 2017 5:18 PM, "Thomas Telkamp" notifications@github.com wrote:

DR6 is not SF6, it is SF7BW250, which is a valid LoRaWAN data rate.

But I don’t now why the RN2483A would not accept it.

On 13 Jun 2017, at 17:11, Peter Savnik notifications@github.com wrote:

When using the join command to join a network the command "mac set ch drrange 1 0 6" is send to the RN2483 chip. With the new RN2483A the response is an error, "err". After this response the command "mac set ch dcycle 0 799" is send which also fails with error code "alid_param".

The first command, drrange set s the allowed data rate range on channel

1. With min data rate 0 to max data rate 6. Where data rate 0 is SF12 and data rate 6 is SF6. But SF6 is not a part of the LoRaWAN protocol, but only a part of the LoRa phy. Hence the RN2483 is LoRaWAN certified using SF6 is blocked. Same reason the dcycle commands fails.

I know the documentation from microchip says it can use SF6 but this is not consistent with LoRaWAN. I guess it will make sense to remove these commands.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ TheThingsNetwork/arduino-device-lib/issues/208, or mute the thread < https://github.com/notifications/unsubscribe-auth/ ANijYa7Qf33MlNIrlghpw46FO6g_e70hks5sDqajgaJpZM4N4o7M>.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/TheThingsNetwork/arduino-device-lib/issues/208#issuecomment-308151257, or mute the thread https://github.com/notifications/unsubscribe-auth/AFrLgsgm3jSDt6vZLsVhxKxzn9NTHuVUks5sDqgqgaJpZM4N4o7M .

[jpmeijers]

I can reproduce this error on the RN2483A:

RN2483	RN2483A	RN2903 (Using EU commands - should fail)
-- STATUS EUI: 0004A30B001C59FC Battery: 3263 AppEUI: 0000000000000000 DevEUI: 0004A30B001C59FC Data Rate: 5 RX Delay 1: 1000 RX Delay 2: 2000 -- JOIN Model: RN2483 Version: 1.0.1 Sending: mac set deveui 0004A30B001C59FC Sending: mac set adr off Sending: mac set deveui 0004A30B001C59FC Sending: mac set appeui 0000000000000000 Sending: mac set appkey 00000000000000000000000000000000 Sending: mac save Sending: mac set rx2 3 869525000 Sending: mac set ch drrange 1 0 6 Sending: mac set ch dcycle 0 799 Sending: mac set ch dcycle 1 799 Sending: mac set ch dcycle 2 799 Sending: mac set ch dcycle 3 799 Sending: mac set ch freq 3 867100000 Sending: mac set ch drrange 3 0 5 Sending: mac set ch status 3 on Sending: mac set ch dcycle 4 799 Sending: mac set ch freq 4 867300000 Sending: mac set ch drrange 4 0 5 Sending: mac set ch status 4 on Sending: mac set ch dcycle 5 799 Sending: mac set ch freq 5 867500000 Sending: mac set ch drrange 5 0 5 Sending: mac set ch status 5 on Sending: mac set ch dcycle 6 799 Sending: mac set ch freq 6 867700000 Sending: mac set ch drrange 6 0 5 Sending: mac set ch status 6 on Sending: mac set ch dcycle 7 799 Sending: mac set ch freq 7 867900000 Sending: mac set ch drrange 7 0 5 Sending: mac set ch status 7 on Sending: mac set pwridx 1 Sending: mac set retx 7 Sending: mac set dr 5 Sending: mac join otaa	-- STATUS EUI: 0004A30B001EC935 Battery: 3294 AppEUI: 0000000000000000 DevEUI: 0004A30B001EC935 Data Rate: 0 RX Delay 1: 1000 RX Delay 2: 2000 -- JOIN Model: RN2483 Version: 1.0.3 Sending: mac set deveui 0004A30B001EC935 Sending: mac set adr off Sending: mac set deveui 0004A30B001EC935 Sending: mac set appeui 0000000000000000 Sending: mac set appkey 00000000000000000000000000000000 Sending: mac save Sending: mac set rx2 3 869525000 Sending: mac set ch drrange 1 0 6 Response is not OK: err Sending: mac set ch dcycle 0 799 Response is not OK: invalid_param Sending: mac set ch dcycle 1 799 Sending: mac set ch dcycle 2 799 Response is not OK: err Sending: mac set ch dcycle 3 799 Response is not OK: invalid_param Sending: mac set ch freq 3 867100000 Response is not OK: invalid_param Sending: mac set ch drrange 3 0 5 Response is not OK: invalid_param Sending: mac set ch status 3 on Response is not OK: rr Sending: mac set ch dcycle 4 799 Response is not OK: invalid_param Sending: mac set ch freq 4 867300000 Response is not OK: invalid_param Sending: mac set ch drrange 4 0 5 Sending: mac set ch status 4 on Response is not OK: err Sending: mac set ch dcycle 5 799 Response is not OK: invalid_param Sending: mac set ch freq 5 867500000 Response is not OK: invalid_param Sending: mac set ch drrange 5 0 5 Response is not OK: invalid_param Sending: mac set ch status 5 on Response is not OK: invalid_param Sending: mac set ch dcycle 6 799 Response is not OK: invalid_param Sending: mac set ch freq 6 867700000 Response is not OK: invalid_param Sending: mac set ch drrange 6 0 5 Sending: mac set ch status 6 on Response is not OK: err Sending: mac set ch dcycle 7 799 Response is not OK: invalid_param Sending: mac set ch freq 7 867900000 Response is not OK: invalid_param Sending: mac set ch drrange 7 0 5 Response is not OK: invalid_param Sending: mac set ch status 7 on Response is not OK: invalid_param Sending: mac set pwridx 1 Response is not OK: invalid_param Sending: mac set retx 7 Response is not OK: invalid_param Sending: mac set dr 5 Response is not OK: invalid_param Sending: mac join otaa	-- STATUS EUI: 0004A30B001AE3D0 Battery: 3233 AppEUI: 0000000000000000 DevEUI: 0004A30B001AE3D0 Data Rate: 3 RX Delay 1: 1000 RX Delay 2: 2000 -- JOIN Model: RN2903 Version: 0.9.5 Sending: mac set deveui 0004A30B001AE3D0 Sending: mac set adr off Sending: mac set deveui 0004A30B001AE3D0 Sending: mac set appeui 0000000000000000 Sending: mac set appkey 00000000000000000000000000000000 Sending: mac save Sending: mac set rx2 3 869525000 Sending: mac set ch drrange 1 0 6 Response is not OK: invalid_param Sending: mac set ch dcycle 0 799 Response is not OK: invalid_param Sending: mac set ch dcycle 1 799 Response is not OK: invalid_param Sending: mac set ch dcycle 2 799 Response is not OK: invalid_param Sending: mac set ch dcycle 3 799 Response is not OK: invalid_param Sending: mac set ch freq 3 867100000 Response is not OK: invalid_param Sending: mac set ch drrange 3 0 5 Response is not OK: invalid_param Sending: mac set ch status 3 on Sending: mac set ch dcycle 4 799 Response is not OK: invalid_param Sending: mac set ch freq 4 867300000 Response is not OK: invalid_param Sending: mac set ch drrange 4 0 5 Response is not OK: invalid_param Sending: mac set ch status 4 on Sending: mac set ch dcycle 5 799 Response is not OK: invalid_param Sending: mac set ch freq 5 867500000 Response is not OK: invalid_param Sending: mac set ch drrange 5 0 5 Response is not OK: invalid_param Sending: mac set ch status 5 on Sending: mac set ch dcycle 6 799 Response is not OK: invalid_param Sending: mac set ch freq 6 867700000 Response is not OK: invalid_param Sending: mac set ch drrange 6 0 5 Response is not OK: invalid_param Sending: mac set ch status 6 on Sending: mac set ch dcycle 7 799 Response is not OK: invalid_param Sending: mac set ch freq 7 867900000 Response is not OK: invalid_param Sending: mac set ch drrange 7 0 5 Response is not OK: invalid_param Sending: mac set ch status 7 on Sending: mac set pwridx 1 Response is not OK: invalid_param Sending: mac set retx 7 Sending: mac set dr 5 Response is not OK: invalid_param Sending: mac join otaa

What is strange is that the module responds with err and not invalid_param. Timing can be an issue, but normally we wait for the ok before sending the next command. This can however be related to the mac save issue.

I'm investigating this further now.

[tftelkamp]

Maybe firmware issue? Install 1.0.3 on both modules?

[jpmeijers]

I can confirm that this issue is related to the mac save issue: https://github.com/TheThingsNetwork/arduino-device-lib/issues/209

Waiting for an ok after calling mac save fixes this issue too.

[jpmeijers]

Fixed by https://github.com/TheThingsNetwork/arduino-device-lib/pull/211