Closed HouzuoGuo closed 3 years ago
As a temporary measure, i'm going to reset the microcontroller if there are too many consecutive readings of 0 on the pax counter:
https://github.com/HouzuoGuo/ESP32-Paxcounter/commit/c18ff869f1f5d10d0c8ed2cd2c65fd78b130c59d
See how that goes..
The readings on OLED further confirm the observations made from the dashboard, both WiFi and BLE counters read 0, while the ID of wifi channel being scanned keeps on rolling - it just happens to read 0 at the moment the picture was taken.
Sorry that you ran in problems running this software.
Zero values could be a result of unsolicited board resets. To ensure that there a no resets, please check uptime value from your board (rcommand 0x81) after you encountered zero values.
@HouzuoGuo Your log shows:
Thank you, i’ll dig deeper and look for the cause of a full lora send queue. According to TTN console, the transmitter indeed was sending consecutive readings of 0 PAX.
In the meanwhile, here’s the dashboard: https://admin.tago.io/public/dashboard/5ff7361709890a0027afb78f/b97d8a56-926e-4c8b-b0cc-46d8633eced3
My temporary, auto-reset patch is running on the transmitter right now, i want to see how often does the auto-reset have to happen.
Check uptime value of the board, to ensure it has not unsolicited resets. Check frame counter in TTN console, to ensure there are no rejoins.
I never saw this issue, and no other user reported this yet.
So, if this is a bug in the code, i will be very interested to find out the root cause.
@HouzuoGuo Can you, please, post your paxcounter.conf
here, thanks.
and one more hint: in vscode, write log file with pio device monitor -f log2file
and another hint: if you're using TTN as LORAWAN network, you may activate data storage integration in your TTN application. Then retrieve the raw payload from the database to check.
Thanks for the hints!
Here's the branch with my configuration files, couple of cosmetic changes made for the OLED display, and couple more tweaks including the auto-reset patch:
https://github.com/HouzuoGuo/ESP32-Paxcounter/commits/master
Here is the paxcounter.conf:
https://github.com/HouzuoGuo/ESP32-Paxcounter/blob/master/src/paxcounter.conf
(BTW, the ABP keys in https://github.com/HouzuoGuo/ESP32-Paxcounter/blob/master/src/loraconf.h are no longer current)
According to the data of the past two days, as plotted on the dashboard, the auto-reset patch seems to have kicked in 15 times, the interval in between is rather random:
Next, I'll collect the log output in a text file and see if there are more clues.
On a related note, do you like this new GPS info display, with more details such as UTC time and altitude? If so, I'll make a PR for it:
Thanks for your improvements here.
You're welcome to redesign screen layout. If you make any changes to the screen layout, keep in mind that same layout must fit on TFT displays (e.g. TTGO T-DISPLAY or M5 stack), too.
We should keep focus on this weird issue with zeroes in the counter. I have no clue what could cause this, and i can not reproduce this issue on any of my boards, including a T-Beam v0.7 which runs for days now.
Thus, the issue may depend on local context, e.g. power supply / timezone / Lorawan network or parameters / board hardware ...
I suspected that the power supply from my laptop's USB port may have been unstable, after digging around in the source code, I managed to:
In addition to couple of cosmetic changes, and automatically resetting the microcontroller if there have been consecutive readings of PAX number 0 for 10 minutes: https://github.com/HouzuoGuo/ESP32-Paxcounter/commit/c09a52cef8d72f64b3e40ae2560ec56e5290c794
My T-Beam is running the code from that forked master branch, the LoRa outgoing packet queue is no longer filling up, the number of queues messages often reads 0 and it is always below 4. Although according to both OLED display and TTN application data console, the PAX counter reading still drops to 0 (and stays at 0) quite often:
Next round, I'll leave the board connected to laptop and collect the serial output into a file.
Do you have a second board to test? Maybe it's hardware problem.
I put the code of current master branch on T-Beam v0.7, but could not reproduce this issue yet.
To check power supply, please dismount 18650 battery from T-Beam while testing / logging, to reduce USB current.
That's a good point, perhaps the board itself is faulty. I don't have another T-Beam v0.7, however there are two v1.1 boards coming in couple of days via mail. Let me open a new issue when this problem happens on another board.
@HouzuoGuo As is see on your dashboard, you got it up and running now without zero drops? What did you change?
@cyberman54 hehe - you were totally right, the ttgo t-beam v0.7 board must have been faulty.
I put it away in favour of a newly arrived t-beam v1.1, along with some bme280 sensor boards. This new t-beam works far better and pax counter has been working fine.
Good day!
According to my observations made on this TTGO T-Beam v0.7, the PAX counter (WiFi + BLE combined) always drops to 0 after the microcontroller has been running for couple of minutes (in some cases hours).
Points of interest:
Here are the latest log entries, earlier entries were lost from vscode console:
Logs