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
Comments
|
|
|
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. LoRaWAN Debug Log |
|
Further packets i see the FCntUp increasing; but in the console the number of uplinks remains 0: Additional LoRaWAN Debug Log |
|
Are you in credit - ie you have pre-paid to be able to receive the uplink? |
|
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. |
|
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 ? |
|
For security reasons i am going to change dev id, app key and nwkkey later but just for your information: // the Device EUI & two keys can be generated on the TTN console #define RADIOLIB_LORAWAN_DEV_EUI 0xbae7bac2a45d16e7
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. |
|
Your deveui / appeui / appkey is ok, or you won't get a join accept 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. |
|
According to the logs above, the DevAddr of that session is (was) 0x4800081D. The NwkSEncKey is not available from the logs. |
|
@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. |
|
@StevenCellist I added the following lines in my code: RADIOLIB_DEBUG_PROTOCOL_PRINTLN("devAddr: %d", this->devAddr ); 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! |
|
@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): RadioLib/src/protocols/LoRaWAN/LoRaWAN.cpp Lines 961 to 963 in 4564d87 |
|
@StevenCellist so with your code you provided this is the log i got: RLB_PRO: DevAddr: 4800096a And so if i go to helium console, activation tab i can confirm I see exactly the same data here! |
|
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. |
|
@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. |
|
Interesting, so it looks like the new Helium server still is unable to handle LoRaWAN 1.1. |
|
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 ? |
|
I got it to work with lorawan 1.0.4 revision B and then it works (though the nwkkey seem to have disappeared). 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. |
Did you really modify this yourself? |
|
@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? |
|
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. |
|
@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 Reconnecting to /dev/cu.usbmodem1101 . Connected! |
|
@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. |
|
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). |
|
@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. |
|
@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. |
|
have a look at mapper : https://mappers.helium.com/ |
|
@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. |
|
@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. |
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()
{
}
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);
}
Expected behavior
I expect an uplink message in Helium-IoT console.
Additional info (please complete):
The text was updated successfully, but these errors were encountered: