Because of COVID-19, many retailers need to count customers entering and leaving their stores. A colleague of Brian’s suggested that he design an electronic counter that small businesses could use, instead of having staff members do manual counts. So, he built an ESP32 MCU-based system with Bluetooth capability that counts customers entering/exiting using proximity sensors, and displays the count.
Since the COVID-19 pandemic began, the numbers of people allowed into places of business at one time have been restricted. Large retailers generally are responding by stationing staff at the entrance and exit of their establishment to keep a running count and to control the number of customers allowed inside. This could be an expensive proposition for a small retailer, or any other small establishment that is expected to enforce such regulations.
— ADVERTISMENT—
—Advertise Here—
A colleague of mine suggested that I design an electronic customer counter, tailored for the small business establishment. Such a unit would count the customers entering/exiting the premises using some sort of proximity sensor. It would need to display both the in-store customer count and the maximum capacity, on a display large enough to be seen at a distance from both inside and outside the premises. It would also need some sort of Red/Green “traffic light” display to indicate if it was OK to enter. While not a necessity in all cases, I included a method whereby staff can enter/leave the premises without affecting the display readings. This is accomplished using common RFID key-tags or cards.
I decided to use the low-cost Espressif ESP32 microcontroller (MCU), which has Bluetooth capability. Using an iOS cell-phone app, the unit can provide the current number of customers in the store, along with the daily running customer total, via Bluetooth.
Figure 1 shows the finished unit. The black enclosure in the foreground is the proximity sensor unit. Mounted on top of the unit is an industrial alarm column that indicates if it is OK to enter the premises. The rear panel of the unit contains an identical LED display. This allows the unit to be mounted in a window at the entrance to the premises, while still allowing the customer numbers to be seen from both the inside and outside. While not visible in the photo, the RFID reader is mounted behind the plastic panel on the right side of the unit.
Shown here is the finished unit, with the proximity sensor enclosure in the foreground. A similar display is also contained on the back panel.
PROXIMITY SENSORS
The first design consideration was the choice of proximity sensor(s). Whichever sensor was used had to be able to detect the presence of a person and determine whether the person was entering or exiting the premises. For practical purposes, the sensor had to detect a person’s presence up to about a meter away. It also could not have a “dead zone” at short distances.
— ADVERTISMENT—
—Advertise Here—
There are basically two general methods of accomplishing the necessary detection:
1) The person breaks a “beam” of some sort when walking through it.
2) The person reflects some of the “beam” energy back to the detector.
Method #1 requires units on either side of the customer pathway, and power may need to be supplied to both units. I am thinking here of early detection schemes that depended on a person breaking a light beam when passing through it. This required either a mirror on the side opposite the light sensor, or a dedicated light source on the opposite side. Using a mirror is simple, but it works best with visible light, and visible light sensors can suffer from interference from other stray light sources.
Method #2 requires only a single unit that acts as both the beam emitter and the detector. This is more convenient to set up, since it doesn’t require two units, both of which may need electrical power. Detecting the reflected portion of the beam requires a more sensitive detector, but modern technology has solved this problem, at low cost.
Using Method #2, four affordable technologies can be considered:
1) Ultrasonic sound range detectors
2) Infrared proximity detectors
3) LIDAR detectors (Light Detection and Ranging)
4) Image recognition using a camera device.
Although options 3 and 4 above might seem to be an expensive way to accomplish the task, such devices are now available at quite reasonable prices. Let’s look at each option individually.
Ultrasonic range detectors: Ultrasonic range detector modules have become so common that they can be purchased for a few dollars. They consist of an ultrasonic transmitter transducer and a receiver transducer. They operate like radar, but with ultrasonic sound in place of RF waves. Even the least expensive modules can detect objects up to 4m away, and they have only a tiny “dead zone” from 0 to 2cm range, which is not an issue in this application. Figure 2 shows a common module of this type.
The ultrasonic range sensor that I used. Although not visible, there are three ICs on the back of the PCB. It is amazing that this can be purchased for less than $3.
Infrared proximity detectors: Infrared proximity detectors come in two types. The simplest type measures the amplitude of the reflected IR signal and bases its distance measurement on that. The reflectivity of the detected object has a marked effect on the accuracy of this measurement. They are inexpensive, but their useable range is generally less than the 1m range that I wanted.
LIDAR detectors: The better IR proximity sensors operate using the “time-of-flight” method—they measure the time it takes a short burst of IR light to travel to the detected object and back again. As such, they are considered LIDAR detectors. Since light is used, this “time-of-flight” is in the order of nanoseconds. Modern technology has only recently made this type of proximity detector affordable for consumer devices. The maximum distance that this type of sensor will measure is about 120cm, and that depends on the IR reflectivity of the target. I felt that this type of detector might not be reliable enough, given the 1m range I felt was necessary. Figure 3 shows such a module.
This tiny module is a time-of-flight IR distance measuring device using STMicroelectronics’ VL53L0X sensor.
The three types of sensors discussed so far determine only the distance to the target object, and don’t provide any information about horizontal or vertical position or motion. Some LIDAR modules provide horizontal and vertical position information, but they are motor-driven scanners and are much more expensive.
Camera Image recognition: Camera modules containing an ESP32 MCU are available for around $10. They are color cameras with good resolution and frame rates, and they can detect a person passing by and determine the direction of motion. However, these modules don’t contain enough free GPIO lines for this project, and writing the software for the image recognition/motion detection would have been time-consuming, so I ruled out this option for the project.
I decided to use HC-SR04 Ultrasonic Range detectors (Figure 2) for the project. They have the following advantages:
1) Their range is significantly greater than the 1m design criterion.
2) They feature a narrow beam width (15 degrees), which is necessary when you are using two of them to detect both the presence of a target and its direction of movement in the horizontal plane.
3) They are electrically easy to interface to an MCU—only two digital GPIO lines are needed.
4) They are not at all sensitive to stray ambient light.
5) They are the lowest cost solution available (approximately $3 each).
6) The software needed to use them is trivial.
TWO ULTRASONIC SENSORS
To detect the direction that person is moving, you need to use two ultrasonic sensors. Figure 4 shows the placement of the two sensors (viewed from the ceiling above). Each sensor projects an ultrasound beam with approximately a 15-degree beam width. The two sensors are slightly angled with respect to one another, to separate the detection area into two distinct segments. You can see this angled geometry in the proximity sensor unit in the foreground in Figure 1 (my actual detector enclosure).
Top view of my sensor unit containing two HC-SR04 ultrasonic ranging units, with an illustration of the ultrasonic beam width drawn in
The program constantly monitors both sensors and, depending on which one “sees” the target first, it branches to one of two routines—“inbound” or “outbound.” Both routines check for at least a minimum number of distance readings within the selected range, to eliminate false detections. Each routine also waits until the target has moved out of the range of both sensors before registering a customer “in” or “out” result. Then it returns to the state in which it is again checking both sensors for the presence of the next customer entering or exiting.
Apart from a mechanical turnstile, there is no way that any sensing arrangement can be 100% foolproof. If, for example, two people crowd together when entering, the sensor would see only one of them. Or, if someone stands too close to the nearest sensor, triggers it and then backs off, it would still be counted as an entry (or exit), even though that hasn’t happened. However, for normal use, this sensing arrangement works fine, if you accept that it could be slightly inaccurate if it’s “fooled” in one of these ways.
Employees coming in and out of the premises also need to be considered. Presumably you don’t want to include the number of staff when keeping track of the number of customers in the store. So, there must be a way to cancel out the detection of an incoming/outgoing employee.
The method used must be convenient for the employee and impossible for an impatient customer, waiting in line, to do. I settled on the idea of RFID tags. These can be in the form of a key-tag or a plastic card the size of a credit card. In use, the employee would tap the RFID tag at the spot indicated on the side of the project’s enclosure. Doing this would erase any changes to the customer count that had occurred within the past 10-seconds, and any that occurred within the next 10 seconds. This would presumably allow the employee to get in or out of the store by passing through the detection area, without affecting the count. The 10-second value could be changed to suit a particular physical layout, by changing the value of the constant staffOverRideTime near the start of the project’s software listing.
The RFID reader and associated key-tags/cards also perform a few other functions. When the unit is started up for the first time, it has no knowledge of the ID numbers of the legitimate RFID key-tags, nor does it know the maximum number of customers allowed in the store. These values must be programmed into the device, and this should only be allowed when a special “supervisor” RFID card has been detected. I will explain this in more detail later in the article.
RFID reader/tags are convenient, secure and inexpensive to implement. Figure 5 shows the kit I obtained, which contains 2 RFID reader modules, two key-tags and two cards, all for about $10 on Amazon. The individual key-tags and cards cost less than $1 apiece in small quantities.
One half of the RC522 RFID kit that I obtained from Amazon
THE DISPLAY
I couldn’t know in advance how far away the unit would be from either customers waiting outside the store, or employees needing to observe it from inside the store. Therefore, I decided to duplicate the same display on both the front and back of the unit. This would allow the unit to be placed in a front-facing store window, for example, and still be read from both the outside and inside. The only type of display that is readily seen at a distance, in bright lighting, is a reasonably big LED display.
Generally, the only things that needs displaying are numbers, so I could have used 7-segment LED readouts. However, during initial configuration, it’s useful to be able to display some alphanumeric characters, too. After checking out various types of LED displays, I decided to use a 32 x 8 LED matrix module for both the front and rear displays. These modules display four alphanumeric characters with a height of about 3cm, which is perfectly readable at expected distances from it. The way that I use them allows for two numbers on the left (Customers in Store), a blank space in the middle and two numbers on the right (Maximum Capacity). These modules can be programmed for up to 15 intensity levels. I found that even when using an intensity of 2, it was plenty bright.
These displays use the ubiquitous Maxim Integrated MAX7219 LED driver chips—one MAX7219 per 8×8 Matrix block. All four MAX7219s are fed in a cascade wiring arrangement, using a three-wire bus that is basically a unidirectional SPI bus. They operate on a 5V power supply, but accept the 3.3V logic level signals from the ESP32 MCU that I used in the project.
These 32×8 LED Matrix modules come from a variety of Chinese manufacturers, so they are very inexpensive (around $7). The trade-off is that they don’t come with any datasheets. Basically, you just use the MAX7219 datasheet to figure out how to drive them, or you use a library that someone else has written. Several Arduino libraries are available.
I don’t know whether all the modules made by the different manufacturers are alike with respect to the way the LEDs in the matrix are wired up to the MAX7219’s SEGMENT and DIGIT outputs. When I tried out two different Arduino libraries written for these LED matrix modules, one of them didn’t work at all—possibly because I was using an ESP32 MCU, and not an Arduino board. The other one worked, but produced characters that were rotated by 90 degrees. Since these modules are meant to be aggregated into large arrays for digital signs, it’s possible that this library was meant to drive such displays in a configuration where they were mounted with the long (32-dot) dimension vertical.
I was able to overcome this issue by re-writing a portion of the library, and generating my own custom 5×7 dot font. I am unsure whether other available LED matrix displays have their LED matrices wired like mine. Currently, due to the pandemic, parcel delivery is very slow. Therefore, I haven’t yet tried to purchase these modules from other sources to see if various versions are available.
CIRCUITRY
For this project, I could have used any of the 8-bit Microchip Technology AVR MCUs with which I have experience. The I/O requirements are quite basic:
1) An SPI port with two Chip Select lines for the display and the RFID reader.
2) Seven GPIO lines to drive the Red and Green LEDs, the piezo buzzer, a rotary encoder, an Enter switch and the RST signal for the RFID reader.
I have lots of experience with the 32 bit ESP32 MCU, which I program using the Arduino IDE. So, I decided to use an ESP32 DevKit-C module. Using the ESP32 MCU gave me the option of providing either Wi-Fi or Bluetooth connectivity to the project.
Initially, I wasn’t sure how many configuration parameters might need to be entered by the user. I thought that this configuration might best be done wirelessly, eliminating the need for any user adjustment controls on the unit itself. (User controls on the unit would have to be protected from tampering by the general public). In the end, I handled the configuration operation using a simple rotary encoder/Enter switch on the unit, which is enabled only when a unique “supervisor” RFID card is present.
I decided to use the Bluetooth capability of the ESP32. I use this Bluetooth link just to provide two numbers—the current number of customers in the store and a running total of number of customers visiting the store since the unit was turned on. This would normally be a daily total, if the unit is shut down at night.
Figure 6 is a schematic diagram of the unit. The interior of the enclosure is shown in Figure 7. The two LED matrix display units are wired in parallel, and are treated in software as one unit. The RC522 RFID reader shares the same SPI port as the LED matrix display, but has its own Chip Select line and RST line.
Complete schematic for the project. Apart from the ESP32 and power supply regulators, many of the modules are mounted off the board, and are connected using 0.1″ sockets and headers.
Interior of the unit plus the external devices. The rear cover is not shown, but it contains another 8×32 LED matrix display.
The HC-SR04 ultrasonic range sensor has two signal lines:
1) A Trig line, which must be pulsed high for a minimum of 10µs to send out the ultrasound pulse.
2) An Echo signal, which goes high as soon as the ultrasound pulse is sent, and drops low when it detects the “echo” coming back. I use the Arduino PulseIn function, which returns the length of time the pulse is high. The PulseIn function contains a parameter specifying which GPIO line it is monitoring. It can also accept a timeout value (in milliseconds). If no echo has been received within this time-frame, a zero will be returned in place of the normal return value.
I trigger each HC-SR04 unit separately, using a GPIO pin for each unit. I also measure each Echo signal separately with a dedicated GPIO pin. The HC-SR04 modules are meant to be powered by 5V and use 5V logic levels. The ESP32 uses 3.3V power and logic levels. The HC-SR04 works nicely when its Trig signal is fed with 3.3V logic levels. However, the 5V Echo signal is too high a level for the ESP32’s GPIO inputs, so both Echo signals go through voltage dividers (R4/R6 and R5/R7) to reduce the logic levels to approximately 3.3V.
Originally, I planned to use a third LED matrix display to display either a “WAIT” or a “GO” message. There wasn’t enough room in my chosen enclosure to do it this way, so instead, I used a standard industrial warning light column (“traffic light” style). I removed the Yellow lens/LED assembly, and just kept the Red and Green LEDs/lenses. Figure 1 shows this tower mounted to the top of the unit’s enclosure.
Actually, it would be more practical to just use large red and green LED indicator assemblies. Here’s why: When I ordered this warning light column, I didn’t notice that it was meant for 220VAC. After it arrived, I realized this. It turns out that such units are either 110VAC or 220VAC, or 24VDC. None of these would have worked on the 12VDC that I had available in the unit.
LED ASSEMBLY REWORK
I dug myself out of this hole by noticing that the column’s three “bulbs” contained an assembly of LEDs mounted on three small boards arranged to make the LEDs visible over a 360-degree range. The plastic lens part of the bulb was easy to remove, and I was able to re-wire the LED assembly to work on 12VDC by removing a small capacitor and resistor that dropped the 220VAC down to the lower voltage needed by the series-connected white LEDs. However, this was doing it the hard way!
A small piezo alarm is included in the unit. I don’t use it for much—it just makes a short “chirp” when a customer comes in, and a lower-pitched one when a customer exits. I thought it might be annoying to have it beeping if the number of customers in the store exceeded the maximum capacity. The red/green industrial warning light column is easy to notice. Since the piezo buzzer is driven by one section of the ESP32’s LED controller pulse-width modulators (PWMs), it would be easy to change this by enabling this PWM whenever the Red LED is on and turn it off as soon as the Green LED comes back on.
The power supply circuitry is a bit unusual. I had read forum posts where people had experienced stray MCU resets and other problems in situations where large LED matrix assemblies were used. These problems arose because the LED matrices could generate “spikes” on the VCC power line when they were switched ON/OFF as the display was refreshed. Although I was using just two LED matrix displays, I had no prior experience with them, so it was a concern.
Due to the COVID-19 pandemic, I experienced delays in the delivery of many the parts needed for this project. While waiting for these parts to arrive, I built the circuit board and decided to play it safe and provide individual power supplies for:
1) The two LED matrix displays
2) The ESP32 and HC-SR04 sensors (the RFID reader is powered by 3.3V from the ESP32-DevKit-C)
3) The red and green LEDs in the warning light column
The power supply for the unit is a 12V, 1A wall adapter. This feeds a 78SR-5/1.5 DC DC switching converter from Murata Power Solutions, which provides 5V to the two LED matrix displays. The 12V also feeds a Traco Power TMV1205S isolated DC-DC switching converter, which supplies 5V to the ESP32 DevKit-C and the other 5V devices. I used an isolated DC-DC converter, and though the ground buses for the display and MCU/associated circuitry are not isolated from each other, they are wired so as to prevent any ground loops. The warning light column needs about 10V to run its three series-connected white LEDs. I feed it directly from the 12V supply through 56Ω current-limiting resistors.
When I finished building the unit, I found that the total current draw from the 12V supply was only a few hundred milliamps. I run the LED matrix displays at an intensity level of only 2 (out of 15). This is bright enough, in my opinion, but if the intensity were cranked up, the total current draw would increase.
I suspect that since the LED matrix displays don’t draw nearly as much current as I had initially guessed, I think I could have run all the circuitry from the 78SR-05/1.5, and eliminated the TMV1205S isolated DC DC converter. If smaller LED assemblies were used instead of the warning light column, they could also be run from a 5V supply. That would result in requiring only a single 5V regulated wall adapter, and would also eliminate the need for the 78SR-5/1.5. Figure 8 is the rear panel of the unit showing the rotary encoder, power socket and the DB9 ribbon connector attaching to the sensor unit.
The unit running, showing the rear panel with the adjustment encoder, power socket and so forth.
SOFTWARE AND OPERATION
The ESP32 software was written using the Arduino 1.89 IDE, with the addition of the ESP32 board package. The board selection is “ESP32 Dev Module.” Although my program is not that long (800 lines), when you include the Bluetooth library, the total code space balloons to about 1,200KB. Therefore, I used the partition option: No OTA, 2MB App, 2MB SPIFFS.
Several Arduino libraries are needed to interface with the various I/O devices:
1) MFRC522. This is a third-party library for the RC522 RFID reader.
2) LedMatrix. This is a third-party library that I had to customize to work with my LED matrix displays (as outlined earlier in the article). You must use my version. My custom font file (FONT_7X5.h) is also needed.
3) Various Bluetooth library modules. (BLEDevice, BLEServer, BLEUtils, BLE2902). These are included with my source code.
4) Encoder.h. This is a rotary encoder library written for PJRC’s Teensy modules, but works fine with ESP32.
All these libraries are included with my source code package on the Circuit Cellar article code and files download webpage.
The MCU must maintain some configuration parameters that will not disappear when power is removed. They are:
1) The maximum number of customers allowed in at one time
2) A list of the ID #s of the RFID key-tags that are valid to use with this unit
These configuration parameters are stored in the ESP32’s flash memory using the preferences class (which is an EEPROM emulator). This invokes in two different modes:
First mode: when the unit is powered up, if you hold the Enter button down while the ESP32 is booting up, it will enter the RFID registration routine. This will be indicated by the message “Supr” showing up on the LED matrix displays. You must then tap the supervisor RFID key-tag (or card) on the RFID reader and then remove it. If you have the DevKit-C plugged into your PC’s USB port, and a terminal application running (with the COM port set for the DevKit-C USB bridge port and baud rate = 115,200), you will see the message, “Correct supervisor tag scanned and removed.” At this point the display will show “ID 00.” You then proceed to tap up to 10 RFID key-tags that you plan to use. You hit the Enter button when you are finished scanning the key-tags. All of these will be stored in non-volatile memory and used later, in operation, to validate that the RFID key-tag being used is legitimate.
Second mode: When you power up the unit without the Enter switch pressed, the unit will be in its normal operating mode. If you tap the supervisor RFID tag at this time, it will allow you to enter the Maximum customer capacity. This will be indicated by the message, “Cap=” on the LED matrix display. At this point you rotate the rotary encoder until the proper value is displayed, and then hit the Enter button. This parameter is also saved in non-volatile flash memory.
I intentionally did not allow the supervisor RFID key-tag to be defined by any routine that could be performed on the unit when it is operating. You can only define the valid staff RFID tags after tapping the supervisor RFID tag. The supervisor RFID tag # must be determined in advance and entered into the program on line 66:
int Card_ID_supervisor= 0xE5C95123; // this is my supervisor RFID #The supervisor ID# can be determined by temporarily adding the following code at line 138 of the program:
while(1) {
getID();
}This will display the ID# of any key-tag that is tapped on the RFID reader via the USB-serial port. This routine is a good way to ensure that the RFID reader is working properly, while building the unit. Remove this code once you’re finished.
In my program at lines 499 and 549, is the following line of code:
duration = pulseIn(ECHO1, HIGH, 4000); // timeout in 4000 usThe “4000” parameter is the timeout of the routine in microseconds. The 4000 value works well for a detection distance up to about 120cm. If there was a wall, or other obstruction closer than this, the routine would “see” an object all of the time and wouldn’t work. This parameter would need to be reduced to a proportionately smaller value (in both lines 499, 549)—corresponding to a shorter sound travel time.
THE BLUETOOTH APP
I’ll be honest with you. I don’t have the capability of writing a “native” Bluetooth iOS app for my iPhone/iPad. This requires an Apple developer account plus a reasonably new Mac computer to run the application software needed to write that app (in either Swift or C). I am not an Apple developer, and my 2012 Mac Mini is too old to run the current software needed. I have various workarounds for this, as I’ve described in earlier articles, including “Bluetooth-Enabled ECG Monitor” from Circuit Cellar 352, November 2019.
For this project, I decided to “cheat” a bit and use the BLE “UART” protocol with Adafruit’s existing (free) “BlueFruit Connect” iOS app. This is a diagnostic app that lets you connect to your Bluetooth project using the UART profile, and allows you to send/receive ASCII messages.
In the firmware for my project, the Bluetooth function is set up in the InitializeBluetooth() routine. In that routine, it sets things up for the UART profile, and gives the project the name “Customer Counter.” When you open the “Bluefruit Connect” app (with the Customer Counter unit running), you should see a screen similar to the one shown in Figure 9. You should see the “Customer Counter” entry in the lower half of the screen, along with any other Bluetooth devices you have around. You can click on the Filter window near the top, and tailor the program so that it only displays Bluetooth devices with the name “Customer Counter” and UART profile.
The initial screen of the Adafruit “BlueFruit Connect” iOS app. You can see that it has detected the “Customer Counter” Bluetooth profile.
When you click on the “Connect” button, you should see the screen shown in Figure 10. Every 5 seconds this should update the two readings shown. While this is certainly not a dedicated, “custom” app, it serves the purpose nicely and is free. I don’t have an Android cell phone, but I suspect there are similar Bluetooth UART diagnostic apps available for the Android OS. 
Once you connect to the Customer Counter, it will update this display every 5 seconds.
RESOURCES
ESP32 DevKit-C Manufacturer’s web-page
https://www.espressif.com/en/products/devkits
ESP32 Arduino Core library/boards package :
https://github.com/espressif/arduino-esp32
MFRC522 RFID reader
Search amazon.com for “RC522.” There are many different sources for this module and the key-tags.
HC-SR04 Ultrasonic Range Module
Search amazon.com for “HC-SR04.” There are many sources for this module.
LED Matrix display 32X8 Red
Search amazon.com for “CANADUINO 32X8 Matrix LED” or
https://www.universal-solder.ca/product/8×8-64-dot-matrix-4-modules-arduino-raspberry-stm/
Unit Enclosure: Hammond 1455T2202
https://www.digikey.ca/en/products/detail/hammond-manufacturing/1455T2202/1090718?s=N4IgTCBcDaIBIFkC0BOADANhAXQL5A
Ultrasonic Sensor Enclosure: Hammond 1591AFBK
https://www.digikey.ca/en/products/detail/hammond-manufacturing/1591afbk/460571
Warning light Column:
This is the product I used. As mentioned in the text, I had to modify it to work on 12V, so this is not an ideal choice.
https://www.amazon.ca/gp/product/B07RRBXZ2H/ref=ppx_od_dt_b_asin_title_s01?ie=UTF8&psc=1
Adafruit | www.adafruit.com
Digi-Key Canada | www.digikey.ca
Espressif Systems | www.espressif.com
Maxim Integrated | www.maximintegrated.com
Microchip Technology | www.microchip.com
Murata Power Solutions | www.murata-ps.com
STMicrolectronics | www.st.com
Traco Power | www.tracopower.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • SEPTEMBER 2020 #362 – Get a PDF of the issue
Sponsor this Article
Brian Millier runs Computer Interface Consultants. He was an instrumentation engineer in the Department of Chemistry at Dalhousie University (Halifax, NS, Canada) for 29 years.
