People Counter

Count people entering and leaving a space through a portal with a low-cost, battery-powered, connected device

Similar projects worth following
We've all heard the bell tinkle at a local shop announcing to the proprietor that a customer has arrived. The bell is inexpensive, lasts forever, and is effective at detecting a door opening. What if the task is both detection and keeping track of the number of people entering and exiting, estimating occupancy, and making this information available on demand via a smart device? Use cases include bathrooms (must be cleaned after every N people), office building conference rooms (only 10 people per month use it? Convert to offices!), museums, factories, etc. Anywhere people come and go and it matters (usually to the building manager) how many go where. Ideally, any device to count ingress and egress events must be small (unobtrusive), low power (run on cheap batteries for years), low cost (we're going to want dozens of them at a site), connected (data collected remotely), and utterly reliable (no false positives/negatives). What are the options? Not as many as you might think..

People counting has a long history which I won't repeat here. There are several available solutions that can be purchased including those using IR emit/detect (so two devices required), cameras and AI (not cheap and cameras present a privacy concern), and even radar (also not cheap). The problem with these solutions is that they don't meet some or all of the (OK, my) criteria for a ubiquitous IoT people counter. Reiterating my ideal design specifications:

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

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

3) inexpensive, say $40 or less BOM cost

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

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

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).

 I am restricting the people counting I have in mind to a device that counts the number of ingresses and egresses at a portal. Some of the devices mentioned above might do other things as well and could be worth the cost, size, and otherwise be perfectly good products that deserve your attention for whatever use case you have in mind. But for the specific task of counting individual human ingress and egress events at a portal and sending the data via LPWAN to a smart device there are currently no solutions that meet the six criteria above.

This project's goal is to design and test such a device.

In order to reach the goal, the right choice of sensor(s) is going to be critical, so let's start there and consider some of the options.

First, in order to reach acceptably low power operation it is necessary that any sensors have an interrupt. This is because the optimal way to run a low power device is to put the MCU to sleep in an ultra-low power (~2 uA) state until woken up by an interrupt, either a timer interrupt or a sensor data ready or threshold crossing interrupt. So any MCU that lacks a state-preserving low-power mode (like the nRF52 and ESP32) can't be a candidate for this people counter. Any sensor that requires continuous monitoring by a host MCU must also be discarded.  This rules out most analog sensors. And while there are a spectrum of remaining options, I seriously considered only four:

The AMG8833 is an attractive option since although it is technically a camera, it is simply not possible to identify anyone from their 8 x 8 pixel AMG8833 thermal image. So this allays privacy concerns. It has a range from 0 to 5 meters, so can easily detect people passing a portal. The fastest frame rate is 10 Hz, a bit on the slow side for people counting. The AMG8833 has the rather unique ability to generate an interrupt when a pixel exceeds a temperature threshold. Yes, that's right, this device has a pixel-specific interrupt. Once the user specifies a temperature threshold, the user can query after interrupt reception which specific pixel or set of pixels caused the interrupt condition. This is extremely useful for people counting, since typically the set of pixels on one side of the device will reach the threshold condition before the set of pixels on the opposite side of the device providing the directional information required for proper egress and ingress discrimination. We successfully developed a prototype using this sensor (which is an uber-kool sensor to play with in any case) but the Achilles Heel here is power consumption. Normal (continuous 10 Hz) mode uses 4.5 mA, standby mode (0.1 Hz, measure every 10 s and too slow for this application) uses 0.8 mA, and while there is a sleep mode for the sensor the lowest current draw is 200 uA. Ouch!...

Read more »

Adobe Portable Document Format - 2.07 MB - 03/10/2019 at 03:04


  • Packaging Matters!

    Kris Winer03/25/2019 at 01:09 0 comments

    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....

  • Second Test with New Design

    Kris Winer03/24/2019 at 02:38 0 comments

    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...

  • First Test of People Counting

    Kris Winer03/13/2019 at 22:19 0 comments

    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.



    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...

  • First Build and Power test

    Kris Winer03/10/2019 at 01:25 0 comments

    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...
    Read more »

View all 4 project logs

Enjoy this project?



yyhhgg wrote a day ago point

Do two or more people go through accounting?

  Are you sure? yes | no

Kris Winer wrote a day ago point

I haven't tested the discrimination possible with multiple people. Presumably, if there is enough separation between the people, they would register as two events. But I don't know what this separation in distance/time might be. This device is more properly a threshold crossing counter rather than a tru people counter; that is, it cannot count thenumber of people in a room at any give time, for example. But it can discriminate between relatively hot humans and relatively cold things, so only counts threshold crossings by people (and maybe animals).

  Are you sure? yes | no

Cliff wrote 05/24/2019 at 11:09 point

Any progress on the project? Also do you have any tips on where to get the TpiS sensor? I have only found it as bare chips on my searches. If you want I could send you the code that ST used for the vl53l1x for their people counter demo.

  Are you sure? yes | no

Kris Winer wrote 05/24/2019 at 16:52 point

I haven't been spending much time on this lately since I got the device to work more or less. It is still not as robust as I would like and I need to optimize the temperature thresholds, etc. But phase 1 let's say, of showing proof of principle with this design, is a success. Not sure what you mean by "bare chips"; I bought mine from Digikey ( and they are in stock if rather expensive for just a few. Yes, I would like to see the code ST uses for their people counter, thanks. I am at

  Are you sure? yes | no

Dan Maloney wrote 02/27/2019 at 17:55 point

I recall a certain mall department we'd visit back in my youth. They had some sort of traffic counter at the entrance from the mall, must have been ultrasonic because I could hear it loud and clear and it was painful as hell. That was with tender ears; I doubt that accumulated damage from a LOT of concerts and five decades of entropy would still make me sensitive to such a device. 

Long way to get around to saying that I wonder if ultrasonic transducers could help.

  Are you sure? yes | no

Kris Winer wrote 02/27/2019 at 18:07 point

Yes, and these are still used in commercial people counters today, one of a variety of methods. I didn't reference them all. They suffer from some of the same problems that the other technologies do, they are typically large in size (not a show stopper) but also require a fair amount of power to run.

But the other problem is they will detect both humans and inanimate objects crossing their path and can't distinguish between them. This is a problem for the VL53L1 ranging sensor as well. This is the advantage of a temperature-based scheme. But in the end, it is practical counting estimation we are after so even a 95% accurate solution will work.

The deal killer for most candidate sensors as part of a remotely-placed, battery-powered people counting device is power usage. Not many sensors of any type have continuous power usage numbers around 15 uA...

  Are you sure? yes | no

Kris Winer wrote 02/27/2019 at 03:54 point

Thanks Greg,, I'll take a look...

"Is privacy really a concern if there is no storage and you do not broadcast the images? "

Yes, not just personal privacy but a lot of potential customers don't want anyone taking pictures of their sensitive operations, facilities etc. They just don't like cameras, no matter what you tell them.

FPGA? Can I use their camera module with an STM32L4?

1 mW is still 300 uA, so not low power from my POV. I am shooting for 0.165 mW

  Are you sure? yes | no

greg wrote 02/27/2019 at 03:36 point

I think an imaging solution can meet your requirements.

Lattice has an example:

The development kit is near your price target:

It consumes 1mW so you should be able to run for a couple years from a couple AAA.

Is privacy really a concern if there is no storage and you do not broadcast the images?  

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates