No consigo que transmita el SAMR34, envio los siguientes comandos, pero no llegan UpLinks al gateway.
25/3/2021 23:09:15 [TX] - sys factoryRESET
25/3/2021 23:09:15 [RX] - _{7GNW7WGnW7W§þ—7GW;N]fGN]f¼W7Gø÷;w]:nw¸·;u]ø
USER BOARD MLS_SDK_1_0_P_4 Mar 25 2021 23:06:30
25/3/2021 23:09:17 [TX] - mac reset AU915
25/3/2021 23:09:17 [RX] - ok
25/3/2021 23:09:18 [TX] - mac set deveui A5000003C1E3B83D
25/3/2021 23:09:18 [RX] - ok
25/3/2021 23:09:19 [TX] - mac set joineui 1111111111111111
25/3/2021 23:09:19 [RX] - ok
25/3/2021 23:09:19 [TX] - mac set appkey 01010101010101010101010101010101
25/3/2021 23:09:19 [RX] - ok
25/3/2021 23:09:20 [TX] - mac set edclass c
25/3/2021 23:09:20 [RX] - ok
25/3/2021 23:09:21 [TX] - mac set subband status 2 off
25/3/2021 23:09:21 [RX] - ok
25/3/2021 23:09:21 [TX] - mac set subband status 3 off
25/3/2021 23:09:21 [RX] - ok
25/3/2021 23:09:22 [TX] - mac set subband status 4 off
25/3/2021 23:09:22 [RX] - ok
25/3/2021 23:09:22 [TX] - mac set subband status 5 off
25/3/2021 23:09:22 [RX] - ok
25/3/2021 23:09:23 [TX] - mac set subband status 6 off
25/3/2021 23:09:23 [RX] - ok
25/3/2021 23:09:23 [TX] - mac set subband status 7 off
25/3/2021 23:09:23 [RX] - ok
25/3/2021 23:09:23 [TX] - mac set subband status 8 off
25/3/2021 23:09:24 [RX] - ok
25/3/2021 23:09:25 [TX] - mac join otaa
25/3/2021 23:09:25 [RX] - ok
25/3/2021 23:09:33 [RX] - denied}

Hi @gd91,

When I performed the tests with the max Uplink and Downlink Payload Size I have observed a mismatch in the uplink and downlink payload size for DR0 on SAMR34 Xplained Pro.

Please find the details below.

End device configuration:

1. Frequency: IND865
2. Transmission Type: Unconfirmed
3. Device Class: Class C
4. Activation Mode: OTAA
5. Data Rate: DR0
6. LoRaWAN Specification of the MLS Stack: LoRaWAN 1.0.4 as per the Migration Guide provided in the MLS 1_0_P_5

Network server: The Things Enterprise Stack (TTES)

Performed the tests with different uplink and downlink payload sizes such as 50, 51, 52 bytes.

TESTS PERFORMED:

Uplink Payload Size: 50

• DUT was sending only 43 byte for DR0 which has a maximum payload size of 50 bytes. When payload above 43 is sent I got invalid_buf_length.

Downlink Payload Size: 50

• Network server is sending the downlink data with 50 bytes, and the end device is receiving all 50 bytes.

Please find the attachments and logs below.
Updated_MLS_P5_Logs (1).zip

As per the MLS stack it will support 43 bytes only. Then it should adhere for both uplink and downlink payload size for DR0 right.

In the lorawan regional specification 1.0.3 rev A for IND865, it is mentioned as below

If we see the MACPayload size length(M) mentioned above. For DR0, the mac payload size is 59 bytes and if we exclude FHDR and FPORT (8 bytes) then the FRMPayload is 51 bytes.

Note: I have tried with mac commands as well and observed the same behaviour. To make the issue more clear I have kept LoRaWAN Mote Application Project results.

Required Information:

1. Why there is a mismatch between max Uplink and Downlink payload size for DR0?
2. After observing the behaviour I was confused with the actual behaviour as per the LoRaWAN specification. Should we consider the maximum payload as FRM payload (51 bytes alone) or FHDR (7 bytes) + FPort (1 byte) + FRMPayload (43 bytes) which totals 51 bytes. Can you make it clear which is the right behaviour for both uplink & downlink when considered with respect to maximum payload used.

samr34_mls_1_0_p_5.txt

Affected (tested) version: MLS_1_0_P_6 (Parser_ECC608 for WLR089)
Steps to reproduce:

1. Configure the device to operate in NZ923 band
2. Join the network, perform a few uplink
3. set aggregated duty cycle to 15 (via mac set command)
4. Perform an uplink once the duty cycle allows to
5. mac get dutycycletime will return 0, but it is supposed to return a much higher value according to new aggdcycle value
6. Try to perform an uplink again
7. Module will return no_free_ch forever (despite waiting a lot more than prescribed time)

The problem is in file lorawan_multiband.c, function setDutyCycleTimer with the call to SwTimerStart(). Call to MS_TO_US() macro will overflow under circumstances described above and will yield to the described behavior.

While a quick workaround for this issue could be to not use aggdcycle 14 or 15, this is not a fix since aggregated duty cycle can also be modified remotely by the network via a DutyCycleReq MAC command.

EDIT: added WLR089 target.

Problem

I wrote a short python serial script to get the WLR089U0 module to join the following LoRaWAN network:

• Application Server: AWS IoT Core for LoRaWAN
• Gateway: Laird Sentrius RG191 LoRaWAN Gateway

The python script is as follows:

import time

import serial

from factory_reset import factory_reset
from join_otaa import join_otaa
from send_command_with_response import send_command_with_response

lora_chip_port = "COM19"
lora_chip_baud = 115200
join_eui = "REDACTED"
app_key = "REDACTED"
wait_time = 35


def main():
    lora_device = serial.Serial(lora_chip_port, lora_chip_baud, timeout=10)
    lora_device.reset_input_buffer()
    lora_device.reset_output_buffer()
    factory_reset(lora_device)
    dev_eui = str(send_command_with_response(lora_device, "sys get hweui"))
    send_command_with_response(lora_device, "mac reset na915")
    send_command_with_response(lora_device, "mac get deveui")
    send_command_with_response(lora_device, f"mac set deveui {dev_eui}")
    send_command_with_response(lora_device, "mac get deveui")
    send_command_with_response(lora_device, f"mac set joineui {join_eui}")
    send_command_with_response(lora_device, f"mac set appkey {app_key}")

    while not join_otaa(lora_device):
        print(f"OTAA join failed, retrying in {wait_time} seconds...")
        time.sleep(35)

    lora_device.close()


if __name__ == "__main__":
    main()

factory_reset(), join_otaa(), and send_command_with_response() are just wrappers for the corresponding rn parser serial write/read functions.

Each time I run this script, the initial response from the module is that I was denied after attempting to join the first time, then when I retry after the join duty cycle time, it accepts. But if I issue any commands to the module other than a join request I will consistently be denied from joining the server. (i.e. issuing mac get joindutycycletime before attempting another mac join otaa, denied every time)

Issuing factory reset...
[UART RX] 
[UART RX] Last reset cause: System Reset Request
[UART RX] LoRaWAN Stack UP
[UART RX] USER BOARD MLS_SDK_1_0_P_5 Jun 18 2021 11:34:32
[UART TX] sys get hweui
[UART RX] REDACTED
[UART TX] mac reset na915
[UART RX] ok
[UART TX] mac get deveui
[UART RX] 0000000000000000
[UART TX] mac set deveui REDACTED
[UART RX] ok
[UART TX] mac get deveui
[UART RX] REDACTED
[UART TX] mac set joineui REDACTED
[UART RX] ok
[UART TX] mac set appkey REDACTED
[UART RX] ok
[UART TX] mac join otaa
[UART RX] ok
[UART RX] denied
OTAA join failed, retrying in 35 seconds...
[UART TX] mac join otaa
[UART RX] ok
[UART RX] accepted

In conclusion, the only time I am able to successfully join otaa is issuing two mac join otaa commands back to back, issuing no other commands and ensuring to wait more than the join duty cycle time in between mac join otaa commands.

What I have tried

• Waiting for the joindutycycletime between setting up all of the otaa keys before attempting to join the first time
  • Still denied entry to the network, then after a second joindutycycletime waiting period, join request is accepted.
• Deleting the device from the application server and re-creating it
  • I tried this to force the server to recognize that the device disconnected, then there would be no duplicate deveui issues.
• Creating a brand new device (fresh deveui) in the application server
  • Same result as above
• After being denied the first time, I use mac get joindutycycletime to get the exact time remaining from the module before being able to attempt to join again.
  • This results in the module being consistently denied from joining the network.

Possible Solution

I don't know what the repository looks like at the moment, but it seems like the module may only be able to transition to an accepted state when coming from a denied state.

Reproducibility

1. Download code
2. Open Microchip Studio
3. Open the solution
4. Change the project to APPS_ENDDEVICE_DEMO1
5. Change configuration to release
6. Build the project

Problem

The build fails when the file parser.h is not found in the include path.

I have tried to put the SAMR34 Xplained Pro in sleep mode using sys sleep standby 60000 command.

SAMR34 Xplained Pro is not responding to that. For remaining commands it is responding.

Can anyone help me out?

I test this RN_PARSER in SAMR34 Xplained Pro but:

I have this problem.
sys reset
_{7GNW7WGnW7W§þ-7GW×;N]fÞGN]f¼W7G×ø÷;Êw]ç:nw¸·;®u]ø
USER BOARD MLS_SDK_1_0_P_5 Oct 30 2020 17:04:32
mac reset au915
ok
mac set edclass c
ok
mac set appkey 01010101010101010101010101010101
ok
mac set joineui 0000000000000001
ok
mac set subband status 1 on
ok
mac join otaa
ok
denied
but, the networkserver send "JoinAcepted".}

At least a dozen times this happens, before I accept a "join" but I always have to do a "sys reset" and initialize everything again every time until I get the connection.
on the other hand, in class C, it is not responding "ACK" to uplinks with confirmation.

I'm using this code for a standalone WLR089 module.
I commented out some pin defintions (button and LEDs) and the button interrupt.

Anyway I'm having trouble with this module at different stages.

Right now I made it so far that the join procedure is as follows:

sys factoryRESET
<< System Reset Request
<< LoRaWAN Stack UP
<< USER BOARD MLS_SDK_1_0_P_5 ...
mac reset 868
<< ok
sys get hweui
<< 0123456789123456
mac set deveui 0123456789123456
<< ok
mac set joineui 0000000000000000
<< ok
mac set appkey abcd1234...
<< ok
mac join otaa
<< ok
(waiting some seconds)
<< denied

I have a gateway close by and I don't see any message from the device received there.
(But other devices can be seen, so the gateway is working).

I there something that I missed? Could it be a hardware fault?

I'm unsure if there are more problems when using WLR089 instead of the XPlained Pro Board.
I lost two modules that suddenly seemed to heat up drawing 300 mA of current... so I'm not sure if there are some more pins I should reconfigure, or if I made a soldering mistake.

Any help appreciated and some explanation on the pins used explicitly for the Xplained Pro Board.

Hello,
Thanks for providing this useful example.

I'm trying to implement in the app layer the LoRa mac command "Device Time Request".
From the lorawan.h in the typedef enum _LorawanAttributes I can see the attribute:

/* If set, ED shall send DeviceTimeReq cmd in next TX */
SEND_DEVICE_TIME_CMD,

From the above comment, I've understood that I should trigger a "mac set DevTimeReq ".
Obviously the entry {"DevTimeReq", NULL, Parser_LoraGetDevTime, 0,0} has been added to the static const parserCmdEntry_t maParserLoraSetCmd[] array
and I wrote the following Parser_LoraGetDevTime () function:

void Parser_LoraGetDevTime(parserCmdInfo_t* pParserCmdInfo)
{
StackRetStatus_t status;
status = LORAWAN_SetAttr(SEND_DEVICE_TIME_CMD, NULL);
pParserCmdInfo->pReplyCmd = (char*)gapParserLorawanStatus[status];
}

The command seems to be accepted by the stack since the returned status is LORAWAN_SUCCESS.

The problem is that after triggering the "mac set DevTimeReq" I'm not able to send any uplink (can't see them on the TTN device page) therefore the end device neither is sending the DeviceTimeReq cmd.

What I'm missing here?
Is there any other document I should read other than the "SAM R34/R35 Microchip LoRaWAN™ Stack Software API
Reference Manual"?

Best regards
Luca

This is very exciting and I would LOVE to see this example! However,
it seems this is empty, Is this still in the works? or did the code somehow
never make it up?

Looking forward to seeing this!!!

Reproducibility

Download code
Open Microchip Studio
Open the solution
Change the project to APPS_ENDDEVICE_DEMO1
Change configuration to release
Build the project

Problem

The build fails when code tries to use EDBG structures even when EDBG_EUI_READ is not set.