Aligning pax values & adjustment best practices

[cyberman54]

@Qmick01 wrote:

This is not an issue, more a couple of thoughts and questions re Paxcounter 3.4.4

I have been doing some tests on this build. I have carried two units into open spaces (no people) and then some more confined spaces, cafes, supermarkets etc where the number of people is typically 5 - 20 at any time. The overall results are interesting and pretty good.

1. These two devices never see my phone - an Android.
2. The count shown versus the number of people present is pretty good
3. These counts are substantially lower than version 3.2 which I am running on about 20 other devices at present.

The reason this is an important thing for me is because the existing estate of sensors reports into several dashboards which then modify the reported numbers to align more accurately with headcount and after this process the numbers are quite good.

And so based on these tests the 3.4.4 code seems to be able to get to a good number without any manual adjustment after the fact - this is good.

Some questions:
Does the new code recognize both Android and Apple devices and are most versions supported or is there a cut-off on year and model of phone?
How does the 3.4.4 code know it has a randomized MAC ? Is this recognized in the nature of the MAC?
What was the reason the older code had a higher count?

As I have learned a good deal about deploying and maintaining these units I was wondering if you know of others I might talk to who are also using them on a largish scale and with whom I could contact so we might share best practices?

Many thanks in advance for your thoughts.

[cyberman54]

Does the new code recognize both Android and Apple devices and are most versions supported or is there a cut-off on year and model of phone?

The sniffing logic is not part of paxcounter code. It's the core of the libpax lib which is used by paxcounter. Libpax does no kind of fingerprinting or filtering devices. It just processes MAC addresses which are received by the radio.

How does the 3.4.4 code know it has a randomized MAC ? Is this recognized in the nature of the MAC?

Wiki: "Addresses can either be universally administered addresses (UAA) or locally administered addresses (LAA)."
Libpax checks the U/L bit of every received MAC, to count only locally administered (= random) MACs. Assumption behind this is, that many headless devices use universal addresses, while human carried devices like smartphones use random MACs.

What was the reason the older code had a higher count?

Prior versions of paxcounter code did not rely on libpax lib and did count all MAC adresses, regardless of U/L bit. That's why counts were higher.

/cc @Qmick01

[cyberman54]

These two devices never see my phone - an Android.

If you are on Wifi sniffing, and your Android is connected to a Wifi network (Access point), disconnect it from the Wifi network.

[Qmick01]

No it's all BLE only. I don't do WiFi sniffing.

…

On Sun, 4 Dec 2022, 17:31 Verkehrsrot, ***@***.***> wrote: These two devices never see my phone - an Android. If you are on Wifi sniffing, and your Android is connected to a Wifi network (Access point), disconnect it from the Wifi network. — Reply to this email directly, view it on GitHub <#922 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOZZCOZHGG6UPYEK5BCIYLLWLTIPNANCNFSM6AAAAAASTOZCWI> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>