People Counter

October 5, 2023

The previous version of the People Counter worked as it was supposed to, at least in our limited testing around the house. The device was able to accurately count people coming and going through a threshold, and distinguish between the two. The counts were updated in real time via LoRaWAN to a laptop. So while the device met the "works like" criteria, there were some things needing improvement. First the cost of the two Calipile sensors ($7.58 each per 3000) was too high; ~$15 BOM cost just for the sensors. Secondly, because the temperature baseline has to be frequently reestablshed for maximum accuracy, the average current usage was ~100 uA (~900 mAH per year), seriously limiting battery life. Neither of these is a show stopper, just areas for improvement.

I tried using the much cheaper AK9754  (now obsolete), which worked well but has a limited range. I also tried using very cheap ($0.85 each per 100) Senba S18 analog PIR sensors. These work well for presence detection and might be able to work to detect ingress/egress. They also consume very little power. However, they are a little on the large side, require a lens for long range,  and being analog, I was never quite convinced of their reliability/accuracy. Still worth a try considering the cost, I just never got around to it.

Now, ST has introduced their version of a presence detector, the STHS34PF80 This is a single-pixel IR detector with embedded presence and motion detection APIs. I designed a 16 x 65 mm pcba with a form factor to allow easy mounting of an AA-sized 2400 mAH LiSOCl2 battery (holder on the back) with two STHS34PF80 on either end. One tricky bit was the STHS34PF80 only has a single I2C address, so I had to make use of a SN74LVC1G3157DRYR SPDT switch in order to separately communicate with each IR sensor on the I2C bus. I also added a mechanical switch and USB for convenience, a BME280 pressure/temperature/humidty sensor for environmental sensing, and a LIS2DW12 accelerometer for wake on motion. Any or all of these could be dropped in a final production design.

Digikey has these at ~$3.50 each per 2000 but there is no stock. Mouser prices are ~$5.47 each per 10 in stock. STStore has them for $3.68 each per 500. So the ~$7 BOM cost for the two IR sensors is half the cost of the Calipile.

Here is a github repository with some sketches showing how to configure the STHS34PF80 IR sensor for basic ambient and object temperature measurements as well as how to configure the embedded function algorithms and use them to detect presence and motion at up to 4 meters range. I also have a basic people counting sketch there which simply shows how to make use of all of the sensors on the board. This lacks the timing comparison that I have used for distinguishing egress and ingress events. But adding this is straightforward.

Ingress and egress detection works at 2 Hz IR sensor sample rate. This still needs to be optimized to maximize accuracy and eliminate false positives. The scheme relies on sensor interrupt on presence detection and comparison of the detection times to determine the direction of motion. With the RTC alarm period set at once per minute (plenty often for environmental data)  the average current usage is ~19 uA in a one minute window (including one RTC alarm event) and ~31 uA in a ten minute window (including one LoRaWAN event and ten RTC alarm events). These values are the same at 32 MHz and 4.2 MHz CPU speeds since the MCU spends nearly all of its time in the lowest-power sleep state. The average current strongly depends on the IR sensor sample rate and increases as ~2 x ODR, so ~19 uA at 2 Hz becomes ~27 uA at 4 Hz and ~43 uA at 8 Hz, etc. Total average power will also depend on the LoRaWAN duty cycle.

Bottom line: People Counter 2.0 offers ingress/egress detection at half the BOM cost and at least half the power consumption of People Counter 1.0. 

The next step is thorough testing and assessment of accuracy...

January 31, 2020

One of the design criteria is that the People Counter should last two or more years on two AAA batteries. This is about 1200 mAH capacity at 3.0 V, so two year battery life would mean an average current usage of:

1200 mAH/(2 Years x 365 days/Year x 24 H /day) ~ 69 uA,

which isn't easy to achieve.

I measured the power usage of the People Counter under conditions known to minimize power usage including 4.2 MHz clock speed, "fastest" Arduino compile optimization, and 10 minute LoRaWAN duty cycle. 

The variable was the period of threshold adjustment, either once every 10 seconds or once every 20 seconds. The former is about the fastest one needs to adjust the threshold since the Calipile sensor drift is <1 count/second.  Adjusting the threshold every 20 seconds saves a significant amount of power but runs the risk of the threshold lagging the sensor baseline and introducing inaccuracy in the transit detection. For most applications, I would expect the "sweet spot" to lie between 10 and 20 seconds.

I measured:

<166 uA at 10 second threshold adjustment period

<106uA at 20 second threshold adjustment period

These currents are the average current after one hour of operation and are upper limits, since the average current will continue to decrease with time until it asymptotes. What this means is that the threshold adjustment uses on average ~120 uA of current at 10 second period, and the rest of the ~46 uA is the cost of the LoRaWAN, sleep current of the STM32L082 and the current to power the sensors. The latter (~40 uA) is consistent with my experience measuring the power usage of similar devices (like the Bin Level Monitor).

So the threshold adjustment is using the bulk of the current in this application and increasing the period to more than 10 seconds is the way to eke out more battery life. But this will eventually come at a cost of accuracy, just at what period and how much loss of accuracy we do not know yet. I would guess that a 20 second period would probably be OK in most cases but I don't know what might happen with longer periods. More testing will tell.

So at 10 second threshold period, two AAA batteries would last ~300 days and at 20 second interval, 472 days. So we are getting close to the power usage goal; at 20 sec period two AAA batteries could last ~1.3 years.

But these are baseline numbers, and battery lifetime will be less depending on the number of people "counted" each day. At 10 second period, the threshold adjusts 360 times an hour, which costs 0.12 mAH. Assuming counting a person uses as much power as a threshold adjustment (a good assumption), then counting one person costs 120 uAH/360 ~ 0.33 uAH/person.

So counting 100 people per day will cost an additional 0.033 mAH per day and reduce the battery life from ~300 days to ~298 days, barely noticeable.

Counting 1000 people per day will cost an additional 0.33 mAH per day and reduce the battery life from ~300 days to ~278 days, about ten percent.

Lastly, counting 10,000 people per day or 1250 people per hour during an eight-hour business day (pretty heavy traffic for, let's say, a bathroom) will cost an additional 3.33 mAH per day and reduce battery life from ~300 days to ~164 days, about half.

Of course, proof is in the testing and while we can measure the power usage of individual units and make projections like those above all day long, we really need some real world results to better judge accuracy and battery life.

01/27/2020

Using the new method of testing the People Counter in the intended operation mode while connected to the serial monitor I captured more data over a longer term to measure threshold drift and its effect on counting accuracy. First, I streamed data for 20 minutes at 10 Hz and walked under the People Counter (mounted on the upper jamb of a portal) a total of six times, twice every 10 minutes or so.

The ingress and egress events were captured with 100% accuracy (6/6). There was significant drift in the baseline of the sensor signals, and the threshold adjustment method was able to keep track well enough to allow the People Counter to maintain its accuracy over the entire 20 minute interval. I suspected that the baseline rise at about the 10 minute mark was due to the house heater coming on, which I verified in the next test.

In the next test, I changed the serial monitor output rate to 1 Hz and collected data for 120 minutes, again walking back and forth under the People Counter at least twice every ten minutes or so.

The sensor signal baseline dropped rapidly as soon as the test started then slowly climbed again. At the 37 minute mark I turned on the local heating system and turned it off at the 54 minute mark. The effect in increasing the baseline is obvious. The 1 Hz serial monitor sample rate is not fast enough to capture the full transit excursions in each case (which is why some of the peaks appear to be below the thresholds) but I counted 30/29 ingresses and 28/29 egresses; one of the transit directions was reversed. So no false positives, 100% transit crossing detection, 96% direction detection success rate in this 2-hour test.

Even though I expect that the sensor baselines will eventually plateau (to be demonstrated) I also expect that changes in the building heating system and even the presence of people crossing the portal will affect the baseline so that threshold management will always be required to maintain accuracy. It seems to be working pretty well on these time scales. That is, the baseline changes are rather slow and smooth, and the threshold adjustment method can easily compensate.

So where are we in this project development? Here are the design criteria with commentary:

1) small and unobtrusive (say, 50 cc or less)

 We are using a ~105 cc Bud Industries container.

2) ultra low power so it can run on two AAA batteries for 2 years or more

Average power usage at 10 minute LoRaWAN duty cycle is ~150 uA; two AAA batteries (1200 mAH) will last one year.  The power usage is significantly impacted by the threshold adjustment requirement. It will also depend on the people counting rate since everytime a person crosses the line-of-sight of the device costs power, so the heavier the traffic the lower the battery life.

3) inexpensive, say $40 or less BOM cost

Initial production cost was higher, the cost per device should drop with higher production volumes such that the first 500 should cost less than $40 each.

4) connected via LPWAN (low-power wide-area network), either LoRaWAN or BLE 5.0

LoRaWAN with excellent range.

5) utterly reliable, meaning 100% no false positives or negatives

0% false positives. 96% accuracy with limited testing. The accuracy is for a portal that is 7 feet tall and 2 - 3 feet wide, a normal household door. We haven't tested the device in other environments or with different portal designs so the ~100% detection accuracy could be lower.

6) no cameras or imagers that might compromise people's demand for privacy (added to the list, but no camera-based technology can meet 2) and 3) anyway).

No camera.

Next step is deployment in the field for more rigorous testing in the intended operation mode. I will report on this next.

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.

24 March 2019

I am still not sure exactly why, but the People Counter just doesn't like the smaller Hammond box. Maybe it's because the sensors are so close to the sides of the box that prevent them from working well.

In any case, I put the new board into the old Bud box and repeated the testing from yesterday and I was very happy to find that the new People Counter pcb with the same old program and Bud box worked at 100% accuracy. I tried five passes (ingress + egress) myself (5' 11") and captured all 10 events. Then I asked my wife (5' 6") to try a couple of times and was able to see her two ingresses and two egresses. Then one more time with me following close behind her on the way in and on the way out. The People Counter captured all events in the proper order. It's like magic!

The Bud box is not a bad option (well, it's the only one that works so far!). It's a bit bigger than I was hoping to get away with, but the advantage of the larger size is I can use two AAA or AA batteries instead of a coin cell to extend the time between battery changes. At the measured < 50 uA average current usage, two AA batteries provide (2400 mAH/0.05 mA) about 5 years of service. Lighter AAA batteries about half that. Pretty close to set and forget.

I am gratified that the pcb design and firmware I developed seem capable of repeatable 100% accuracy. I was afraid I had a one-off on my hands.

I need to make a few sets of these People Counters using the Bud box and deploy them in a test friendly environment to get some real-world test data. I will likely ask my machinist friend to drill the holes for me to make sure these are all the same. I have some likely venues for this next stage in testing. More to come....

23 March 2019

Having fixed the hole placement by redesign I assembled the new pcbs I received from OSH Park and tested the performance using the existing program that worked so well on the first test. Plug and play, I hoped....

The first thing I tried was relatively small holes for the thermopile sensors (bottom case side) but I didn't record any entries or exits on the first few passes so I enlarged the hole sizes to match what I used on the previous test (top case side).

I am using the same coin cell battery plus jumper for power but now a chip antenna instead of the copper monopole. I noticed a significant degradation in the RSSI signal with the board mounted in the case and the battery sitting on top of the board. I think this huge hunk of steel right next to the antenna stay out zone is costing me range. I might have to return to the monopole which seemed to work pretty well, which would also save some cost.

I like this smaller Hammond container:

It's about half the size of the Bud box. But while the Bud box can accommodate two AA or two AAA batteries plus holder the smaller Hammond box can only be powered by the 950 mAH coin cell battery.

How did it work?

Plug and play...Not!  Even with the larger holes I often missed completely one or two out of the five passes back and forth that I used as a test run. Occasionally, I would register two ingresses when one each ingress and egress should have been measured. There is something different between this assembly and the previous design even though placement of the Type ABZ module and Calipile sensors on the pcb is identical. The mounting, container and holes are different (even though the same diameter) resulting in a difference in the field of view that must matter. One possibility is that my criterion for signal correlation is too strict, which works on one design but not another. What this means is I need to go back to diagnosing in detail what is happening with this particular device and see if I can get it to work well.

It would be fine if I needed two sets of criteria one specific to each container. better if I could find settings that worked well for both.

It is not surprising to see such sensitivity to externals like packaging especially with optical (or IR anyway) devices. I would have been surprised (although happy) if this device had worked at the same 100% accuracy of the first one. Beginner's luck I guess...

March 13, 2019

I soldered on an 82-mm-long,  insulated, 26-gauge copper wire as a simple monopole antenna, added LoRaWAN Tx at one-minute intervals to the People Counter sketch and plugged in the 3V, 950 mAH Renata battery.

I used Scotch tape to mount the People Counter on my bedroom door frame such that the door could close and not interfere with the container. This is how I would expect the People Counter to be mounted "in the field".

The door frame is at a standard 7-foot height, so when I walked through it the sensors would be about 30 cm from my head and 50 cm from my shoulders. I assume my head is what would trigger the ingress/egress detection.

After testing with a handwave on the workbench I installed the device on the doorway frame and proceeded to walk through the door, wait a minute or so, and then walk out the door and check the Cayenne dashboard to see if the latest trespass was captured by the People Counter. At one-minute Tx intervals, I usually saw the ingress on the dashboard when I returned to the workbench and could sit and wait until the egress showed up. Pretty exciting!

Somewhat to my surprise, each of five passes through the threshold and back again registered as it should and I had captured all five of each ingress and egress with 100% (OK, 10/10) accuracy.

Ingress:

Egress:

So I am pretty happy with this simple test of performance.

There is more extensive testing needed, of course. I suppose I could stand at a portal at a store somewhere with a counter and manually mark entrances and exits and then compare with, say, an hour's worth of data from the People Counter.  After such testing, I am sure there would be some fine tuning needed. For example, the sensitivity of the threshold detection might need adjustment; the LoRaWAN Tx duty cycle needs to be selected for the particular use case.

At this point, I am interested in generating failures of the counter to work. The portal I selected for the first test is too narrow for more than one person to even try to pass at the same time, and this is where this kind of people counter is intended to be deployed. But what about performance when people of different sizes pass through, or people wearing hats, or who knows what. I need to generate a more realistic test to find out where this kind of device might fail and augment the sketch to deal with such situations properly. It is unlikely that in a real deployment the accuracy would remain at 100%.

But this is a good first start...

March 9, 2019

First builds are always fun. It's where you find out where the mistakes are.
I received my first iteration of the People Counter pcbs from OSH Park and immediately tried the fit into the two low-cost containers I plan to use for this project. One is the Bud Industries HP-3649-B costing $1.30 each per 100, and the other is the Hammond 1551-HBK costing $1.61 each per 100. Fit into the Bud box was as expected since I had tested this on other projects and hadn't modified the design of the mounting devices (quarter circles) on the pcb. I did however change the position of the holes for mounting into the Hammond box without realizing that they are asymmetrically placed with respect to the pcb edges. So the People Counter fits fine on the Hammond box mounting posts if I install it upside down!  I redesigned the board for proper hole placement, having to move some edge pin ports around to do so, and resubmitted to OSH Park. In the meantime I will use the Bud box for testing and optimizing function.

The Bud box is roomy and affords space for 2 AA batteries and holder.

It took me about an hour to assemble the relatively simple board. Here is what the assembled pcb looks like:

Programming is through the SWD port on pins D8 and D9 using an ST-Link V2 I bought from e-bay. I used the "ST Link (STM32L0)" programmer selected from the tools menu in the Arduino IDE and the "Upload Using Programmer" method in the Sketch pull down menu. On this device, I need to use a jumper to pull the Boot pin (BTN, which is also a user button on D2) HIGH to put the STM32L082 in boot mode to allow programming. Not as convenient as using on-board buttons and USB connectors but it worked well enough.
Serial output for debugging was available via Serial 2 on pins A2/A3. I have a blue led on pin D10 (shared with SPI nCS) for indication as well which helped make sure things were happening in the sketch as they should. 
I am using the Murata CMWX1ZZABZ (STM32L082 + SX1276) as host MCU and for LoRaWAN connectivity. LoRaWAN is ideal for low data rates and infrequent messages. This application needs to send just a few bytes every so often (1 or 10 minutes intervals, for example) to the LoRaWAN gateway ("I got three ingress counts and 6 ingress counts since the last update!"). It could also send a LoRaWAN Tx message every time it detects an ingress or egress event.  I am not sure this would work well in a situation where a LoRaWAN Tx message had to be sent every time someone entered a big conference room as it filled up for a meeting. My preference would be to update the egress and ingress counts on a periodic basis, like once a minute, but only if there was a change since the last update, and otherwise every 10 or 30 minutes. The Tx strategy will depend on the use case and the customers' preference. 
The two Calipile (TPiS 1S 1385) thermopile sensors are placed as far from each other on the pcb as I could manage. The diagonal placement also insures the orientation of the box doesn't matter except to properly identify which direction is egress and which is ingress, but this is arbitrary. Might as well be directions 1 and 2. The Calipile's have address pins to allow up to four on a single I2C bus. These are set to respond to I2C addresses 0x0C and 0x0D. These have dedicated interrupts as well which ensures the temperature threshold crossing events are properly attributed to the corresponding sensor.
There is a PTH for soldering an 82-mm copper wire as a LoRaWAN monopole antenna. Later designs use a chip/pcb antenna. There are two PTHs for mounting the 3V, 950 mAH CR2477NAH I plan to use when deployed. Finally, there is a secure element ATECC608A to allow secure boot, secure LoRaWAN provisioning and key storage, as well as secure FOTA when these are deployed in the "field" (office building, hospital, factory, etc.). Security is often neglected in IoT devices and it is not straightforward to get it right.  I will discuss all of these aspects in later logs but here I want to start discussing performance and power usage.

The Calipile sensors have a 120 degree field of view that needs to be stopped down a bit to increase the discrimination, both in terms of increasing the effective separation distance of the sensors but also by narrowing the contribution to the signal from background. I started with 3-mm-diameter holes I drilled into the Bud box. At ~6 mm from the Calipile sensor faces to the holes this amounts to a reduced field of view of ~28 degrees. I had a hard time measuring anything. This could have been due to problems I was having with the firmware or interrupts since I was doing several things at once. But for whatever reason I decided to increase the hole diameter to ~4 mm and this seemed to work robustly.  I need to find a method for drilling these holes with more precision; they are not centered on the sensors which means the sensitivity will depend on mounting direction which is not what I intended.

This produces a field of view of ~37 degrees. I was able to detect ingress and egress events (left-to-right hand swipes vs. right-to-left ones) with high accuracy from about 15 cm away from the box face. I am sure there is a trade off between hole diameter, object speed, and detection distance. I haven't optimized the design by any means but I am gratified that I can detect events with high accuracy from a useable distance with these modest holes in the box. I would like to avoid the more elaborate lensing or tube approach discussed in the CaliPile Application Software Evaluation Guide if possible. 
One of the main goals of this project is remote, battery-powered people counting. If I had the luxury of connecting to main power wherever this device might be placed the design would be very different. So the main concern after people counting accuracy and reliability is average power usage. And since this device will spend most of its time waiting for something to happen, it has to have a very low sleep current. So the first thing I did was measure the power usage running a typical program without the LoRaWAN element. I know from other projects that at a 10 minute duty cycle LoRaWAN Tx costs about 20 uA.
I used ST's X-Nucleo-LPM01 power meter set at 3 V (nominal coin cell battery output). I could see the power rise everytime I waved my hand over the device. I was seeing about 25 uA when the device was in STOP mode with ~1.5 sec excursions to ~900 uA when the interrupts fired and I2C transactions took place. One thing I noticed right away is that for a while the device would work as expected and then all of a sudden the current would jump to ~300 uA and just stay there until another gesture was detected. It took me a while to understand that this happens when only one of the interrupts fires so the correlation condition fails, leaving one interrupt active until the next true event is detected. This can happen, for example, when someone approaches the device but only close enough to set off one of the threshold detectors. I had to fix this in software (it's always the software !) by getting the logic right. In this case, I simply clear any interrupt in the main loop after it is detected because the really useful information is the interrupt time which is captured in the interrupt handler. More power tests once the LoRaWAN Tx is active will be required but for now it seems the Calipile thermopile sensor data sheet is accurate in that each sensor uses < 15 uA while fully active; I make it ~11 uA or so. The total I measured, ~25 uA, plus the typical ~20 uA for LoRaWAN Tx at a 10 minute duty cycle would bring the total People Counter average power usage somewhere in the neighborhood of ~50 uA. With the 950 mAH coin cell battery then, the battery lifetime of such a People Counter device would be ~2 years depending on the number of people the device is expected to count.
So far in the project I have encountered no show stoppers and it looks like I might end up with a really useful device!  Next log, I will add LoRaWAN Tx and see what kind of accuracy I might be able to get in a real test of the functionality...