Hardware components | ||||||
 |
| × | 1 | |||
 |
| × | 1 | |||
 |
| × | 1 | |||
Software apps and online services | ||||||
| ||||||
| ||||||
 |
| |||||
| ||||||
| ||||||
Hand tools and fabrication machines | ||||||
 |
| |||||
The COVID-19 outbreak has infected around a quarter million population in 178 countries and caused more than 10k deaths (as of March 2020). Measures to contain the virus have led to shortages in supply, economic losses, social distancing and lockdowns. While a major part of humanity is embracing work-from-home and home-quarantine policies, one cannot help but wonder if this is enough to prevent infection from this highly contagious virus...
A virus generally transmits itself in the following ways -
- As a stream of droplets emerging from a sneeze or cough from an infected patient (The virus remains in the air for a few seconds before being pulled down by gravity and falling on a surface)
- As an aerosol, in case of which it can easily linger and spread for hours
- Touching a surface, paper, metal, cardboard, etc where it can remain active for hours and make its way into your system via your hands and T-region of the face.
Findings show that the COVID-19 virus is currently spreading majorly as a stream of droplets, and seldomly as an aerosol, reducing its R-value (The R-value is the avg people infected by a single infected person. It is around 2-2.5 in general conditions for COVID-19). While many things about the virus' transmissivity are unknown, there are a few trends that have been observed while considering its survivability on environmental surfaces in this paper -
- The virus shows higher survivability at lower relative humidity (<20%) and can easily thrive for days in a wide range of RH levels (20% - 60%).
- The virus also showed higher survivability at lower Air Temperatures (<20 deg C), surviving for 2 days, showing a very small loss in infectivity over time.
- The effect of RH is greater than that of AT for its viral inactivation.
- It is observed and predicted that high temperature and high RH will reduce the transmissivity of the virus. The relations are shown in figure 1.
- Apart from RH and AT, from our past experiences with similar viruses, it is being predicted that sunlight exposure and UV radiation will have a significant effect on the transmissivity and survivability of the virus. While this has NOT been proved scientifically as of March 2020 for the COVID-19, it can be safe to say that places with better and direct sunlight can have a good impact on the viruses' survivability.
- Corona is a respiratory disease that has a lower mortality rate than SARS and MERS, but it is still severe for people with other diseases, including respiratory ones. This means the AQI or Air Quality Index also plays a significant role in determining the severity of the virus in your locality. As Sara De Matteis, at Cagliari University, Italy says -
"Patients with chronic lung and heart conditions caused or worsened by long-term exposure to air pollution are less able to fight off lung infections and more likely to die. This is likely also the case for Covid-19. By lowering air pollution levels we can help the most vulnerable in their fight against this and any possible future pandemics."The Solution
As we can easily see, a number of environmental factors play a significant role in transmitting and contracting this disease. Its fatality and severity are also affected by these factors. Hence we plan to devise a system with a particular set of features that will help the user to identify the values of the before-mentioned parameters and give a transmissivity, survivability and severity (TSS) score for the COVID-19 virus in that local environment.
The RSL10-SENSE-DB-GEVK is a kit, developed by ON-Semiconductor contains all the sensors needed and even more features in a small form factor. It has significant benefits over other choices, like -
- Very long battery life, even when powered using a coin cell
- A small form factor of circular shape helps to integrate it with other devices to make a complete system.
- The in-built Audio DSP processor and Codec reduces the load on any external uC.
- Built-in mic for capturing voice samples and audio commands.
- Built-in Bluetooth (BLE) functionality, compatible with the free On Semiconductor Sense and Control App.
- Cloud access and data storage using the Sense and Control App via MQTT protocol makes it a feature-rich IoT empowered device.
- The RSL10 contains an Arm Cortex M3 processor that controls all onboard sensors using a simple I2C interface. It is Industry's Lowest Power BLE SOC with an EEMBC ULP rating of 1090 at 3V and 1260 at 2.1V which is the industry's best till now.
- The RSL10 operates on a proprietary BLE protocol.
- Ample of useful sensors, controlled using the same I2C interface. Hence they are easily accessible to any externally attached uC.
- 64kB NFC EEPROM for data storage, authentication and wireless access.
The working of the module will be simple -
- The sensor hub will measure Atmospheric Temperature, Relative Humidity, Air Quality Index, Ambient Lighting, Compass data and IMU parameters (to check if the user has not suffered a fall or a collapse).
- The sensor module will use the sensor module's mic to capture the user's commands and voice, including noises of screams, groans and other noises that might indicate an emergency situation.
- All this data will be relayed to the uC via an I2C interface as a telemetry packet.
- The uC will then combine the received data with the GPS location from the Adafruit Ultimate GPS to calculate the TSS score.
- Using voice commands, the user can switch off the device, ask for the TSS score or issue an SOS signal. The parameters that identify the sound will be sent to the uC as a part of the telemetry.
- The TSS score can be seen on the Web App, that I developed based on the help available on this review of the RSL10 sensor board device. A similar phone-based app could be developed for portability.
- Any SOS msg can be relayed using the user's phone or Laptop once he has connected the device to the custom App using BT, with his location and condition.
So Let's begin building the System!
RSL10-SENSE-DB-GEVKThe sensor board from On-Semiconductor is a wonderful piece of HW that has immense power packed into a minuscule form factor. While this board has multiple sensors and a breakout header for the I2C interface, it has a few limitations -
- The board is not a development board or a uC as such since all the interfaces of the Arm Cortex M3 processors are already used by the on-board sensors. Only 1 GPIO and 1 I2C interface come out from the breakout header which is in most cases not sufficient.
- The DMIC INMP522ACEZ-R7 is capable of handling two channels as is with any normal earphone, but the RSL10 schematic shows that the RL pin is grounded, meaning the IC permanently operates on the right channel.
- The documentation of this board and the RSL10 chip though vast, has a steep learning curve and is much more difficult then arduino coding.
- The RSL10 chip operates on a proprietary BLE protocol, which means that generic apps or devices cannot directly connect to the device and the documentation on this topic is as good as absent.
- The NFC antenna while small, flexible and suitable for the board; is extremely delicate and prone to wear and tear.
- The NOA1305 Lux sensor works erratically sometimes, even with example codes, returning 0 value all the time.
Hence, we need a dedicated uC to connect the GPS (which works on the Serial Interface) and send custom messages which one might find difficult to send via the BLE protocol of the RSL10. If you don't want to incorporate the GPS and keep it simple, you can easily perform the remainder of the tasks using the Built-in Arm Cortex M3
The ON Semiconductor IDE has plenty of examples. The sense_production_tests example suits our application the most. It contains code to receive all the sensor data and audio input directly using the RTT viewer and BLE.
Sensor Data Measurement:
All the sensor data that is measured is compressed in the form of a telemetry packet as follows:
sprintf(aTxBuffer, "%d,%0.2f,%0.2f,%0.2f,%0.2f,%0.2f,%0.2f,%0.2f,%0.2f,%0.2f,%0.2f,%0.2f,%0.2f,%d\r\n", lux, temp, humidity, press, aqi, heading, yaw, pitch, ax, ay, az, gx, gy, gz,avg);To make things simpler and save power, the gas resistance measurements done by the Arduino and added to the telemetry with GPS data.
Audio Packets:
Using the scope, we can easily visualise the audio inputs coded by the Built-in mic and process them to identify unique voices.
This was done using 4 parameters - cumulative amplitude, dmic threshold, command time and dmic difference. The Interrupt handler that collects the audio inputs is shown below.
void DMIC_OUT_OD_IN_IRQHandler(void)
{
dmic_value = (int32_t)AUDIO->DMIC0_DATA;
dmic_abs_old = dmic_abs;
dmic_abs = absolute(dmic_value);
if (dmic_flag == 1) {
cum_ampl = cum_ampl + dmic_abs;
command_time++;
if(command_time_1 < command_time) {
command_time_1 = command_time;
}
if(cum_ampl_1 < cum_ampl) {
cum_ampl_1 = cum_ampl;
}
}
else if (dmic_flag == 0) {
cum_ampl = 0;
command_time = 0;
dmic_min = 0;
dmic_max = 0;
}
if (dmic_abs > dmic_thresh) {
dmic_flag = 1;
if (dmic_abs_old < dmic_abs) {
dmic_max = dmic_abs;
dmic_min = dmic_abs_old;
}
else if (dmic_abs_old > dmic_abs) {
dmic_max = dmic_abs_old;
dmic_min = dmic_abs;
}
}
else if (dmic_abs_old < dmic_thresh) {
dmic_flag = 2;
dmic_diff = absolute(dmic_max - dmic_min);
}
}The handler first takes the dmic_value and removes its sign, considering only its absolute value(dmic_abs). While this absolute value crosses the dmic threshold(dmic_thresh), the dmic_abs variable is added to the cum_ampl variable, and the command_time variable starts incrementing. This means that the user has made an audio input, greater than the normal noise bed. The dmic_diff variable is calculated by subtracting the dmic_min variable from the dmic_max variable, which helps in normalizing the command. The avg value is then calculated as follows:
if (dmic_flag == 2) {
avg = absolute(cum_ampl_1/(command_time_1*dmic_diff));
cum_ampl_1 = 0;
command_time_1 = 0;
dmic_flag = 0;
} The avg value is done using the sum of all dmic values (cum_ampl) divided by the total command time (command_time), normalized by the dmic_diff variable. This gives us a unique avg value that helps us in recognizing the command or audio input. Once the avg value is noted, the variables are reset.
I2C communication:
The I2C address of the RSL10 is 0x10 by default. The transmission code for the sensor board is as follows:
static int8_t tele_I2C_Write(uint8_t dev_id, uint8_t reg_addr, uint8_t *reg_data, uint16_t len)
{
int32_t status;
uint8_t *write_data = malloc(len + 1);
if (write_data == NULL)
{
return -1;
}
write_data[0] = reg_addr;
memcpy(write_data + 1, reg_data, len);
status = HAL_I2C_Write(dev_id, write_data, len + 1, false);
free(write_data);
return status;
}The receiver code for the sensor board is -
static int8_t tele_I2C_Read(uint8_t dev_id, uint8_t reg_addr, uint8_t *reg_data, uint16_t len)
{
int32_t status;
uint8_t *read_data = malloc(len + 1);
if (read_data == NULL)
{
return -1;
}
read_data[0] = reg_addr;
memcpy(read_data + 1, reg_data, len);
status = HAL_I2C_Read(dev_id, write_data, len + 1, false);
free(read_data);
return status;
}The Arduino Side
The Arduino side of the code adds the GPS and gas resistance data to the telemetry packet. The I2C pins (A4, A5 and D13) are connected to the corresponding I2C pins of the Sensor board (SDA, SCL and SCK resp). The GPS module is connected to the UART (D0 and D1) pins of the Nano, in an opposite fashion (RX of GPS -> Tx of Arduino and so on). After adding the GPS and AQI Data to the telemetry, the data is processed and multiplied with weights to get the TSS value of the locality.
Combining it all
Different weights were assigned to each aspect of the telemetry. All these weights are taken together and multiplied to the telemetry received. The TSS data, SOS data and GPS data are received by any device using BLE and displayed on the phone or web app.
Comments