LMIC delay of 12 minutes (720 seconds)?

End Devices (Nodes) [obsolete] SCPF-related
1

Hello,
I am using LMIC V4.1.0 in the Arduino IDE (MCCI Arduino LoRaWAN Library v0.9.1) for ESP32 (TTGO module). I am using SF9 and I send a message of 22 Bytes every hour (some sensor data). I am using a home-built 1 channel gateway for reception (but this should not have any influence). I am using channel 3 (868.5 - SF7BW125 to SF12BW125), so I am not on channel 1 (868.1 MHz), which may have special restrictions.

I am writing some DEBUG info on the serial console of the TTGO and so I can see that a new message is scheduled for sending exactly every hour. Very good. The first message (after a reboot of the TTGO) is then sent within a few seconds and I see the confirmation on the console. I can then see that data package on the gateway and then also on the TTN page. All good and well.

An hour later the same happens but now it takes EXACTLY 12 minutes between queueing the message on the TTGO and sending the message on the TTGO. Again I see the data on the gateway and in TTN.

After another hour it now takes 24 minutes between queuing and sending of the message. And sometimes this message then does not arrive at the gateway (and also not at TTN).

But it is a repeating pattern:

  1. message sent immediately
  2. message sent after 12 minutes delay
  3. message sent after 24 minutes delay, sometimes not sent at all
  4. message sent immediately
  5. message sent after 12 minutes delay
  6. message sent after 24 minutes delay, sometimes not sent at all
  7. message sent immediately
    and so on.

What is causing these delays?

Any help appreciated
Helmut

2

All bets are off when using a Single Channel Packet Forwarder - they are not supported by TTN as they cause disruption to the network - please disconnect it immediately.

See details here:

It may well be LMIC is getting tied up in knots or even trying different channels - who knows!

We do know LMIC & LMIC-node (the very well supported, tried & tested wrapper for it) works wonderfully on TTGO with a full 8 channel gateway.

3

I am also running a commercial 8-channel gateway at my workplace, but due to Corona I am 100km away from work in my home office where I don’t have an 8-chan GW available.

And the last time I was at work I seem to remember that the same thing happened there as well, but this was months ago and I did not (yet) pay a lot of attention to it (I was working on other problems/aspects back then).

If this is a likely cause, I can drive there next week and give it a try. But if this is just “we don’t want 1-chan GWs, go away” I might try something else instead and save the 200km drive.

But thanks for your response, I appreciate it, as it points into a direction I did not think could cause that. Always good to look at new directions! :wink:

Helmut

4

We don’t want SCPFs - correct - but no one is saying go away, we are saying please don’t use them.

Various vendors will get you a TTIG for less than the cost of the fuel & time, probably for tomorrow morning …

5

Pardon?

The contents of the 2019 post that @descartes referred to and numerous other posts on the forum make it very clear that SCPF are not supported on The Things Network and the forum. It is also explained why and advised to get a cheap LoRaWAN compliant gateway (e.g. TTIG) instead.

That you don’t have access to a LoRaWAN gateway at your current location is a pity but does not change the fact that SCPF are not supported and is no excuse for trying to get support for SCPF on the forum.

LoRaWAN and The Things Network have progressed and SCPF are now obsolete.

6

Closed because SCPF related which are obsolete and not supported.