Same do i.
Can’t believe that there is no uint16_t meter value in Cayenne… ?
1 Like
That’s funny, I already asked that feature (just counter data) on mydevice forum, in this post one year ago
And also when they claimed LPP 2.0 on this one 5 month ago (seems you asked too 
)
I love cayenne look and feel, but for professional business I can’t use it, they’re missing 2 mandatory features:
- basic counter (yeah, of course, never used in industrial companies) and
- the ability of multitenant account/data sharing, can’t tell my customers to give me their password to see wha’ts going on. This feature is awesome on TTN console
2 Likes
Hi, we are looking for a solution to count people passing by (i.e. cyclists and maybe also pedestrians). I tried the Paxcounter but it seems it is too slow to detect a reasonable percentage of people for a solid extrapolation.
13 WiFi channels are switched every ½ s which means 6.5 s for a complete scan – and an “attention span” of < 8% for each channel. I am pretty sure this does not suffice for a person passing by on a bike.
Anyone here with experience on this issue? Alternatives? One could think of a cluster of ESP boards (maybe ESP8266, not ESP32) to parallelize the scan, but of course this would consume much more energy. Ideas?
1 Like
You can try using shorter scan times on wifi and bluetooth channels. The scan times are configurable in paxcounter.conf, so it is comfortable to test different settings for your setup. Maybe shorter scan times catch more pedestrians passing by.
Bluetooth scan is much faster than Wifi scan, since only 3 (instead of 13) channels need to be scanned to detect advertisings. So you may want to focus on Bluetooth, not Wifi, for your use case.
Paxcounter Software does Bluetooth and Wifi scanning in parallel.
Just some intermediate results of our PAX counter deployment at #Roverway:
1 Like
I was just wondering about that. Since it is a combination of bluetooth and wifi and time present to be able to catch devices of which some may be radiating nothing. Some people may be counted double and others not at all which may even cancel out errors to some degree. Are there already any numbers or guestimates of the correlation with real-world attendance?
1 Like
I just made a single scan in the restaurant and counted approximately 110 persons. This means that about 75% is counted or has a smartphone with Wi-Fi enabled.
I ignore ble because at the time of counting only 3 ware counted
2 Likes
I see. But the relative “attention span” aka “duty cycle” remains at < 8% for each channel. This in combination with a quite short timespan a person passing by is in reach of the counter makes it difficult to get a countable packet from each person. So the 75% ratio of detection Remko has mentioned will drop significantly in our setup, and extrapolation will be unstable, I’m afraid.
I still have to understand the low-level mechanisms (WiFi as well as Bluetooth) to appraise the counter’s mode of operation in detail.
This result could point to an issue with the BLE filtering logic in paxcounter (blescan.cpp). BLE has a large set of options to filter devices based on their advertising payload. The paxcounter code for BLE scanning is still very simple. I’m sure improvements are possible here. Would be great if someone makes pull requests…
is ‘out of BLE range’ also possible ? … people walking into the restaurant and maybe take a seat 25 meters from esp board ?
is possible, yes. Wifi range seems often greater than Bluetooth range.
But i suspect the filters in blescan.cpp also have bugs.
But nice to see that it seems to work pretty good in that real world usecase!
And is so easy to install with TTN.
Mine is at home, locate at the window facing the street. You can really see a pattern with rush hours morning / late afternoon; but bluetooth is largely at zero, even when I am close to the device…
Today i finished a special paxcounter module for integration in a tube.
17mm width and 6mm height was the target.
Mission completed - do it yourself! 
5 Likes
New v1.4.2 of paxcounter software released today:
Some of the new features added in this and previous versions:
- Send Queue implemented, this buffers data while LoRaWAN connection is busy (e.g. waiting for duty cycle or join)
- Beacon proximity alert, sends an alarm via LoRaWAN if a preconfigured MAC address (wifi or bluetooth) is seen. Beacon MACs can be added remotely.
- Payload can be sent to local wired interface in parallel, useful if device has no LoRa
- 4 different payload encoders selectable, this makes it easy to integrate with different frontends, e.g. myDevices Cayenne
- Remote command interpreter now accepts multiple commands per downlink, giving improved usability and saving downlink airtime
- code migrated to run under current arduino-espressif32 core v1.2.0
- PSRAM support (e.g. now 4 MB free RAM for storing hashed MACs on a TTGO T-Beam)
- Interrupt routines are now esp32 hardware timer controlled, for better performance
- Code modularized, giving you better overview for improving by your pull requests!
4 Likes
Introducing Paxcounter TUBE:
A LED tube, lightning and counting.
Replacing conventional lightning tubes, saving energy. This is eco & smart building technology! 
1 Like
Any hints of what to change for this to work on AS2 923-925Mhz frequency in Lora?
You need to change code of lmic library, since there is no default configuration in lmic for AS923.
I have no experience how to do this. So i can only point you to some sources which may help you to figure out how to do it:
Furthermore you should change the wifi parameters in paxcounter.conf according to the wifi frequency regulation of your country, i.e. channels.
> // WiFi scan parameters
> #define WIFI_CHANNEL_MIN 1 // start channel number where scan begings
> #define WIFI_CHANNEL_MAX 13 // total channel number to scan
> #define WIFI_MY_COUNTRY "EU" // select locale for Wifi RF settings
1 Like
Thanks - I thought the same so I worked on that.
I have done the work based on the code of https://github.com/orenonline/arduino-lmic-as923 but unfortunately your code has additional, I believe, debugging messages and display-related codes modified from the official LMIC library so I cannot figure out another neat way other than manually compare your modified LMIC library and that of the link above.
I have a copy of the modified
config.h
lmic.c
lmic.h
lorabase.h
under
lib/arduino-lmic-1.5.0-arduino-2-tweaked/lmic/
to basically added the channel plans and modified the code so it’s working quite nicely now. Of course one has to change the paxcounter.conf
// Select frequency band here according to national regulations
//#define CFG_eu868 1
//#define CFG_us915 1
#define CFG_as923 1
keeping the integrity of your tidy code.
And on top of that, the author of above also had a few lines of code modified in radio.c and I incorporated that.
However, I don’t understand your code on src/display.cpp
// helper string for converting LoRa spread factor values
#if defined(CFG_eu868)
const char lora_datarate = {“1211100908077BFSNA”};
#elif defined(CFG_us915)
const char lora_datarate = {“100908078CNA121110090807”};
So I just made up a figure so the whole code complied.
// helper string for converting LoRa spread factor values
#if defined(CFG_eu868)
const char lora_datarate = {“1211100908077BFSNA”};
#elif defined(CFG_us915)
const char lora_datarate = {“100908078CNA121110090807”};
#elif defined(CFG_as923)
const char lora_datarate[] = {“100908078CNA121110090807”};
I tested it with my RAK831 gateway configured to operate on AS923 frequency and my node is Heltec Wifi Lora 32, it all works now apparently. PAX is counting and payloads are being sent to the gateway with the correct frequency and spread factor etc. as shown on the TTN console.
My question now @Verkehrsrot is: I am quite new to all these and I haven’t contribute much in github that way, shall I send you the modified code separately so you can consider incorporate it in the next version (I hope. Because LoraWAN needs some love from Europe to Asia and other regions! I still struggle with other region / frequency related issues such as antenna not built to work on 923-925Mhz although the manufacturer claimed to) or shall I fork it or make a pull request (again I am not very experienced wih github on that for the best practice under this circumstance)?
I am not 100% convinced the code I modified was good but apparently it works.
Sorry it’s a bit long but I realise a lot of you are on European time zone while I am on Asian time zone so it’s better to be long-winded…
Please make a Pull Request, using the current master version as base.
Can you confirm if the code works with this board:
https://www.aliexpress.com/store/product/TTGO-ESP32-SX1276-LoRa-868-915MHz-Bluetooth-WI-FI-Lora-Internet-Antenna-Development-Board-for-Arduino/2090076_32845370112.html?spm=2114.12010608.0.0.3e5156341tAQdC
It does not have oled. I believe it is the TTGO v1 but I am not sure.
The code refers to oled for the v1 but this board does not have oled.
Cheers