Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LMIC not stable on ESP32 (Heltec WiFi LoRa r2) #463

Closed
terrillmoore opened this issue Sep 29, 2019 · 6 comments
Closed

LMIC not stable on ESP32 (Heltec WiFi LoRa r2) #463

terrillmoore opened this issue Sep 29, 2019 · 6 comments
Assignees

Comments

@terrillmoore
Copy link
Member

At the things.nyc office-hours last week, one of our members had a Heltec board, and we tried the LMIC. No luck -- I could not get the compliance sketch to work stably. I played with the compile options in the BSP to no avail, although I was able to change behavior a little. It was somewhat non-reproducible, so I suspect that I had a configuration problem. Any advice from the ESP32 users out there? The member was good enough to lend me the board, so I have something to test with -- but limited time due to the end of the quarter.

@manuelbl
Copy link

manuelbl commented Oct 1, 2019

How does the unstable behavior manifest itself? Can I run the compliance sketch myself or does it need test equipment? Or what's the easiest setup to reproduce the problem?

@terrillmoore
Copy link
Member Author

I ran the compliance script and couldn't even get it to join reliably; it hung at different places depending on what clock rates I chose, etc.. If you change the keys, you should be able to do this with a live network. I have added the board to the "first class boards" in my sandbox, will push that change momentarily.

@terrillmoore
Copy link
Member Author

The branch to test is https://github.com/mcci-catena/arduino-lmic/tree/issue453; it incorporates the fix for #466.

@manuelbl
Copy link

manuelbl commented Oct 6, 2019

In my setup, the compliance script works (it joins reliably and sends CA FE F0 0D messages) for all boards except the heltec LoRa 32 V2. I can get it working if I define the pinmap explicitly.

So after some more investigation it turns out that the DIO1 pin for the Heltec v2 is invalid if automatic pinmap detection is used. In getpinmap_ttgo_loar32_v1.cpp, it is set to 33. That's correct for the TTGO LoRa32 V1 board (hence the name of the file). For the heltec LoRa 32 V2 it should be 35. This mismatch leads to the effect of not joining.

Fun fact: by touching pin 35 with my fingers, I can inject sufficient voltage to get it to join. But it fails with an assertion quickly after the join. At first this contributed to the impression of non-deterministic behavior.

Could this be the problem you have experienced? Or did you use an explicit pinmap and there is an additional problem?

I will later contribute a patch fixes the automatic pinmap configuration for the Heltec boards and extends it to a few additional ones.

@terrillmoore
Copy link
Member Author

Thanks @manuelbl -- I guessed that there was some kind of problem along those lines. We were doing a group session in NYC, and nobody had any docs -- I was copying the pin definitions from the Heltec reference, and either screwed up, or got the wrong reference.

@manuelbl
Copy link

manuelbl commented Oct 7, 2019

There was a discussion about a year ago on the TTN forum about the Heltec board. They seems to have mixed up versions, pinmaps and schematic. At the time, I removed the display to get to the SX1276 chip and beep out the connections with a multimeter. Most likely the board documentation is still not cleaned up, properly labelled and consistent.

There are also several revisions of the "v2" boards. One of them will fry your board if you connect both a battery and USB.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants