This is a presence sensor that uses 60GHz radar pulses to detect human presence indoors.
The sensor communicates over the OpenThread protocol, utilizing existing IPv6 infrastructure (without the need for a IoT protocol "translator"). In order to facilitate low-power operation, CoAP is used for the sensor to notify a server of state changes.
Refer here for the CoAP Server.
The IPR is designed on a 6-layer POFV, impedance controlled PCB. The components run off a single 1.8v supply, due to limitations of the radar IO voltage, in order to avoid level-translators. The main controller on the board is of the EFR32MG24 Series. Due to chip shortages, more than one part in this series was used with little effect on the actual functionality.
IPR v2 PCB
3D printed enclosure and CAD drawings
Radar was chosen for this project due to its ability to detect micro movements and perform 'filtering' by estimating distance/speed of target. This makes it suitable for certain applications where traditional sensing methods such as PIRs may be insufficient, such as needing to sense presence in specific areas, or in areas of high traffic. It also helps to overcome limitations of PIRs in detecting human presence without significant motion, which would be an issue in certain areas, i.e. a study area.
For example, consider an open space with multiple lighting zones, such as a public library or a large living/dining room. The constant motion of people walking by will need to be filtered to only activate when someone sits down or stays in a particular zone. This automatically rules out the PIR (which would be far superior in terms of power usage).
Thus, radar appears to be an obvious choice, as well as some other solutions such as VL53L5X and CH201, which appear to consume similar amounts of power for this application.
The obvious downside of radar over other similar technologies such as ToF, IR, etc. is that it is computationally expensive, as described below.
In general, the IPR uses the following software layers to process the radar data into useful detection information:
| SW Layers | Type | Purpose |
|---|---|---|
| Application Algorithm | Custom | Filters presence algo and manages power usage |
| Presence Algorithm | RSS (Proprietary) | Provides useful interpretation of service data |
| Sparse Service | RSS (Proprietary) | Pre-processes sensor data |
| HAL | Platform | Provide a generic HW interface to the RSS |
Documentation on RSS can be found here.
For the application layer, the main constraints are a compromise between power consumption and sensor performance/responsiveness.
Hence, the application will adjust the sampling rate of the sensor based on the presence or absence of a target.
More specifically, the sensor will sample at a rate of approx. 0.33 frames/s (radio gets priority since this is not time-critical), and based on the results of this detection, the frame rate can be increased up to 2Hz. Note that each frame contains 63 consecutive sweeps of the detection range. The application also introduces a hystersis-like behavior to the detection state. The table below shows the parameters used during testing.
Hence, the maximum time (excluding radio subsystem yields) required to switch to a "detected" state is
Through limited testing, this configuration yielded a false positive (i.e spurious detections without any apparent presence) rate of
| Parameter | Value |
| Start/End Distance | 0.2/1.75m |
| Threshold (TH+/TH-/THMAX) | 80/20/100 |
| dTH/dt(+/-) | 20/5 |
| Rx Gain | 0.5 |
| HWAAS | 63 |
| Power Mode | Off |
| Detection Threshold | 2000 |
| PCA Noise Reduction | 1 |
| Service Profile | 4 |
| Max Inter-frame Delay (IFDMAX) | 3000ms |
| Min Inter-frame Delay (IFDMIN) | 750ms |
Only the data from the detection algo is sent over CoAP (i.e state changes) together with some other stuff (ambient brightness, battery levels etc.).
The IPR utilizes CoAP for low-power communication with a remote server. In this project, the server runs on the same hardware as the border router.
| Server (OTBR) | Client (IPR) | Message | |
|---|---|---|---|
| <------------------ | DNS-SD | Register SLAAC IPv6 with SRP server | |
| GET | ------------------> | Informs client of the server IP and uri | |
| <------------------ | ACK | Ack (must be received or will not proceed) | |
| . | . | . | . |
| . | . | . | . |
| <------------------ | PUT | If change of detection state AND periodically | |
| ACK | ------------------> | Ack |
It is noteworthy that CoAP has many security issues like MQTT, but they were not of particular concern in this application since CoAP communication never leaves mesh-local.
There is also IPv6 address discovery implemented over DNS-SD (RFC6763), to allow the CoAP server to discover nodes that are connected to other routers.
Currently, the sensor has an average power consumption of approx. 140-160uA @ 1.8v, which can be reduced at the cost of performance (shown below)
This gives the sensor a battery life of >1 year on 2 x LR03 cells.
Future improvements are to replace the sensor with the pin-compatible A121, which is an improved version of the radar sensor with significantly lower idle vtx/rx currents, and should offset the avg. current by -60uA. Another obvious improvement is to disable the sensor at night.
The CoAP server allows for data collected to be visualized as shown below:
Overall, the DUT (3 nos.) remained stable during the field test, for the duration of > 1 year. This included power cycling of the border router, sporadic disconnections from the Internet, restarts of the SRP server etc.
The radar performance met expectations, with the exception of a single event (during the entire duration of the test) consisting of erroneous triggers lasting for approx. 5 minutes, for one DUT. Due to the nature of the event, it may have been caused by some form of interference or an unexpected strong reflector (i.e metal). Users should be aware of the possibilities of this occurence with radar.
The battery life calculations were corroborated by the measured battery life, which averaged no less than 1 yr (m = 1.1y, std = 0.06y). All tested units ran 24/7.