Feather M0 EV_JOIN_TXCOMPLETE: no JoinAccept problem

Are you re-using already used join nonces? That’s a spec violation, and as such you won’t get an answer until you use a join nonce that’s never been used before.

LMiC tends to somewhat dubiously start with a random number and then count forward, so if your random function is broken and always returns the same thing, it will take longer and longer each time to get to an unused value.

Of course it could also be a timing problem where your node isn’t listening at exactly the right time to catch the response.

Hi @cslorabox ,

Not sure where to check the random number generation in LMIC, but from what I have read after your comment, I’ve checked the live data and could see that TTN is sending join responses. Not sure if this is a good sign that the random number is being generated ok.

image

Then at least in that sequence you’re into unused join nonces, though that doesn’t mean you necessarily are at other points in other trials.

Most likely though that moves the prime suspicion to receive issues. Is the code up to date? Are the DIO’s correctly connected? Something you can do is get a cheap USB logic analyzer and use it to watch both the SPI bus and the DIO’s - you want to see that measured from the DIO transition marking the end of the uplink transmission, SPI operations then setup a receive window beginning just before each of the 4 and 5 second marks, and that the receive timeout DIO doesn’t fire until a bit after that expected time.

If you have physical access to the gateway, you may be able to get its transmit LED on the logic analyzer record, too - but you can generally assume the gateway’s timing is right if it transmits at all - if Internet or server latency doesn’t get the response back in time, the gateway won’t transmit at all (IIRC there’s a checkbox in gateway registration to indicate that the gateway can accept packets as soon as they’re calculated, vs the old situation without a queue where packets had to be held on the server until just before transmit time, meaning that even with a 4 second delay only a few hundred milliseconds were available for Internet delays)

Thanks @cslorabox , I can discard Gateway problems since I have two other nodes reporting correctly to TTN, one Dragino and a LilyGo TBeam.

I’m going to re-check connections now and let you know.

Many thanks!

@cslorabox I’m using now the verbose option, and I see an “Uplink channel not found”. Maybe it is a Gateway problem?

I was reading here: V3 - drop join request - uplink channel not found - #7 by luigirusso

But I’m using a multi channel Dragino Gateway (LIG16):

image

@cslorabox, I was reading here:

https://www.thethingsnetwork.org/docs/lorawan/frequency-plans/#au915-928

image

And maybe I have to select subBand 2 in this part of my code?

image

Very sorry to have made you guys waste your time. It appears that it is a frequency config problem.

My most sincere apologies.