-
-
Notifications
You must be signed in to change notification settings - Fork 408
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
Add support for TTGOv1 board after testing it with this code #1
Comments
I never tested the code on a TTGOv1 board. I did not buy one, because several issues were reported on this board in TTN forum. The board is reported to feature a SX1278. Not sure if this makes any difference to SX1272 and SX1276 for which the code was tested. But the reported error seems to point to a wifi, not a LoRa related problem. For further diagnostics try backtrace with the reported value of the program counter (PC) to find out at which part of the code the module resets. An abort could be intenially caused by the configASSERT statement in the wifi_sniffer_loop() in main.cpp:
Try to comment out the line with configASSERT and try again, checking the logs. |
For reference, a log on a TTGOv2 board looks like this:
|
I removed the "configASSERT" line, but it is still not working. I noticed the line at the end where our logs differ:
Do you have any hints on how to backtrace to the PC? |
I'm not an expert on this and not into JTAG debugging. Maybe you find these links useful: The TTGOv1 uses sames ESP32 SoC as Heltec board, as far as i know. The wifi monitor mode is part of the ESP32 SoC, does not need peripherals. So i don't see a reason why it should not work with TTGOv1 board. It may be possible that the Wifi firmware of ESP32 SoC differs. Check in boot log. |
Since the abort seems to happen at a point where Wifi on the ESP32 is activated: What power supply are you using? Sure, that it feeds the TTGOv1 with enough peak power? You may try changing your power supply to a bigger one. |
Normally I use my Notebook to power the ESP32, but I also checked my active USB Hub - unfortunately nothing. Isn't the complete SoC firmware compiled and uploaded by PlatformIO? However, I will have a look if there is a possibility to clean up the NVRAM. |
Ok... I finally got it working. I compared the Paxcounter setup code with the one I use when I tested the promiscuous mode of the ESP32 and found the following line:
If I understand it correctly, the line needs to be called before the esp_event_loop_init and the code works after I put it right before it in the main.cpp file.
Hmm... would be nice if somebody who owns the TTGO v1 checks if it works with it, too. |
Not sure if this is the root cause, because the code is running on all previously supported boards without TCP/IP stack. Perhaps this is a side effect. Besides that, a TCP/IP stack is not needed for the paxcounter app. Since the stack draws ressources (memory and power) i intentionally disabled it. Perhaps the ESP event loop is not needed at all. Can you try disable event loop init and tcp/ip and try again on TTGOv1? |
I created new branch TTGOv1-test and merged your edits there. Can you test with your board, please? |
Changed some settings in wifisniffer.cpp, Wifi NVRAM settings now disabled. |
TTGOv1 support now implemented in 1.3.0, Issue closed. |
Hi,
I am using a TTGO v1 board, but I ma unable to use it with the current version of the Paxcounter, because it seems not to be able to use WiFi. Here is the log of it:
Any idea, what's going on here?
Btw, I also added a TTGO v1 configuration file and changed the platformio.ini to support it. I have attached them to this posting.
platformio.ini.txt
ttgov1.h.txt
The text was updated successfully, but these errors were encountered: