Unable to join - Example Project

I’m not able to join the Helium network using the example project that comes with the board libraries. I updated the DevEui, AppEui, and AppKey but it still won’t connect. I have other LoRaWAN devices / nodes that work so I know it’s not a reception issue. I used MSB (Big Endian) values for the DevEui and AppEui, and LSB (Little Endian) for the AppKey.

Is anyone able to see what I’m doing wrong? Thanks!

#include “LoRaWan_APP.h”
#include “Arduino.h”

/*

  • set LoraWan_RGB to Active,the RGB active in loraWan
  • RGB red means sending;
  • RGB purple means joined done;
  • RGB blue means RxWindow1;
  • RGB yellow means RxWindow2;
  • RGB green means received done;
    */

/* OTAA para*/
uint8_t devEui[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
uint8_t appEui[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
uint8_t appKey[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

/* ABP para*/
uint8_t nwkSKey[] = { 0x15, 0xb1, 0xd0, 0xef, 0xa4, 0x63, 0xdf, 0xbe, 0x3d, 0x11, 0x18, 0x1e, 0x1e, 0xc7, 0xda,0x85 };
uint8_t appSKey[] = { 0xd7, 0x2c, 0x78, 0x75, 0x8c, 0xdc, 0xca, 0xbf, 0x55, 0xee, 0x4a, 0x77, 0x8d, 0x16, 0xef,0x67 };
uint32_t devAddr = ( uint32_t )0x007e6ae1;

/LoraWan channelsmask, default channels 0-7/
uint16_t userChannelsMask[6]={ 0x00FF,0x0000,0x0000,0x0000,0x0000,0x0000 };

/LoraWan region, select in arduino IDE tools/
LoRaMacRegion_t loraWanRegion = ACTIVE_REGION;

/LoraWan Class, Class A and Class C are supported/
DeviceClass_t loraWanClass = LORAWAN_CLASS;

/the application data transmission duty cycle. value in [ms]./
uint32_t appTxDutyCycle = 15000;

/OTAA or ABP/
bool overTheAirActivation = LORAWAN_NETMODE;

/ADR enable/
bool loraWanAdr = LORAWAN_ADR;

/* set LORAWAN_Net_Reserve ON, the node could save the network info to flash, when node reset not need to join again */
bool keepNet = LORAWAN_NET_RESERVE;

/* Indicates if the node is sending confirmed or unconfirmed messages */
bool isTxConfirmed = LORAWAN_UPLINKMODE;

/* Application port /
uint8_t appPort = 2;
/
!

  • Number of trials to transmit the frame, if the LoRaMAC layer did not
  • receive an acknowledgment. The MAC performs a datarate adaptation,
  • according to the LoRaWAN Specification V1.0.2, chapter 18.4, according
  • to the following table:
  • Transmission nb | Data Rate
  • ----------------|-----------
  • 1 (first) | DR
  • 2 | DR
  • 3 | max(DR-1,0)
  • 4 | max(DR-1,0)
  • 5 | max(DR-2,0)
  • 6 | max(DR-2,0)
  • 7 | max(DR-3,0)
  • 8 | max(DR-3,0)
  • Note, that if NbTrials is set to 1 or 2, the MAC will not decrease
  • the datarate, in case the LoRaMAC layer did not receive an acknowledgment
    */
    uint8_t confirmedNbTrials = 4;

/* Prepares the payload of the frame */
static void prepareTxFrame( uint8_t port )
{
/*appData size is LORAWAN_APP_DATA_MAX_SIZE which is defined in “commissioning.h”.
*appDataSize max value is LORAWAN_APP_DATA_MAX_SIZE.
*if enabled AT, don’t modify LORAWAN_APP_DATA_MAX_SIZE, it may cause system hanging or failure.
*if disabled AT, LORAWAN_APP_DATA_MAX_SIZE can be modified, the max value is reference to lorawan region and SF.
*for example, if use REGION_CN470,
*the max value for different DR can be found in MaxPayloadOfDatarateCN470 refer to DataratesCN470 and BandwidthsCN470 in “RegionCN470.h”.
*/
appDataSize = 4;
appData[0] = 0x00;
appData[1] = 0x01;
appData[2] = 0x02;
appData[3] = 0x03;
}

void setup() {
Serial.begin(115200);
#if(AT_SUPPORT)
enableAt();
#endif
deviceState = DEVICE_STATE_INIT;
LoRaWAN.ifskipjoin();
}

void loop()
{
switch( deviceState )
{
case DEVICE_STATE_INIT:
{
#if(LORAWAN_DEVEUI_AUTO)
LoRaWAN.generateDeveuiByChipID();
#endif
#if(AT_SUPPORT)
getDevParam();
#endif
printDevParam();
LoRaWAN.init(loraWanClass,loraWanRegion);
deviceState = DEVICE_STATE_JOIN;
break;
}
case DEVICE_STATE_JOIN:
{
LoRaWAN.join();
break;
}
case DEVICE_STATE_SEND:
{
prepareTxFrame( appPort );
LoRaWAN.send();
deviceState = DEVICE_STATE_CYCLE;
break;
}
case DEVICE_STATE_CYCLE:
{
// Schedule next packet transmission
txDutyCycleTime = appTxDutyCycle + randr( 0, APP_TX_DUTYCYCLE_RND );
LoRaWAN.cycle(txDutyCycleTime);
deviceState = DEVICE_STATE_SLEEP;
break;
}
case DEVICE_STATE_SLEEP:
{
LoRaWAN.sleep();
break;
}
default:
{
deviceState = DEVICE_STATE_INIT;
break;
}
}
}

Can you see any information about join request in server?

I have the same problem AB01. Which is correct MSB or LSB for the OTAA Parameters? I tried all MSB, than all LSB and neither work. I switched to the AB02A and it didn’t work either.

Firstly,board need to be selected correct.
Secondly,the server and node parameters are the same.

The server is Helium and node is the Cubecell Board…correct?
I copied and pasted the “msb:” version Device EUI, App EUI and the App Key. I changed the Board to HTCC-AB02A then recompiled and downloaded to the AB02A and below are the results. What am I missing?
15:16:11.105 ->
15:16:11.105 -> AT Rev 1.3
15:16:11.105 -> +AutoLPM=1
15:16:11.105 ->
15:16:11.105 -> +LORAWAN=1
15:16:11.105 ->
15:16:11.105 -> +KeepNet=0
15:16:11.105 -> +OTAA=1
15:16:11.105 -> +Class=A
15:16:11.105 -> +ADR=1
15:16:11.105 -> +IsTxConfirmed=1
15:16:11.105 -> +AppPort=2
15:16:11.105 -> +DutyCycle=15000
15:16:11.105 -> +ConfirmedNbTrials=4
15:16:11.105 -> +ChMask=0000000000000000000000FF
15:16:11.105 -> +DevEui=(For OTAA Mode)
15:16:11.105 -> +AppEui=
(For OTAA Mode)
15:16:11.105 -> +AppKey=*********************************(For OTAA Mode)
15:16:11.105 -> +NwkSKey=*********************************(For ABP Mode)
15:16:11.105 -> +AppSKey=*************************(For ABP Mode)
15:16:11.131 -> +DevAddr=
(For ABP Mode)
15:16:11.131 ->
15:16:11.131 ->
15:16:11.131 -> LoRaWAN US915 Class A start!
15:16:11.131 ->
15:16:11.269 -> joining…join failed, join again at 30s later
15:20:25.705 -> join failed, join again at 30s later

You can view the hostpost diagnostic interface to see if there is any network access information.

Here is the LoRa Log from the Heltec Helium Hotspot right after power cycling the Cubecell:
Note 1 : If the the size of lora packet data is 52, it probably is a poc beacon.

Note 2 : The log is not updated in time. The time displayed in the log may be delayed by minutes.

Feb 18 16:50:47 JSON up: {“rxpk”:[{“tmst”:3053702540,“chan”:7,“rfch”:1,“freq”:905.300000,“stat”:1,“modu”:“LORA”,“datr”:“SF8BW125”,“codr”:“4/5”,“rssis”:-67,“lsnr”:1.2,“rssi”:-67,“size”:23,“data”:“AAMAABECxSYsOAEQ0KTVs3DilDBvUbo=”}]}
Feb 18 16:50:47 JSON up: {“rxpk”:[{“tmst”:3064618828,“chan”:8,“rfch”:0,“freq”:904.600000,“stat”:1,“modu”:“LORA”,“datr”:“SF8BW500”,“codr”:“4/5”,“rssis”:-76,“lsnr”:0.0,“rssi”:-76,“size”:23,“data”:“AAMAABECxSYsOAEQ0KTVs3AW94x8xbo=”}]}
Feb 18 16:50:47 JSON up: {“rxpk”:[{“tmst”:3075705892,“chan”:3,“rfch”:0,“freq”:904.500000,“stat”:1,“modu”:“LORA”,“datr”:“SF8BW125”,“codr”:“4/5”,“rssis”:-76,“lsnr”:-2.8,“rssi”:-73,“size”:23,“data”:“AAMAABECxSYsOAEQ0KTVs3DC/pq+j2M=”}]}
Feb 18 16:58:47 JSON up: {“rxpk”:[{“tmst”:3539704684,“chan”:1,“rfch”:0,“freq”:904.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-73,“lsnr”:6.2,“rssi”:-73,“size”:52,“data”:“QDDaAAE+UlR9ANzfAMrBp9xHhp/m3SWBvsKILEXeBvIGi/0i6gVGHOWmT30rtt1RECXlEQ==”}]}
Feb 18 17:47:17 JSON up: {“rxpk”:[{“tmst”:2187986180,“chan”:1,“rfch”:0,“freq”:904.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-72,“lsnr”:5.0,“rssi”:-72,“size”:52,“data”:“QDDaAAG3v8OpABA1AFLnkSfLkIy+AwpKn6yZQ+O863fMCGNNF4bGcTe9olHG8qyFiwSODQ==”}]}
Feb 18 19:57:47 JSON up: {“rxpk”:[{“tmst”:1402778100,“chan”:0,“rfch”:0,“freq”:903.900000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-88,“lsnr”:2.5,“rssi”:-88,“size”:52,“data”:“QDDaAAHAtn5VAEJCAJt3KtQM4ClT6JwuzjGnxoO5hZOtgeI3eTyl0akoh/ohhLqajwahJQ==”}]}
Feb 18 20:42:47 JSON up: {“rxpk”:[{“tmst”:4056662652,“chan”:2,“rfch”:0,“freq”:904.300000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-84,“lsnr”:-2.5,“rssi”:-81,“size”:52,“data”:“QDDaAAF3lHYlABqtAK5Elx7Ab/ZrCoGyv5FXu/7E0StDpftQJokb9PrkEXOXluK54f8HVw==”}]}
Feb 18 21:10:47 JSON up: {“rxpk”:[{“tmst”:1470378348,“chan”:0,“rfch”:0,“freq”:903.900000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-93,“lsnr”:-4.0,“rssi”:-89,“size”:52,“data”:“QDDaAAFCwH/4AE4uAMd2yfhgeCdwQMn7esmSRmJyuzcpQIad6CO8CPZtV6VJVBJXGGqCCQ==”}]}
Feb 19 00:11:18 JSON up: {“rxpk”:[{“tmst”:3739411228,“chan”:2,“rfch”:0,“freq”:904.300000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-89,“lsnr”:-3.8,“rssi”:-85,“size”:52,“data”:“QDDaAAHO/G+XABOUACsoT7GeSb+wEiReKy1mrAzECiveG9JCg8Z52K6ivgt7xGmZHYVG3Q==”}]}
Feb 19 01:53:18 JSON up: {“rxpk”:[{“tmst”:1229012372,“chan”:3,“rfch”:0,“freq”:904.500000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-109,“lsnr”:-12.2,“rssi”:-97,“size”:52,“data”:“QDDaAAELaZfPAPXwAOl/+5XD3JXjpg2oH+ZMbDFFu74ZqoI6hEfpDwHBP1Id4sRdiJKXrg==”}]}
Feb 19 02:46:48 JSON up: {“rxpk”:[{“tmst”:211380964,“chan”:4,“rfch”:1,“freq”:904.700000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-87,“lsnr”:2.2,“rssi”:-87,“size”:52,“data”:“QDDaAAG4zqmtALASADw42IHdWparL8PF0zmDwIXVd12XLCDLq7kP2RD4REee4r2g1uxTRQ==”}]}
Feb 19 04:03:48 JSON up: {“rxpk”:[{“tmst”:535398548,“chan”:0,“rfch”:0,“freq”:903.900000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-110,“lsnr”:-10.0,“rssi”:-100,“size”:52,“data”:“QDDaAAEmMVq0ACa8AJ3cB1qpR8Z2HT+3AYYxH07EYV9F2Pnfu0DqGgvlxgZv23h7U65nIQ==”}]}
Feb 19 04:53:48 JSON up: {“rxpk”:[{“tmst”:3545736804,“chan”:3,“rfch”:0,“freq”:904.500000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-95,“lsnr”:-9.2,“rssi”:-86,“size”:52,“data”:“QDDaAAGlw2KqAKvyACddT+gYOR2IBuI/EvtukPrv3ufPTN06pE+7jsPSdY7IPHITOB8/eQ==”}]}
Feb 19 08:35:48 JSON up: {“rxpk”:[{“tmst”:3968498532,“chan”:6,“rfch”:1,“freq”:905.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-75,“lsnr”:6.8,“rssi”:-75,“size”:52,“data”:“QDDaAAGHBfT2ANlyANawJ8K9yFELqjmnrhVZQioXye48aedS55+I9YWxuhrcRGvL4nWDdA==”}]}
Feb 19 09:20:48 JSON up: {“rxpk”:[{“tmst”:2350274460,“chan”:0,“rfch”:0,“freq”:903.900000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-82,“lsnr”:0.5,“rssi”:-82,“size”:52,“data”:“QDDaAAENHVFKAPMSAGLbWr9HkMyqj4h9bAs/XrwLu2aSFRM5Ci4BuLFm90TPcQjdSKw1ew==”}]}
Feb 19 12:54:49 JSON up: {“rxpk”:[{“tmst”:2325209004,“chan”:5,“rfch”:1,“freq”:904.900000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-102,“lsnr”:-10.5,“rssi”:-91,“size”:52,“data”:“QDDaAAGIcYGiAOVYACxsYZQk8ocX0g+QXMgtfmOaCUg2KTapLyYxOFcVGnVq1sxAFZ0DdA==”}]}
Feb 19 13:56:19 JSON up: {“rxpk”:[{“tmst”:1658407460,“chan”:1,“rfch”:0,“freq”:904.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-79,“lsnr”:-0.8,“rssi”:-78,“size”:52,“data”:“QDDaAAGX+fbSAFKDAPhP9E1dBkrCo8a8m2852MQTNG4Y1ltjokB8hSNWB/Zt58FaOUqYxg==”}]}
Feb 19 14:36:19 JSON up: {“rxpk”:[{“tmst”:4087948812,“chan”:6,“rfch”:1,“freq”:905.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-75,“lsnr”:5.5,“rssi”:-75,“size”:52,“data”:“QDDaAAEa0ht5ABJ/AD1DwAYbL+Q5crv2KAI+ou0tf4PpW/JUd2XabnV322R88VJEinvv/w==”}]}
Feb 19 14:54:49 JSON up: {“rxpk”:[{“tmst”:883674292,“chan”:0,“rfch”:0,“freq”:903.900000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“rssis”:-90,“lsnr”:0.8,“rssi”:-90,“size”:52,“data”:“QDDaAAHG2UavAGceACiLRZFCCnsqgZpiFFxaYUPZCEcLxQqwUuOjKRemI6syDU0IBBrhiQ==”}]}
Feb 19 15:11:19 JSON up: {“rxpk”:[{“tmst”:1929818060,“chan”:4,“rfch”:1,“freq”:904.700000,“stat”:1,“modu”:“LORA”,“datr”:“SF10BW125”,“codr”:“4/5”,“rssis”:-53,“lsnr”:9.2,“rssi”:-53,“size”:23,“data”:“ABMAAAoAX2MgSQAAyABfYyBpO7LKHwQ=”}]}

The gateway only uploads, but does not deliver. This may be caused by the inconsistency between the node information added by the server and the information of the node itself. You can check it out.

Is the node information that you are referring to the devEui, appEui, appKey? I have checked and re-checked these and they are correct? I must be missing something simple, but I can’t figure out what it is.

Thanks

You can update the cubecell environment to the latest and try changing the preamble length.