Ok, I need to focus on other work now and this evening, talk to you later. Are you on TTN slack ?
same to me.
Yes, i am on TTN slack
Tested with the latest mod in mac_add.
Still same issue: devices resets at around 500 counts.
Is it more friendly on a dashboard?
Hey, wow, that looks like there is something with Cayenne LPP in preparation!
@charles iām investigating on the reset issue with the BLE stack. Found something in N. Kolbanās BLE C++ description that may apply to the issue:
Finally, drill into the āBluedroid Bluetooth stack enabledā and set the āBluetooth event
(callback to application) task stack sizeā to be 8000 (or more).
This adresses the ESP-IDF. Iām now trying to find out how to set the bluetooth event stack size at runtime or by compiler directive in PlatformIO. Then will try again in dense environment. German āMedia Marktā is a good place for this purpose, making lots of air pollution with bluetooth advertisers
Did some minor display cosmetics.
Found this one in esp32-arduino:
#ifdef CONFIG_NEWLIB_NANO_FORMAT
#define TASK_EXTRA_STACK_SIZE (0)
#else
#define TASK_EXTRA_STACK_SIZE (512)
#endif
ā¦
#define BT_TASK_EXTRA_STACK_SIZE TASK_EXTRA_STACK_SIZE
Maybe increasing this value solves the reset issue? I tried a define in compiler directive, but compiler gives warning
warning: āBT_TASK_EXTRA_STACK_SIZEā redefined
#define BT_TASK_EXTRA_STACK_SIZE TASK_EXTRA_STACK_SIZE
Where did you put the define? I think it need to be defined in idf ble source code ;(
I tried a define 8n platformio.ini as compiler option, but does not work, gives redefined error.
Yeah because it must hard defined in ble stack code library
Maybe for the simple counting use case we donāt need the separate high level BLE stack from N. Kolban, but could do everything with native Arduino-ESP32 BT stack.
But this wouldnāt solve the problem to increase the Task stack size, too.
What if we compile the whole Arduino-ESP32 lib separately with increased stack size, generate object file and integrate this?
Oh I even didnāt noticed we had 2 stack sorry ? Let me check over the we
I checked this symbol adding in main.h
to see what value it has
#ifdef CONFIG_NEWLIB_NANO_FORMAT
#error "ASK_EXTRA_STACK_SIZE 0"
#else
#error "TASK_EXTRA_STACK_SIZE 512"
#endif
looks like extra stack size already set to 512
So solution is to change in .platformio\packages\framework-arduinoespressif32\tools\sdk\include\esp32\esp_task.h
/* Bt contoller Task */
/* controller */
#define ESP_TASK_BT_CONTROLLER_PRIO (ESP_TASK_PRIO_MAX - 2)
#ifdef CONFIG_NEWLIB_NANO_FORMAT
#define TASK_EXTRA_STACK_SIZE (0)
#else
#define TASK_EXTRA_STACK_SIZE (512)
#endif
#define BT_TASK_EXTRA_STACK_SIZE TASK_EXTRA_STACK_SIZE
#define ESP_TASK_BT_CONTROLLER_STACK (3584 + TASK_EXTRA_STACK_SIZE)
around line 42 by setting value to 1024
/* Bt contoller Task */
/* controller */
#define ESP_TASK_BT_CONTROLLER_PRIO (ESP_TASK_PRIO_MAX - 2)
#ifdef CONFIG_NEWLIB_NANO_FORMAT
#define TASK_EXTRA_STACK_SIZE (0)
#else
#define TASK_EXTRA_STACK_SIZE (512)
#endif
#undef TASK_EXTRA_STACK_SIZE
#define TASK_EXTRA_STACK_SIZE (1024)
#define BT_TASK_EXTRA_STACK_SIZE TASK_EXTRA_STACK_SIZE
#define ESP_TASK_BT_CONTROLLER_STACK (3584 + TASK_EXTRA_STACK_SIZE)
I logged an exception today and decoded it, see below.
Iām not sure how to read the stack results, but it looks like the crash happenes in Bluetooth-stack?
abort() was called at PC 0x40162673 on core 0
Backtrace: 0x4008af28:0x3ffe2e70 0x4008b027:0x3ffe2e90 0x40162673:0x3ffe2eb0 0x401626ba:0x3ffe2ed0 0x401501fb:0x3ffe2ef0 0x40150422:0x3ffe2f10 0x400d68d5:0x3ffe2f30 0x400d6a19:0x3ffe2f50 0x400d4451:0x3ffe2f90 0x400d4c44:0x3ffe2fe0
Rebooting...
Decoding stack results
0x4008af28: invoke_abort at .../ESP32/esp-idf-public/components/esp32/./panic.c line 139
0x4008b027: abort at .../ESP32/esp-idf-public/components/esp32/./panic.c line 148
0x40162673: __cxxabiv1::__terminate(void (*)()) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 47
0x401626ba: std::terminate() at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 57
0x401501fb: __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*)) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc line 87
0x40150422: operator new(unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc line 54
0x400d68d5: std::vector >::vector(std::vector > const&) at ...\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\5.2.0\ext/new_allocator.h line 104
0x400d6a19: BLEScan::start(unsigned int) at .piolibdeps\ESP32 BLE Arduino_ID1841\src/BLEScan.h line 32
0x400d4451: BLECount() at src\macsniff.cpp line 150
0x400d4c44: sniffer_loop(void*) at src\main.cpp line 343
For me this looks like the BLEScan cannot handle more than a few hundred advertising BLE devices, then it crashes.
I opened issue for BLEScan.h at https://github.com/nkolban/esp32-snippets/
I created a little breakout to be able to also measure battery voltage and display percentage on screen
Waiting to receive them
Today i released Paxcounter software v1.3.0
āMajor release after refactoring bluetooth and display control part of codeā
New functions:
- bluetooth scan now runs parallel to wifi scan in separate RTos task
- enhanced bluetooth device filtering logic, based on evaluating GAP data (to be further worked out)
- RSSI limiter now controls wifi and bluetooth
Non functional changes and bugfixes:
- new log level DEBUG (switch in platformio.ini), making log level INFO more silent
- binary size significantly reduced by removing BLE library (no longer needed at all)
- display now controlled by separate task with constant refresh rate (should solve display garbage problems)
- screen saver function disabled (to come back in future with better time management)
I found this thread today. Itās looks like a 100% fit. Currently Iām working on a similar project. The device we have developed is used as a Wi-Fi and Bluetooth scanner but needs internet connectivity and is mostly PoE connected. Core is a Raspberry Pi 3 model B+ with a Wi-Fi dongle in monitoring mode and a BT+BLE long range dongle.
After some ESP8266 projects, I already felt that the ESP32 could be used. LoRaWan makes it even more interesting.
Iām following TTN for some time now (followed a course in 2016 on the IoT tech day in Utrecht) but never started a project yet.
I ordered the suggested board on AliExpress (Heltec LoRa-32) and as soon it arrives will try to install the software.
Question: how often will the counting data be transferred via the TTN?