"Join failed - ERR_MIC_MISMATCH (-1112)" When Pressing "RST" Button on TTGO LoRa32 V1 (ESP32) #1544
Replies: 3 comments 2 replies
-
|
Mr. Etherton... I am once again stunned by the weird blend of eye for detail, red flags that are then ignored, the balance of "think (understand) before you speak" consumed and forum etiquette. Yes, that is my bag of mixed feelings that I describe there. I do believe that you're a fast learner however, so here are a few things:
Really, we want to support whatever journey you are on (we still never heard what that journey is), you got the brains to get there as far as I'm concerned, but if you want to get somewhere useful, it is crucial to ask the right questions, give the proper context, understand what is worth spending your time on, and what is worth asking someone else to spend their time on. Humans are not LLMs that generate some output whenever you throw in a question. Please keep this in mind. |
Beta Was this translation helpful? Give feedback.
-
|
All of the above (but not the JoinNonce, I didn't spot that, but TL;DR!) Plus:
This is embedded hardware that is hardly cutting edge, millions of these processors & flash memory are in use. We don't need to assume anything, the metric F tonne of documentation & debugging tools allow us to KNOW stuff upon investigation. Additionally:
I'm the owner of the TTGO LoRa32 and I'll run any tests that you produce that continues to cause issue if I don't have to wade through baked beans to get to the detail. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @StevenCellist and @HeadBoffin, Thank you both for your replies. I have combined my reply for simplicity.
My contributions are made in good faith. Just like many, I work on LoRaWAN in my spare time, and I share what I find as a way to both document progress and potentially help others facing the same problems. I do not claim that my posts are complete or correct, they are a snapshot of where I am at that time. I post when I reach a stopping point, a gap in understanding or run out of time. Rather than delay indefinitely, I prefer to share what I have, even if it’s rough, because incomplete information can still be useful. Others might identify with the same issue or spot something I’ve missed. I do not expect replies or validation, but I would like to think that my participation, even if flawed or imperfect, is respected as part of what builds an open technical community. If my posts are not helpful to someone, they are free to disregard them. Because of the feedback, I am increasingly conscious of my wording, research, and phrasing in an effort to avoid issues. I feel like I have meaningful things to contribute, especially because the questions I raise often concern areas where documentation is sparse, discussion is limited, or few clear sources exist online.
Thank you for clarifying the purpose of the "Discussions" tab. I am perfectly happy for this to have moved as per my original post: This is not a big issue, and is easily avoided by disconnecting and reconnecting power to the board, however I can't imagine that I would be the only person to have thought that "RST" and power cycling would have the same result.
I have applied the "details" formatting as per your suggestion. This has required me to edit my original post, however has been done to substantially improve readability.
Yes, they are indeed very weird! Further leads to my suspicion that memory is not being cleared fully by pressing the "RST" button.
For others, this is referring to this post on the TTN Forum which I posted within the past couple of days (there's overlap between this repository and the Forum). The mention of "dwelltime" refers to this TTN Forum post. One thing which I did not mention in my original post was success with adapting the library to work with LoRaWAN Regional Parameters v1.1rA for AU915 rather than LoRaWAN Regional Parameters v1.1rB. Why is this version difference important for AU915? Using the older regional parameters is perfectly fine in Australia as there are no legislated dwell time limits. How did I make the change? Put simply...
No expectations, just awareness, and as @HeadBoffin rightly pointed out, devices under deployment conditions don't have their "RST" button pressed.
My journey is one of learning and discovery, to understand how to use LoRaWAN reliably, with confidence and to its fullest potential. I want to make sure I understand the transmission and network protocol correctly before starting to consider integrations and use cases.
Good point. I have not tried replicating the issue on another one of my TTGO LoRa32 boards.
My development environment is the Arduino IDE. I have yet to investigate the
Absolutely, the ESP32 does have the ability to save data, however "persistence" is not implemented in the code.
Great idea! |
Beta Was this translation helpful? Give feedback.
-
The tough part here is that by posting an issue (a discussion somewhat less), you explicitly request replies and/or validation. We take the responsibility upon us to support a library, which means working through all issues and most discussions that are posted. An issue especially calls out the developer, and discussions and forum-topics request someone to take a look, read it through and hopefully comment - in the absence of active community support, that goes to the developers as well at least half the time.
I understand that, I tend to do so as well, and if it was the first ever post I had seen I may have responded differently - the digital trace that people leave behind does matter however. We've had similar discussions with other people, it's not just you that we try to educate ;)
Not a problem at all, improving formatting is always a welcome edit. It's changing the content of a post that we really try to prevent because it messes up the discussion.
I really, really doubt that this is the right strategy. For two reasons:
All in all, I'm pretty sure your heart is in the right place; you wouldn't get these detailed and long responses from us otherwise. The main thing to consider is, again, how you want to consume your credits on the public, social, online meeting points. Pick your battles, try to figure out what is worth spending your and others' time on. Formatting of a post is a minor thing, editing posts is sorted out all good now, but it's the compliance and respect to institutes and people (and their time) that is a balance which I think can be tuned finer. |
Beta Was this translation helpful? Give feedback.
-
|
Or TL;DR: We STILL don't understand what you are working towards. Because the rest of us just get on with deploying devices to the greater good (of community or own income) whereas you appear to have a rabbit problem and we are desperately trying to erect a rabbit proof fence to save our and possibly your sanity by stopping you from deploying your genetically modified mega-rabbit that makes holes no one else can see. The very best way you will learn to use LoRaWAN reliably is by incrementally moving the Starter script towards the Reference script, folding in the persistence for ESP32 along the way, ending up with half a dozen active devices out of walking range that you just let run. This, along with the TTN Learn section and perhaps taking the Fundamentals exam to ensure you have absorbed it, is all most LW developers need to know, if they stick to the explicit AND the implied rules & boundaries of the current specifications. About once a quarter we get someone on TTN who comes along to "test" LoRaWAN - by which they mean they don't think it works so they have to see it for themselves by trying to push it around - usually with illegal levels & frequency of transmissions and comprehensively trashing the TTN FUP. As there are deployments by metering companies in the UK in the 150,000+ devices range, you and millions worldwide and occasionally some of us get paid for this stuff, you don't need to take this evaluation to the next level.
But are so niche that no one would go there or cares so your questions are highly academic which makes them, in the face of a perfectly good working system, rather pointless. I started on LW, as a migration from using LoRa for High Altitude Ballooning, in June 2019. Rather than asking LW 101 questions I just used search, a lot, plus some years of coding experience, so had a couple of gateways and a three hand-built and a PCB from which I had half-a-dozen devices made up & deployed before I registered on TTN forum on 2nd Nov that year to ask my first question. Now you may be the more academic type, which is more @StevenCellist's role in the Dynamic Duo. But this isn't a spec for a Large Hadron Collider, its for something that's meant to be used. Life goes through peaks & troughs - I can see you had some pretty massive highs towards the end of your education which you may not be feeling so much now. So its all going to be down to blood, sweat & tears - which mostly gets noticed by taking things out of the privacy of your head or office and out in to the world. As such you will learn so much more if you stick some temperature & humidity monitors out & about in community locations and setup a dashboard so the community can see the results. Because the hard part of LW is not the technicals, it's the application & the people. And the good news is that with climate issues, this is super easy - @StevenCellist has done it and he's not actually graduated yet - he took a school air quality monitor project, reworked it, deployed it, created a website with sexy dials on the dashboard, got municipal funding and an award. Just do that. No big secret, Sensirion SEN66, UV sensors, a GNSS module, LW radio and you are in business. And if by now you've not hooked up with the LW massive in AU, you should have done, but perhaps not nit-pick at esoteric points above. And most of all, as the ISM band is shared by many users far more useful in the world than us, if you deny them service because you think you have a legal leg to stand on, start finding a lawyer. Best endeavours, current good practise is a defence, you don't have one, particularly as the audit trail that Google can generate of your White Rabbit / Mad as a Hatter schemes will be very damning. Last point for you to think on. We like energy & delivery and have access to resources. Tell us what practical, useful application you would like to explore (that is NOT real-time tracking) and if we can facilitate or host or some such, we can look at it. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I'm using a TTGO LoRa32 V1 SX1276 (ESP32) with the LoRaWAN_Starter example code with TTN, using LoRaWAN Specification V1.1 and Regional Parameters V1.1 on AU915 and OTAA. I have enabled
#define RADIOLIB_DEBUG_BASICand#define RADIOLIB_DEBUG_PROTOCOLinBuildOptUser.h.I have "Reset join nonces" enabled in the TTN Console as I do not have any "persistence" capability.
Given each new join resets the DevNonce on OTAA, I do not need to reset this.
If I restart my board by pressing the "RST" button, I regularly get the error message
Join failed - ERR_MIC_MISMATCH (-1112). No such issue has ever occurred if I disconnect and reconnect power to the board. Without delving into it too deeply, I am assuming that the volatile memory on some components, such as the SX1276 LoRa radio or certain ESP32 peripherals, are not fully cleared when pressing the RST button, whereas a full power cycle does completely reset them.If this is a result of the board's design, no worries, go ahead and close this, but I thought it would be valuable to document it here for others who may be experiencing the same issue.
Below are a few examples, showing the serial output and the associated downlink payload. Do note how the
LoRaWAN revisionalso changes without adjustments to settings from my side.Example No. 1
Serial Monitor
TTN Console
Example No. 2
Serial Monitor
TTN Console
Example No. 3
Serial Monitor
TTN Console
Beta Was this translation helpful? Give feedback.
All reactions