Joining TTN fails with error code -1116 - DevNonce is too small

[Krulknul]

Hi! I come from a Computer Science background but I'm a bit new to embedded, so please bear with me

I am using this LILYGO T-BEAM featuring an ESP32 and SX1276

I would like to create a device that uploads location data to TTN. I have the GPS module working, and I can receive longitude and latitude information.

I worked through LILYGO's example for LoRaWAN, and I am now successfully able to initialize the LoRa module and try to join the network. However, when I join the network, the following error code is returned: -1116
This error code seems to be related to no downlink being present for the join request, which the troubleshooting guide says is normal due to not every uplink having a downlink, but I wonder if that's the case for join requests.

When I look on the TTN's web interface, it looks like some of the join requests are listed there, but most are not. More importantly though: All the join requests that are listed there are failed with the message: "DevNonce is too small".

I'm wondering: Could this be due to a misconfiguration? Or is the signal too weak?

Should note that I do not have my own gateway, but I am living in an urban/suburban area in the Netherlands with a few gateways around (judging by TTN's coverage map)

Thank you very much in advance! I have another request: I'm looking for a nice community or channel to chat about these kinds of things and/or ask questions. I would really appreciate some leads on that, if anyone would happen to know one :)

[K4KDR]

Greetings! I was running into similar issues - primarily because of my lack of experience on the subject.

But thanks to the people affiliated with RadioLib, it became obvious that the root of my problem was that since DOWNLINK messages were not possible (1-way comms... UPLINK to satellite only), the correct way for me to configure my devices in TTN was to set them as type 'ABP'. Then, TTN was simply waiting to hear from them... which it did via in-house testing thru a standard LoRaWAN gateway.

The replies that helped get me past this issue are at:

#1070

[Krulknul]

Thanks for this response! I will keep ABP in mind as another option over OTAA in dev environments

[StevenCellist]

Hi @Krulknul, welcome to RadioLib! And if you happen to study / have studied at Utrecht University, then we may have seen each other as well - MSc CS at UU here.
While the solution provided by @K4KDR is somewhat reasonable, we can definitely do better in NL as there are mostly plenty of gateways around. So we'll stick to the OTAA examples that you used in the LilyGo examples.
What LilyGo didn't include in their repo-examples, is the README that you can find in the examples/LoraWAN directory of this repo, namely that to be LoRaWAN v1.1 compliant, a device must keep track of the used DevNonces and monotonically increase those with each JoinRequest. As persistent memory implementation hugely differs between platforms, we decided to abstract those away from RadioLib's core repository, but instead move them to a different persistence repository. There you will find a sketch for the ESP32 that is fully compliant, littered with comments and after reading through and understanding most if not all of it, you can reduce the number of comments and find that it's not that bad as it seems at first glance.
You may find it useful to toggle the "Resets DevNonces" box on the TTN Device console page under network settings for development, but once persistence is nicely working, you should be able to use it without resetting DevNonces and find that it works nicely.
Good luck, and let us know if there are additional problems. The troubleshooting guide on LoRaWAN needs some extra explanation, for which posts like these serve as a nice basis. En welterusten ;)

[Krulknul]

Hi Steven! Thank you so much for this response!
I am currently still working on my BSc informatica at the UvA, so not quite there yet :P
To keep myself busy this summer break, I'm trying to create a pet tracking device using LoRa and GPS.
Before posting here, I saw you on the TTN forum, and looked at your MJLO project. Looks like a fun and interesting use case for LoRa!

I continued tweaking a bit yesterday, and it looks like the first error I was experiencing (-1116) was due to insufficient range, judging by the following facts:

• The TTN Dashboard did not show all of the join requests that were sent. This suggests that:
  • Some of the join requests were not received by any gateways
• The "-1116" error seems to indicate that no downlink was received. This might suggest that either:
  • That particular join request was not received by a gateway, or
  • The join response was not received by my end device

After I increased both the spreading factor and the output power, the device had more success joining the network. Likely because it increased the chance for gateways to successfully receive the join request. I'm not sure whether it also increases the chance for the end device to successfully receive though, that might depend on how the gateway picks the spreading factor. Going outside and testing there also worked better than from inside my home.

About the "DevNonce is too small" errors: I managed to get rid of them for now by toggling the option you suggested in the TTN Dashboard. Now, I am successfully able to send uplinks to the network, in the form of latitude and longitude data :) I will have to look into the persistence repo for better handling of the nonces, so thank you for mentioning that.

There was also a slight bug/oversight that really confused me in the LILYGO example, which is the following line:
https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series/blob/4c9a339382c8f42e5da205b72f329d064c806157/examples/LoRaWAN/RadioLib_OTAA/RadioLib_OTAA.ino#L194
They print a "Join failed" message using this debug function if the state code is negative, but the RADIOLIB_LORAWAN_NEW_SESSION (-1118) state is actually also negative while I assume being a perfectly normal outcome of joining. Just posting here in case someone else comes across that.

My next step is testing the range around my area and then designing a new device to be as power-efficient and performant (range) as possible to track my cat :P

[HeadBoffin]

@StevenCellist was being so very kind to @K4KDR, the reality is that LoRaWAN is a terrestrial transmission system and by asserting that downlinks aren't possible due to the satellite comms being 1 way only is confusion of the very highest order. The notes.md give precise & detailed instructions on setup including the issue of the DevNonce - if @Krulknul ensures they read them, they will make good progress apart from having to suffer horribly if any pet trackers are used on cats because be assured, the best way to kill a cat is to put a clunky collar on them. But at least you can find the body.

The CONSOLE (please please read notes.md, we call it the console) won't show join requests that the gateways don't hear due to the meta-physical nature of the universe. If one does hear the JR and the dev nonce is too small, that's because you haven't read the notes.md. Even though Steven issued a spoiler, please read the notes.md for other information. There is a reasonable prospect of the JA being sent but your device doesn't hear it, please bear that in mind. It is highly recommended that you have your own gateway so you can see what's going on. Next best is to have read only access to the console but I'm not sure if UU has provided that - shame on them if they haven't.

If the equally impressive Learn section on TTN hasn't been read, please do so now. LoRaWAN is not at all suitable for tracking applications due to the duty cycle limitations and on TTN, the Fair Use Policy. It is OK for asset location (ie, stopped moving for a while).

You are right about increasing the SF. Messing with the power could lead to jail time, there are EU laws about the power output and how often you can transmit. The gateway is but a dumb convertor box, it doesn't choose anything, ever, apart from dumping packets that don't pass CRC. Leave ADR to alter the settings, the LNS is so much better at it than we are.

We have no control over others copying the library in to their own offering, so any issues with what they've provided needs addressing with them - until now I didn't know that they had copied the implementation wholesale, at least the really helpful and awesome notes.md was included. I'd recommend using this repro as it's, like updated when issues are raised, LilyGo have copied not set as a sub-module so it won't automatically get updates. I'll check this issue isn't in this version as the senior dev is away getting sunburnt.

If you love your cat, do not attach a tracker to it. If you don't love your cat, Steven will pick it up when he gets home and re-home it with me.

Dogs don't do any of the things that cats do and are almost always supervised and are larger. Track them with a purchased harness that carries it in the middle of their back comfortably. Do not use duck tape.

As Steven will attest, I'm actually a big pussy cat, happy to help, I even house, feed & entertain students from UU, but only the ones that have read the Learn section and don't mess with cats.

If you want more bonhomie sarcasm, do drop by the TTN forum where a bunch of LoRaWAN nerds hang out.

LW is a great way to get good at embedded - the radio side is a bit niche but all the rest of writing efficient firmware applies.

[Krulknul]

Thank you very much for this response, even though I can't help but read it as a bit of a lecture :P

I am aware that there's a risk involved with attaching collars to cats, but what I found is that it's pretty simple to minimize the risk by using a breakaway collar, similar to what Tractive has. I will obviously not attach anything to my cat using duck 🦆 tape, and not even duct tape. Better yet, I don't even own a cat (although I wish I did). My goal is to make a small-as-possible device and attach it to a safe collar. See Katzentracker, but rectangular, not hanging and as unobtrusive as possible.

I am aware of the law and FUP, but I am in an explorative step where I am simply testing the restrictions and capabilities of the technology. That's why I'd rather bypass ADR for now. No, I will not be transmitting endlessly in this stage.

I do think TTN is suitable for GPS tracking, even with FUP and laws: It is a cheap alternative without the recurring costs of cellular. It's not real time, but it may be enough to get a location update every X minutes, which should be possible under FUP and laws judging by the airtime calculator

I am aware that I should use this up-to-date repo and not the version LILYGO offers in their examples repo. I just use PlatformIO and their library manager.

[Krulknul]

from https://www.thethingsnetwork.org/docs/lorawan/adaptive-data-rate/
xD

[HeadBoffin]

I do think TTN is suitable for GPS tracking

The experts on the TTN forum think otherwise and they actually implement stuff, unlike LNS developers or students.

Don't get too cocky, you aren't culturally aware enough to be able to start correcting brand names of tape and perhaps read "How to win friends and influence people" because you never know what may come up in the future.

[Krulknul]

Don't read too much into it; I was only countering some friendly sarcasm with just that

I'm not too great at it though: Maybe it's because I'm Dutch