thank you my friend
i test it and this is result
i found somewhere in my code that devNonce variable initialize with a random number and i comment it and asign a fix value to that
please give more detail I’m too much beginer
That will guarantee it gets re-used…which is the problem. 
You want a value (preferably random?) that increments each time and isnt re-used. Note any given device has a limited pool of DevNonces (actually quite a lot!) which under normal use & life time operation should not become exhausted, but if joining regularly (some badly witten s/w joins every time before 1st data TX and is a waste of space/should be avoided like the plague) such that you run out in the working life of the device then only option is to delete device in LNS and start again!
How about the Learn link at the top of the every forum page? And the link bottom right to the documentation on every console page?
And then there is the LoRaWAN specification on the LoRa Alliance website.
There is an error in my post above - I missed a not - I’ve edited this now - LMIC does NOT support v1.0.4 so if you’ve selected that as your device version, it will need to be changed to v1.0.3
1 Like
I have enabled reset join nonces and reset used DevNonces
you mean this steps?
i did them but still reJoining time is around 15min
We’d need some more info on what it’s doing for those 15 minutes - serial logs from the device as text formatted with the </> tool plus screen shots at a reasonable “old person” resolution of the exact same time from the device console in verbose mode.
sorry for big delay
i am posting console log as you say
and notice that it is first join attemp takes 20min to join
serial log:
============== DEBUG STARTED ==============
JOINING
try joining
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
JOINED
val = 000000DF
EV_TXSTART
Unknown event
TXCOMPLETE
EV_TXCOMPLETE (includes waiting for RX windows)
val = 000000DF
EV_TXSTART
Unknown event
val = 000000DF
TXCOMPLETE
EV_TXCOMPLETE (includes waiting for RX windows)
console log:
A summary of what you see would help speed up feedback. And please format serial logs with the </> tool
in summery I’m using lmic in stm32 and testing otaa joining method
but there is 2 problem:
- it takes to much time to join something around 20min
- and when i reset the device or reprogram it connecting takes to much time although i heve “reset used devnonce” key in console setting
my first pictures is console log for first time joining
and second pictures is console log after reseting device
main question is how i can reduce this time buecaus i’m in developing and i need to test many times???
device log(even dont have any thing helpfull):
============== DEBUG STARTED ==============
JOINING
try joining
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
EV_TXSTART
Unknown event
JOINED
val = 000000DF
EV_TXSTART
Unknown event
TXCOMPLETE
EV_TXCOMPLETE (includes waiting for RX windows)
val = 000000DF
EV_TXSTART
Unknown event
val = 000000DF
TXCOMPLETE
EV_TXCOMPLETE (includes waiting for RX windows)
This!
I meant a summary of any differences you may have seen after you’d done the reset
actually no defferences after reset!
do you have any idea what should i do? 
Your RSSI/SNR looks OK, there aren’t any warnings in the console about the DevNonce, so I’d have to suspect that something is stopping the device from hearing the Join Accept. Potentially:
- The gateway is not transmitting the accept - you can check on the gateway console
- The antenna is inefficient, compensated for by the device transmitting at a high power providing a good signal, but the antenna isn’t quite right for listening.
- The timing is badly out due to other threads on the device so it misses the receive window - you’ll need to turn on the timestamps on the serial log so we can see what it is doing.
Hi everyone,
Im still developing my project but now I have another problem.
I developed a Node Red app that sends a hexadecimal data (B6 BB 9E). I can see it on ttn console without problem. The problem comes when my board read the MAC payload as B6 BB 9E.
You can think that I coded this interpretation on my stm32 project but I didn’t. That’s what I want but even if I have my Node Red app closed, it’s still interpreting the same way.
I post 2 pictures to better understanding
All the answer are welcomed.
Thank you.
Its probably the LNS screaming back at you “no no stop have mercy please stop hammering me!”
Why do you think sending an uplink every 5 sec is acceptable? Check TTN FUP (and potentially legal limits in your area!)
Check out this tool, correct your behaviour then come back and confirm compliance to the rules 
https://avbentem.github.io/airtime-calculator/ttn/eu868/10
p.s. you might also want to try seperating node and GW (Forum search for the win) they are clearly far too close for a LOng RAnge technology…
Despite being told previously that you need to consider the Fair Use Policy, you appear to be sending every 5 seconds. You were asked to read the Learn section which covers this. This is not only a massive breach, but is illegal use of the radio spectrum - illegal like police, court fines, etc etc.
Do not post serial logs as an image.
Suspending the thread until you confirm you are working to FUP. That’s if the TTI staff don’t suspend your entire account first.
Make that continuous uplinks, the 5 seconds are the RX1 delay the stack (hopefully) observes.
I am probably dense, but you are sending a value and next thing is that you are surprised that actual value arrives at the node? Or do you have another problem and am I missing the point? If so, please clearly state what you expect to (not) happen compared to what is happening.
Are you using confirmed downlinks? (Yes or no answer please!)
Hello everyone,
It is not at all my intention to break the rules or the FUP. I am sorry for being such a newbie and sometimes not understanding well what you are trying to tell me.
I am having trouble being able to code my project correctly, hence sending so many packets. In fact, I either don’t want to send anything, only receive but my coding is not working as expected.
What I am trying to do is, when or I want to through my Node red app, send a value that the end node will receive and act accordingly. The issue is that I am receiving all the MAC Payload from the console on my end node as if it was a command given by my Node Red app. That is, when I decide to send the order through the app, the end node should receive B6 BB 9E, but now all MAC Payload is receiving it as B6 BB 9E without me wanting that to happen.
Again sorry for the inconvenience.
Thanks and best regards.
If you had actually read the Learn section as requested during your timeout, you’d be clear that this cannot happen with a normal Class A device. And that downlink messages are not MAC commands.
And that sending downlinks is a bad move.
But fundamentally, you have control over how often your device activates so there are no excuses for sending many packets.
And as @kersing says, you send your payload from Node-Red and it is received by the device at which point you can write code to act upon it - it’s clearly marked by the debug output that says Received - so we are still none the wiser how this is not doing what you say you want it to do.