[LORAWAN] sending uplink packet… failed code -4 about radiolib HOT 31 CLOSED

No matter how few changes you made, please share your sketch and some of the serial output. Very very much preferred inside code blocks using triple backticks (```) at the beginning and at the end (or using the <> tool).

from radiolib.

/*
  RadioLib LoRaWAN End Device Example

  This example joins a LoRaWAN network and will send
  uplink packets. Before you start, you will have to
  register your device at https://www.thethingsnetwork.org/
  After your device is registered, you can run this example.
  The device will join the network and start uploading data.

  LoRaWAN v1.1 requires the use of EEPROM (persistent storage).
  Please refer to the 'persistent' example once you are familiar
  with LoRaWAN.
  Running this examples REQUIRES you to check "Resets DevNonces"
  on your LoRaWAN dashboard. Refer to the network's 
  documentation on how to do this.

  For default module settings, see the wiki page
  https://github.com/jgromes/RadioLib/wiki/Default-configuration

  For full API reference, see the GitHub Pages
  https://jgromes.github.io/RadioLib/
*/

// include the library
#include <RadioLib.h>

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

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

// create the node instance on the EU-868 band
// using the radio module and the encryption key
// make sure you are using the correct band
// based on your geographical location!
//LoRaWANNode node(&radio, &EU868);

// for fixed bands with subband selection
// such as US915 and AU915, you must specify
// the subband that matches the Frequency Plan
// that you selected on your LoRaWAN console

LoRaWANNode node(&radio, &US915, 2);


void setup() {
  Serial.begin(9600);

  // initialize SX1262 with default settings
  Serial.print(F("[SX1262] Initializing ... "));
  int state = radio.begin();
  if(state == RADIOLIB_ERR_NONE) {
    Serial.println(F("success!"));
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
    while(true);
  }

  // application identifier - pre-LoRaWAN 1.1.0, this was called appEUI
  // when adding new end device in TTN, you will have to enter this number
  // you can pick any number you want, but it has to be unique
  uint64_t joinEUI = "TTN_JoinEUI_Key";

  // device identifier - this number can be anything
  // when adding new end device in TTN, you can generate this number,
  // or you can set any value you want, provided it is also unique
  uint64_t devEUI = "TTN_devEUI_Key";

  // select some encryption keys which will be used to secure the communication
  // there are two of them - network key and application key
  // because LoRaWAN uses AES-128, the key MUST be 16 bytes (or characters) long

  // network key is the ASCII string "topSecretKey1234"
  uint8_t nwkKey[] = { "TTN_nwkKey" };

  // application key is the ASCII string "aDifferentKeyABC"
  uint8_t appKey[] = { "TTN_appKey" };

  // prior to LoRaWAN 1.1.0, only a single "nwkKey" is used
  // when connecting to LoRaWAN 1.0 network, "appKey" will be disregarded
  // and can be set to NULL


  // on EEPROM-enabled boards, after the device has been activated,
  // the session can be restored without rejoining after device power cycle
  // this is intrinsically done when calling `beginOTAA()` with the same keys
  // in that case, the function will not need to transmit a JoinRequest

  // now we can start the activation
  // this can take up to 10 seconds, and requires a LoRaWAN gateway in range
  // a specific starting-datarate can be selected in dynamic bands (e.g. EU868):
  /* 
    uint8_t joinDr = 4;
    state = node.beginOTAA(joinEUI, devEUI, nwkKey, appKey, joinDr);
  */
  Serial.print(F("[LoRaWAN] Attempting over-the-air activation ... "));
  state = node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);

  if(state >= RADIOLIB_ERR_NONE) {
    Serial.println(F("success!"));
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
    while(true);
  }

}

// counter to keep track of transmitted packets
int count = 0;

void loop() {
  // send uplink to port 10
  Serial.print(F("[LoRaWAN] Sending uplink packet ... "));
  String strUp = "Hello World! #" + String(count++);
  String strDown;
  int state = node.sendReceive(strUp, 10, strDown);
  if(state == RADIOLIB_ERR_NONE) {
    Serial.println(F("received a downlink!"));

    // print data of the packet (if there are any)
    Serial.print(F("[LoRaWAN] Data:\t\t"));
    if(strDown.length() > 0) {
      Serial.println(strDown);
    } else {
      Serial.println(F("<MAC commands only>"));
    }

    // print RSSI (Received Signal Strength Indicator)
    Serial.print(F("[LoRaWAN] RSSI:\t\t"));
    Serial.print(radio.getRSSI());
    Serial.println(F(" dBm"));

    // print SNR (Signal-to-Noise Ratio)
    Serial.print(F("[LoRaWAN] SNR:\t\t"));
    Serial.print(radio.getSNR());
    Serial.println(F(" dB"));

    // print frequency error
    Serial.print(F("[LoRaWAN] Frequency error:\t"));
    Serial.print(radio.getFrequencyError());
    Serial.println(F(" Hz"));
  
  } else if(state == RADIOLIB_ERR_RX_TIMEOUT) {
    Serial.println(F("no downlink!"));
  
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
  }
  
  // wait before sending another packet
  uint32_t minimumDelay = 60000;                  // try to send once every minute
  uint32_t interval = node.timeUntilUplink();     // calculate minimum duty cycle delay (per law!)
  uint32_t delayMs = max(interval, minimumDelay); // cannot send faster than duty cycle allows

  delay(delayMs);
}

Edited for clarity

from radiolib.

[SX1262] Initializing ... success!
[LoRaWAN] Attempting over-the-air activation ... success!
[LoRaWAN] Sending uplink packet ... failed, code -4
[LoRaWAN] Sending uplink packet ... failed, code -4
[LoRaWAN] Sending uplink packet ... failed, code -4

from radiolib.

I just tried my other board TTGO Lora 32 T3 v2.1.6 with SX1276 chip and I got the same error message "[LoRaWAN] Sending uplink packet ... failed, code -4".

from radiolib.

Hmm, I don't see an obvious reason why this would fail. Could you maybe find the file BuildOptUser.h and uncommented the debug flag? Please leave the verbose flag commented - don't need that one.
With the debug flag enabled, please run the sketch again and share the complete output of joining and an uplink. Preferrably formatted with the triple backtick, the single backtick is not enough for larger blocks of output. Thank you in advance!

from radiolib.

Can test shortly on my setup

from radiolib.

There are suspicions about the why but it would help enormously if @altinem could provide the debug log to corroborate.

from radiolib.

I found the problem. It was my Gateway setup as pocket forwarder. It now works after setting up the gateway as Basics Station. But sometimes I get no downlink message.
Thank you!

[SX1262] Initializing ... success!
[LoRaWAN] Attempting over-the-air activation ... success!
[LoRaWAN] Sending uplink packet ... no downlink!
[LoRaWAN] Sending uplink packet ... received a downlink!
[LoRaWAN] Data:
[LoRaWAN] RSSI: -26.00 dBm
[LoRaWAN] SNR: 11.00 dB
[LoRaWAN] Frequency error: 31.00 Hz

from radiolib.

[SX1262] Initializing ...
RadioLib Debug Info
Version: 6.4.2.0
Platform: ESP32
Compiled: Feb 13 2024 21:03:38

Found SX126x: RADIOLIB_SX126X_REG_VERSION_STRING:
0000320 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00 | SX1261 V2D 2D02.

M SX126x
success!
[LoRaWAN] Attempting over-the-air activation ... Found existing session; restoring...
LoRaWAN session: v1.1
Setting up fixed channels
exe MAC CID = 03, len = 4
ADR REQ: dataRate = 4, txPower = 0, chMask = 0x0002, chMaskCntl = 07, nbTrans = 0
DR 32: LORA (SF: 8, BW: 500.000000, CR: 5)
ADR mask: clearing channels
mask[7] = 0x0002
Channel UL 65 (1) frequency = 904.599976 MHz
UL: 65 1 904.60 (4 - 4) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
ADR ANS: status = 0x07
exe MAC CID = 03, len = 4
ADR REQ: dataRate = 4, txPower = 0, chMask = 0xff00, chMaskCntl = 00, nbTrans = 0
DR 32: LORA (SF: 8, BW: 500.000000, CR: 5)
mask[0] = 0xff00
Channel UL 8 (2) frequency = 903.899963 MHz
Channel UL 9 (3) frequency = 904.099976 MHz
Channel UL 10 (4) frequency = 904.299988 MHz
Channel UL 11 (5) frequency = 904.500000 MHz
Channel UL 12 (6) frequency = 904.700012 MHz
Channel UL 13 (7) frequency = 904.899963 MHz
Channel UL 14 (8) frequency = 905.099976 MHz
Channel UL 15 (9) frequency = 905.299988 MHz
UL: 65 1 904.60 (4 - 4) | DL: 0 0 0.00 (0 - 0)
UL: 8 1 903.90 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 9 1 904.10 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 10 1 904.30 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 11 1 904.50 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 12 1 904.70 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 13 1 904.90 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 14 1 905.10 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 15 1 905.30 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
ADR ANS: status = 0x07
exe MAC CID = 03, len = 4
ADR REQ: dataRate = 3, txPower = 14, chMask = 0xff00, chMaskCntl = 00, nbTrans = 1
DR 24: LORA (SF: 7, BW: 125.000000, CR: 5)
ADR mask: clearing channels
mask[0] = 0xff00
Channel UL 8 (1) frequency = 903.899963 MHz
Channel UL 9 (2) frequency = 904.099976 MHz
Channel UL 10 (3) frequency = 904.299988 MHz
Channel UL 11 (4) frequency = 904.500000 MHz
Channel UL 12 (5) frequency = 904.700012 MHz
Channel UL 13 (6) frequency = 904.899963 MHz
Channel UL 14 (7) frequency = 905.099976 MHz
Channel UL 15 (8) frequency = 905.299988 MHz
UL: 8 1 903.90 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 9 1 904.10 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 10 1 904.30 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 11 1 904.50 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 12 1 904.70 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 13 1 904.90 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 14 1 905.10 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 15 1 905.30 (0 - 3) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
UL: 255 0 0.00 (0 - 0) | DL: 0 0 0.00 (0 - 0)
ADR ANS: status = 0x07
exe MAC CID = 04, len = 1
Max duty cycle: 1/2^0
exe MAC CID = 05, len = 4
Rx param REQ: rx1DrOffset = 0, rx2DataRate = 8, freq = 923.299988
Rx param ANS: status = 0x07
exe MAC CID = 08, len = 1
RX timing: delay = 5 sec
exe MAC CID = 09, len = 1
TX timing: dlDwell = 0, ulDwell = 1, maxEirp = 30 dBm
exe MAC CID = 0c, len = 1
ADR param setup: limitExp = 6, delayExp = 5
exe MAC CID = 0f, len = 1
Rejoin setup: maxTime = 15, maxCount = 10
Number of MAC commands: 1
success!
[LoRaWAN] Sending uplink packet ...
Channel frequency UL = 904.500000 MHz
DR 24: LORA (SF: 7, BW: 125.000000, CR: 5)
Uplink MAC payload (1 commands):
0000000 0b 01 | ..
uplinkMsg pre-MIC:
0000000 c0 00 78 56 60 d6 ce 3f 13 00 00 00 34 12 ba ab | ..xV`..?....4...
0000010 40 b6 fc 0c 26 82 01 00 1c 99 0a 07 a3 17 00 00 | @...&...........
uplinkMsg:
0000000 49 00 00 00 00 00 b6 fc 0c 26 01 00 00 00 00 0c | I........&......
0000010 40 b6 fc 0c 26 82 01 00 1c 99 0a 07 31 2d 5f 77 | @...&.......1-_w
Timeout in 77184 us
Uplink sent <-- Rx Delay start

Channel frequency DL = 925.099976 MHz
DR 16: LORA (SF: 7, BW: 500.000000, CR: 5)
Opening Rx1 window (26464 us timeout)... <-- Rx Delay end
closing
DR 96: LORA (SF: 12, BW: 500.000000, CR: 5)
Opening Rx2 window (185888 us timeout)... <-- Rx Delay end
closing
no downlink!

from radiolib.

Good to hear that you've setup your gateway on Basic Station. It is unlikely however to be the issue that you encountered earlier that resulted in the -4 error: we confirmed that the example uplink text (Hello World! #0) violates the dwell time limits on DR0 in the US915 band. If the join-accept did not immediately tell your node to use a faster datarate, it would result in -4; however on later attempts with the gateway also running fresh software, it likely immediately told your device to use a faster datarate, which means you don't hit the dwell time limits.

We will update the uplink payload in the examples such that they don't result in violating the dwell time limits on DR0.

from radiolib.

The LNS dropped the DR down to 8 and then 7 in short order. At DR0 you can only send 12 bytes and "Hello World #1" is 5 bytes ...

Maybe have a different error return to indicate that it's too long due to legal limitations, not that it exceeds the buffer?

from radiolib.

Fair distinction between gateway and LNS, yes. But the SF8 in the logs is from setting up the default channels before it restored the SF7 from EEPROM / some point in history where the LNS instructed the use of SF7 ;)

We'll introduce a 'new' error for dwell time limits, that's a good addition.

from radiolib.

I forgot to mention that I changed the uplink message to H letter after I was first told the message was too long. And the message was sent without any problem. I also tested the code With Heltec wireless stick v3 with for loop snippet added to show scrolling text message on the Oled display. Because due to oled display size limitation on Heltec wireless v3. Another strange behavior I discovered with the code. When I flashed the board and and I get an error code -4. Then I changed the strUp message to short message like single letter It will send the uplink message..

from radiolib.

Ahh yep that will have solved your issue! Thanks for the feedback.

from radiolib.

I also get no downlink repeatedly. the for loop snippet I used for scrolling text for oled display cause long delay to receive downlink?
I will send the edited sketch with for loop snippet added when I get home tonight .

from radiolib.

It is actually good that you don't receive a downlink usually - LoRaWAN is not meant for receiving downlinks on each uplink. And unless you specifically request the server to send a downlink, it hardly ever happens that you get one. If you want to receive a downlink on each uplink, I'd recommend you think hard if there is an option to use LoRa point to point instead of LoRaWAN, or maybe something else completely.

I am not sure what your idea is with the scrolling text on the display, but that shouldn't interfere in any way with the fact that you don't receive downlinks.

from radiolib.

Heltec wireless stick v3 comes with 0.49” Oled display(64x32). The screen is too small to show messages and/or status unless using a scrolling text snippet code when you are not connected to serial terminal. I also tried to send a downlink message from the TTN console. It still says no downlink. Thanks!

from radiolib.

The ability of the Heltec module to display information isn't a function of LoRaWAN. I have a v2 & a v3 module for testing on my desk right now which covers ESP32 + SX1276 & SX1262 radios - both will receive a downlink if required that is shown in the serial log. The circumstances under which a downlink arrives isn't as straightforward as it seems - if the gateway is out of legal duty cycle the downlink won't be scheduled immediately, so if there are some MAC commands that have been sent over a short period, the gateway may not transmit.

Additionally, sending every 60 seconds is in breach of the TTN Fair Use Policy. For one character, the minimum time is 133.4 seconds.

If you can leave your device to perform half a dozen uplinks to let any MAC commands be run through and then try a downlink and then post the serial log - but this time, please please please use three backticks to format that log so it's easy to read.

from radiolib.

Will do thanks. Please Correct me if this following statement is true which I found on the TTN forum. “There is no duty cycle in US915, but there is a so-called “dwell time”. If you keep individual transmissions under 400ms, there are no other legal restrictions.”

from radiolib.

I'm no lawyer but that is my understanding not that it matters as the code is policing the situation. I was actually referring to the TTN Fair Use Policy which is covered in the Learn section.

from radiolib.

The original issue is solved with #974 - please let us know if the issue can be closed. If you have specific problems with your code, I would suggest you compare & study some examples on display code and LoRaWAN code and if still stuck probably open a Discussion :)

from radiolib.

I justed tested the new code. I still get get error code -4. I deleted one letter at a time in the uplink string untill no error message. I won`t get error message when the string text is "String strUp = "HelloWor" + String(count++);" "HelloWor0". I also noticed I get "no downlink" message unless I add "node.wipe(); " line then I get "received downlink" message.

from radiolib.

A wise man once said:

“There is no duty cycle in US915, but there is a so-called “dwell time”. If you keep individual transmissions under 400ms, there are no other legal restrictions.”

That code -4 is saving you $$$ and court time. At the SF you are using, you can only send 12 bytes. So anything longer is a code -4 and no sirens.

from radiolib.

I also noticed I get "no downlink" message unless I add "node.wipe(); " line then I get "received downlink" message.

Well, that's exactly how it is intended! LoRaWAN is all about sending information up, not down. There can be a downlink, but usually there won't be any - and there shouldn't be any. After issuing node.wipe(), your node will issue a join which always causes a downlink - not friendly for everyone around you!

from radiolib.

I don’t see any activities in the TTN console when uplink sent . node.wipe(); was commented.

from radiolib.

If it's a code -4, it won't do, it didn't send ....

from radiolib.

No activity in the TTN console after shortening the uplink message when I get no downlink message

from radiolib.

I guess we can close this issue and I will open up a discussion

from radiolib.

No activity in the TTN console after shortening the uplink message when I get no downlink message

I'm not sure I understand - you shorten the uplink message but don't see the uplink in the console when there is no downlink. Does this mean you do see the uplink when you've scheduled a downlink?

I've now got remote access to the test devices, I can re-try your code to see what the serial & console outputs are.

from radiolib.

I think we can close the code -4 situation as it is dwell time related - maybe @StevenCellist we could have a different error code for such situations. However I'll open a new issue as I have a code combo that produces the uplink not appearing on the console. This comes about from a previous join that's not had the f_cnt updated after each uplink. Whilst technically not a bug it isn't very developer friendly at all, but that pretty much sums up LoRaWAN!

from radiolib.

As I was told earlier I am not supposed to receive a downlink after the uplink message was sent unless I schedule a downlink messge. I get downlink message "[LoRaWAN] Data: MAC commands only" when I add node.wipe(); line to the sketch. When I remove the " node.wipe(); " line from the sketch the uplink was sent and receive no downlink link message which I am not supposed to get any. However, i don`t see any activities in i the TTN console if the uplink message was received by the TTN. I am moving this to discussion #977

from radiolib.