search

jgromes / RadioLib

Universal wireless communication library for embedded devices
https://jgromes.github.io/RadioLib/
MIT License
1.49k stars 376 forks source link

Dwell Time Error - LoRaWAN_Starter Example with AS923 Region #1180

Closed LakinduBabySoap closed 1 month ago

LakinduBabySoap commented 1 month ago

I am using TTGO LoRa32 v2.1 board with SX1276 module and while running the LoRaWAN_Starter example, I face some issues. Before I explain my situation, it is worth mentioning that I have set the LoRa WAN version to 1.1 and the Regional Parameters as RP001 Regional Parameters 1.1 revision A as mentioned in the notes. I also have checked the 'Reset DevNonces' box in the TTN console.

The issue is face is I get the error "RADIOLIB_ERROR_DWELL_TIME_EXCEEDED(-1114)" when I try to send uplinks. The region is AS923 and we have a 400ms dwell time. On the TTN console, via the live data, I can see that the the data rate is SF10BW125. On the airtime calculator, it mentions that the Spreading factor needs to be between 7-9 for it to not exceed dwell timing and I do not understand how to change the dwell time on the code.

I have tried to add a line uint8_t sf = 7 (and sf=8, sf=9), but none of them seem to work.

Sketch that is causing the module fail

LoRaWAN_Starter.ino


void setup() {
  Serial.begin(115200);
  while(!Serial);
  delay(5000);  // Give time to switch to the serial monitor
  Serial.println(F("\nSetup ... "));

  Serial.println(F("Initialise the radio"));
  int16_t state = radio.begin();
  debug(state != RADIOLIB_ERR_NONE, F("Initialise radio failed"), state, true);

  // Setup the OTAA session information
  node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);

  Serial.println(F("Join ('login') the LoRaWAN Network"));
  state = node.activateOTAA();
  debug(state != RADIOLIB_LORAWAN_NEW_SESSION, F("Join failed"), state, true);

  Serial.println(F("Ready!\n"));
}

void loop() {
  Serial.println(F("Sending uplink"));

  // This is the place to gather the sensor inputs
  // Instead of reading any real sensor, we just generate some random numbers as example
  uint8_t value1 = radio.random(100);
  uint16_t value2 = radio.random(2000);

  // Build payload byte array
  uint8_t uplinkPayload[3];
  uplinkPayload[0] = value1;
  Serial.print("Value1 is");
  Serial.print(value1);
  Serial.print("Value2 is");
  Serial.print(value2);
  uplinkPayload[1] = highByte(value2);   // See notes for high/lowByte functions
  uplinkPayload[2] = lowByte(value2);

  // Perform an uplink
  int16_t state = node.sendReceive(uplinkPayload, sizeof(uplinkPayload));    
  debug((state != RADIOLIB_LORAWAN_NO_DOWNLINK) && (state != RADIOLIB_ERR_NONE), F("Error in sendReceive"), state, false);

  Serial.print(F("Uplink complete, next in "));
  Serial.print(uplinkIntervalSeconds);
  Serial.println(F(" seconds"));

  // Wait until next uplink - observing legal & TTN FUP constraints
  delay(uplinkIntervalSeconds * 1000UL);  // delay needs milli-seconds
}

Config.h

#define _CONFIG_H

#include <RadioLib.h>

// how often to send an uplink - consider legal & FUP constraints - see notes
const uint32_t uplinkIntervalSeconds = 5UL * 60UL;    // minutes x seconds

// joinEUI - previous versions of LoRaWAN called this AppEUI
// for development purposes you can use all zeros - see wiki for details
#define RADIOLIB_LORAWAN_JOIN_EUI  0x0000000000000000

// the Device EUI & two keys can be generated on the TTN console 
#ifndef RADIOLIB_LORAWAN_DEV_EUI   // Replace with your Device EUI
#define RADIOLIB_LORAWAN_DEV_EUI   0x
#endif
#ifndef RADIOLIB_LORAWAN_APP_KEY   // Replace with your App Key 
#define RADIOLIB_LORAWAN_APP_KEY  
#endif
#ifndef RADIOLIB_LORAWAN_NWK_KEY   // Put your Nwk Key here
#define RADIOLIB_LORAWAN_NWK_KEY 
#endif

// for the curious, the #ifndef blocks allow for automated testing &/or you can
// put your EUI & keys in to your platformio.ini - see wiki for more tips

// regional choices: EU868, US915, AU915, AS923, IN865, KR920, CN780, CN500
const LoRaWANBand_t Region = AS923;
const uint8_t subBand = 0;  // For US915, change this to 2, otherwise leave on 0

// ============================================================================
// Below is to support the sketch - only make changes if the notes say so ...

// Auto select MCU <-> radio connections
// If you get an error message when compiling, it may be that the 
// pinmap could not be determined - see the notes for more info

// Adafruit
#if defined(ARDUINO_SAMD_FEATHER_M0)
    #pragma message ("Adafruit Feather M0 with RFM95")
    #pragma message ("Link required on board")
    SX1276 radio = new Module(8, 3, 4, 6);

// LilyGo 
#elif defined(ARDUINO_TTGO_LORA32_V1)
  #pragma message ("Using TTGO LoRa32 v1 - no Display")
  SX1276 radio = new Module(18, 26, 14, 33);

#elif defined(ARDUINO_TTGO_LORA32_V2)
   #pragma message ("Using TTGO LoRa32 v2 + Display")
   SX1276 radio = new Module(18, 26, 12, RADIOLIB_NC);

#elif defined(ARDUINO_TTGO_LoRa32_v21new) // T3_V1.6.1
  #pragma message ("Using TTGO LoRa32 v2.1 marked T3_V1.6.1 + Display")
  SX1276 radio = new Module(18, 26, 14, 33);

#elif defined(ARDUINO_TBEAM_USE_RADIO_SX1262)
  #pragma error ("ARDUINO_TBEAM_USE_RADIO_SX1262 awaiting pin map")

#elif defined(ARDUINO_TBEAM_USE_RADIO_SX1276)
  #pragma message ("Using TTGO T-Beam")
  SX1276 radio = new Module(18, 26, 23, 33);

// HelTec: https://github.com/espressif/arduino-esp32/blob/master/variants/heltec_*/pins_arduino.h
#elif defined(ARDUINO_HELTEC_WIFI_LORA_32)
  #pragma message ("Using Heltec WiFi LoRa32")
  SX1276 radio = new Module(18, 26, 14, 33);

#elif defined(ARDUINO_heltec_wifi_lora_32_V2)
  #pragma message ("Using Heltec WiFi LoRa32 v2")
  SX1278 radio = new Module(14, 4, 12, 16);

// Pending verfication of which radio is shipped
// #elif defined(ARDUINO_heltec_wifi_lora_32_V2)
//   #pragma message ("ARDUINO_heltec_wifi_kit_32_V2 awaiting pin map")
//   SX1276 radio = new Module(18, 26, 14, 35);

#elif defined(ARDUINO_heltec_wifi_lora_32_V3)
  #pragma message ("Using Heltec WiFi LoRa32 v3 - Display + USB-C")
  SX1262 radio = new Module(8, 14, 12, 13);

// Following not verified  
#elif defined (ARDUINO_heltec_wireless_stick)
  #pragma message ("Using Heltec Wireless Stick")
  SX1278 radio = new Module(14, 4, 12, 16);

#elif defined (ARDUINO_HELTEC_WIRELESS_STICK)
  #pragma message ("Using Heltec Wireless Stick")
  SX1276 radio = new Module(18, 26, 14, 35);

#elif defined (ARDUINO_HELTEC_WIRELESS_STICK_V3)
  #pragma message ("Using Heltec Wireless Stick v3")
  SX1262 radio = new Module(8, 14, 12, 13);

#elif defined (ARDUINO_HELTEC_WIRELESS_STICK_LITE)
  #pragma message ("Using Heltec Wireless Stick Lite")
  SX1276 radio = new Module(18, 26, 14, 35);

#elif defined (ARDUINO_HELTEC_WIRELESS_STICK_LITE_V3)
  #pragma message ("Using Heltec Wireless Stick Lite v3")
  SX1262 radio = new Module(34, 14, 12, 13);

// If we don't recognise the board
#else
  #pragma message ("Unknown board - no automagic pinmap available")

  // SX1262  pin order: Module(NSS/CS, DIO1, RESET, BUSY);
  // SX1262 radio = new Module(8, 14, 12, 13);

  // SX1278 pin order: Module(NSS/CS, DIO0, RESET, DIO1);
  // SX1278 radio = new Module(10, 2, 9, 3);

  // For Pi Pico + Waveshare HAT - work in progress
  // SX1262 radio = new Module(3, 20, 15, 2, SPI1, RADIOLIB_DEFAULT_SPI_SETTINGS);

#endif

// copy over the EUI's & keys in to the something that will not compile if incorrectly formatted
uint64_t joinEUI =   RADIOLIB_LORAWAN_JOIN_EUI;
uint64_t devEUI  =   RADIOLIB_LORAWAN_DEV_EUI;
uint8_t appKey[] = { RADIOLIB_LORAWAN_APP_KEY };
uint8_t nwkKey[] = { RADIOLIB_LORAWAN_NWK_KEY };

// create the LoRaWAN node
LoRaWANNode node(&radio, &Region, subBand);

// result code to text ...
String stateDecode(const int16_t result) {
  switch (result) {
  case RADIOLIB_ERR_NONE:
    return "ERR_NONE";
  case RADIOLIB_ERR_CHIP_NOT_FOUND:
    return "ERR_CHIP_NOT_FOUND";
  case RADIOLIB_ERR_PACKET_TOO_LONG:
    return "ERR_PACKET_TOO_LONG";
  case RADIOLIB_ERR_RX_TIMEOUT:
    return "ERR_RX_TIMEOUT";
  case RADIOLIB_ERR_CRC_MISMATCH:
    return "ERR_CRC_MISMATCH";
  case RADIOLIB_ERR_INVALID_BANDWIDTH:
    return "ERR_INVALID_BANDWIDTH";
  case RADIOLIB_ERR_INVALID_SPREADING_FACTOR:
    return "ERR_INVALID_SPREADING_FACTOR";
  case RADIOLIB_ERR_INVALID_CODING_RATE:
    return "ERR_INVALID_CODING_RATE";
  case RADIOLIB_ERR_INVALID_FREQUENCY:
    return "ERR_INVALID_FREQUENCY";
  case RADIOLIB_ERR_INVALID_OUTPUT_POWER:
    return "ERR_INVALID_OUTPUT_POWER";
  case RADIOLIB_ERR_NETWORK_NOT_JOINED:
      return "RADIOLIB_ERR_NETWORK_NOT_JOINED";

  case RADIOLIB_ERR_DOWNLINK_MALFORMED:
    return "RADIOLIB_ERR_DOWNLINK_MALFORMED";
  case RADIOLIB_ERR_INVALID_REVISION:
    return "RADIOLIB_ERR_INVALID_REVISION";
  case RADIOLIB_ERR_INVALID_PORT:
    return "RADIOLIB_ERR_INVALID_PORT";
  case RADIOLIB_ERR_NO_RX_WINDOW:
    return "RADIOLIB_ERR_NO_RX_WINDOW";
  case RADIOLIB_ERR_INVALID_CID:
    return "RADIOLIB_ERR_INVALID_CID";
  case RADIOLIB_ERR_UPLINK_UNAVAILABLE:
    return "RADIOLIB_ERR_UPLINK_UNAVAILABLE";
  case RADIOLIB_ERR_COMMAND_QUEUE_FULL:
    return "RADIOLIB_ERR_COMMAND_QUEUE_FULL";
  case RADIOLIB_ERR_COMMAND_QUEUE_ITEM_NOT_FOUND:
    return "RADIOLIB_ERR_COMMAND_QUEUE_ITEM_NOT_FOUND";
  case RADIOLIB_ERR_JOIN_NONCE_INVALID:
    return "RADIOLIB_ERR_JOIN_NONCE_INVALID";
  case RADIOLIB_ERR_N_FCNT_DOWN_INVALID:
    return "RADIOLIB_ERR_N_FCNT_DOWN_INVALID";
  case RADIOLIB_ERR_A_FCNT_DOWN_INVALID:
    return "RADIOLIB_ERR_A_FCNT_DOWN_INVALID";
  case RADIOLIB_ERR_DWELL_TIME_EXCEEDED:
    return "RADIOLIB_ERR_DWELL_TIME_EXCEEDED";
  case RADIOLIB_ERR_CHECKSUM_MISMATCH:
    return "RADIOLIB_ERR_CHECKSUM_MISMATCH";
  case RADIOLIB_LORAWAN_NO_DOWNLINK:
    return "RADIOLIB_LORAWAN_NO_DOWNLINK";
  case RADIOLIB_LORAWAN_SESSION_RESTORED:
    return "RADIOLIB_LORAWAN_SESSION_RESTORED";
  case RADIOLIB_LORAWAN_NEW_SESSION:
    return "RADIOLIB_LORAWAN_NEW_SESSION";
  case RADIOLIB_LORAWAN_NONCES_DISCARDED:
    return "RADIOLIB_LORAWAN_NONCES_DISCARDED";
  case RADIOLIB_LORAWAN_SESSION_DISCARDED:
    return "RADIOLIB_LORAWAN_SESSION_DISCARDED";
  }
  return "See TypeDef.h";
}

// helper function to display any issues
void debug(bool isFail, const __FlashStringHelper* message, int state, bool Freeze) {
  if (isFail) {
    Serial.print(message);
    Serial.print(" - ");
    Serial.print(stateDecode(state));
    Serial.print(" (");
    Serial.print(state);
    Serial.println(")");
    while (Freeze);
  }
}

// helper function to display a byte array
void arrayDump(uint8_t *buffer, uint16_t len) {
  for(uint16_t c = 0; c < len; c++) {
    char b = buffer[c];
    if(b < 0x10) { Serial.print('0'); }
    Serial.print(b, HEX);
  }
  Serial.println();
}

#endif

Hardware setup The controller that I am using. (I am using the SX1276, 923Mhz)

Debug mode output

Initialise the radio
Join ('login') the LoRaWAN Network
Ready!

Sending uplink
Uplink complete, next in 300 seconds
Sending uplink
Error in sendReceive - RADIOLIB_ERR_DWELL_TIME_EXCEEDED (-1114)
Uplink complete, next in 300 seconds

Additional info (please complete):

Thank you to anyone who can help me! Really appreciate it!

HeadBoffin commented 1 month ago

Duplicate to https://www.thethingsnetwork.org/forum/t/join-request-to-cluster-local-join-server-failed-error-when-sending-data-to-ttn/68803 - will close the forum thread as this is too far in to the weeds for over there.

HeadBoffin commented 1 month ago

As per forum comment - look at the Reference version for the JoinDR setting. In the meanwhile I'll see if a test can be done on AS923 using kit in the UK ;-)

HeadBoffin commented 1 month ago

Some confusing on my part as I was tracking your original combos of other devices and getting the Join to work.

So you are joining, getting an uplink done and then trying to send more payload than you are legally allowed to. Because it occurs on the second uplink I'd make the presumption the LNS has increased the SF to 11 or 12. The only way to be sure is for you to turn on the protocol debugging in BuildOptUser.h (see https://github.com/jgromes/RadioLib/wiki/Debug-mode) so we can see what's sent and what comes back.

If the LNS has moved you to SF11 or 12, then you need to sort out the range to the gateway &/or antennas.

LakinduBabySoap commented 1 month ago

Hello, thank you very much for the help!

The only way to be sure is for you to turn on the protocol debugging in BuildOptUser.h (see https://github.com/jgromes/RadioLib/wiki/Debug-mode) so we can see what's sent and what comes back.

Thank you for this. I do apologize for my ignorance but how do I add this to the file? I downloaded the raw file and added it to my sketch in arduino and then added

#include <BuildOptUser.h>

But I cannot get it to work. Sorry about this.

If the LNS has moved you to SF11 or 12, then you need to sort out the range to the gateway &/or antennas.

Actually, when I run the code, I can send a few uplinks and the code just stops working then for some reason, I cannot understand what the problem is. For the successful uplinks, the data rate is SF7/8 and BW 125 which is the proper amount. Earlier, I had to enable the "Verbose Stream" on both the End device and the gateway for me to at least get the program to work for a little bit.

[LoRaWAN] Output power: 16 dBm
[LoRaWAN] Frame count:  0
[LoRaWAN] Port:     0
[LoRaWAN] LinkCheck margin: 26
[LoRaWAN] LinkCheck count:  1
[LoRaWAN] DeviceTime Unix:  1722924041
[LoRaWAN] DeviceTime second:    1/46
[LoRaWAN] Next uplink in 394s
<MAC commands only>
[LoRaWAN] RSSI:     -67.00 dBm
[LoRaWAN] SNR:      10.75 dB
[LoRaWAN] Frequency error:  1841.30 Hz
[LoRaWAN] Event information:
[LoRaWAN] Confirmed:    69
[LoRaWAN] Confirming:   59
[LoRaWAN] Datarate: 200
[LoRaWAN] Frequency:    923.200 MHz
[LoRaWAN] Output power: 16 dBm
[LoRaWAN] Frame count:  0
[LoRaWAN] Port:     0
[LoRaWAN] Next uplink in 394s
[LoRaWAN] Next uplink in 353s
[LoRaWAN] Next uplink in 353s
[LoRaWAN] Next uplink in 353s

Below is the console logs of the gateway. At this time, I didn't see any live data in the end device console or anything in the program. Moreover, after a few minutes, I kept the program running and even the gateway stopped receiving any logs. image

I do sincerely apologize if it is a careless mistake on my side but I appreciate the help and I am trying my very best to solve the issue too.

Thank you!

HeadBoffin commented 1 month ago

Thank you for this. I do apologize for my ignorance but how do I add this to the file?

You don't add it, per instructions:

To enable debug, you can go to the BuildOptUser.h file, and uncomment any of these lines

So you find it in the src folder in the library and edit it there. There is a link to where it is and what it looks like.

Just noticed this:

I have tried to add a line uint8_t sf = 7 (and sf=8, sf=9), but none of them seem to work.

I'm not sure how you think this would work - you need to call functions with values and it's referenced by Data Rate not Spreading Factor. The code can't join up you allocating a variable called 'sf' to figure out you want to change the DR.

You've shown a screen shot of the gateway - the data for a device is shown in the device console ...

However we are going to stop now, because you clearly aren't using the Starter code anymore, you appear to be sending every five seconds which makes it impossible for the device to run the stack properly and means you are transmitting ILLEGALLY and appears to be blocking the ADR downlinks and are in breach of the TTN Fair Use Policy so I'm not in a position to help until you stop using a programming hammer to try to make things work. If you hit a finger with a hammer and broke it, would you try another finger to see if it happened again. Or take a step back to consider what's going on?

If you want to proceed, please go and read the Learn section in detail as you've been asked to do before, perhaps print it out and use a highlighter pen to ensure you have picked up the key items (which is all of it).

LakinduBabySoap commented 1 month ago

So you find it in the src folder in the library and edit it there. There is a link to where it is and what it looks like.

Hello, I added it and I can get a detailed output now thank you.

You've shown a screen shot of the gateway - the data for a device is shown in the device console ...

I am aware of that. Earlier, I faced an issue where the gateway would receive the packets yet I could not see anything on the device console so I added a screenshot of the gateway logs thinking maybe it could be of any help to solve the problem.

However we are going to stop now, because you clearly aren't using the Starter code anymore, you appear to be sending every five seconds which makes it impossible for the device to run the stack properly and means you are transmitting ILLEGALLY and appears to be blocking the ADR downlinks and are in breach of the TTN Fair Use Policy so I'm not in a position to help until you stop using a programming hammer to try to make things work. If you hit a finger with a hammer and broke it, would you try another finger to see if it happened again. Or take a step back to consider what's going on?

I am using the reference example as you suggested previously instead of the starter example. And I would like to add that I did not change the uplink interval by any means in the code, I kept it to the default 393 second interval. Earlier, sometimes the gateway would get spammed with 4 similar packets from the same device address for some reason. Please note that, in the reference code, I have only edited the keys and the region so this is not intentional on my side.

If you want to proceed, please go and read the Learn section in detail as you've been asked to do before, perhaps print it out and use a highlighter pen to ensure you have picked up the key items (which is all of it).

Kindly note that I have read the starter materials as suggested by you.

However, I was able to establish the connection. I deleted the previous end device, made a new end device with the same settings. And the code was running fine. Attached below is a screenshot of my device console.

image

Attached below is a picture of the gateway logs to prove that the device no longer forwards 4 packets at once and as proof that I am not breaching TTN policy (you can compare the console and the device logs to see the uplink time).

image

Setup
Initialise the radio
Join ('login') the LoRaWAN Network
RLB_PRO: Setting up dynamic channels
RLB_PRO: UL:   0 1 923.200 (0 - 5) | DL:   0 1 923.200 (0 - 5)
RLB_PRO: UL:   1 1 923.400 (0 - 5) | DL:   1 1 923.400 (0 - 5)
RLB_PRO: [MAC] 0x03
RLB_PRO: 0000000 40 00 00 80                                     | @...              
RLB_PRO: LinkADRReq: dataRate = 4, txSteps = 0, chMask = 0x0000, chMaskCntl = 0, nbTrans = 0
RLB_PRO: LinkADRAns: status = 0x07
RLB_PRO: [MAC] 0x04
RLB_PRO: DutyCycleReq: max duty cycle = 1/2^7
RLB_PRO: [MAC] 0x05
RLB_PRO: 0000000 02 80 de 8c                                     | ....              
RLB_PRO: RXParamSetupReq: rx1DrOffset = 0, rx2DataRate = 2, freq = 923.200012
RLB_PRO: RXParamSetupAns: status = 0x07
RLB_PRO: [MAC] 0x08
RLB_PRO: 0000000 01                                              | .                 
RLB_PRO: RXTimingSetupReq: delay = 1 sec
RLB_PRO: [MAC] 0x09
RLB_PRO: 0000000 35                                              | 5                 
RLB_PRO: TxParamSetupReq: dlDwell = 1, ulDwell = 1, maxEirp = 16 dBm
RLB_PRO: [MAC] 0x0C
RLB_PRO: 0000000 65                                              | e                 
RLB_PRO: ADRParamSetupReq: limitExp = 6, delayExp = 5
RLB_PRO: [MAC] 0x0F
RLB_PRO: 0000000 fa                                              | .                 
RLB_PRO: RejoinParamSetupReq: maxTime = 15, maxCount = 10
RLB_PRO: RejoinParamSetupAns: status = 0x03
RLB_PRO: 
RLB_PRO: PHY: Frequency UL = 923.200 MHz
RLB_PRO: PHY: SF = 8, TX = 16 dBm, BW = 125.000 kHz, CR = 4/7
RLB_PRO: JoinRequest sent (DevNonce = 0) <-- Rx Delay start
RLB_PRO: 
RLB_PRO: PHY: Frequency DL = 923.200 MHz
RLB_PRO: PHY: SF = 8, TX = 16 dBm, BW = 125.000 kHz, CR = 4/7
RLB_PRO: Opening Rx1 window (81 ms timeout)... <-- Rx Delay end 
RLB_PRO: Closing Rx1 window
RLB_PRO: JoinAccept (JoinNonce = 1, previously 0):
RLB_PRO: 0000000 20 01 00 00 13 00 00 94 77 0b 26 82 05 70 b7 8c |  .......w.&..p..
RLB_PRO: 0000010 40 bf 8c 10 c7 8c e0 ce 8c b0 d6 8c 00 d0 20 21 | @............. !
RLB_PRO: 0000020 99                                              | .                 
RLB_PRO: LoRaWAN revision: 1.1
RLB_PRO: [MAC] 0x05
RLB_PRO: 0000000 02 80 de 8c                                     | ....              
RLB_PRO: RXParamSetupReq: rx1DrOffset = 0, rx2DataRate = 2, freq = 923.200012
RLB_PRO: RXParamSetupAns: status = 0x07
RLB_PRO: [MAC] 0x08
RLB_PRO: 0000000 05                                              | .                 
RLB_PRO: RXTimingSetupReq: delay = 5 sec
RLB_PRO: Setting up dynamic channels
RLB_PRO: UL:   0 1 923.200 (0 - 5) | DL:   0 1 923.200 (0 - 5)
RLB_PRO: UL:   1 1 923.400 (0 - 5) | DL:   1 1 923.400 (0 - 5)
RLB_PRO: Processing CFList
RLB_PRO: [MAC] 0x07
RLB_PRO: 0000000 02 70 b7 8c 50                                  | .p..P             
RLB_PRO: NewChannelReq:
RLB_PRO: UL:   2 1 922.200 (0 - 5) | DL:   2 1 922.200 (0 - 5)
RLB_PRO: NewChannelAns: status = 0x03
RLB_PRO: [MAC] 0x07
RLB_PRO: 0000000 03 40 bf 8c 50                                  | .@..P             
RLB_PRO: NewChannelReq:
RLB_PRO: UL:   3 1 922.400 (0 - 5) | DL:   3 1 922.400 (0 - 5)
RLB_PRO: NewChannelAns: status = 0x03
RLB_PRO: [MAC] 0x07
RLB_PRO: 0000000 04 10 c7 8c 50                                  | ....P             
RLB_PRO: NewChannelReq:
RLB_PRO: UL:   4 1 922.600 (0 - 5) | DL:   4 1 922.600 (0 - 5)
RLB_PRO: NewChannelAns: status = 0x03
RLB_PRO: [MAC] 0x07
RLB_PRO: 0000000 05 e0 ce 8c 50                                  | ....P             
RLB_PRO: NewChannelReq:
RLB_PRO: UL:   5 1 922.800 (0 - 5) | DL:   5 1 922.800 (0 - 5)
RLB_PRO: NewChannelAns: status = 0x03
RLB_PRO: [MAC] 0x07
RLB_PRO: 0000000 06 b0 d6 8c 50                                  | ....P             
RLB_PRO: NewChannelReq:
RLB_PRO: UL:   6 1 923.000 (0 - 5) | DL:   6 1 923.000 (0 - 5)
RLB_PRO: NewChannelAns: status = 0x03
[LoRaWAN] DevAddr: 260B7794
RLB_PRO: [MAC] 0x03
RLB_PRO: 0000000 4f 00 00 80                                     | O...              
RLB_PRO: LinkADRReq: dataRate = 4, txSteps = 15, chMask = 0x0000, chMaskCntl = 0, nbTrans = 0
RLB_PRO: LinkADRAns: status = 0x07
Ready!

[LoRaWAN] Requesting LinkCheck and DeviceTime
RLB_PRO: 
RLB_PRO: PHY: Frequency UL = 922.800 MHz
RLB_PRO: PHY: SF = 8, TX = 16 dBm, BW = 125.000 kHz, CR = 4/7
RLB_PRO: Uplink MAC payload (3 commands):
RLB_PRO: 0000000 0b 01 02 0d                                     | ....              
RLB_PRO: Uplink (FCntUp = 0) decoded:
RLB_PRO: 0000000 21 00 78 56 fc 8c fb 3f 13 00 00 00 34 12 ba ab | !.xV...?....4...
RLB_PRO: 0000010 80 94 77 0b 26 04 00 00 96 40 cb 0a 0a 4f 00 00 | ..w.&....@...O..
RLB_PRO: 0000020 14 80                                           | ..                
RLB_PRO: Uplink sent <-- Rx Delay start
RLB_PRO: 
RLB_PRO: PHY: Frequency DL = 922.800 MHz
RLB_PRO: PHY: SF = 8, TX = 16 dBm, BW = 125.000 kHz, CR = 4/7
RLB_PRO: Opening Rx1 window (81 ms timeout)... <-- Rx Delay end 
RLB_PRO: Closing Rx1 window
RLB_PRO: PHY: Frequency DL = 923.200 MHz
RLB_PRO: Opening Rx2 window (249 ms timeout)... <-- Rx Delay end 
RLB_PRO: Closing Rx2 window
[LoRaWAN] Next uplink in 353s
[LoRaWAN] Requesting LinkCheck and DeviceTime
RLB_PRO: 
RLB_PRO: PHY: Frequency UL = 923.200 MHz
RLB_PRO: PHY: SF = 8, TX = 16 dBm, BW = 125.000 kHz, CR = 4/7
RLB_PRO: Uplink MAC payload (3 commands):
RLB_PRO: 0000000 0b 01 02 0d                                     | ....              
RLB_PRO: Uplink (FCntUp = 1) decoded:
RLB_PRO: 0000000 21 00 78 56 fc 8c fb 3f 13 00 00 00 34 12 ba ab | !.xV...?....4...
RLB_PRO: 0000010 80 94 77 0b 26 04 01 00 a3 c6 d2 29 0a 1c 00 00 | ..w.&......)....
RLB_PRO: 0000020 14 80                                           | ..                
RLB_PRO: Uplink sent <-- Rx Delay start
RLB_PRO: 
RLB_PRO: PHY: Frequency DL = 923.200 MHz
RLB_PRO: PHY: SF = 8, TX = 16 dBm, BW = 125.000 kHz, CR = 4/7
RLB_PRO: Opening Rx1 window (81 ms timeout)... <-- Rx Delay end 
RLB_PRO: Closing Rx1 window
RLB_PRO: Downlink (NFCntDown = 0) encoded:
RLB_PRO: 0000000 49 01 00 00 00 01 94 77 0b 26 00 00 00 00 00 1d | I......w.&......
RLB_PRO: 0000010 60 94 77 0b 26 a0 00 00 00 4a ec 96 f0 8b 3a 35 | `.w.&....J....:5
RLB_PRO: 0000020 b2 7a 02 6a 2c c1 41 8a 8e 44 ab 10 9c c2 16 56 | .z.j,.A..D.....V
RLB_PRO: 0000030 1c                                              | .                 
RLB_PRO: [MAC] 0x0B
RLB_PRO: 0000000 01                                              | .                 
RLB_PRO: RekeyConf: server version = 1.1
RLB_PRO: [MAC] 0x0D
RLB_PRO: 0000000 b7 a7 dd 53 aa                                  | ...S.             
RLB_PRO: DeviceTimeAns: [user]
RLB_PRO: [MAC] 0x02
RLB_PRO: 0000000 18 01                                           | ..                
RLB_PRO: LinkCheckAns: [user]
RLB_PRO: [MAC] 0x09
RLB_PRO: 0000000 35                                              | 5                 
RLB_PRO: TxParamSetupReq: dlDwell = 1, ulDwell = 1, maxEirp = 16 dBm
RLB_PRO: [MAC] 0x07
RLB_PRO: 0000000 07 a0 af 8c 50                                  | ....P             
RLB_PRO: NewChannelReq:
RLB_PRO: UL:   7 1 922.000 (0 - 5) | DL:   7 1 922.000 (0 - 5)
RLB_PRO: NewChannelAns: status = 0x03
RLB_PRO: [MAC] 0x06
RLB_PRO: DevStatusReq
RLB_PRO: DevStatusAns: status = 0x920a
<MAC commands only>
[LoRaWAN] RSSI:     -56.00 dBm
[LoRaWAN] SNR:      10.25 dB
[LoRaWAN] Frequency error:  1606.42 Hz
[LoRaWAN] Event information:
[LoRaWAN] Confirmed:    0
[LoRaWAN] Confirming:   1
[LoRaWAN] Datarate: 4
[LoRaWAN] Frequency:    923.200 MHz
[LoRaWAN] Output power: 16 dBm
[LoRaWAN] Frame count:  0
[LoRaWAN] Port:     0
[LoRaWAN] LinkCheck margin: 24
[LoRaWAN] LinkCheck count:  1
[LoRaWAN] DeviceTime Unix:  1723000101
[LoRaWAN] DeviceTime second:    1/170
[LoRaWAN] Next uplink in 354s
RLB_PRO:

This is the output I get from the code. I also have edited the reference code payload to send only 1 byte (1 random number), as opposed to the default 3 bytes.

Thank you.

HeadBoffin commented 1 month ago

I added a screenshot of the gateway logs thinking maybe it could be of any help to solve the problem.

This was hugely confusing as it wasn't clear to me that the entries you were showing were not your device. Showing a console screen shot that does not include your device does not provide any information at all beyond that they are not there which is starting to end up in some philosophical Schrödinger's cat type situation so you'll have to excuse my confusion and reaction.

However, I was able to establish the connection. I deleted the previous end device, made a new end device with the same settings. And the code was running fine

There may be a fair amount of "lost in translation" going on here. It seems you have a successful join and you receive an ADR request to change the DR to 4 which is SF8. As we only see two uplinks in the debug I can't speak to what happens next.

The phrases "I was able" and "the code was running fine" sort of implies that you are no longer able and it is no longer running fine. The word "was" means that the situation of it working is in the past and by implication is no longer working. If it is now joining and you are able to uplink, please use the present tense - like "It is joining and it is uplinking".

Fingers crossed you have a working system.

LakinduBabySoap commented 1 month ago

This was hugely confusing as it wasn't clear to me that the entries you were showing were not your device. Showing a console screen shot that does not include your device does not provide any information at all beyond that they are not there which is starting to end up in some philosophical Schrödinger's cat type situation so you'll have to excuse my confusion and reaction.

I do understand it is a miscommunication on my side.

There may be a fair amount of "lost in translation" going on here. It seems you have a successful join and you receive an ADR request to change the DR to 4 which is SF8. As we only see two uplinks in the debug I can't speak to what happens next.

The phrases "I was able" and "the code was running fine" sort of implies that you are no longer able and it is no longer running fine. The word "was" means that the situation of it working is in the past and by implication is no longer working. If it is now joining and you are able to uplink, please use the present tense - like "It is joining and it is uplinking".

Fingers crossed you have a working system.

Haha yes, thank you for the explanation. I have been testing it and it has been working for the most part. What I mean is, sometimes, it connects initially and the uplinks don't get sent but when one uplink does get sent, it works completely fine. Thank you for your help. I really appreciate and I do apologise if it was frustrating explaining some stuff to me.

HeadBoffin commented 1 month ago

You'll probably find that the lost uplinks are due to the close proximity of the device & gateway - you need 10m & a brick wall between them to get the RSSI down to around -50, otherwise the device is shouting in the ears of the gateway and you will see some corruption of packets due to overload.

LakinduBabySoap commented 1 month ago

You'll probably find that the lost uplinks are due to the close proximity of the device & gateway - you need 10m & a brick wall between them to get the RSSI down to around -50, otherwise the device is shouting in the ears of the gateway and you will see some corruption of packets due to overload.

Noted. Will keep that in mind. Thank you

HeadBoffin commented 1 month ago

Seems to be resolved, so closing