Close
0%
0%

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

Preview
Download

  • A Word or Two About Power Usage

    Kris Winer02/01/2020 at 01:24 0 comments

    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.

  • More on Threshold Drift​, Test Results

    Kris Winer01/27/2020 at 20:26 2 comments

    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.

  • Optimization and Testing

    Kris Winer01/26/2020 at 19:07 4 comments

    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.

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

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

  • 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 7 project logs

Enjoy this project?

Share

Discussions

Gerardo wrote 13 hours ago point

Hello Kris, I'm an IoT developer and would like to know the development stage of this solution. Thanks in advance

  Are you sure? yes | no

Pascal Mattes wrote 09/14/2020 at 11:07 point

Is there any update on this project? Sounds interesting and would love to get one for myself.

  Are you sure? yes | no

Kris Winer wrote 10/17/2020 at 15:34 point

Still working on lowering BOM cost and improving accuracy. Not quite ready for sales just yet.

I have sent out samples to several people for testing and I am awaiting results.

I would be interested in finding additional commercial customers to help me take the project over the finish line...

  Are you sure? yes | no

Jim Me wrote 01/26/2020 at 00:57 point

Kris, or anyone following Kris' People Detection project:  Have you done any evaluation or experimentation with the Doppler RADAR Motion Sensor?  I see the RCWL-0516 PCBA has some potentially interesting specs (e.g. range, 360 degree FOV, 4-28V, Interrupt pin, cheap, enable pin for power reduction, can be sealed in case)??  I am considering evaluating it versus the AK9753 4IR sensor (perhaps including both in a sensor node to improve reliability of operation.).

  Are you sure? yes | no

Kris Winer wrote 01/26/2020 at 01:04 point

I haven't looked at it but the 2.8 mA operating current is the deal killer for me. This would use ~67 mAH per day so would last just 14 days on the 950 mAH Renata coin cell battery I am using. Compare against the ~10 uA used by each Calipile and the 9 - 12 month battery life I expect in typical use cases.

  Are you sure? yes | no

Jim Me wrote 01/26/2020 at 01:16 point

Kris, thanks for the prompt reply! I concur with the power consumption issue. I am thinking of limited power on time of a RCWL-0516, used to confirm the triggering of the AK9753 (IR sensor). Your dual Calipile approach is tempting! The apparent complexity of tuning the Calipile to different environments concerns me, and the cost (using two Calipile) is a concern (somewhat offset by potential for long battery life!). In my application, using a pair of AAA or even AA alkaline batteries is acceptable. I am happy to share any learning if/as I pursue my investigation further.

  Are you sure? yes | no

Kris Winer wrote 01/26/2020 at 04:21 point

For people detection the tuning turns out to be pretty straightforward. The hard part is drift compensation, but even this is manageable. Agree, the Calipiles are expensive at ~$8 each, it makes the People Counter device cost more than I would like.  Small, cheap, or fast (or low power, in this case), pick any two....

  Are you sure? yes | no

Jim Me wrote 01/26/2020 at 17:45 point

Kris, FYI and based upon your comments, as my next step in sensor tech evaluation, I've ordered a Excelitas Calipiles DemonKit adapter of the TPiS 1S 1385 and also a Grove Module of the AKM AK9753 4 IR sensor.  I've also ordered a few of the cheap RCWL-0516 3.2GHz microwave Sensor boards to play with (to see if they can be used in a gated power mode to overcome their current draw).

  Are you sure? yes | no

Kris Winer wrote 01/26/2020 at 18:33 point

Are you just playing around or do you have an application in mind? If you want to discuss in more detail than possible here send me e-mail at tleracorp@gmail.com.

  Are you sure? yes | no

yyhhgg wrote 12/04/2019 at 11:49 point

Do two or more people go through accounting?

  Are you sure? yes | no

Kris Winer wrote 12/04/2019 at 17:51 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 true 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 (https://www.digikey.com/product-detail/en/excelitas-technologies/TPIS-1S-1385/1601-1012-6-ND/9760643) 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 tleracorp@gmail.com.

  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:  http://www.latticesemi.com/Products/DesignSoftwareAndIP/IntellectualProperty/ReferenceDesigns/ReferenceDesign04/HumanPresenceDetection

The development kit is near your price target:

http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/HimaxHM01B0

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