Closed LakinduBabySoap closed 3 months 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.
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 ;-)
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.
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.
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!
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).
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.
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).
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.
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.
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.
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.
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
Seems to be resolved, so closing
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
Config.h
Hardware setup The controller that I am using. (I am using the SX1276, 923Mhz)
Debug mode output
Additional info (please complete):
Thank you to anyone who can help me! Really appreciate it!