Today new paxcounter software v2.1.0 was released:
New deep sleep mode
New mac filter logic (includes remove of formerly used vendor oui filter)
Wifi channel hopping can now be switched off (means sniffing is locked to first channel in band)
MQTT code reworked, to reduce disconnects
In deep sleep mode a T-Beam v1.0/1.1 with OLED display draws ~900µA battery power. Deep sleep cycle time can be configured by user. Thus, uptimes of weeks and even months are possible with a T-Beam with single 18650 cell - depending on how often the device shall look for pax (or transmit other sensor data).
Hi, first of all, congrats on this project and on growing community of TTN. I tried to read through almost all messages, but I don’t think i found an answer to my question.
I managed to get the Pax counter running with standard code and it seems to work (but the counted number of people around it, changes all the time, eventhough we’re testing it in the office).
My question is: When there are 2 people entering the office with 5 devices (one has 3 cell phones, one has 1 cellphone and 1 tablet). Is it possible to count them as 2, or only possible to count them as 5 ?
With these sorts of things you have to do some manual calibration / counting to get an average. So if you spend a day with a manual clicker (from Amazon or similar) and then compare with the PAX counter, you can get a ratio. Do that a few more times and it will get more accurate. After that, less accurate …
Apply some AI/ML at the edge/node and correlate pairs/triplets/quads of radio sets coming in together when same person arrives each time then you can be more precise…but likely requires longer term storage (at least of hashed MAC’s etc to avoid risk of privacy issues/breaches…if work premises write into employment t&c’s?) If a number of radios associated with given individual then even if only say 2 or 3 out of 4 active you can determine a given individual present…)
Hey @janjongboom HNY2U - its been a while since we saw you on the forum… (really since ‘The Sheep’!?) - is the above data/people extraction from Paxcounter a potential use for EI?
Only if you have some training data - which as well as the BlueTooth data you’d need some hard counts on the people passing in range of the counter.
Given that the majority of the population only carry one BT enabled / active device and a measurable number don’t have BT on and a proportion have a device with BT off or of too low a version to hear or no Bt, it’s a simple ratio. In London the ratio will be different than Bolton or Devon or Kendal or wherever. It just needs someone to stand there for a day or so. ML is a bit over the top in this case.
If you want to use it to track individual people, NSA style (GCHQ have already embedded implants via our Covid vaccinations so they don’t need to use BT), then that’s all about context & permission. I use it to unlock doors, a bugger when I don’t have one of my two phones on me. For staff members in the right environment it makes a great deal of sense over messing with an access control system.
For footfall in Castleton, live ML via video plays a part in terms of identifying ovals with a strip at the bottom and two roundish whitish circles above - this counts adults & young people who are on walking. But still needs validation with a hard count just to be sure.
If you are a shopping centre, this is a great application. If you are a nightclub, not so much.
First, thanks for your project cyberman54/ESP32-Paxcounter.
Wifi+Ble scan works fine in my new T-BEAM (T22_v1.1 20191212)
I can see data in my TTN Console, but I don’t see GPS data.
By default, GPSPORT is set to 4, but not work … and I try to set it to 1, to send combined GPS+COUNTERPORT payload, but nothing happens, only Wifi & BLE count devices are displayed with the payload decoder.
On the T-BEAM board, there’s a red led blinking … under the GPS chip, but never fix.
Perhaps you can try this sketch to reset the GPS.
The board with Meshtastic preinstaled can behave very odd.
If you have a version with the ublox M8N GPS chip you can expect problems with timesynchronisation.
There is already an open issue in the github an a solution in this thread a few weeks ago.
I try to upload T22-GPS-reset-v3, but it seems that doesn’t works.
Maybe I need to try this sketch ? T22-GPS-restoreFactory-v2.ino
My GPS module is NEO-6M.
What board do you recommend to avoid problems? If can have OLED, all the better.
It’s funny because Paxcounter is actually not a device but a piece of software that runs on different types of hardware devices (where each type can have different hardware versions).
I was wondering what options the “Hardware Ver.” dropdown provides, but currently there are none.
Is this by design? It’s not clear that no Hardware version must be selected here but a firmware version can be selected (because Firmware Ver. appears greyed out).
I would expect to to see a list with supported hardware under “Hardware Ver.” but maybe this can only contain numbers and not strings?
Anybody able to spot a (probably obvious) mistake?
I have configured the current Paxcounter code from Github for a Heltec V2 module I had in a drawer. I am in IE so EU868, and all looks right at a glance, I see join requests/accept in the console, time request is sent port 9 as code suggests and if I flip through the OLED screens, I have current time so LoRaWAN appears to be OK?
The Paxcount is updated but the board seems to be hanging waiting for a “rxstart”? The queued messages build up past 10 on the display. I can see the messages being queued on a serial console connected to the board’s USB.
Have I missed a basic setting in the paxcounter.conf? Any idea why I get no data transmitted even though queued?
FYI: the last activity on the Things Stack console is that time request being relayed to the Application server.
Any help appreciated!
It turns out that my V2 Heltec was in fact a V1 and I am guessing there is a DIO/pin-mapping issue. There is a merry dance on the IO between TX and RX and it looks like it was hanging waiting for a DIO that never happened…
It is possible, and indeed former version of paxcounter (v2.x) worked on “real” MACs.
But times and things changed: If you want to measure footfall, i.e. focusing on smartphones or other mobile devices carried by humans, you achive better results if you count randomized MACs. Because otherwise you will catch lot’s of unmanned devices like cars, wifi routers etc.
Also, focusing on randomized MACs makes it easier to keep your application GDPR compliant.
If a number of radios associated with given individual then even if only say 2 or 3 out of 4 active you can determine a given individual present…)
