Just tried the new Heltec module I received today with the exact same code and it just works now.
@MOS-FET Same problem here too. I got a couple of the Heltec Cubecell’s, I fired it up with the sample code, set it to 915mhz, and it just worked and thought it was amazingly simple. Then 19hours later it just stopped… I saw a couple partial joins, then it’s never joined again. I pulled out the 2nd one, known good 900mhz antenna, same issue. It’s really discouraging. My other nodes are working fine, so I suspect my gateway is running fine.
EDIT: Yes I tried different pigtails and moving between 3 - 20m from the gateway.
@noebl1 ok. Which of cubecell you are using I used the capsulate one. I think they have problem in receiving. Because the join in my case was always accepted from my Gateway.
I have written an issue on GitHub to this matter.
Thanks for your answer. I have an TTIG indoor Gateway. I will do more test next day’s if I have time. Because the electrical node specs and low power are quite super.
@cslorabox can u suggest an logic anylizer.
Is there a way with TTNv2 to
- surely see if a Join Accept was generated by the network server?
- to which gateway it was sent?
- to clear the DevNonce history of a device (to ensure double DevNonces are not an issue)?
Posted by @arjanvanb back in Feb 17
@MOS-FET They are both the CubecCell dev boards.
I had wondered if for some reason there was an issue on the TTN side (I figured a remote chance, even though unlikely), so created a new application with a new app key and same issue. I’ll post to the Heltec forum as well for some ideas.
Apparently somehow depending on the type of gateway, or on the type of forwarder software (like Semtech UDP or TTN MQTT), the gateway Traffic page(s) might show an orange Join Request. The application’s and device’s Data page will always show an orange Activation if TTN accepted the Join Request (including the new DevAddr). And the Traffic page of the gateway that was selected for the downlink will show the green Join Accept:
I just retried my first Heltec Lora esp32 V2 node now that I have 2 other Heltec nodes working and everything points to a defective board. It transmits but it has a hard time to receive. Sometimes it does but most of the times only when it goes to SF9
Which library are you using? LMIC?
I had this kind of problem with older Heltec (v1) boards, too. I assume root cause is a timing issue due to the onboard oscillator.
@obaeyens Whenever I have joining problems, 9 out of 10 times it is my local network for some reason messing up the incoming traffic, so my gateway never transmits the join accept message that is in fact send from the TTN backend.
For around 10 dollars on Ali you can buy a USB stick spectrum analyzer that makes an incredibly helpful tool, because it makes visible the transmissions of your node AND the replies of your gateway, so you can troubleshoot much faster.
I tried this SDR dongle and SDR# yesterday, I seem to be the only one that actually use that frequency. I am in a small city far away from bigger cities and the first one to install a LoRaWan gateway here.
But now that I have 2 working nodes that have no issue with joining and transmitting data. I retried that node again, but still no it does not recognize the join acceptance. So must be the board itself.
Pretty clearly not the issue here since some of the nodes work better than others
LMiC in general has had may timing bugs, especially when run on ESP32’s via an Arduino layer.
Also you’re not stating which repository and state of it you are using - there are various forks each having and missing various bugfixes.
I followed what I found online:
IBM LMIC framework by IBM version 1.5.0+arduino-0
You need to link to a specific state of a specific repository.
An actual link, not words.
An again, pay attention to the comment that most are known to be broken for your usage.
Better use MCCI LMIC instead. It has a lot of bug fixes and enhancements.
This thread is getting way off-topic and is therefore closed.
The issues described in the initial post are related to defective hardware and are not representative for OTAA in general.