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.
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.
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.
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.
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:
The antenna’s between the 2 boards?
The pigtail cables (assuming use of pigtail + SMA antenna)?
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.
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
The bad node appears to become functional when you wait long enough and when it gets to SF9.
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.
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.
