January 26, 2020
I haven't posted anything on this project for a while as I was busy with other things. But I have recently had occasion to revisit and I have made some progress in understanding how best to use this device. The kind of testing I had been doing was either 1) looking at copious output on the serial monitor upon egress/ingress detection on the bench or 2) installing and simply using the device to count egress and ingress transits reported via LoRaWAN. The trouble is that things mostly work in mode 2) but when they didn't I couldn't really diagnose the problem.
For this round of tests, I mounted the device on the entrance way between our Hall and Dining Room where I work in such a way that I could maintain the serial tether to the laptop and record the details of the sensor device while I walked under the PeopleCounter. I streamed object temperature, object temperature theshold, and ingress and egress counts at rates from 10 - 80 Hz, captured the data from the serial monitor and plotted the data in a spreadsheet. This is a typical result:
The way the PeopleCounter works is that the sensors detect when a warm human crosses their line of sight, the time difference in the detection determines the direction of the transit. Simple. The sensors allow a threshold to be specified so that an interrupt is generated upon crossing the threshold, either upward or downward crossing. I have been using about 200 counts as an upper threshold to detect people crossing at a distance of ~1 - 2 foot from the sensors (where the head and shoulders are, more or less, when the device is mounted on an upper door jamb). The problem, as can easily be seen, is that the sensor responses drift, and if the baseline isn't corrected every so often, the drift will result in a large enough separation between the transit excursion and the threshold that it will never be crossed and the device will stop counting.
The threshold, then, has to be reset at a fast enough rate to keep track of any baseline drift but not too fast to cause a large power drain on the battery. But there is a problem here as well. If the threshold adjustment happens to coincide with a person transiting the device (as in the fourth peak in the figure), the baseline reset can be skewed upward. So some limit needs to be applied. Threshold management turns out to be critical to obtaining accurate performance. I expected this from the start, but didn't realize how difficult it would be to find a 100% accurate solution.
The good news is that the people counter accuracy is > 90% in simple tests that I can do around the house. We are about to test it "in the field" and will have data from more realistic deployments soon. I expect to learn a lot more about how such a device might behave in less controlled environments.