OTAA Issue due to delay

Hi guys!

I’m facing a issue, when i’m trying to connect several differents nodes in OTAA,it’s never works :confused:
I have investigate in the differentsl logs in the lora_pkt_fwd, and i can see that the JoinAccept message is send.

But i think that he is sending to quickly: If i check the logs in the web Api i can see that the JoinAccept is send immediatly:

I was thinking that the JoinAccept was supposed to be equal to 5 seconds.

Any Ideas? :slight_smile:

I think it is, you have to look in the uplink and downlink meta-data timestamp field.

at the packet_forwarder?

It is displayed in the UI (last screenshot, you have to expand the meta-data). Please note that LoRa Server schedules the frame in advance to the gateway and that the gateway will keep a queue of frames to be transmitted. So a frame sent to the gateway does not mean it is instantly transmitted.

Sorry for the delay,
Ok i have add the metadata and the difference between the tx and the rx is equal to 5000000, i supposed it’s the 5 seconds delay.

But when i reading the pkt_fwd i can see this:

Does it mean that the tx packet is send with an other delay equal to 1495 seconds/ticks?

Should the pkt_fwd and lora-app-server start at the same time to the lora-app-server, to prevent timestamp issues?.

In fact i’m using the ic880a with an usb to spi adaptater, the C232HM from FTDI and working with 1MhZ frequency on the spi, 8Mhz is not stable.

All the spi logs looks good, but i’m asking myself if the tx is working or not, even in abp i’m not so sure if the tx works, i have try in confirmed and unconfirmed transmission. The logs looks good, but any of my sensor get the message.

And the leds on my ic880a never toggle :confused: only the power one is on.

Thanks :slight_smile:

after few investigation: i have add the hal debug logs in the packet_forwarder and the lgw_send function is never called :confused:
any ideas?

You might want to upgrade your packet-forwarder on the gateway. The overwrite warning looks like it is outdated as the latest version implements a just-in-time queue.


my packet_forwarder is 4.0.1 and libloragw is 5.0.1
I think that they are the latest updates

Well, new update:

After few try, i can’t connect in OTAA or in ABP, my nodes never get the messages :cry:
When i check the logs i’m lost:

I receive some UnconfirmedData and still my app-server automatically reply with a UnconfirmedData !!!
And the delay between the up and the down is always equal to 232 seconds. I think that it’s a bug.

My lora-app-server version: 0.20.1
My loraserver version: 0.26.1

Ok i found what we are answering, we are asking RXTimingSetupReq and RXParamSetupReq.
And because the end device don’t get the message, he never answered. But i’m still don’t understand this 232s delay.

The regional parameters give the following recommendation for EU:

ACK_TIMEOUT: 2 +/- 1 s (random delay between 1 and 3 seconds)

Have a look at the mac layer configuration of the end device and check which values are used.

Hi Guys!

I’m facing the same problem about the join procedure via OTAA. I have a 145+ nodes in production that take too much time to join the network, about +5h sometimes, after the join I’m able to send packets normally. It is important to say that after some (many) tries, the node seems to not send any other packet of join, only after many hours. I tried everything that i knew and i don’t have any approach left. I’m using the regional band US_902_928.

My current situations are the following:

I have 2 gateways in the field:

And I’m about to add 2 more Sentrius Gateways. In the end, the maximum distance between the gateways will be 2km.

All my nodes are class C. I’m using the last version of loraserver.io

Here is a screenshot of the log from Laird Gateway:

Example of Join Request received by the gateway

Example of Join Accept Sent by the gateway

I was noticing that for some nodes (as in the image) the signal looks pretty bad with loraSNR -15 and sometimes with nodes that are closer to the gateway. This happens commonly with the multitech gateway.

I tried to verify the timestamp and looks ok. When I test the join procedure in the lab with a few nodes works fine. But in production, the things are mad.

My configurations for US915 are as the following:

Device Profiles

In my service profile I set:

The loraserver.toml file is as follow:

By the way, I use the US915 in hybrid mode. The channels are already configured on the gateways and my nodes. I’m using in both the 8 first channels available.

An example of gateway Laird configuration is:

Any clue about what is happening @Mathis @brocaar ?

thanks in advance.

I updated to the last version of the loraserver and is working fine along with Laird gateway, however, seems like there is a problem with the multitech gateway, probably it needs some updates.