Wifi/BLE Paxcounter Project with ESP32 boards

End Devices (Nodes)
405

I also operate some test devices which “endless” uptimes.
It seems all major bugs in the software were catched over the last months.
So we freeze it now :wink:

2 Likes
406

Paxcounter repository v1.7.7 is now PlatformIO 4.0 ready.

Note: There were some major changes to platformio.ini.
Target board is now specified in section [board], like

[board]
halfile = generic.h
2 Likes
407

Paxcounter v1.7841 is out now.

  • Bosch BME sensor software was updated to current Bosch BSEC 1.4.7.4
  • Wifi sniffing code was made slightly more efficient
  • Some bug fixes in i2c bus locking and interrupt masking
3 Likes
408

Paxcounter v1.7.93 is out now:

  • LMiC now running in own task with raised priority
  • Relaxed lmic clock error procentage (to prevent LoRaWAN join problems)
  • Removed arduino loop task
  • Removed BME reading task
  • Improved GPS time handling (experimental, precision still bad ~1sec)
  • Update vendor_array.h with new vendor codes
  • Added TinyPICO board
  • Added ledmatrix footfall line diagram
2 Likes
409

Hi Amedee, can you point any resource on how you do it ? I´m struggling on parsing the data as it comes in multiple messages, I use TTN->Cayenne and getting the data from ttn with node-red, thanks in advance

410

I’m using a quite simple construct for node-red: a ttn-message node for every paxcounter device, an json node for converting the data into json and a influxdb-out for storung the data.

Summary

[{“id”:“10b97b38.df7dc5”,“type”:“ttn message”,“z”:“2c645e49.99b922”,“name”:“ttgo-1”,“app”:“734f3e5e.88104”,“dev_id”:“ttgo-1”,“field”:"",“x”:90,“y”:4540,“wires”:[[“6bb407e3.5bd1d8”]]},{“id”:“6706b764.637678”,“type”:“influxdb out”,“z”:“2c645e49.99b922”,“influxdb”:“79d6a2c4.84465c”,“name”:“paxcounter”,“measurement”:“ttgo1”,“precision”:“s”,“retentionPolicy”:"",“x”:650,“y”:4540,“wires”:[]},{“id”:“6bb407e3.5bd1d8”,“type”:“json”,“z”:“2c645e49.99b922”,“name”:“JSON für String -> Int”,“property”:“payload”,“action”:“obj”,“pretty”:true,“x”:360,“y”:4540,“wires”:[[“6706b764.637678”]]},{“id”:“734f3e5e.88104”,“type”:“ttn app”,“z”:"",“appId”:“paxcounter-shinebar”,“region”:“eu”,“accessKey”:“ttn-account-0815”},{“id”:“79d6a2c4.84465c”,“type”:“influxdb”,“z”:"",“hostname”:“127.0.0.1”,“port”:“8086”,“protocol”:“http”,“database”:“paxcounter”,“name”:"",“usetls”:false,“tls”:“f7c4764f.769aa8”},{“id”:“f7c4764f.769aa8”,“type”:“tls-config”,“z”:"",“name”:“local-tls”,“cert”:"",“key”:"",“ca”:"",“certname”:"",“keyname”:"",“caname”:"",“verifyservercert”:false}]

411

Paxcounter v1.8.0 is out now:

  • LMiC stack now using hardware interrupts for SX1272/76 for improved timing accuracy (instead of polling, which was used before)
  • Reworked LMiC tx/rx functions, should improve stability
  • Voltage and BME data transmit now remote configurable
  • TTGO T-Beam V10 support added (AXP192 PMU support implemented)
  • MAC network command sniffer (experimental, not fully working yet)
412

Hi there I´ve added a new sensor to the sensor.h size and bytes, payload plain it show correctly the data and that provides several values about gases but I want to use the Cayenne Payload (=3). But I receive in TTN something like payload not provided, other sensors like BME680 and GPS gives the right data, any help will be appreciated !! THanks in advance

413

You must add your code for preparing the payload in payload.cpp line 412ff:

void PayloadConvert::addSensor(uint8_t buf[]) {

#if(HAS_SENSORS)
// to come
/*
uint8_t length = buf[0];
memcpy(buffer, buf+1, length);
cursor += length; // length of buffer
*/
#endif // HAS_SENSORS
1 Like
414

thanks @Verkehrsrot I will try

415

Paxcounter v1.8.2 is out now:

  • raised LMIC task priority to stabilize downlink command reception
  • update ESP-IDF to v3.3
  • TTGO T-Beam V10 battery monitor enhanced (now displaying battery charging/discharging current in mAh)
1 Like
416

Hey there,
I’m currently trying to count people using this, I have a Things Indoor Gateway and using the TTGO T3_1.6
The good news is it’s counting people in small numbers fairly accurately. The bad news is it seems to top out around 20 even when there are far more devices nearby.
Is there anything known about limitations on counts? Anything I should be considering about wifi density, or ability to track devices when they’re in certain states (connected to wifi vs not)

I appreciate any guidance!

417

What do you mean by “top out”? Please explain.

418

We never get a higher count. Even if there are 160 people nearby, we still get a max count of ~20.
We’ve tested this on multiple of the same end device.

419

Then you probably have wrong expectations.
In non cumulative mode the counter runs for (configurable) 60 seconds.
Since ESP32 has only 1 radio, but Wifi is using 13 channels, the channels must be rotated. Thus higher volumes of devices will need some time to capture. To try configure the paxcounter for cumulative mode. Then it counts without resetting it’s memory every 60 seconds.

420

Interesting! So you’re saying that I could either increase the count time or configure cumulative mode? Or are those the same thing?
Is there a better hardware solution for counting these higher numbers?
Thanks for your replies!

421

You can do various optimizations:

  • set the count cycle time while wifi devices are counted (and memorized) until counter is reset (and memory is cleared)
    -> parameter SENDCYCLE in paxcounter.conf
  • set counter mode to cumulative (sum up “forever”) or non cumulative (sum up only over 1 count cycle)
    -> parameter cfg.countermode in cfgmanager.cpp or send remote command 02 01
  • set wifi channel rotation speed
    -> parameter WIFI_CHANNEL_SWITCH_INTERVAL in paxcounter.conf
  • disable vendor OUI filter
    -> parameter VENDORFILTER in paxcounter.conf
422

F3B39D90-C4FA-4830-84E7-BC83AF16DCA4

Man bekommt nie das Optimale.

Hi,
my experiences with the ttgo node and the Heltec v2 Node with modified WiFi antenna. Best results for WiFi scanning with modified Heltec node… but no OTAA connection. WiFi scanning not so sensible with ttgo , but OTAA works.

What are your best nodes for paxcounter installations ?

Best regards
Frank

424

I got reports by a couple of users complaining OTAA is not working properly with LMIC on Heltec nodes, i.e. Heltec Lora32 as well as Heltec Stick.

I can reproduce this issue on my Heltec Lora32 v1 and v2 boards, but did not manage yet to find out what’s the root cause.

Some assumptions:

  1. Timing jitter due to tolerances of the CPU oscillator, in conjunction with LMIC running on top of ESP32 RTOS
  2. Hardware RF issue in the reception path
  3. Software issue with LMIC in conjunction with RFM95 circuit on Heltec boards

I tried to mitigate 1) in the paxcounter software by using hardware interrupt driven timestamping of DIO LMIC events, but not success so far.

A path to further analyze this issue:

  • install MCCI LMIC OTAA EU868 compliance script on a Heltec node and write log
  • write gateway log while joining
  • compare both logs
425

What exactly is meant with OOTA is not working (properly)?

Are the symptoms comparable to LMIC on slower 8-bit AVR ATmega328 and ATmega32u4 MCUs at 8MHz where OTAA fails to join on lower spreading factors but after many minutes succeeds to join on a higher SF?

Could loosening/relaxing LMIC timing be helpful here?