I am using the RAK7244 with ChirpStack and the US915 channel plan. I’m having some problems in the OTA Join process.
When my device makes a join request, the gateway answers immediately instead of waiting 5 seconds. I can confirm that ChirpStack is sending a successful join response and that the response contains a 5 second delay field.
Why is the gateway not delaying the join response for 5 seconds as directed by ChirpStack?
Thanks,
KeithHello. Can you share the versions of the Packet Forwarder and ChirpStack NS and AS. The Gateway can not answer if there is no response from the NS and AS.
@Keith
Please refer to the following steps to start the lora_pkt_fwd process to the foreground.
sudo systemctl stop ttn-gatewaycd /opt/ttn-gateway/packet_forwarder/lora_pkt_fwdsudo ./lora_pkt_fwdAfter opening the gateway process to the foreground, and then the node rejoins, you will see the following log at the gateway foreground,
The gateway will immediately receive the join accept of chirpstack, but the gateway will send the join accept to the node after a certain delay.
You can send your printed information to me.
ZhuQI:
Thank you for your response. Here are my results. As you can see, there is no 5 second delay.
The log seems to properly indicate the 5 second delay in the difference of timestamps.
You won’t see a message at the actual time of transmission appearing in the packet forwarder log, because the timing of the transmission is done by a counter in the hardware of the SX130x chip that counts up to the programmed packet time. At most, in some later generation packet forwarder programs you might get a message when a packet is moved from a software “jit queue” to the single-packet hardware buffer (which would happen when it becomes clear that nothing else can need to go out first) but not necessarily. Simpler/older versions of the forwarder code just load packets into the hardware immediately as they are received over the backhaul without implementing a software queue to re-sort them in order of actual transmit time. That really only makes a difference in the case where you have something like a normal 1-second uplink/downlink cycle from a different node popping up in the middle of a 5-second join/accept cycle, which is not happening here.
If you want to really see what is going on, see if you can get a scope probe on the gateway transmit LED and modify your node firmware to blip a GPIO at the start and end of the uplink packet and receive window. Trigger on the node transmission and then see where the gateway activity falls on the other scope channel, and then where the node’s receive window is falling relative to that.
I’d suspect though that the problem is either receive window timing on the node end, or a mismatch of identity/key causing the node to be unable to use a response if it is actually receiving one.
