RadioLib / Heltec detour via Chirpstack

I’m running multiple Wireless Stick Lite V3 on US915. I’d love to help test since I’m having issues in this area. Let me know how I can help.

Hi @xuuxij, thanks for reaching out!
Are you using RadioLib yet, or using another stack? And since we’re on the TTN forum, I assume you’re connecting to TTN?

I’m currently in the process of finalising the complete Class A specification (except ‘dynamic rejoining’ within a session) which can be tracked from this PR.

@descartes is trying to help as much as possible to verify US915 behaviour, but that doesn’t include real-world use.
He did help uncover two or three bugs in the PR for bands like US915 which I hope to fix today or tomorrow - you’re more than welcome to give the PR a shot once those bugs are tackled! Feel free to comment on the PR when you get around to it - we can use GitHub for that to keep the forum clean :slight_smile:

Or @xuuxij could just run the latest 6.3.0 release - TBH any arising issues in the WIP version may require some extensive logs to be generated :wink:

1 Like

LOL what @descartes is omitting here is the fact that he generated 400MB of logs while his device crashed approx. 30,000 times in the span of 16 hours.


Thank you so much for all of this.

I’m using this example:

Which appears to be able to load and function with my Heltec Wireless Stick V3 on a Chirpstack LNS. However, I think my keys/credentials aren’t being passed through correctly.

  • level:“ERROR”
  • code:“UPLINK_MIC”
  • description:“MIC of join-request is invalid, make sure keys are correct”

I’ll follow all the links and directions you’ve given and do my best to try and make the suggestions work. I’m a bit out of my element, so I’ll try not to annoy anyone.

This is not the forum you are looking for, this is TTN, not Chirpstack, please post somewhere else - the error info looks rather like Chirpstack than the output from RadioLib - as the proud owner of 400+MB of error logs, I should know - so you probably need to go to Chirpstack forum and not GitHub.


It’s all the same problem as you can see here: WiFi LoRa 32 V3: Send sensor data via LoRa, then go back to deep sleep - LoRa Node - Heltec Automation Technical Community

I don’t see how cross-posting between various communities in an attempt to solve a problem is such a huge issue though. We’re all in this together regardless of what stack we’re using.

BNS does mention TTN and Radiolib throughout the post.

This forum & the servers are funded by The Things Industries to support its endeavours & The Things Network. Forum policy is that assistance related to specific implementation issues is only for TTS.

However at a level up, how many people do you think there are that know LoRaWAN that care enough to help? Duplicate posts in a forum is a waste but relatively easily to spot. Cross-forum posts are worse.

To a degree I’d agree, but you are raising an issue with a specific stack and as I have some degree of familiarity with RadioLib, I suspect all you have given us thus far is information from Chirpstack which is off-topic for this forum.

Have you posted in the Chirpstack forum?

That post bears no relation to your issue. And to highlight my comment above about the limited pool of help, do you know who BNS is??

Have you searched here, Heltec & Chirpstack for “invalid MIC” - as this is a common enough issue for setting up.

If you happen to register on TTN and follow the instructions for RadioLib and can provide a TTN related issue - which would require you to get the instructions wrong because the setup of the DevEUI, JoinEUI and AppKey is particularly easy for RadioLib - then you are more than welcome to carry on.

To facilitate your understanding, there are comprehensive introductory materials publicly available linked as Learn at the top of the forum page.

There are some hard boundaries on this forum, TTS issues only and no breach of TTN Fair Use Policy - please respect that.


I have a TTN account, but at this point in my experience I’ll go else where. I was trying to thank you guys and try to help sort out a well-known problem with Heltec devices but I guess gatekeeping is more important around here.


This makes no sense what so ever - you posted an issue about MIC mismatch on the RadioLib thread and now say it’s about helping with a well-known issue with Heltec devices / stack that isn’t really clear beyond the well known issue with the Heltec stack being very old. Linking to someone who is trying to hack a project together the hard (normal) way of not learning the fundamentals first (sound familiar?) was irrelevant.

@stevencellist, myself & Mr BNS, who is in fact @stevencellist (I’m nmcc over there) have been using Heltec devices for testing RadioLib, so for this thread and Heltec, there is no issue.

As for gatekeeping, the funding for the forum comes from TTI - they provide us a fully featured LNS to use for free with three clusters around the globe, for emphasis, for free. It’s down right rude to use these resources to try to solve your issues using a competitors product.