PRINT

Sonic Communication Technology for Quick Development of Low Cost Connected Thermometers

HIRATA Hideie
Application Development Dept.
Data System H.Q., Development Center
OMRON HEALTHCARE CO.,LTD.
Specialty: Software Engineering

With the rising demand for body temperature measurement and recording under the COVID-19 pandemic, there had not been a variety of choices for smartphone-connected thermometers. To respond to the significant leap of needs for body temperature recording, we faced the urgent task of developing a connected thermometer in a minimal time frame. Moreover, we found we would not be able to meet the timeline if we choose Bluetooth connectivity, since it requires a new hardware design and a new production line. In this situation, instead of Bluetooth communication, we considered sonic communication by taking advantage of notification buzzers already installed on our traditional thermometers. We focused on the fact that our thermometer could communicate by sonic wave transmitted by the buzzer just by changing its firmware. Our thermometer sends sound waves that modulate the measurement data using the buzzer in sonic communication, and smartphones receive sound waves using a microphone. It demodulates sound waves to measurement data. We have quickly delivered a connected thermometer to the markets at low cost by selecting this method. Also, it enabled better usability by eliminating the Bluetooth pairing process. We can extend this method to connected products for developing countries where low costs and simple usability are key factors.

1. Introduction

OMRON HEALTHCARE CO., LTD., released the MC-280B1), a sonic communicative contact thermometer for the European market, in January 2021, and then the MC-6800B2), a sonic communicative predictive thermometer for the Japanese market, in March 2021. Both models received favorable market responses (4.4 points on the 5-point Amazon review evaluation scale as averaged over a total of 993 reviews as of January 28, 2022).

Following the outbreak of the COVID-19 pandemic at the end of 2019, body temperature taking became a daily routine worldwide, leading to a rapid global expansion of demand for thermometers. At the same time, a new social challenge emerged of body temperature recording3). OMRON HEALTHCARE CO., LTD., considered that transferring and recording body temperature measurements to smartphones would add high convenience to personal health management and thermometry reporting and contribute, in turn, to solving that social challenge. Thus, we decided to face the urgent challenge of developing a communicative thermometer amid the COVID-19 pandemic. To supply communicative thermometers to the market with a short delivery lead-time, we adopted sonic communication technology, which had already been under development in-house, as a quick response to the social challenge.

Radio wave communication is a form of communication that relies on electromagnetic waves. Meanwhile, sonic communication is a sound wave-based form of communication. In recent years, empirical experiments and product developments have been underway using sonic communication technologies. Familiar fields have also seen the application of sonic communication technologies. For example, Chromecast, released by Google in 2014, uses a sonic communication technology for TV-smartphone pairing4).

Thermometers come standard with a piezoelectric buzzer to notify the user of the completion of temperature taking. If this buzzer could be used for sonic communication, thermometer firmware implementation would be the only job necessary to achieve the fastest commercialization. Therefore, we started the development of a sonic communication thermometer. Nevertheless, the demodulation algorithm for the smartphone on the receiving side was particularly important to provide stable sonic communication when our existing thermometer models had considerable hardware constraints.

This paper presents a description of the sonic communication technology adopted for our sonic communication thermometer.

2. Outline of Our Sonic Communication Technology and the Modulation Scheme Therefor

Sonic communication is a sound wave-based form of communication and works on the same principle as electromagnetic wave communication. The only difference is whether data is modulated into electromagnetic waves or sound waves. As such, sonic communication uses a conventional modulation technology. However, the prerequisite was that this modulation technology should be implementable with thermometer firmware only and nothing else. Thermometers use the sound generator function built into their CPUs and apply the CPU-generated rectangular wave output to the buzzer to ring it. We decided to use this sound generator function for modulation. Then, we narrowed down our list of candidate modulation schemes to ASK5) and FSK6), neither of which has phases among their modulation factors, after considering the constraint that only frequency and duty ratio are controllable while phase is not.

FSK schemes use changes in frequency to perform modulation and hence fell short of adoption, considering significant ringing frequency errors in the thermometer. Instead, we adopted an ASK scheme, which uses amplitude as the modulation key.

ASK schemes, in general, are noise-susceptible and rarely used for long-distance radio communication. However, because we premised proximity communication, during which the thermometer is held close to the smartphone窶冱 microphone (Fig. 1), our ASK scheme achieved an acceptable level of communication accuracy. The next section describes the investigation process that led to the definition of this preparatory action for communication.

Fig. 1 Conceptual image of sonic communication
Fig. 1 Conceptual image of sonic communication

3. Usability

To commercialize a sonic communication thermometer, we had to consider a preparatory action for communication that is effortlessly performable by the user. In an ASK-based sonic communication scheme, changes in amplitude are those in sound pressure. Accordingly, we had to ensure that the sound pressure radiated from the thermometer would reach a sufficient level for communication. For this purpose, we first studied the distribution of sound waves from the thermometer and investigated the most suitable direction (directivity) from the thermometer for sonic communication (Fig. 2).

Fig. 2 Measurement of the sound wave directivity of the thermometer
Fig. 2 Measurement of the sound wave directivity of the thermometer

Fig. 3 shows the results of measuring the sound pressure and the S/N ratio in Directions (1) to (5) (measurements were taken with a sample size of 25 to consider individual variations).

Fig. 3 Measurement results for sound pressure and S/N ratio
Fig. 3 Measurement results for sound pressure and S/N ratio

The investigation results revealed that the sound pressure and the S/N ratio fared the best in Direction (5) (thermometer窶冱 backside). The behavior of pushing this portion against the smartphone窶冱 microphone part, as in Fig. 1, was defined as the standard preparatory action for communication. This preparatory action for communication is only possible with a lightweight, pencil-shaped thermometer. A usability test verified that this preparatory action for communication allows the user to establish communication between the thermometer and the smartphone.

4. Sound Wave Demodulation by the Smartphone

The smartphone app (OMRON connect7)) for receiving measurement data from the sonic communication thermometer supports both Android and iOS and is implemented with a sonic communication demodulation process for both Android and iOS.

4.1 Demodulation Process

Fig. 4 shows the flow of the demodulation process in the smartphone.

Fig. 4 Demodulation process
Fig. 4 Demodulation process

4.1.1 PCM Audio Recording

The smartphone窶冱 microphone is used to capture acoustic signals to obtain PCM data sequences. This process is based on a function available on Android and iOS. Android has multiple audio source parameters for microphone recording, which posed a particularly difficult challenge to select the parameters most suitable for sonic communication (to ensure compatibility with various OS versions and smartphone models). The Android Compatibility Definition Document (CDD)8) served as the basis for a hypothesis for parameter selection. Based on this hypothesis, we conducted an exhaustive verification of various smartphone models to make an optimal selection of audio source parameters for sonic communication.

4.1.2 Frequency Band Filter

Following the adoption of an ASK scheme, a bandpass filter (IIR filter) tuned for the carrier wave frequency band was developed with the thermometer窶冱 ringing frequency errors in mind to eliminate all frequency components other than the carrier wave frequency band. The carrier wave is contained in a near-ultrasonic, high-frequency band and is resistant to environmental noise interference.

4.1.3 AM Demodulation

PCM data is converted into time-series amplitude values before ASK demodulation (Fig. 5). The broken line after the conversion into amplitude values is the peak envelope for PCM data. In other words, this process corresponds to the AM9) demodulation process in analog radio communication.

Fig. 5 AM demodulation
Fig. 5 AM demodulation

4.1.4 Spike Noise Filter

The signal immediately after AM demodulation contains high spike noise in its leading and trailing edges as shown in Fig. 6.

Fig. 6 Signal immediately after AM demodulation
Fig. 6 Signal immediately after AM demodulation

This phenomenon occurs as a result that the sound waves radiated from the thermometer are not ideal acoustic signals for communication because neither the thermometer窶冱 hardware design nor its buzzer窶冱 performance originally assumed sonic communication. If left unsolved, this problem would affect level normalization (explained below), resulting in reduced communication accuracy.

This product is aimed to allow communication with no change to the hardware design. Therefore, we decided to eliminate this spike noise on the smartphone side to ensure demodulation performance. We combined generic filter algorithms into an optimally tuned spike noise filter, successfully reducing the spike noise. Fig. 7 shows the waveform of the signal in Fig. 6 after spike noise filtration.

Fig. 7 Signal after spike noise filtration
Fig. 7 Signal after spike noise filtration

4.1.5 Level Normalization

Various fluctuation factors exist, including smartphone model-specific ones, such as the free-space path loss attenuation or the smartphone窶冱 built-in amplifier or gain control, before the smartphone samples an acoustic signal radiated from the thermometer. The sampled signal level does not remain constant. Besides, some smartphone models come with an auto gain control (AGC)10) function that automatically changes the gain wherein the signal level may fluctuate over the lapse of time. An ASK scheme relies on the magnitude of amplitude for demodulation and cannot uniquely determine the threshold for High-Low determination when the signal level does not remain constant.

If this problem is to be solved, the signal level value must be normalized to a constant level. Fig. 8 shows the AM demodulation signal from a smartphone model, showing that the AGC causes the signal level to increase gradually over the lapse of time.

Fig. 8 AM demodulation signal from an AGC-equipped smartphone
Fig. 8 AM demodulation signal from an AGC-equipped smartphone

This signal waveform can be converted into that in Fig. 9 by normalization up to 1 within a constant time window. Fig. 9 shows how the AGC-induced signal increase was leveled out with the maximum value normalized to 1.

Fig. 9 AM demodulation signal after normalization
Fig. 9 AM demodulation signal after normalization

4.1.6 ASK Demodulation

Amplitude values are normalized to the maximum value of 1 by level normalization. Assuming a threshold of 0.5 here, amplitudes exceeding it and those equal to or below it are demodulated into high and low amplitudes, respectively (Fig. 10). All that remains is to demodulate the resulting digital waveform into data.

Fig. 10 Signal subject to ASK demodulation
Fig. 10 Signal subject to ASK demodulation

4.2 Software Architecture for the Sound Wave Demodulation Process

Fig. 11 shows the software architecture for the smartphone窶冱 sound wave demodulation process. The sonic communication core engine is an implementation common to both Android and iOS.

Fig. 11 Software architecture
Fig. 11 Software architecture

Table 1 shows the details of the respective software blocks:

Table 1 Descriptions of software blocks
Block Language
used for implementation
Description
Android-specific block Java Passes PCM data captured using the Audio Record function to the common layer for the sonic communication core engine.
iOS-specific block Objective C Passes PCM data captured using the Audio Unit function to the common layer for the sonic communication core engine.
Common block C++ Is a sonic communication core engine. Implemented using the C++ language, with a common code base intended for compilation on both Android and iOS.

Worthy of special note is the sonic communication core engine implemented using the C++ language. The C++ language was selected to provide a cross-platform solution non-dependent on operating systems, including Android and iOS. The sonic communication demodulation process requires a huge amount of computational processing. However, the use of the C++ language native code enabled high-speed execution unachievable, especially with Java for Android. Moreover, the sonic communication core engine has been diverted to the pre-shipment inspection equipment for sonic communication thermometers, providing an additional benefit of the cross-platform solution.

5. Accuracy of Sonic Communication

Smartphones come in a wide variety of models and differ in the performance of the built-in microphone and the audio recording algorithm therefor. Accordingly, we conducted an exhaustive verification of smartphones to ensure that many smartphone models would have no problem with sonic communication. Each model underwent the verification in the six positioning patterns (= 3テ2) shown in Fig. 12.

Fig. 12 Positioning patterns in the exhaustive verification
Fig. 12 Positioning patterns in the exhaustive verification

For a total of 197 smartphone models (smartphones for the Japanese and overseas markets as of October 2020), we defined the ratio of the number of normally demodulated packets per 40 packets from the thermometer as the communication success rate and evaluated each model against the target communication success rate of 35% or higher. We set the communication success rate to 35% or higher considering the following points:

  • The required communication time per packet is approximately 0.7 seconds, which means that seven-packets-worth of communication is possible every 5 seconds.
  • A communication success rate of 35% means a failure rate of 65%. The probability of communication failure for seven consecutive packets is 0.657 = 0.05, in other words, 5%.
  • From the above, assuming a communication success rate of 35% or higher, a communication session will complete within 5 seconds with a 95% or higher probability.

Table 2 summarizes the communication success rate distribution for the measurement points (depth テ 3; height テ 2). Models falling short of the target communication success rate accounted for about 2% to 5% of all models used. However, more than 94% of the models used achieved high communication accuracy with a communication success rate of 80% or higher.

Table 2 Results of the exhaustive verification
Table 2 Results of the exhaustive verification

In this verification, the PCM data sampled by each smartphone was saved in a WAV file. Then, the demodulation algorithm underwent cycles consisting of tuning and subsequent verification against the WAV file. Thus, the verification contributed to brushing up the demodulation algorithm and each parameter.

6. Conclusions

Our sonic communication thermometer, the MC-6800B, has become an exceptional hit product11) in Japan for a consumer product equipped with sonic communication, challenging the conventional view about the possibility of sonic communication. Sonic communication is a low-cost means of communication that only needs a sound wave generation device (piezoelectric buzzer in this study) and a microphone (built in smartphones) to establish communication. As such, this product has been made available in a smaller size with a lower price tag than conventional communicative thermometers. The sonic communication scheme that we devised has a simple modulation scheme and requires no special hardware for modulation. Besides, our demodulation algorithm was developed for stable sonic communication, especially with smartphones in mind. We expect its application to devices for emerging country markets, where the priority requirement is low-cost, straightforward communication usability.

Low in the available communication rate, our modulation scheme is currently unsuitable for high-volume data transfer. However, the room remains to improve communication speed through enhanced device hardware performance. We will improve the scheme into a communication protocol able to accommodate high-volume data transfer.

References

1シ
OMRON HEALTHCARE EUROPE B.V., 窶廢co Temp Intelli IT MC-280B.窶 OMRON HEALTHCARE EUROPE. https://www.omron-healthcare.com/eu/thermometers/Eco_Temp_Intelli_IT.html (accessed Jan. 6, 2022).
2シ
OMRON HEALTHCARE CO., LTD., 窶彜onic Communication Thermometer MC-6800B Ken窶冩n-Kun,窶 (in Japanese), OMRON HEALTHCARE. https://www.healthcare.omron.co.jp/product/mc/mc-6800b.html (accessed Jan. 6, 2022).
3シ
Feitian Japan Co., Ltd., 窶廸ew Coronavirus Measures窶鼎ompanies and Schools to Introduce Compulsory Temperature Checks,窶 (in Japanese), Feitian Japan Co., Ltd., blog. https://ftsafe.co.jp/blog/temperature-measurement-mandatory/ (accessed Jan. 28, 2022).
4シ
Style Corporation, WirelessWire News Editorial Staff, 窶廨oogle窶冱 窶呂hromecast窶 to Be Connectable to Mobile Terminals Using Ultrasonic Waves,窶 (in Japanese), WirelessWire News. https://wirelesswire.jp/2014/06/16578/ (accessed Feb. 9, 2022).
5シ
Incept Inc., 窶弩hat Is Amplitude Shift Keying (ASK)?窶 (in Japanese), Glossary of IT terms e-Words. https://e-words.jp/w/ASK.html (accessed Jan. 6, 2022).
6シ
Incept Inc., 窶弩hat Is Frequency Shift Keying (FSK)?窶 (in Japanese), Glossary of IT terms e-Words. https://e-words.jp/w/FSK.html (accessed Jan. 6, 2022).
7シ
OMRON HEALTHCARE CO., LTD., 窶廾MRON connect Official Site,窶 (in Japanese), OMRON HEALTHCARE. https://www.omronconnect.com/jp/ja_def/ (accessed Jan. 6, 2022).
8シ
Android Open-Source Project, 窶廣ndroid Compatibility Definition Document,窶 (in Japanese), Android Open-Source Project. https://source.android.com/compatibility/cdd?hl=ja (accessed Jan. 6, 2022).
9シ
ITmedia Inc., 窶廣mplitude Modulation (AM),窶 (in Japanese), EDN Japan. https://edn.itmedia.co.jp/edn/articles/1411/26/news015.html (accessed Jan. 6, 2022).
10シ
Japan Media Systems Corp., 窶廣uto Gain Control (AGC),窶 (in Japanese), LiveOn. https://www.liveon.ne.jp/glossary/wk/agc.html (accessed Jan. 6, 2022).
11シ
Smart Solution Technology, Inc., 窶300K Units Sold! Omron窶冱 Smash Hit 窶牢onic Communication Thermometer窶吮典he Plan Developer and Engineers Tell the Surprising Reason for the Adoption of 窶牢onic Communication窶,窶 (in Japanese), Smart Sound Lab. https://smartsoundlab.com/2022/01/000078.html (accessed Jan. 28, 2022).

The names of products in the text may be trademarks of each company.
Android is the registered trademark of Google LLC (USA) in Japan and other countries.
iOS is the registered trademark of Cisco Systems, Inc. (USA) in Japan and other countries and is used by Apple, Inc., (USA) under license.
Java is the registered trademark of Oracle Corporation (USA) in Japan and other countries.