search

jgromes / RadioLib

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

Issue with Lorawan, I can send JoinRequest and receive JoinAccept. But when I transmit a message it is not being received by the Helium network. #1299

Open predictitai opened 1 month ago

predictitai commented 1 month ago

After a JoinRequest and JoinAccept I transmit "hello world". I see that via an rtl sdr that the message has actually been send; however I don't see the uplink message frame in my Helium-IoT Console. Note that transmit and sendReceive function do not result in an uplink frame. scanguard=50 and added enabled debugging; .

Debug mode output

Setup ... Initialise the radio RLB_DBG: RadioLib Info Version: "7.1.0.0" Platform: "ESP32" Compiled: "Oct 31 2024" "13:29:29" RLB_DBG: Found SX126x: RADIOLIB_SX126X_REG_VERSION_STRING: RLB_DBG: 00000320: 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00 SX1261 V2D 2D02. RLB_DBG: RLB_DBG: M SX126x Join ('login') the LoRaWAN Network RLB_PRO: Setting up dynamic channels RLB_PRO: UL: 0 1 868.100 (0 - 5) | DL: 0 1 868.100 (0 - 5) RLB_PRO: UL: 1 1 868.300 (0 - 5) | DL: 1 1 868.300 (0 - 5) RLB_PRO: UL: 2 1 868.500 (0 - 5) | DL: 2 1 868.500 (0 - 5) RLB_PRO: [MAC] 0x03 RLB_PRO: 00000000: 20 RLB_PRO: LinkAdrReq: dataRate = 2, txSteps = 0, nbTrans = 0 RLB_PRO: LinkAdrAns: 07 RLB_PRO: [MAC] 0x04 RLB_PRO: 00000000: 07 . RLB_PRO: DutyCycleReq: max duty cycle = 1/2^7 RLB_PRO: [MAC] 0x05 RLB_PRO: 00000000: 00 d2 ad 84 .... RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq = 869.525 RLB_PRO: [MAC] 0x08 RLB_PRO: 00000000: 01 . RLB_PRO: RXTimingSetupReq: delay = 1 sec RLB_PRO: [MAC] 0x09 RLB_PRO: 00000000: 05 . RLB_PRO: [MAC] 0x0c RLB_PRO: 00000000: 65 e RLB_PRO: ADRParamSetupReq: limitExp = 6, delayExp = 5 RLB_PRO: [MAC] 0x0f RLB_PRO: 00000000: fa . RLB_PRO: RejoinParamSetupReq: maxTime = 15, maxCount = 10 RLB_PRO: RLB_PRO: PHY: Frequency = 868.100 MHz, TX = 16 dBm RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U RLB_DBG: Timeout in 1853 ms RLB_PRO: JoinRequest sent (DevNonce = 39783) <-- Rx Delay start RLB_PRO: 00000000: 00 64 bf 97 76 8d 2a 9b b0 e7 16 5d a4 c2 ba e7 .d..v.*....].... RLB_PRO: 00000010: ba 67 9b ba 8b 29 78 .g...)x RLB_PRO: RLB_PRO: PHY: Frequency = 868.100 MHz, TX = 16 dBm RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: D RLB_PRO: Opening Rx1 window (331 ms timeout)... <-- Rx Delay end RLB_PRO: Closing Rx1 window RLB_PRO: JoinAccept (JoinNonce = 49, previously 0): RLB_PRO: 00000000: 20 31 00 00 24 00 00 1b 08 00 48 80 01 18 4f 84 1..$.....H...O. RLB_PRO: 00000010: e8 56 84 b8 5e 84 88 66 84 58 6e 84 00 93 84 d2 .V..^..f.Xn..... RLB_PRO: 00000020: 1c . RLB_PRO: LoRaWAN revision: 1.1 RLB_PRO: Setting up dynamic channels RLB_PRO: UL: 0 1 868.100 (0 - 5) | DL: 0 1 868.100 (0 - 5) RLB_PRO: UL: 1 1 868.300 (0 - 5) | DL: 1 1 868.300 (0 - 5) RLB_PRO: UL: 2 1 868.500 (0 - 5) | DL: 2 1 868.500 (0 - 5) RLB_PRO: [MAC] 0x05 RLB_PRO: 00000000: 00 d2 ad 84 .... RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq = 869.525 RLB_PRO: [MAC] 0x08 RLB_PRO: 00000000: 01 . RLB_PRO: RXTimingSetupReq: delay = 1 sec RLB_PRO: Processing CFList RLB_PRO: [MAC] 0x07 RLB_PRO: 00000000: 03 18 4f 84 50 ..O.P RLB_PRO: UL: 3 1 867.100 (0 - 5) | DL: 3 1 867.100 (0 - 5) RLB_PRO: [MAC] 0x07 RLB_PRO: 00000000: 04 e8 56 84 50 ..V.P RLB_PRO: UL: 4 1 867.300 (0 - 5) | DL: 4 1 867.300 (0 - 5) RLB_PRO: [MAC] 0x07 RLB_PRO: 00000000: 05 b8 5e 84 50 ..^.P RLB_PRO: UL: 5 1 867.500 (0 - 5) | DL: 5 1 867.500 (0 - 5) RLB_PRO: [MAC] 0x07 RLB_PRO: 00000000: 06 88 66 84 50 ..f.P RLB_PRO: UL: 6 1 867.700 (0 - 5) | DL: 6 1 867.700 (0 - 5) RLB_PRO: [MAC] 0x07 RLB_PRO: 00000000: 07 58 6e 84 50 .Xn.P RLB_PRO: UL: 7 1 867.900 (0 - 5) | DL: 7 1 867.900 (0 - 5) Connected to the network! Sending uplink RLB_DBG: Timeout in 1443 ms Message sent successfully! RLB_DBG: Timeout in 1443 ms Message sent successfully!

To Reproduce I use the T-Deck plus device. I used code from https://github.com/Xinyuan-LilyGO/T-Deck but removed Radiolib completely and replaced it with the latest version https://github.com/jgromes/RadioLib version 7.1.0

Sketch that is causing the module fail

#include "config.h" #define SHORT_ATTEMPT_INTERVAL 60 // Short interval between quick attempts in seconds #define LONG_SLEEP_INTERVAL 300 // Deep sleep interval in seconds after a session of attempts #define MAX_SHORT_ATTEMPTS 3 // Max quick attempts per session void setup() { //! The board peripheral power control pin needs to be set to HIGH when using the peripheral pinMode(BOARD_POWERON, OUTPUT); digitalWrite(BOARD_POWERON, HIGH); //! Set CS on all SPI buses to high level during initialization pinMode(BOARD_SDCARD_CS, OUTPUT); pinMode(RADIO_CS_PIN, OUTPUT); pinMode(BOARD_TFT_CS, OUTPUT); digitalWrite(BOARD_SDCARD_CS, HIGH); digitalWrite(RADIO_CS_PIN, HIGH); digitalWrite(BOARD_TFT_CS, HIGH); pinMode(BOARD_SPI_MISO, INPUT_PULLUP); SPI.begin(BOARD_SPI_SCK, BOARD_SPI_MISO, BOARD_SPI_MOSI); 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 state = node.beginOTAA(joinEUI, devEUI, nwkKey, appKey); debug(state != RADIOLIB_ERR_NONE, F("Initialise node failed"), state, true); Serial.println(F("Join ('login') the LoRaWAN Network")); while (true) { bool connected = false; // Inner loop: multiple quick attempts within one session for (int attempt = 0; attempt < MAX_SHORT_ATTEMPTS; attempt++) { int connectionStatus = node.activateOTAA(); if (connectionStatus == RADIOLIB_LORAWAN_NEW_SESSION) { Serial.println("Connected to the network!"); connected = true; break; } else { Serial.printf("Quick attempt %d failed. Retrying in %d seconds... Errorcode: %d \n", attempt + 1, SHORT_ATTEMPT_INTERVAL, connectionStatus); delay(SHORT_ATTEMPT_INTERVAL * 1000); // Short wait before next quick attempt } } if (connected) { // Exit setup on success return; } else { // If no connection after all quick attempts, enter long sleep Serial.println("Session failed. Entering deep sleep for a longer interval."); esp_sleep_enable_timer_wakeup(LONG_SLEEP_INTERVAL * 1000000); // Set sleep interval in microseconds esp_deep_sleep_start(); } } Serial.println(F("Ready!\n")); } void loop() { Serial.println(F("Sending uplink")); int state = radio.transmit("hello world!"); if (state == RADIOLIB_ERR_NONE) { Serial.println("Message sent successfully!"); } else { Serial.print("Failed to send message, code: "); Serial.println(state); } delay(uplinkIntervalSeconds * 1000UL); // delay needs milli-seconds } void loopThatAlsoNotWorks() { // 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; 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_ERR_NONE, F("Error in sendReceive"), state, false); // Check if a downlink was received // (state 0 = no downlink, state 1/2 = downlink in window Rx1/Rx2) if (state > 0) { Serial.println(F("Received a downlink")); } else { Serial.println(F("No downlink received")); } Serial.print(F("Next uplink in ")); Serial.print(uplinkIntervalSeconds); Serial.println(F(" seconds\n")); // Wait until next uplink - observing legal & TTN FUP constraints delay(uplinkIntervalSeconds * 1000UL); // delay needs milli-seconds }

Expected behavior I expect an uplink message in Helium-IoT console.

Additional info (please complete):

StevenCellist commented 1 month ago

radio.transmit() indeed does not work here - none of the (LoRaWAN) examples even mention this. node.sendReceive() is the way to go. But then I don't see your function loopThatAlsoNotWorks() being called, so it looks like your code doesn't even attempt this. Can you share what happens when you use this function instead?

predictitai commented 1 month ago

Thank you for your quick response! Just to be sure I will send you the complete log; joinrequest and joinaccept i see in the log. But no uplink message. When i use my frequency analyzer i notice that the message actually been send by the device. I get "No downlink received", which probably makes sense as the message has not been received by Helium IOT. Hope you can advice me!

LoRaWAN Debug Log


Initialise the radio
RLB_DBG: RadioLib Info Version: "7.1.0.0" Platform: "ESP32" Compiled: "Oct 31 2024" "13:29:29"
RLB_DBG: Found SX126x: RADIOLIB_SX126X_REG_VERSION_STRING:
RLB_DBG: 00000320: 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00 SX1261 V2D 2D02.

RLB_DBG:
RLB_DBG: M SX126x Join ('login') the LoRaWAN Network
RLB_PRO: Setting up dynamic channels
RLB_PRO: UL: 0 1 868.100 (0 - 5) | DL: 0 1 868.100 (0 - 5)
RLB_PRO: UL: 1 1 868.300 (0 - 5) | DL: 1 1 868.300 (0 - 5)
RLB_PRO: UL: 2 1 868.500 (0 - 5) | DL: 2 1 868.500 (0 - 5)

RLB_PRO: [MAC] 0x03
RLB_PRO: 00000000: 20
RLB_PRO: LinkAdrReq: dataRate = 2, txSteps = 0, nbTrans = 0
RLB_PRO: LinkAdrAns: 07

RLB_PRO: [MAC] 0x04
RLB_PRO: 00000000: 07 .

RLB_PRO: DutyCycleReq: max duty cycle = 1/2^7

RLB_PRO: [MAC] 0x05
RLB_PRO: 00000000: 00 d2 ad 84 ....

RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq = 869.525

RLB_PRO: [MAC] 0x08
RLB_PRO: 00000000: 01 .

RLB_PRO: RXTimingSetupReq: delay = 1 sec

RLB_PRO: [MAC] 0x09
RLB_PRO: 00000000: 05 .

RLB_PRO: [MAC] 0x0c
RLB_PRO: 00000000: 65 e

RLB_PRO: ADRParamSetupReq: limitExp = 6, delayExp = 5

RLB_PRO: [MAC] 0x0f
RLB_PRO: 00000000: fa .

RLB_PRO: RejoinParamSetupReq: maxTime = 15, maxCount = 10

RLB_PRO:
RLB_PRO: PHY: Frequency = 868.100 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U
RLB_DBG: Timeout in 1853 ms

RLB_PRO: JoinRequest sent (DevNonce = 17386) <-- Rx Delay start
RLB_PRO: 00000000: 00 64 bf 97 76 8d 2a 9b b0 e7 16 5d a4 c2 ba e7 .d..v.*....]....
RLB_PRO: 00000010: ba ea 43 44 51 a8 e3 ..CDQ..

RLB_PRO:
RLB_PRO: PHY: Frequency = 868.100 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: D
RLB_PRO: Opening Rx1 window (331 ms timeout)... <-- Rx Delay end
RLB_PRO: Closing Rx1 window

RLB_PRO: JoinAccept (JoinNonce = 50, previously 0):
RLB_PRO: 00000000: 20 32 00 00 24 00 00 1d 08 00 48 80 01 18 4f 84 2..$.....H...O.
RLB_PRO: 00000010: e8 56 84 b8 5e 84 88 66 84 58 6e 84 00 b5 21 2a .V..^..f.Xn...!*
RLB_PRO: 00000020: bb .

RLB_PRO: LoRaWAN revision: 1.1
RLB_PRO: Setting up dynamic channels
RLB_PRO: UL: 0 1 868.100 (0 - 5) | DL: 0 1 868.100 (0 - 5)
RLB_PRO: UL: 1 1 868.300 (0 - 5) | DL: 1 1 868.300 (0 - 5)
RLB_PRO: UL: 2 1 868.500 (0 - 5) | DL: 2 1 868.500 (0 - 5)

RLB_PRO: [MAC] 0x05
RLB_PRO: 00000000: 00 d2 ad 84 ....

RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq = 869.525

RLB_PRO: [MAC] 0x08
RLB_PRO: 00000000: 01 .

RLB_PRO: RXTimingSetupReq: delay = 1 sec

RLB_PRO: Processing CFList

RLB_PRO: [MAC] 0x07
RLB_PRO: 00000000: 03 18 4f 84 50 ..O.P
RLB_PRO: UL: 3 1 867.100 (0 - 5) | DL: 3 1 867.100 (0 - 5)

RLB_PRO: [MAC] 0x07
RLB_PRO: 00000000: 04 e8 56 84 50 ..V.P
RLB_PRO: UL: 4 1 867.300 (0 - 5) | DL: 4 1 867.300 (0 - 5)

RLB_PRO: [MAC] 0x07
RLB_PRO: 00000000: 05 b8 5e 84 50 ..^.P
RLB_PRO: UL: 5 1 867.500 (0 - 5) | DL: 5 1 867.500 (0 - 5)

RLB_PRO: [MAC] 0x07
RLB_PRO: 00000000: 06 88 66 84 50 ..f.P
RLB_PRO: UL: 6 1 867.700 (0 - 5) | DL: 6 1 867.700 (0 - 5)

RLB_PRO: [MAC] 0x07
RLB_PRO: 00000000: 07 58 6e 84 50 .Xn.P
RLB_PRO: UL: 7 1 867.900 (0 - 5) | DL: 7 1 867.900 (0 - 5)

Connected to the network!

Sending uplink
RLB_PRO: Uplink MAC payload:
RLB_PRO: 00000000: 0b 01 ..

RLB_PRO: Uplink (FCntUp = 0) decoded:
RLB_PRO: 00000000: 1d 08 e5 00 00 78 56 ad 4c c3 ce 3f 17 00 00 00 .....xV.L..?....
RLB_PRO: 00000010: 40 1d 08 00 48 82 00 00 3b ff 01 35 22 55 56 ad @...H...;..5"UV.
RLB_PRO: 00000020: 4c c3 L.

RLB_PRO:
RLB_PRO: PHY: Frequency = 867.100 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U
RLB_DBG: Timeout in 1648 ms

RLB_PRO: Uplink sent <-- Rx Delay start

RLB_PRO:
RLB_PRO: PHY: Frequency = 867.100 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: D
RLB_PRO: Opening Rx1 window (331 ms timeout)... <-- Rx Delay end
RLB_PRO: Closing Rx1 window

RLB_PRO:
RLB_PRO: PHY: Frequency = 869.525 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 12, BW = 125.0 kHz, CR = 4/5, IQ: D
RLB_PRO: Opening Rx2 window (788 ms timeout)... <-- Rx Delay end
RLB_PRO: Closing Rx2 window

No downlink received
Next uplink in 300 seconds
predictitai commented 1 month ago

Further packets i see the FCntUp increasing; but in the console the number of uplinks remains 0:

Additional LoRaWAN Debug Log


Sending uplink
RLB_PRO: Uplink (FCntUp = 1) decoded:
RLB_PRO: 00000000: 1d 08 e5 00 00 78 56 ad 4c c3 ce 3f 17 00 00 00  .....xV.L..?....
RLB_PRO: 00000010: 40 1d 08 00 48 80 01 00 01 53 43 68 21 78 56 ad  @...H....SCh!xV.

RLB_PRO: PHY: Frequency = 868.100 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U
RLB_DBG: Timeout in 1648 ms

RLB_PRO: Uplink sent <-- Rx Delay start

RLB_PRO: PHY: Frequency = 868.100 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: D
RLB_PRO: Opening Rx1 window (331 ms timeout)... <-- Rx Delay end
RLB_PRO: Closing Rx1 window

RLB_PRO: PHY: Frequency = 869.525 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 12, BW = 125.0 kHz, CR = 4/5, IQ: D
RLB_PRO: Opening Rx2 window (788 ms timeout)... <-- Rx Delay end
RLB_PRO: Closing Rx2 window

No downlink received
Next uplink in 300 seconds

Sending uplink
RLB_PRO: Uplink (FCntUp = 2) decoded:
RLB_PRO: 00000000: 1d 08 e5 00 00 78 56 ad 4c c3 ce 3f 17 00 00 00  .....xV.L..?....
RLB_PRO: 00000010: 40 1d 08 00 48 80 02 00 01 16 36 3d 21 78 56 ad  @...H.....6=!xV.

RLB_PRO: PHY: Frequency = 867.300 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U
RLB_DBG: Timeout in 1648 ms

RLB_PRO: Uplink sent <-- Rx Delay start

RLB_PRO: PHY: Frequency = 867.300 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: D
RLB_PRO: Opening Rx1 window (331 ms timeout)... <-- Rx Delay end
RLB_PRO: Closing Rx1 window

RLB_PRO: PHY: Frequency = 869.525 MHz, TX = 16 dBm
RLB_PRO: LoRa: SF = 12, BW = 125.0 kHz, CR = 4/5, IQ: D
RLB_PRO: Opening Rx2 window (788 ms timeout)... <-- Rx Delay end
RLB_PRO: Closing Rx2 window

No downlink received
Next uplink in 300 seconds
HeadBoffin commented 1 month ago

Are you in credit - ie you have pre-paid to be able to receive the uplink?

predictitai commented 4 weeks ago

i have 196 data credits but I am not sure whether that is sufficient for uplinks. I wrote an email to Helium IOT about this issue. Thanks and i will keep you informed.

disk91 commented 4 weeks ago

A much I can see (on the operator side) , the device uplink is not received and does not generate error. The credits are OK, the join request seems to be a success according to the log. Can you see in the log the devaddr used and the nework key to verify it ?

predictitai commented 4 weeks ago

For security reasons i am going to change dev id, app key and nwkkey later but just for your information: I have set this in config.h // 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 0xb09b2a8d7697bf64

// the Device EUI & two keys can be generated on the TTN console

ifndef RADIOLIB_LORAWAN_DEV_EUI // Replace with your Device EUI

Screenshot 2024-11-01 at 14 50 56

define RADIOLIB_LORAWAN_DEV_EUI 0xbae7bac2a45d16e7

endif

ifndef RADIOLIB_LORAWAN_APP_KEY // Replace with your App Key

define RADIOLIB_LORAWAN_APP_KEY 0x09, 0x70, 0x2B, 0x09, 0x40, 0x15, 0x03, 0xA0, 0xB2, 0x07, 0x50, 0x79, 0x05, 0x70, 0x5A, 0x07

endif

ifndef RADIOLIB_LORAWAN_NWK_KEY // Put your Nwk Key here

define RADIOLIB_LORAWAN_NWK_KEY 0x0C, 0x70, 0x37, 0x04, 0x40, 0x92, 0x0B, 0x70, 0x0A, 0x05, 0x00, 0x47, 0x08, 0xD0, 0x99, 0x00

endif

Screenshot 2024-11-01 at 14 43 38

In the attachment you can see a screendump of the settings from Helium console. And yes I also asked my friend chatgpt to double confirm the settings are correct.

disk91 commented 4 weeks ago

Your deveui / appeui / appkey is ok, or you won't get a join accept This is why I'm asking to control the devaddr and the nwkSkey used by the device to make sure it corresponds to what you see in chirpsatck in the Ativation Session.

Note: I can see you detail myself in the console so don't need to copy here. But I can't see if this is matching the device one.

StevenCellist commented 4 weeks ago

According to the logs above, the DevAddr of that session is (was) 0x4800081D. The NwkSEncKey is not available from the logs.

StevenCellist commented 4 weeks ago

@predictitai it might be useful if you can provide logs with millisecond-timestamps enabled in your terminal. That way we can see if the timing of the internals is as we'd expect. I do not see a real reason why it would be off, but who knows.

predictitai commented 4 weeks ago

@StevenCellist I added the following lines in my code: RADIOLIB_DEBUG_PROTOCOL_PRINTLN("devAddr: %d", this->devAddr ); RADIOLIB_DEBUG_PROTOCOL_PRINTLN("appSKey: %d", this->appSKey ); RADIOLIB_DEBUG_PROTOCOL_PRINTLN("nwkSEncKey: %d", this->nwkSEncKey ); RADIOLIB_DEBUG_PROTOCOL_PRINTLN("fNwkSIntKey: %d", this->fNwkSIntKey ); RADIOLIB_DEBUG_PROTOCOL_PRINTLN("sNwkSIntKey: %d", this->sNwkSIntKey );

Just to be certain that the session data matches. I am currently at a location without helium reach so I will have to do the actual tests tonight. Thanks for your support so far!

StevenCellist commented 4 weeks ago

@predictitai that will not work the way you hope it will; please make these changes by inserting the following lines in the whitespace here (in protocols/LoRaWAN/LoRaWAN.cpp):

https://github.com/jgromes/RadioLib/blob/4564d87721997917c567f75c2078106ee92e757a/src/protocols/LoRaWAN/LoRaWAN.cpp#L961-L963

RADIOLIB_DEBUG_PROTOCOL_PRINTLN("DevAddr: %08lx", this->devAddr );
RADIOLIB_DEBUG_PROTOCOL_PRINTLN("AppSKey, NwkSEncKey, FNwkSIntKey, SNwkSIntKey:");
RADIOLIB_DEBUG_PROTOCOL_HEXDUMP(this->appSKey, 16);
RADIOLIB_DEBUG_PROTOCOL_HEXDUMP(this->nwkSEncKey, 16);
RADIOLIB_DEBUG_PROTOCOL_HEXDUMP(this->fNwkSIntKey, 16);
RADIOLIB_DEBUG_PROTOCOL_HEXDUMP(this->sNwkSIntKey, 16);
predictitai commented 4 weeks ago

@StevenCellist so with your code you provided this is the log i got:

RLB_PRO: DevAddr: 4800096a RLB_PRO: AppSKey, NwkSEncKey, FNwkSIntKey, SNwkSIntKey: RLB_PRO: 00000000: 4d d1 c7 ec 79 be 6d d3 90 ba e2 b7 bc 4b 2f 20 M...y.m......K/ RLB_PRO: 00000000: d0 68 56 7a 5d 6f 46 2f 57 57 8a ed 31 51 08 38 .hVz]oF/WW..1Q.8 RLB_PRO: 00000000: 72 2e 7e af 17 cf 5a 00 a7 53 96 c6 0b c6 24 99 r.~...Z..S....$. RLB_PRO: 00000000: a9 c0 1a 25 14 42 f3 97 44 90 7b 63 0f 50 7b f0 ...%.B..D.{c.P{.

And so if i go to helium console, activation tab i can confirm I see exactly the same data here!

StevenCellist commented 4 weeks ago

Not much of a surprise, but confirmation is good. Next useful thing is to enable timestamps in your terminal and have your device do a join + one or two uplinks and paste the output here. That way we can verify whether the timing also makes sense.

predictitai commented 3 weeks ago

@StevenCellist So i kind of fixed the problem by accident. I used Lorawan 1.1.0 but if i switch back to 1.0.4 i do get up- and downlinks. Confusing part is that in the documentation it is recommended to set it to 1.1.0 https://github.com/jgromes/RadioLib/wiki/LoRaWAN:-Device-setup-on-TTN. So i am not sure if it was intended or a glitch but 1.1.0 doesn't seem to be working yet....

StevenCellist commented 3 weeks ago

Interesting, so it looks like the new Helium server still is unable to handle LoRaWAN 1.1. @disk91 can you brief us on this?

disk91 commented 3 weeks ago

You need to setup chirpstack device profile and device to the same version. I don't know what was your previous test versions. It's good to know a such difference can bring no error message and no messages received.

Can you please details what was the device + device profile version setup when not working and what is once working please ?

predictitai commented 3 weeks ago

I got it to work with lorawan 1.0.4 revision B and then it works (though the nwkkey seem to have disappeared). Previously i setup lorawan 1.1.0 revision A (including the nwkkey) but no uplink/downlink messages. I use the T-Deck plus (which is esp32) and noticed that in Radiolib you can set the version to 1.0 or 1.1 (uint8_t rev = 0;) but you cannot set the revision anywhere on the device.

I tried all combinations of 1.1.0 and all revisions but none seems to generate an uplink or downlink (or error for that matter). The only version that works find for me is 1.0.4 revision B.

Please let me know if you need any additional information or further testing.

StevenCellist commented 3 weeks ago

I noticed that in Radiolib you can set the version to 1.0 or 1.1 (uint8_t rev = 0;)

Did you really modify this yourself?

predictitai commented 3 weeks ago

@StevenCellist Yes I see now that it is supposed to be set by the network. So this basically means that you only have to set version and revision in Helium settings and that you don't have to do anything on the device am i correct?

StevenCellist commented 3 weeks ago

That is correct. As you noticed, v1.1 has a NwkKey while 1.0.4 doesn't. So that, along with some magic from the JoinAccept, is enough information for RadioLib to figure out what version and encryption it should use.

So, while you re-test 1.1.0 without any modifications to RadioLib (although maybe keep the key dumps in there) and provide us your NwkKey alongside, please tell us why you thought you'd had to modify the internals - it's useful information so we can hopefully prevent others from doing so.

predictitai commented 3 weeks ago

@StevenCellist I was in the assumption that bother server and device had to use exactly the same lorawan version in order to function properly. I couldn't find in the code where the detection of version and revision was being done; but that could be my mistake.

Anyhow I reverted all code and set the scanguard to 50 again. At platformio.ini i added monitor_filters = time, esp8266_exception_decoder I set in helium 1.1.0 revision B.

Reconnecting to /dev/cu.usbmodem1101 . Connected! 13:54:31.901 > 13:54:31.901 > Setup ... 13:54:31.901 > Initialise the radio 13:54:31.901 > RLB_DBG: 13:54:31.901 > RadioLib Info 13:54:31.901 > Version: "7.1.0.0" 13:54:31.901 > Platform: "ESP32" 13:54:31.901 > Compiled: "Nov 4 2024" "13:29:51" 13:54:31.914 > RLB_DBG: Found SX126x: RADIOLIB_SX126X_REG_VERSION_STRING: 13:54:31.914 > RLB_DBG: 00000320: 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00 SX1261 V2D 2D02. 13:54:31.914 > RLB_DBG: 13:54:31.914 > RLB_DBG: M SX126x 13:54:31.952 > Join ('login') the LoRaWAN Network 13:54:31.952 > RLB_PRO: Setting up dynamic channels 13:54:31.952 > RLB_PRO: UL: 0 1 868.100 (0 - 5) | DL: 0 1 868.100 (0 - 5) 13:54:31.952 > RLB_PRO: UL: 1 1 868.300 (0 - 5) | DL: 1 1 868.300 (0 - 5) 13:54:31.952 > RLB_PRO: UL: 2 1 868.500 (0 - 5) | DL: 2 1 868.500 (0 - 5) 13:54:31.952 > RLB_PRO: [MAC] 0x03 13:54:31.952 > RLB_PRO: 00000000: 20
13:54:31.952 > RLB_PRO: LinkAdrReq: dataRate = 2, txSteps = 0, nbTrans = 0 13:54:31.953 > RLB_PRO: LinkAdrAns: 07 13:54:31.953 > RLB_PRO: [MAC] 0x04 13:54:31.953 > RLB_PRO: 00000000: 07 .
13:54:31.953 > RLB_PRO: DutyCycleReq: max duty cycle = 1/2^7 13:54:31.953 > RLB_PRO: [MAC] 0x05 13:54:31.953 > RLB_PRO: 00000000: 00 d2 ad 84 ....
13:54:31.953 > RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq = 869.525 13:54:31.961 > RLB_PRO: [MAC] 0x08 13:54:31.961 > RLB_PRO: 00000000: 01 .
13:54:31.961 > RLB_PRO: RXTimingSetupReq: delay = 1 sec 13:54:31.961 > RLB_PRO: [MAC] 0x09 13:54:31.961 > RLB_PRO: 00000000: 05 .
13:54:31.961 > RLB_PRO: [MAC] 0x0c 13:54:31.961 > RLB_PRO: 00000000: 65 e
13:54:31.961 > RLB_PRO: ADRParamSetupReq: limitExp = 6, delayExp = 5 13:54:31.961 > RLB_PRO: [MAC] 0x0f 13:54:31.961 > RLB_PRO: 00000000: fa .
13:54:31.961 > RLB_PRO: RejoinParamSetupReq: maxTime = 15, maxCount = 10 13:54:32.031 > RLB_PRO: 13:54:32.031 > RLB_PRO: PHY: Frequency = 868.100 MHz, TX = 16 dBm 13:54:32.033 > RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U 13:54:32.034 > RLB_DBG: Timeout in 1853 ms 13:54:32.411 > RLB_PRO: JoinRequest sent (DevNonce = 54720) <-- Rx Delay start 13:54:32.412 > RLB_PRO: 00000000: 00 2b 1a 0f 9e 8d 7c 6b 5a a6 b7 e8 d9 f1 a2 c3 .+....|kZ....... 13:54:32.412 > RLB_PRO: 00000010: b4 c0 d5 55 d9 2c fb ...U.,.
13:54:32.412 > RLB_PRO: 13:54:32.413 > RLB_PRO: PHY: Frequency = 868.100 MHz, TX = 16 dBm 13:54:32.414 > RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: D 13:54:37.407 > RLB_PRO: Opening Rx1 window (231 ms timeout)... <-- Rx Delay end 13:54:37.638 > RLB_PRO: Closing Rx1 window 13:54:37.855 > RLB_PRO: JoinAccept (JoinNonce = 29, previously 0): 13:54:37.855 > RLB_PRO: 00000000: 20 1d 00 00 24 00 00 6d 09 00 48 80 01 18 4f 84 ...$..m..H...O. 13:54:37.856 > RLB_PRO: 00000010: e8 56 84 b8 5e 84 88 66 84 58 6e 84 00 6d 99 0a .V..^..f.Xn..m.. 13:54:37.856 > RLB_PRO: 00000020: 51 Q
13:54:37.856 > RLB_PRO: LoRaWAN revision: 1.1 13:54:37.857 > RLB_PRO: Setting up dynamic channels 13:54:37.857 > RLB_PRO: UL: 0 1 868.100 (0 - 5) | DL: 0 1 868.100 (0 - 5) 13:54:37.858 > RLB_PRO: UL: 1 1 868.300 (0 - 5) | DL: 1 1 868.300 (0 - 5) 13:54:37.858 > RLB_PRO: UL: 2 1 868.500 (0 - 5) | DL: 2 1 868.500 (0 - 5) 13:54:37.858 > RLB_PRO: [MAC] 0x05 13:54:37.858 > RLB_PRO: 00000000: 00 d2 ad 84 ....
13:54:37.858 > RLB_PRO: RXParamSetupReq: Rx1DrOffset = 0, rx2DataRate = 0, freq = 869.525 13:54:37.859 > RLB_PRO: [MAC] 0x08 13:54:37.859 > RLB_PRO: 00000000: 01 .
13:54:37.859 > RLB_PRO: RXTimingSetupReq: delay = 1 sec 13:54:37.859 > RLB_PRO: Processing CFList 13:54:37.859 > RLB_PRO: [MAC] 0x07 13:54:37.859 > RLB_PRO: 00000000: 03 18 4f 84 50 ..O.P
13:54:37.860 > RLB_PRO: UL: 3 1 867.100 (0 - 5) | DL: 3 1 867.100 (0 - 5) 13:54:37.860 > RLB_PRO: [MAC] 0x07 13:54:37.860 > RLB_PRO: 00000000: 04 e8 56 84 50 ..V.P
13:54:37.861 > RLB_PRO: UL: 4 1 867.300 (0 - 5) | DL: 4 1 867.300 (0 - 5) 13:54:37.861 > RLB_PRO: [MAC] 0x07 13:54:37.861 > RLB_PRO: 00000000: 05 b8 5e 84 50 ..^.P
13:54:37.861 > RLB_PRO: UL: 5 1 867.500 (0 - 5) | DL: 5 1 867.500 (0 - 5) 13:54:37.861 > RLB_PRO: [MAC] 0x07 13:54:37.861 > RLB_PRO: 00000000: 06 88 66 84 50 ..f.P
13:54:37.862 > RLB_PRO: UL: 6 1 867.700 (0 - 5) | DL: 6 1 867.700 (0 - 5) 13:54:37.862 > RLB_PRO: [MAC] 0x07 13:54:37.862 > RLB_PRO: 00000000: 07 58 6e 84 50 .Xn.P
13:54:37.863 > RLB_PRO: UL: 7 1 867.900 (0 - 5) | DL: 7 1 867.900 (0 - 5) 13:54:37.864 > Connected to the network! 13:54:37.864 > Sending uplink 13:54:38.001 > RLB_PRO: Uplink MAC payload: 13:54:38.001 > RLB_PRO: 00000000: 0b 01 ..
13:54:38.070 > RLB_PRO: Uplink (FCntUp = 0) decoded: 13:54:38.070 > RLB_PRO: 00000000: 1d 08 e5 00 00 78 56 ad 4c c3 ce 3f 17 00 00 00 .....xV.L..?.... 13:54:38.070 > RLB_PRO: 00000010: 40 6d 09 00 48 82 00 00 0c 29 01 b7 30 ed 56 ad @m..H....)..0.V. 13:54:38.070 > RLB_PRO: 00000020: 4c c3 L.
13:54:38.072 > RLB_PRO: 13:54:38.073 > RLB_PRO: PHY: Frequency = 867.700 MHz, TX = 16 dBm 13:54:38.074 > RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: U 13:54:38.075 > RLB_DBG: Timeout in 1648 ms 13:54:38.412 > RLB_PRO: Uplink sent <-- Rx Delay start 13:54:38.412 > RLB_PRO: 13:54:38.412 > RLB_PRO: PHY: Frequency = 867.700 MHz, TX = 16 dBm 13:54:38.414 > RLB_PRO: LoRa: SF = 10, BW = 125.0 kHz, CR = 4/5, IQ: D 13:54:39.407 > RLB_PRO: Opening Rx1 window (231 ms timeout)... <-- Rx Delay end 13:54:39.638 > RLB_PRO: Closing Rx1 window 13:54:39.639 > RLB_PRO: 13:54:39.639 > RLB_PRO: PHY: Frequency = 869.525 MHz, TX = 16 dBm 13:54:39.640 > RLB_PRO: LoRa: SF = 12, BW = 125.0 kHz, CR = 4/5, IQ: D 13:54:40.407 > RLB_PRO: Opening Rx2 window (688 ms timeout)... <-- Rx Delay end 13:54:41.096 > RLB_PRO: Closing Rx2 window 13:54:41.096 > No downlink received 13:54:41.096 > Next uplink in 300 seconds

predictitai commented 3 weeks ago

@StevenCellist I updated the code (see previous mail); i received a downlink at my location here. If you need any further info please let me know.

StevenCellist commented 3 weeks ago

Given the poor reach of your device apparently, as it often fails to join, have you considered the possibility that none of the uplinks is heard due to signal strength? Do you have access to a Helium gateway yourself so you can check what happens on the gateway?

Also, there's an oddity that occurs when you don't receive the JoinAccept, as it looks like a DIO is not fired correctly / at the right time. Please double-check your radio wiring. And what happens when you don't modify the scanGuard?

As I don't have any Helium credits, don't aspire to buy any, and I also don't know if I even have Helium coverage here, there is no possibility for me to replicate this with the Helium server. The best action you can take is to try and have your device join The Things Network (now known as Stack Sandbox instead of Network).

disk91 commented 3 weeks ago

@StevenCellist As much as I've seen the signal is good for transmitting the Join Request, I can't say if the join accept is received. We can easily investigate the Join Request signal if required. (sometime, problem on join accept is also to to signal streingh too high)

If you want to do some trial on helium-iot you have 500 credit for free, and I'll be happy to credit you more for this kind of debugging purpose, just let me know with a DM / Service request on the platform.

StevenCellist commented 3 weeks ago

@disk91 where can I check if there's supposed to be coverage around for this helium-iot network? Honestly no clue which website to look at as there are multiple now, it appears.

disk91 commented 3 weeks ago

have a look at mapper : https://mappers.helium.com/ if the area is not mapped you can have a look at https://explorer.moken.io to see where the hotspot are

predictitai commented 3 weeks ago

@StevenCellist I just tested it with the standard scanguard of 10 which also seem to be working fine so i set it back to its default value. I actually wanted to buy a gateway but for some reason they are quite expensive and i will only do that once i am 100 procent confident helium is suitable for the applications i have in mind.

As for the DIO issue i forwarded this to Lilygo as i don't see anything that could cause any issues as i am using basic examples.

At my home my helium coverage but around the city i have good network. So i am pretty confident it has nothing to do with the coverage cause where ever i go i don't see any uplinks and/or downlinks.

I will test it out on the TTN platform this evening.

disk91 commented 3 weeks ago

@predictitai you can use a standard gateway with helium, connecting it to a gateway-rs service or enabling local gateway-rs selecting a helium data only hardware.

Usually data only are at the same price than a classical gateway. Look at Seed and Rak light gateways if you want to mine at a low cost or data only gateway if you don't want no mine.