(4)I’ve read downlink problems can be solved by extending the RX1/RX2 length. How can I do that?
Hi, Abe-san,
In my experience,the number of times is more important than the RX1/RX2 length.
There is a great deal of variation in the time it takes for the gateway to throw Join Request to the TTN server and receive Join Accept.
.(At least in my enviroment it’s not a level to extend the RX1/2 length, and in most cases Join Accept has not reached in RX1/2 correspoding to Join Request.)
Therefore, the Gateway that received Join Accept after RX1/2 has waiting for the timing RX1/2 that its own station can transmit next.
If.possible, the End device will send empty frame that does not affect the OTAA authentication process and the Gateway will get the timing to send the Join Accept. I dit that.
(The other method is for the End device to send another Join Request to receive Join Accept, but the Join Accept that can be received at that time is for the old Join Request and is confusing, so I stopped it.)
Please forgive me if there is a lack of understanding.
Thank you.
That should not be causing issues; if it is, the gateway needs a lower latency internet connection.
If.possible, the End device will send empty frame that does not affect the OTAA authentication process and the Gateway will get the timing to send the Join Accept.
No, that’s not workable. The join accept can only be sent in direct response to the join request, not in response anything else.
Provided it is the right frequency radio module, this would be an issue of software not hardware.
As I was explaining before, this is one of the test platforms for MCCI LMiC, who have some past experience in Japan, and also have the ability to conduct “closed” tests on LoRaWAN operation in one country, even while sitting in another.
Today I realized my Conduit does NOT respond to Join Request within RX1/RX2 time.
When OTAA Joining fails Conduit does NOT respond within above 1s after receiving Join Request. When OTAA succeeds Conduit does respond.
Here is a screenshot from my TTN console.
These are the problems I found.
(1)In #1 Jon Request is received by GW at 20:58:52. But Jon Accept was sent from GW at 20:58:56. It takes 4s. Can not respond within RX1/RX2.
(2)In #2 why does the GW respond with 924.4MHz frequency? According to LoRaWAN™ 1.0.3 Specification, section 3.3.1, the first receive window RX1 uses a frequency that is a function of the uplink frequency and a data rate that is a function of the data rate used for the uplink. I’m not sure 924.4MHz in Join Accept is OK or not. Please tell me.
When OTAA succeeds Join Accept is sent from the GW immediately after Join Request with the same frequency as the frequency of Join Request.
Except RX1/RX2 is for downlinks, if you look at your first screen shot above, you’ll see the join delay is 5s and 6s - presumably this will be sent in the second window when the gateway gets it.
Your picture shows your node seemingly transmitting pairs of join requests at different frequencies impossibly close in time.
The 924.4 MHz responses are legitimate responses to one of those, but you’re getting confused because you are looking at the other copy on a different frequency.
Now of course, what is actually happening is not the node transmitting twice. Rather, your node is too close to your gateway causing it to be overloaded and bleedover into additional fictitious signals on channels it did not actually transmit on.
Move your node further away from the gateway, and make sure that the log is only showing one join attempt or uplink with a given timestamp, not two.
