Project Logs

Collapse logs

• A Word or Two About Power Usage

  Kris Winer • 02/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 Winer • 01/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 Winer • 01/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 Winer • 03/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 Winer • 03/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 Winer • 03/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 Winer • 03/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