Wifi/BLE Paxcounter Project with ESP32 boards

End Devices (Nodes)
81

Tested in dense environment. Display now working like a charm, fast update and no errors.

But the TTGOv2 now occasionally resets after a few minutes, did not see it climbing higher than 400.

With older versions i came until ~3500.

Not sure what causes these resets. I will try to reproduce it while logging serial.IMG_20180405_095419

2 Likes
82

can this be used as a detector for intelligent alarmsystems , not based on video but based on this technology + lorawan ?

83

One of my ideas behind the Paxcounter technology would be to do fourier analysis on the gathered data, and implementing this on the node, not on the server.

84

if you place two a few hunderd meters apart you could detect to which direction the crowd is movingā€¦ even if they are running or walking normally ?

85

Yes, that would be possible, but this would cause further privacy concerns.

The usual mechanism in commercial appliances for this kind of tracking is to transfer and store all collected hash values on a server, which then does the analytics. Thats for example what mobile network providers do. Of course not under their company names, the ususally have small unknown daughter companies for this sensible business. E.g. Deutsche Telekom -> Motion Logic or Spain Telefonica -> Next

This is not my intention with the Paxcounter project. I want to build an intelligent counter node that respects maximum privacy and does not pollute the LoRaWAN network by transferring hash values to a cloud. So we need a new clever solution.

86

Intelligence uses this technology mobile ā€¦ just set it up somewhere and it acts like a normal cellā€¦ all phones in the area (think protest demonstrations) are recorded.

but what I suggested was only detecting a sudden 'group movement from A to B, detecting a difference in the 'normal pattern, and lorawan is probably not the right platformā€¦ to much data :sunglasses:

87

Great,I have also reset on V2 while V1 works like a charm with same firmware ;-(

88

@Charles one minor bug, but is logical, not a display error: if BLE scan ends with result 0, the third ā€œ.ā€ of ā€œBLE scanā€¦ā€ sticks in display. see picture.IMG_20180405_135607

89

oh, yes Iā€™ll fix it

Fixed in PR :wink:

90

with latest commit display error came back :frowning:

(see missing ā€œiā€ in join message)IMG_20180405_153626

91

I didnā€™t changed anything on OLED between this morning and the fix Iā€™ve just done ;-(

Would you try the version you tested this morning? and just uncomment the line ~277 of main.cpp to fix the 3rd dot display?

        //u8x8.clearLine(3);
92

I flashed your last pull requested before merging it, so itā€™s the code with your latest modifications - quite a lot :slight_smile:
Display is also slightly flickering now, that was not with that version from today morning.

93

@charles i managed it to capture a serial log while TTGOv2 resets in a very dense environment. The crash happened while BLE scan is running and capturing a high number of BLE MACs.

Will try again if it this can be reproduced. If yes this may be an issue with N. Kolbanā€™s Bluetooth stack, maybe not prepared for high workloadsā€¦

[I][macsniff.cpp:74] mac_add(): BLE  RSSI -82dBi -> MAC xxxxxxxx -> Hash E9E8 -> WiFi:95  BLE:183  already seen
[I][macsniff.cpp:74] mac_add(): BLE  RSSI -77dBi -> MAC xxxxxxxx -> Hash BA6D -> WiFi:95  BLE:184  new
[I][macsniff.cpp:74] mac_add(): BLE  RSSI -89dBi -> MAC xxxxxxxx -> Hash C91A -> WiFi:95  BLE:185  new
[I][macsniff.cpp:74] mac_add(): BLE  RSSI -85dBi -> MAC xxxxxxxx -> Hash 3867 -> WiFi:95  BLE:185  already seen
[I][macsniff.cpp:74] mac_add(): BLE  RSSI -87dBi -> MAC xxxxxxxx -> Hash C0E4 -> WiFi:95  BLE:186  new
[I][macsniff.cpp:74] mac_add(): BLE  RSSI -86dBi -> MAC xxxxxxxx -> Hash B379 -> WiFi:95  BLE:187  new
E (66896) BT: btc_search_callback  BLE observe complete. Num Resp 133

[I][macsniff.cpp:74] mac_add(): BLE  RSSI -77dBi -> MAC BA060DB0 -> Hash 79AC -> WiFi:95  BLE:187  already seen
abort() was called at PC 0x40162643 on core 0

Backtrace: 0x4008af28:0x3ffe2e80 0x4008b027:0x3ffe2ea0 0x40162643:0x3ffe2ec0 0x4016268a:0x3ffe2ee0 0x401501cb:0x3ffe2f00 0x401503f2:0x3ffe2f20 0x400d68ad:0x3ffe2f40 0x400d69f1:0x3ffe2f60 0x400d4469:0x3ffe2fa0 0x400d4c5c:0x3ffe2ff0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0x40078000,len:0
load:0x40078000,len:11404
entry 0x40078a28
[I][main.cpp:439] setup(): Starting PAXCNT 1.2.94
[I][main.cpp:454] setup(): This is ESP32 chip with 2 CPU cores, WiFi/BT/BLE, silicon revision 1, 4MB embedded Flash
[I][main.cpp:455] setup(): ESP32 SDK: v3.1-dev-239-g1c3dd23f-dirty
94

Yes this makes sense, since itā€™s async, may be missing time to execute each callback and I found a bug in mac_sniff that was using too much time (try add to bles and wifis even if was already found in macs) Iā€™m fixing it

95

Could capture a second log, lucky me working in very well visited place :wink:
Again the crash happened while scanning BLE.

[I][macsniff.cpp:74] mac_add(): BLE  RSSI -81dBi -> MAC XXXXXXXX -> Hash 9AD2 -> WiFi:346  BLE:227  already seen
[I][macsniff.cpp:74] mac_add(): BLE  RSSI -93dBi -> MAC XXXXXXXX -> Hash D638 -> WiFi:346  BLE:227  already seen
[I][macsniff.cpp:74] mac_add(): BLE  RSSI -96dBi -> MAC XXXXXXXX -> Hash E688 -> WiFi:346  BLE:228  new
[I][macsniff.cpp:74] mac_add(): BLE  RSSI -87dBi -> MAC XXXXXXXX -> Hash 2CD7 -> WiFi:346  BLE:228  already seen
E (884735) BT: btc_search_callback  BLE observe complete. Num Resp 19

abort() was called at PC 0x40162643 on core 0

Backtrace: 0x4008af28:0x3ffe2de0 0x4008b027:0x3ffe2e00 0x40162643:0x3ffe2e20 0x4016268a:0x3ffe2e40 0x40150661:0x3ffe2e60 0x401503e4:0x3ffe2e80 0x40153a09:0x3ffe2ea0 0x401540c7:0x3ffe2ec0 0x40154111:0x3ffe2ef0 0x400d674e:0x3ffe2f10 0x400d68d6:0x3ffe2f40 0x400d69f1:0x3ffe2f60 0x400d4469:0x3ffe2fa0 0x400d4c5c:0x3ffe2ff0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0x40078000,len:0
load:0x40078000,len:11404
entry 0x40078a28
[I][main.cpp:439] setup(): Starting PAXCNT 1.2.94
96

Backtrace shows same PC in both cases. So we have a clear single root cause.

97

Optimization on add pushed, give it a try ?

98

And a 3rd one, again reset while BLE scanning and same PC in backtrace. Gotcha.

[I][macsniff.cpp:74] mac_add(): BLE  RSSI -90dBi -> MAC XXXXXXXX -> Hash E17F -> WiFi:406  BLE:231  new
E (435608) BT: btc_search_callback  BLE observe complete. Num Resp 39

abort() was called at PC 0x40162643 on core 0

Backtrace: 0x4008af28:0x3ffe2de0 0x4008b027:0x3ffe2e00 0x40162643:0x3ffe2e20 0x4016268a:0x3ffe2e40 0x40150661:0x3ffe2e60 0x401503e4:0x3ffe2e80 0x40153a09:0x3ffe2ea0 0x401540c7:0x3ffe2ec0 0x40154111:0x3ffe2ef0 0x400d674e:0x3ffe2f10 0x400d68d6:0x3ffe2f40 0x400d69f1:0x3ffe2f60 0x400d4469:0x3ffe2fa0 0x400d4c5c:0x3ffe2ff0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0x40078000,len:0
load:0x40078000,len:11404
entry 0x40078a28
[I][main.cpp:439] setup(): Starting PAXCNT 1.2.94
99

With the latest PR ?

100

All your commits until ā€œFixed display bugā€,
but not the latest one ā€œOptimize add function, fixed New/Already Seen bugā€.
I will try again with the latest, stay tuned.