OTAA and bad contacts in your node's antenna


this may be of interest to people new to OTAA.

If you see a Join received by your gateway and a join accept on your gateway but your node does not transmit data, it could be a bad contact in the node’s antenna.

In my case the gateway correctly received the join request and transmitted it, but the node only started to react when the OTAA code started to use higher and higher spread factors even though the node is 1 meter from the gateway.

I never had issue with the ABP, but in that case the node only transmits and does not receive.

Or it could be that a distance of one metre is too close between a node and a gateway, which causes the receiver to be overloaded.

Highly unlikely to be the issue. Much more likely, wrong timing on the node, or illicit join nonce reuse leading to success only when walking to an unused value.

1 Like

I have 2 identical Heltec ESP32 V2, running identical software. One has no issues, the other one seems to be able to transmit correctly but is tone deaf to retrieve the joined accepted message.

I am going to order a new one to verify if I do not have a broken device.

One moment when I fiddled with the antenna suddenly it appeared to function correctly, but after I moved it I can’t seem to make it work anymore. The gateway receives it without issues.

Yes, but maybe you just damped the RX in the correct moment. As i set up some paxcounters too near the gateway (ca 4m, 2 walls) i shielded their antennas inside my fist for OTAA joining. That worked quite well. No chance without that.

I just put it into a closed microwave. Same effect, tomorrow I go out and try this again from distance.

Sure, but they have different identify to the TTN servers. If one identity is illicitly re-using frame count or join nonce numbers and the other is not, one will not work and the other will.

I’ve never seen a node radio misoperate as a result of being too close to the gateway. Very naive network software can be confused by a node’s transmission bleeding over into additional channels on a gateway beside the true one, but those logic bugs should have been fixed long ago. (That said, having a node too close can easily blank out other nodes at a distance from being heard while it is transmitting, even when they are on other channels)

Note that a marginal timing error issue could be affect by something so simply as temperature change.

This node is driving me nuts. But once joined it works flawless.

I did use the node for developing my software on it, so it did got manipulated a lot and maybe I damaged something.

When I leave it, the it retries with different SF and mostly it connects when it tries with SF9.

You really need to see if TTN is generating join accepts in response to the non-working join requests.

If accepts are being generated, the most likely issue is a timing bug in your node. This has been a widely reported difficulty on ESP32 based devices, because the ESP32 hardware requires a different sort of software scheme than what the authors of most LoRa stacks had in mind when they wrote their receive window timing routines.

If accepts are NOT being generated for initial attempts, then you should look to see that the join nonce being used is “new” and not a value that was previously used. If the device invents the same “random” number every time, and then simply increments it until it works, it will take one more try to join each time you power up or reset it.

Except for the type of devices you provide little additional information.

Wat exactly do you mean with ‘fiddle with the antenna’?

What antenna’s are you using?

Have you tried switching:

  1. The antenna’s between the 2 boards?
  2. The pigtail cables (assuming use of pigtail + SMA antenna)?
  3. Both pigtail and antenna’s?

If so, what happened?

And 1m is just too near to the gateway. Better use 3m minimal distance.

What about the RSSI and SNR values of received uplink messages? Do you see significant differences between the two boards/setups? If so then the issue is probably RF related.

The issue appears to expose with downlink messages, hence the problem with receiving OOTA join confirmations on lower SF.

You mention ABP works without problems, but that will probably be for uplink messages only.
If you do some experiments with downlink messages (can be done from TTN Console/Application/Device/Data) while using ABP, you will probably run into similar issues (unless you explicitly connect on higher SF).
The exact cause is yet unclear. It could be an issue with the board but also the antenna/cable/connectors.

One antenna is standard from a Helvetec ESP32 Lora V2 board. The other one is from a Rak2245 standard antenna that came with.

Both antennas appear to be exactly the same, a cork screw.

I already spent way too much time in this one module, so I ordered a newer module to see if it solves the issue or not.

Problem node: (5 m away)

“coding_rate”: “4/5”,
“timestamp”: “2019-12-30T23:47:07.783Z”,
“rssi”: -63,
“snr”: 9.5,
“app_eui”: “70B3D57ED0027222”,
“frequency”: 868100000

Good node 1 m away

“coding_rate”: “4/5”,
“timestamp”: “2019-12-30T23:48:14.997Z”,
“rssi”: -37,
“snr”: 9.2,
“app_eui”: “70B3D57ED0027222”,
“frequency”: 868300000

I did order a casing for my RAK2245 and an external glass fiber antenna from RAK. I only reach 250 meters radius max, I will try to increase this with a better antenna.

For me all this is pretty new, but this gateway is here to stay :slight_smile:

The bad node appears to become functional when you wait long enough and when it gets to SF9.

The TTN gateway generates Join accepts in this case.

The software I run on both identical ESP32’s is identical and I bought both of the at exactly the same time. I even swapped the node

What confuses me is that I fiddled with the antenna and suddenly it worked.

Sounds like a timing problem

Attempting to do meaningful comparisons at such short distances is very difficult and prone to error.

Perhaps if the Gateway was in an anechoic chamber or out of doors in a large open area with no nearby objects, and the two nodes antennas were at the exact same height and angle, you might get some form of consistent result …

Your problem is exemplary, related to defective materials: board, antenna and/or antenna cable. The issue is not specifically related to OTAA. It will impact ABP down-link messages just as well. Latter you seem not to have tested.

The issue is not OTAA specific, therefore ‘people new to OTAA’ makes no sense here.
(And lack of experience would be better expressed as ‘new to LoRaWAN’ than as ‘new to OTAA’.)

Like @cslorabox already mentioned the observations described are usually caused by timing issues (in software). Defective hardware (and poor antenna connections) can cause different kinds of problems but are not representative for OTAA issues.

@bluejedi I am with you.
but today it was crazy I have nothing done with my node. No change in software no change in position of antenna and even I didn’t get a join. I just had the node off some day. Ten minutes later a get suddenly a join with no problem at all. And also it worked several times later.

Probably time to modify the node firmware to blip a GPIO on transmit and receive and start looking at the timing with a scope or logic analyzer.

Also review the issues list for whatever firmware you are using.

I am testing at the moment the heltec cubecell with arduino support. And modify firmware is not so easy here and hobiest as I am are have no Oscilloscope at home. In my company I have a 1.5 GHz Oscilloscope a spectrum and a network anyliser so all needed to see the UhF transmission. But no time to do this at work.
So I have just the option to hope my hardware is good enough. And the provided lorawan library is good. So I can understand when people are frustrated.
I was it also if it doesn’t work because I have nothing changed in firmware of the node just connect power. Last day it worked. Suddenly not. Ten minutes without power it worked again. No change in hardware and software.
So even sometimes luck when it is working.

It’s only random so long as you don’t consider the actual causes.

A cheap $10 USB based logic analyzer works too, you don’t need a scope.

Just tried the new Heltec module I received today with the exact same code and it just works now.