Designing an outdoor people counter

Requirements

Having been in the retail footfall counting business for a number of years I am well aware of the process of counting people, a sensor to ‘see’ the people, a data logger to record the counts and then a way of uploading the counts to a central server so the numbers can be seen by the client, however this presents a whole new set of challenges when there is no power and you are miles from anywhere.

The brief:

Count people
Be battery powered with a long life (ideally over 5 years)
Upload the data so it does not have to be manually collected.
Be cost effective.

Low power

The power requirements are key to the project and are the critical factor in deciding what parts to use and the functionality of the system. Every component in the system needs to get optimised for as little power as possible.

Sensors

Traditional sensors could not be used, while accurate and reliable they all consumed a lot of power, many mAs so would flatten a battery in no time at all.

The choice was quite limited and the for our post-style counter we chose to go down the PIR sensor route. These are very low power and come in a wide variety of specifications.

We were lucky to get involved with a supplier that specialises in PIR sensors that are geared towards various types of detection including human and various types of gas analysis. They were able to specify a suitable sensor and lenses to get us started.

The final sensor chosen consumed only 10uA at 3.3V, ideal for battery power but its analogue output would present some ‘interesting’ software challenges.

The sensor had a field of view of around 110 degrees so a lens and other methods were used to narrow this down so a narrow ‘beam’.

At 10uA we would need a 500 mAh battery to last 5 years, no problem, a pair of AAA could easily do that.

Data logger

The data logger would need some low power electronics along with some vey optimised software to minimise the power usage. The data logger would need to do the following:

Analyse the analogue signal from the sensor and convert to counts
Save that data every hour to build a profile for the days count.
Upload the data once per day to the central server.

Analysing the analogue sensor data. This was the critical part of the data logger as it would need to run all the time, read the analogue data and convert to counts. The signal coming from the PIR sensor represents a change of IR on the sensor so normally sits at half the supply voltage and swings high or low depending on if someone has entered or left the sensor field of view. After much analysis and research a reliable algorithm was created that could read the sensor around 6 times a second and extract the count data from that. The call to read the data was optimised to around 65uS so very quick.
Saving the data every hour. Many micro controllers have some inbuilt EEPROM for data and parameter storage, we have 1024 bytes so can store the data internally. The data storage is very quick and tales just a few ms even hour. We have to keep track of the time to make sure everything happens when it should. An RTC (real time clock) device was also included on the board to help with this and draws only a dew uA.
Uploading the data. The data is ideally uploaded once a day, there are occasions where the upload may fail and will need to be retried several times over the next few hours. The data upload take a lot of power, the micro controller is active for 20-30 seconds during this process along with the modem that is sending the data. The micro-controller consumes around 3-4maA while running.
Chosen electronics. An Atmel ATmega328P was chosen, it has all the peripherals needed, enough memories and is low power. It is also widely used in the maker space so has lots of support and libraries. By running the micro-controller at 8MHz and at 3.3V it would consume only 3-4mA while active and around 10uA while sleeping. With all the above taken into consideration we would need around a 1600mAh battery to last 5 years, a pair of AA batteries would be fine.

Uploading data

There are multiple ways to upload data including GSM, Sigfox, Lora, NB-IoT, unfortunately no options are as widespread as GSM so this has been adopted while other options are explored.
As for power consumption, GSM is possibly the worst, the chosen modem takes and average of 150mA for the 20-30 seconds it takes to upload the data.

The modem would required a 4000mAh battery to last for 5 years.

Power/batteries

For the sensor, electronics and the modem we would need a 6-7Ah battery to last us the full five years. This does assume everything works as it should and there are no other losses. If we assume 1.5 uploads per day then this would go up to around 8-9Ah.
Adding another 15% to allow for battery degradation takes us to 10.5Ah.

Lithium Thionyl Chloride batteries have a number of advantages, 3.6V, can use without a regulator, wide temperature range, very long shelf life, high capacity and enough ‘pulse’ capacity to power the modem during the upload.

A D-sized cell has a capacity of 19Ah, this gives plenty of headroom to cover any other losses we have not foreseen.

As the modem is a 5V device we need two of these batteries in series, this is not a problem but does then require a regulator adding another 2uA to the continual power draw.

Mechanics

I range of recycled posts was sourced. These are rugged and have a hollow core that allows us to hide everything inside the post. An alternative was a box mounted sensor, for this a suitable IP66 rated box was sourced.

It is vital that the electronics is protected from the environment so waterproofing was vital, the post/box gives excellent protection.

Once the post/box was accounted for it was a question of designing the sensor and electronics housings, this went through several designs before the final one was decided upon. The post electronics is housed in a length of drainpipe with the various caps and internal fittings produced by 3D printing.