Otaa join_accept message not received by seeeduino node

Hi,
I am running a Raspberry Pi with IMST iC880A gateway with the poly_pkt_fwd package forwarder running. I try to get OTAA working but struggle with the join_accept messages. I can see that TTN is sending join_accept messages and some matching messages in the package forwarded (where I am not 100% sure if they belong to the join_accept, but it´s really likely) but the node does not seem to get it:

+RESET: OK
+ID: DevAddr, 00:0E:34:03
+ID: DevEui, 00:D8:C0:83:E7:A0:3F:70
+ID: AppEui, 70:B3:D5:7E:D0:00:ED:A2
+ID: DevEui, 00:D8:C0:83:E7:A0:3F:70
+ID: AppEui, 70:B3:D5:7E:+KEY: APPKEY 6A1CF732D2AE94C759F1B9F77530E861
+MODE: LWOTAA
+DR: EU868
+DR: DR0
+DR: EU868 DR0  SF12 BW125K
+CH: 0,868100000,DR0:DR5
+CH: 1,868300000,DR0:DR5
+CH: 2,868500000,DR0:DR5
+CH: 3,867100000,DR0:DR5
+CH: 4,867300000,DR0:DR5
+CH: 5,867500000,DR0:DR5
+CH: 6,867700000,DR0:DR5
+CH: 7,867900000,DR0:DR5
+RXWIN1: ERROR(-1)
+RXWIN2: 868300000,DR3
+ADR: OFF
+LW: DC, OFF, 0
+LW: JDC, OFF
+POWER: 2
+JOIN: Start
+JOIN: NORMAL
+JOIN: LoRaWAN modem is busy
+JOIN: Join failed
+JOIN: Done

Logs from the gateway:

##### 2018-05-15 21:36:50 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (215 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### [GPS] ###
# Invalid gps time reference (age: 1526420210 sec)
# Manual GPS coordinates: latitude 53.85579, longitude 10.73494, altitude 0 m
##### END #####
INFO: [down] for server router.eu.thethings.network PULL_ACK received in 62 ms

The code I use on the node:

//#include "LoRaWan.h"
#include<LoRaWan.h>
#include "keys.h"

//#define FREQ_RX_WNDW_SCND_US  923.3
#define FREQ_RX_WNDW_SCND_EU  869.525
/*#define FREQ_RX_WNDW_SCND_AU  923.3
#define FREQ_RX_WNDW_SCND_CN  505.3
#define FREQ_RX_WNDW_SCND_KR  923.3
#define FREQ_RX_WNDW_SCND_IN  866.55
#define FREQ_RX_WNDW_SCND_AS1 923.3
#define FREQ_RX_WNDW_SCND_AS2 923.3*/

//const float US_hybrid_channels[8] = {903.9, 904.1, 904.3, 904.5, 904.7, 904.9, 905.1, 905.3}; //rx 923.3
const float EU_hybrid_channels[8] = {868.1, 868.3, 868.5, 867.1, 867.3, 867.5, 867.7, 867.9}; //rx 869.525
/*const float AU_hybrid_channels[8] = {916.8, 917.0, 917.2, 917.4, 917.6, 917.8, 918.0, 918.2}; //rx 923.3
const float CN_hybrid_channels[8] = {487.1, 487.3, 487.5, 487.7, 486.3, 486.5, 486.7, 486.9}; //rx 505.3 
const float KR_hybrid_channels[8] = {922.1, 922.3, 922.5, 922.7, 922.9, 923.1, 923.3, 0};     //rx 921.9 
const float IN_hybrid_channels[8] = {865.0625, 865.4025, 865.9850, 0, 0, 0, 0, 0};            //rx 866.55
const float AS1_hybrid_channels[8] = {923.2, 923.4, 922.2, 922.4, 922.6, 922.8, 923.0, 922.1}; //rx 923.2
const float AS2_hybrid_channels[8] = {923.2, 923.4, 923.6, 923.8, 924.0, 924.2, 924.4, 924.6}; //rx 923.2*/

//United States Receive Window Data Rate = DR8
//#define DOWNLINK_DATA_RATE_US DR8
#define DOWNLINK_DATA_RATE_EU DR8
/*#define DOWNLINK_DATA_RATE_AU DR8
#define DOWNLINK_DATA_RATE_CN DR0
#define DOWNLINK_DATA_RATE_KR DR0
#define DOWNLINK_DATA_RATE_IN DR2
#define DOWNLINK_DATA_RATE_AS1 DR2
#define DOWNLINK_DATA_RATE_AS2 DR2*/

//#define US_RX_DR DR8
#define EU_RX_DR DR8
/*#define AU_RX_DR DR8
#define CN_RX_DR DR0
#define KR_RX_DR DR0
#define IN_RX_DR DR2
#define AS1_RX_DR DR2
#define AS2_RX_DR DR2*/

//United States max data rate for uplink channels = DR3
//#define UPLINK_DATA_RATE_MAX_US  DR3
#define UPLINK_DATA_RATE_MAX_EU  DR5
/*#define UPLINK_DATA_RATE_MAX_AU  DR3
#define UPLINK_DATA_RATE_MAX_CN  DR5
#define UPLINK_DATA_RATE_MAX_KR  DR5
#define UPLINK_DATA_RATE_MAX_IN  DR5
#define UPLINK_DATA_RATE_MAX_AS1 DR5
#define UPLINK_DATA_RATE_MAX_AS2 DR5*/

//#define MAX_EIRP_NDX_US 13
#define MAX_EIRP_NDX_EU  2
/*#define MAX_EIRP_NDX_AU 13
#define MAX_EIRP_NDX_CN  7
#define MAX_EIRP_NDX_KR  4
#define MAX_EIRP_NDX_IN 13
#define MAX_EIRP_NDX AS1 5
#define MAX_EIRP_NDX_AS2 5*/

//The min uplink data rate for all countries / plans is DR0
#define UPLINK_DATA_RATE_MIN DR0

#define DEFAULT_RESPONSE_TIMEOUT 5
unsigned char frame_counter = 1;
int loopcount = 0;

char buffer[256];


void setup(void)
{
    SerialUSB.begin(115200);
    while(!SerialUSB);     
    
    lora.init();
    lora.setDeviceReset();
  
    memset(buffer, 0, 256);
    lora.getVersion(buffer, 256, 1);
    SerialUSB.print(buffer); 
       
    memset(buffer, 0, 256);
    lora.getId(buffer, 256, 1);
    SerialUSB.print(buffer);

    lora.setId(NULL, DEV_EUI, APP_EUI);
    lora.setKey(NULL, NULL, APP_KEY);
    
    lora.setDeciveMode(LWOTAA);
    lora.setDataRate(DR0, EU868);
    setHybridForTTN(EU_hybrid_channels);
    
    lora.setReceiceWindowFirst(868.3,  EU_hybrid_channels[0]);
    lora.setReceiceWindowSecond(FREQ_RX_WNDW_SCND_EU, DOWNLINK_DATA_RATE_EU);

    lora.setAdaptiveDataRate(false); 
    
    lora.setDutyCycle(false);
    lora.setJoinDutyCycle(false);
    lora.setPower(MAX_EIRP_NDX_EU);

//        SerialUSB.print("Starting OTTA Join.\n");
//    loopcount = 0;
//    while(true) {
//        loopcount++;
//        if (lora.setOTAAJoin(JOIN))
//            break;
//    }
//    SerialUSB.print("Took ");
//    SerialUSB.print(loopcount);
//    SerialUSB.println(" tries to join.");
    while(!lora.setOTAAJoin(JOIN));
    //lora.loraDebug();
}

void setHybridForTTN(const float* channels){
    for(int i = 0; i < 8; i++){
        if(channels[i] != 0){
            lora.setChannel(i, channels[i], UPLINK_DATA_RATE_MIN, UPLINK_DATA_RATE_MAX_EU);
         
        }
    }
}

void loop(void)
{
    while(!lora.setOTAAJoin(JOIN));
    bool result = lora.transferPacket(&frame_counter, 1, DEFAULT_RESPONSE_TIMEOUT);

    if(result)
    {
        delay(50);
        frame_counter++;
        short length;
        short rssi;
        
        memset(buffer, 0, 256);
        length = lora.receivePacket(buffer, 256, &rssi);
        
        if(length)
        {
            SerialUSB.print("Length is: ");
            SerialUSB.println(length);
            SerialUSB.print("RSSI is: ");
            SerialUSB.println(rssi);
            SerialUSB.print("Data is: ");
            for(unsigned char i = 0; i < length; i ++)
            {
                SerialUSB.print("0x");
                SerialUSB.print(buffer[i], HEX);
                SerialUSB.print(" ");
            }
            SerialUSB.println();
        }
    }
  
    lora.loraDebug();
    delay(1000);
}

I am running out of ideas, I think the problem is not on ttn side since there I can see the join accept messages:
19

Do you have any ideas?

  1. Why does the node log show the RX2 window is set to both the wrong frequency and datarate (entry just above ADR) You need to use 869.525 MHz and DR0. The code uses DR8? for EU downlink datarate?
  2. Your gateway log extract shows no data received by the gateway and transmitted to the node. (PULL_RESP is 0) However the gateway log time stamp does not match the console log so you probably looked at the wrong time window.
  3. TTN console shows join response packets are to be transmitted at 868.3 MHz which means RX1 window. Make sure your node setup for RXWIN1 is correct. The node log shows an error on RXWIN1 setup(errors are always a sign you need to investigate/fix unles you are very sure nothing is wrong… in this case it might well be the cause of your issues)

Any luck?

No, unfortunately not. I changed the code according to the comments from @kersing and I was at least able to the join ack responses in TTN and on the gateway - but they are not received by the node.

I changed the firmware to the actual version(2.1.16) and now the join requests didn´t even reach the gateway. @brady_aiello Since I think something is wrong on the node - do you know any more debugging possibilities there?

I am also wondering if my setup of gateway and node is caused some of the problems, because they are located in the same room?

Sorry, try commenting out the join in the loop() portion:
while(!lora.setOTAAJoin(JOIN));
Sorry I left that in the code. Let me know if that helps.

Sorry for the long delay, I´ll check it. I still think I have some problems with my setup of gateway and node because I got 100% CRC errors now and no proper packages arrives the gateway.

Okay, cool. I have not been able to get the poly_pkt_fwd program to work, so I can’t speak from experience. I’m using the TTN packet forwarder at it has been a gazillion times easier to use. https://github.com/TheThingsNetwork/packet_forwarder/blob/master/docs/INSTALL_INSTRUCTIONS/IMST_RPI.md#build

I guess I am on the same initial issue but I don’t find the solution in the thread.
I have just deleted the ABP enddevice on TTN and re-created it as an OTAA enddevice.
As Seeeduino does not provide a JoinEUI Key, I put 0000000000000000, as adviced.
The OTAA code proposed by Seeeduino is very close to ABP code, but for
lora.setDeciveMode(LWOTAA);
and
while(!lora.setOTAAJoin(JOIN));
I am not sure of
lora.setKey(“2B7E151628AED2A6ABF7158809CF4F3C”, NULL, “2B7E151628AED2A6ABF7158809CF4F3C”);
for I found different versions on the net (two NULL for the first two keys, for example, whereas Seeeduino code maintains all three keys as in ABP).
My log on IDE serial output is

14:49:00.713 -> +VER: 3.5.13
14:49:01.714 -> +ID: DevAddr, 00:06:81:DE
14:49:01.714 -> +ID: DevEui, 8C:F9:57:20:00:06:81:DE
14:49:01.714 -> +ID: AppEui, 8C:F9:57:20:00:00:00:00
14:49:01.746 -> +KEY: NWKSKEY 2B7E151628AED2A6ABF7158809CF4F3C
14:49:02.844 -> +KEY: APPKEY 2B7E151628AED2A6ABF7158809CF4F3C
14:49:03.978 -> +MODE: LWOTAA
14:49:05.131 -> +DR: EU868
14:49:06.121 -> +DR: DR0
14:49:06.121 -> +DR: EU868 DR0  SF12 BW125K 
14:49:07.210 -> +CH: 0,868100000,DR0:DR5
14:49:08.314 -> +CH: 1,868300000,DR0:DR5
14:49:09.429 -> +CH: 2,868500000,DR0:DR5
14:49:10.517 -> +CH: 3,867100000,DR0:DR5
14:49:11.617 -> +CH: 4,867300000,DR0:DR5
14:49:12.710 -> +CH: 5,867500000,DR0:DR5
14:49:13.826 -> +CH: 6,867700000,DR0:DR5
14:49:14.940 -> +RXWIN1: 0,868100000
14:49:16.030 -> +RXWIN2: 869500000,DR3
14:49:17.135 -> +POWER: 14
14:49:18.236 -> +JOIN: Start
14:49:18.280 -> +JOIN: NORMAL
14:49:34.285 -> +MSG: LoRaWAN modem is busy
14:49:34.285 -> +JOIN: Join failed
14:49:34.285 -> +JOIN: Done

and gateway console shows


What is missing?

And

Does not compute…

The JoinEUI is called the AppEUI in older LoRaWAN versions. So if your node transmits this AppEUI (and it seems to looking at the console output) you should either modify the code to set the AppKey to the JoinEUI you entered for the device or modify (or recreate) the device in the TTN console with the AppEUI value in the JoinEUI field.

Please check the RX2 frequency as well… the debugging output shows something that differs from what I wrote in the above…

I modified downlink frequency too during all my trials.
It was already running with
lora.setReceiceWindowSecond(869.525, DR0);
What makes the difference is giving the AppEUI as JoinEUI when re-creating the end device.
So now the application can see it
15:22:42 eui-8cf95720000681de Join-request to cluster-local Join Server failed DevNonce is too small
I thought DevNonce was generated by lora.setOTAAJoin(JOIN) without me adding anything.
What is it about?

Which version of the LoRaWAN specification have you specified? And what version is the code on your device? For LoRaWAN version 1.0.4 and over the devnonce should be increasing. Older versions allow use of a random value.
You might need to recreate (delete and create again) the device to reset the devnonce.

Reading the LoRaWAN specification helps to understand these kind of messages.

lora.getVersion() answers +VER: 3.5.13
I don’t understand why devnonce should be too smal when it has never be used before. Does ABP frame counter becomes devnonce when switching the device to OTAA?
I just reset devnonce on the general settings of the end device but that did not change anything.
I had read in the documentation about trouble shooting:
DevNonce is too small error in the device events: If the device is using LoRaWAN MAC version 1.1 or 1.0.4, this error occurs when DevNonce is not being incremented, so the Join Server ignores Join Requests with the same or lower DevNonce value comparing to the previous one. Contact your device’s manufacturer to find out the correct LoRaWAN MAC and PHY versions, and configure the device in The Things Stack accordingly
I am not sure of how to do that for I haven’t see that on the configuration of the end device.

If it is the original RHF76-052 based Seeeduino then it’s from 2018 and will have very old firmware.

The RSSI is way way too high for either device or gateway to cope with demodulation - 5 to 10m plus a brick wall is recommendation for minimum separation.

And to be fair to the others currently trashing the Fair Use Policy, unlisting the topic pending confirmation of adhering to it.

A previous join request has used a random value that is higher. Happens al the time with devices with older firmware when you specified a new version in the TTN console.
Create a device on TTN with LoRaWAN version 1.0.2 or 1.0.1,

You’re right. It works with LoRaWAN version 1.0.1 and 1.0.2.
Thanks.