Reality vs marketing statements
It is not surprising that the rise in long range, low cost, low power and unlicensed communication technologies such as LoRaWAN has generated a family of new products which are relatively inexpensive and can be easily deployed.
One of these devices are active Wi-Fi scanners used with the purpose of collecting traffic foot fall data. These units are sometimes called people counters, crowd density monitors, traffic counters, etc. SimplyCity Australia’s products in this range are called Crowd Density Monitors These devices provide Local Governments, event organisers, etc. with easy, low cost sensors that provide real time data on crowd density and movement.
SimplyCity has been deploying these devices around Australia for over 3 years with great success. Their applications have included: understanding COVID-19 lockdown and restriction impact, measuring the success of new project development, measuring Local Government festival success, analysing general consumer traffic through specific areas, and many more.
With every deployment, quite often we are asked four simple questions :
How does it work ?
How accurate is it ?
Can I power this from a battery or solar panel ?
Can I get data such as “dwell time” ?
Let’s answer these questions and debunk some of the myths we have seen around.
How does it work ?
The principle is very simple. The Wi-Fi scanner acts searches for certain signals from Wi-Fi active devices. For the benefit of this article , we will simplify the explanation and the technicalities behind it.
The Crowd Density Monitor will scan the area for WIFI devices. Every device will then be identified based on its response which includes its MAC address. The MAC address is a sort of serial number, which, for most devices, is fixed. Please note: for most but not for all ! This piece of information will be very important later. This is because Android and Apple devices have a privacy feature which randomises their MAC addresses. This is done to prevent person tracking and protect anonymity. The Wi-Fi scanner also attaches a signal strength information to the received packet.
Once the device scans its surroundings, a count of the detected unique MAC addresses is performed and the number generated is then sent to an end point. SimplyCity’s end point is the SimplyControl platform. This platform is capable of: storing incoming data, managing device range by remotely adjusting its sensitivity and frequency of reporting, visualising the incoming data and sending alarms based on various triggers. Mac addresses are NOT stored or transmitted. This is done in order to provide privacy and manage the limited memory in the sensor.
At the end of the transmission, the Wi-Fi scanner’s memory is cleared and another scan is performed. This is another critical piece of information, also used in this article a little later.
As mentioned in the beginning, the principle is very simple. However, it raises a few challenges.
How accurate is it ?
Wi-Fi scanning is reasonably accurate but it cannot be used to determine exact numbers.
For example, since some individuals can wear 2 smart devices, they can appear to be two. Others are detected as 1. There is also the baseline information to be collected with regards to fixed assets which are Wi-Fi enabled: laptops, kiosk, tills, cameras, etc. The baseline information is a calibration method used to understand in an environment with no people, what is the number of devices detected. This information will be used to establish the “zero” level.
Detection areas are set by implementing RSSI (or signal level filters. In the image above, the detection area “excludes” 3 devices with RSSI levels below -100dB. This filter is not perfect. The filtering does not completely cut out the devices with very weak signals. There is no “line in the sand” or hard border where the signal stops. The monitoring device receives all signals that reach it and an internal algorithm will discard and not count those signals weaker than a set level.
This filtering is an excellent tool when trying to restrict the detection area to a market garden, an outdoor area of a coffee shop and so on. Quite often re-defining the detection area is done by reprogramming the device. However this is inconvenient, expensive and time consuming. That is why SimplyCity has implemented a remote control feature inside its SimplyControl platform. The user only enters the desired detection radius in meters and presses a button on the screen. The rest is taken care in the background.
Needless to say that Wi-Fi scanning couldn’t be used for example to strictly enforce occupancy restrictions due to COVID-19 restrictions. But it will give a good idea of orders of magnitude of number of people in a given area and how it changes over time. Information such as this can trigger a focus of the Covid-19 marshals which can now guid their efforts to a specific area. This is very valuable business intelligence and extremely easy to obtain and use.
The benefit of the W-Fi scanners are in providing real time and time based information on crowd movement. This can be easily correlated with weather information, activities/events, promotional activities and other data streams. SimplyControl platform does just that. Using visualisation options, customers can see average numbers for different times of the day, maximum and minimum numbers detected, estimated current counts, etc.
This information is also an excellent indication of how the crowds move throughout an event area, when the influx of customers has started, how it trended during the day, etc. You can even determine in real time what is the more popular spot of a public event or space. All this is available directly on the screen and can also be exported in form of reports on a schedule as well as manually when needed.
A good use of this estimate is maintenance management, cleaners, security, which can be despatched based on trending values rather than just set on a cleaning and maintenance schedule.
Can I power this from a battery or solar panel ?
The Wi-Fi scanners are notoriously power hungry. The Wi-Fi modules are quite power consuming and every minute of scan uses milliwatts of battery power. This might not sound like much but when you want to monitor the foot fall for a 3 day event, once can quickly realise that an enormous battery level is required.
The software running on these devices can put the device in “deep sleep” mode but due to the nature of the data collected and the required frequency of scanning times, any gains using deep sleep functions would be obliterated by the sheer number of scans and transmissions.
One work around this issue is to slow down the number of reports per day. This can be used in some situations with success but the customer has to be aware that there will be larger periods between transmissions.
SimplyCity offers a solar-powered solution with battery back-up for this purpose. A very important thing to remember is that solar installations are larger , therefore more exposed to vandalism and more visible.
Can I get customer behaviour data such as “dwell time” ?
LoRaWAN Wi-Fi scanners do not have huge processing power. They also have limited memory to work with. These are very compact devices.
Therefore, most of the data processing and any analytics required by customers is done inside the platform.
The SimplyControl platform can display the historical trend of movement of groups of people through an area, can trigger alerts if the estimated numbers are above a set threshold and will forward this data to the customer’s long-term database or platform for further processing.
Commercial value is easily found in the connection between numbers detected and new initiatives such as street closures for open markets, parklet installation etc. The portability of such devices makes them an ideal investment. Devices don’t have to be locked in one spot and can follow the development of a suburb as the various stakeholders require.
An interesting question that has been asked is related to so called “dwell time”. For those who are not familiar with the term, dwell time, in this context, refers to the average length of time a person or group of people stays in one place. This is an indicator of how engaging or attractive a particular area is for visitors. The more they spend there, the higher the impact of that area has over them. It is a great metric for performance evaluation, BUT..
And here is the BUT:
Let’s refer to the two very important elements mentioned in the first paragraph: MAC address randomisation and memory clearing of Wi-Fi scanners.
If a device changes its MAC address (as we have seen, all new Android phones and all iPhones do), then two different scans of the area will detect the same device twice but the Wi-Fi scanner will not know.
There is a way around this by extending the scan window to capture the device in one scan multiple times. Instead of scanning for devices for 1 minute and then sending the data, the scan is performed over 10 minutes long window. In this time, in a highly mobile environment, a device can be seen appearing (thus being counted) then disappearing. With a bit of simple math applied in the code, the device can send another measurement to its end point: the average dwell time of detected devices in the detection range. Once the packet of information is sent, the memory of the Wi-Fi scanner needs to be cleared (remember the memory is quite limited), therefore there will be no historical information stored for the next scan. If a person remains in an area 15 minutes, the dwell time of that person will still be 10 minutes, the length of the scan window.
Here is a graphic explaining how this looks:
Let us analyse the image above:
At the beginning the the read/scan cycle, Person 2 and Person 3 are there and they are counted. Around 2 minutes later, Person 1 arrives and at minute 5, person 4 arrives. After 10 minutes, the counter sends the counted number, four, and the calculated dwell time by averaging. Looking at the graph, the approximate average dwell time will be sent as : (8+10+10+6)/4= 8.5 minutes.
Due to limitations described above, the scanner does no know that Person 3 and Person 4 are still there and they have spent actually 12 minutes and 8 minutes respectively. Using the actual times they have spent and using the formula above, the actual calculated average dwell time should have been: (8+10+12+8)/4=9.5 minutes. As you can see, we already have a discrepancy of 1 minute.
Here is what happens in this long stay situations:
In static events such as concert areas or food truck areas, this becomes useless since most of the people will spend in excess of 10 minutes. In case of outdoor events, due to queues and table searching, the real dwell time could be even 30-40 minutes. Yet the system will never report more than 10 minutes average dwell time. It simply can’t due to its own limitations. In the example above, all 4 individuals will be counted twice (a normal limitation of the scan process) but none of them will manage to extend the dwell time to more than 10 minutes maximum , even though they could all spend in excess of 30 minutes in an area.
Over a 20 minute period, there will be two independent scans. In both, the dwell time calculation will start being highly inaccurate. If we extend this window to 240 minutes (4 hours) which is normal for an event, the numbers will drift even worse. This is a simple example and it is easy to dismiss it as irrelevant in the context of general accuracy. However, during events and even in normal applications such as monitoring foot fall traffic on a dense coffee strip, the numbers will be completely out of range.
Furthermore, due to the storage requirements of the data being collected during the scan window and because of the calculations required, these devices cannot detect more than a few hundred devices/people. If your event attracts 1000+ people in an area, you will never have that number detected. The count will be out by 400-600 or even more. This is far more than an acceptable 10-15% accuracy in numbers for trending purposes..
It is easy to see why dwell time is important and useful commercially but it comes with limitations for the use of these devices.
Small inexpensive devices such as the SimplyCity Crowd Density Monitors keep the investment and operational cost to a minimum and the data granularity to a maximum. If dwell time is not used, measurements can be sent every 3 minutes or even less for highly dynamic areas. This method will highlight the dynamics of the population movement and it is more accurate in terms of detected numbers. SimplyCity’s Crowd Density Monitors detect in excess of 1500 devices every scan in busy areas and events.
