Wifi/BLE Paxcounter Project with ESP32 boards

Don’t modify the wifi timings in paxcounter.conf, since they were well tested in experiments.

A shorter time between switching the wifi channels speeds up the recognition of pax, but may result in less pax totals. If you need very fast recognition Bluetooth could be better because BT signals on only 3 channels (Wifi 13), so BT is faster. But there are usually far less BT than Wifi devices.

1 Like

@Verkehrsrot Is there anyway to prevent the Oled display from burning-in. e.g. screensaver that switches of the display after time-out?

Screensaver is already implemented, can be switched by remote command, look in the readme.md in rcommand table

Thanks for mentioning. I get confused because parameterisation is not consistent over config files and remote commands.

I can switch of the display. How do I switch on screensave?

yes, there were some breaking changes during growth of the software, since lack of a roadmap. The screen can only be turned off. What would be your suggestion for logic of screen saver?

@Verkehrsrot First I would like to express my apreciation for the work in PAXCounter. It is a huge job to keep it maintained and receive and react on all responces from users. From experience I know what it takes. I feel sorry for always only pointing on things that are not as opimized as one would like. Therefore this intermezzo; Thank you. I hope we can continue to work on and with PAXcounter.

With respect to the logic on screen saver: I can think of a timed state that, when screen saver is enabled, will switch of the display after a preset time and switch it on, on events like a keypress or when data is sent. So the display state kan be: ON, SCREEN_SAVE, or OFF.

It might be possible to use the same variable for display on and off and add a third value for screensave:
0=off, 1=on, >1 is screensaver timeout in seconds.

Although I hve not fully examined the code, this seems initially an implementable solution.


yes, i think it can be done like that by using a Ticker.h counter. Can you open issue for this?


1 Like

First of all: thanks for the great Paxcounter! It’s working like a charm.
I’m using the TTGO Lora32 V2.1 1.6 an wonder if anybody has a 3d-Model for a nice case. The two on Thingieverse are sort of flimsy or not fitting really. I’m not really good in SketchUp so I hope someone did this before and is willing to share his results.

1 Like

I am disappointed…
I was expecting to see a packet counter roll-over at 64K, but is still counts up…


I am logging the packet count as the TTGO used to crash on a regular basis, and it allowed me to track how long it was operating before restarting.
I have updated the software a couple of months ago, and since then it is rock solid, not a single crash!


As an aside, if you really expected the counter to rollover:

1 Like

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:


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

halfile = generic.h

Paxcounter v1.7841 is out now.

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

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

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

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.


[{“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”:“”,“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}]

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)

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

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

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

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