To avoid brownout resets add this line to the <board.h> file and recompile code:
#define DISABLE_BROWNOUT 1
Yes, I’ve seen that when my devices are on the lab power supply: there seem to be a very short peek in current when it initializes, and if I set the the current limit too low it will reboot at that time.
To avoid brownout resets add this line to the <board.h> file and recompile code:
#define DISABLE_BROWNOUT 1
Does not work in Arduino, although this does;
Include some files
#include “soc/soc.h”
#include “soc/rtc_cntl_reg.h”
And then execute;
WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0); //disable brownout detector
Indeed, this doesn’t work.
I don’t know where to include the files. In <board.h> file? And how to execute the command? I wrote in <board.h> but this seems to be wrong.
Include the files at the top of the Arduino program before any functions.
This is the start of the program I was using to test the WiFi;
#include “WiFi.h”
#define LED1 2 //Arduino pin number for LED, when high LED should be on.
#include “soc/soc.h”
#include “soc/rtc_cntl_reg.h”void loop()
{
WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0); //disable brownout detectorSerial.println(“Set WiFi to Station mode”); //Set WiFi to station mode
Serial.flush();
WiFi.mode(WIFI_STA);
WiFi.disconnect();
The #define is for the paxcounter software only, not for Arduino in general.
The line must included in the hal file for the board, e.g. /src/hal/ttgobeam.h
Thank you. I did so but it worked not after doing a clean compile, but after quitting PlatformIO and relaunch. It’s strange!
Where can I find information about how to transmit data like temperature and battery voltage using the two analog channels t-beam sends to Cayenne?
And a last question: The paxcounter on all three of my devices (ttgov2, ttgov21 and ttgobeam) begin a new cycle count after counting about 120 to 180 pax. Can I change this cycle? I looked into paxcounter.conf but there seems not to be a possibility to change this cycle (yes, I found Scan Window, Scan Interval and Scan Duration but I suspect they have other purposes, am I right?
In paxcounter.conf line
#define SEND_SECS 30 // payload send cycle [seconds/2] -> 240 sec.
controls the timer trigger, when data is sent.
Whether pax count (and collected MAC data) is cleared or not, after count was sent, is controlled by the countermode. See readme.
0x02 set counter mode
0 = cyclic unconfirmed, mac counter reset after each wifi scan cycle, data is sent only once [default]
1 = cumulative counter, mac counter is never reset
2 = cyclic confirmed, like 0 but data is resent until confirmation by network received
Thanks a lot, I set counter mode.
Is it right that Cayenne LPP channel 21 is submitting Pax by counted WiFi and channel 22 by counted BLE? The value appearing in Cayenne is something like 0.05.
Where in the code can I multiply with the factor 100 to get integer values?
21 = Wifi, 22 = BLE is correct.
The bug with the missing *100 is already fixed in current development version.
Switch to branch “development” on githup repo and use this version, then you have the bug fixed.
PS: This is not a support channel.
RTC_CNTL_BROWN_OUT_REG = 0 is not a ultimate solution.
Default BROWNOUT level in ESP-IDF is already set to the bare minimum. So when the triggering event does happen and ignored - this may cause hidden memory corruption which will lead into “Guru Meditation Error” to come up later.
1 Like
Of course, whilst turning off brown out detect is a useful diagnostic tool, clearly any commercial bought gear should not need it.
Wonderful, it works perfect. And as I can see, you have the button on T-Beam got to work.
I found another issue regarding the *100 bug:
If count is set to 1, it can become negativ. In display it is shown correctly but Cayenne payload is wrong:
Please open issue on github since this is the forum for ESP32 boards in general, not for paxcounter software.
I don’t think this is an issue with Cayenne and payload encoding. The device sends obviously wrong count data:
WIFI 0xD098 = 53400
BLE 0xC418 = 50200
Cayenne interpretes this as negative float.
What values did the device show on the OLED display?
Are you sure that the display values were not affected by this error?
The display shows WiFi: 545 and BLE: 854 for T-Beam and WiFi: 539 and BLE: 504for ttgoV2.0
The display is not affected, I watched it counting up and there was no issue.
I found the (heavy) bug in the payload encoder and fixed it.
Please try current version in development branch.
If you use consecutive mode, be aware that RAM is very limited on boards without PSRAM, you have ~50KB which is enough for ~2.000 MACs. After reaching memory limit the counter sends current count and then resets counter to zero.
Are the changes only in payload.cpp? Then I only change this file.
Yes, only payload.cpp is affected.