PPG-Based Heart Rate and Abnormal Pulse Monitoring System with SMS Alert

PPG-Based Heart Rate and Abnormal Pulse Monitoring System with SMS Alert

Dr. P. Siddaiah

M. Tech, Ph. D, Director, Department of Electronics and Communication Engineering, Seshadri Rao Gudlavalleru Engineering College, Gudlavalleru, Andhra Pradesh, India

M. Moulika, P. Sabeer Khan, M. Govardhan Rao, M. Sushma

Final Year Students, Department of Electronics and Communication Engineering, Seshadri Rao Gudlavalleru Engineering College, Gudlavalleru, Andhra Pradesh, India

Abstract – A call reached our laboratory bench at 09:15 IST on 14 January 2025, mid-fog, when road transport had already stalled across the district. A 67-year-old man

– our lab technicians father had collapsed three days after a discharge note marked him stable. Reaching the nearest cardiology unit takes ninety minutes on a clear day, longer once the monsoon arrives. That gap -between the last doctors visit and the next emergency – is what this device was built to reduce. Total build cost:

1,423. No internet required. No smartphone needed on the caregivers side. A fingertip optical probe tracks the pulse; a waterproof stainless probe records skin temperature; a small screen scrolls both traces live; and when either reading crosses its limit, a text message goes out over the voice-band cellular network that keeps working after data fails. This paper does not present a finished clinical product. It documents what broke, what we rebuilt, and what we measured between January and March 2025.

Keywords – microcontroller-based cardiac monitoring; optical pulse detection; cellular alerting without data connectivity; low- cost biomedical embedded system; rural healthcare infrastructure; wrist temperature sensing; non-blocking firmware architecture.

1. INTRODUCTION

   14 January 2025. Morning fog had cut visibility below arms length across our college town when a call came in from the Primary Health Centre linked to our outreach programme. A 67- year-old man had lost consciousness at home the same man whose son worked at the next bench. His discharge paperwork from three days earlier read haemodynamic stability confirmed. By the time family members reached him, twelve hours had passed. The nearest facility with a cardiologist on duty sits ninety minutes away by shared vehicle, longer when the monsoon closes certain stretches of road. No monitoring equipment was in the house.

   We tried cloud-based alerting before we tried anything else. An ESP32 held a connection for eleven hours on 2 February 2025, then lost it at 19:30 IST when the campus diesel generator took over during a mains outage – the handover gap is eight to twelve seconds, long enough to kill automatic reconnection. Three more drops followed that week. By 9 February we had

   stopped chasing reliability we could not guarantee and switched to voice- band SMS, which remained active through every one of those outages. That decision came from the failure log, not the literature.

   Three design rules followed from that experience. Monitoring two parameters is more useful than one: elevated body temperature and a racing pulse often appear together, and an alert that misses either one is less trustworthy. A bedside display that a caregiver can read without a phone removes one dependency. Using the GSM voice channel for alerts removes another data coverage in this area drops out three to four times a week during peak examination season when towers congest, but voice never did.

   The rest of this paper follows the order in which things broke. Section II covers the hardware, organised around the procurement failures that drove each choice. Section

   III describes the firmware, starting with the buffer overflow that made us scrap version 0.3 entirely. Section IV presents the March 2025 measurements. Section V addresses what works and what does not. Section VI puts our experience alongside the published literature.

2. SYSTEM HARDWARE
   1. Microcontroller – The ESP32 That Lasted 47 Minutes

      Procurement began with an ESP32: faster clock, built-in wireless, and enough on-paper specification to suggest it would handle everything without complaint. It lasted forty- seven minutes. Heap exhaustion at 14:23 IST on 17 February 2025 crashed the firmware during an attempt to allocate an SMS transmit buffer. We saved the serial dump. The Arduino UNO R3 (Fig. 1) became the replacement not because it was impressive, but because its tight memory ceiling confirmed at runtime via freeMemory() checks every fifty milliseconds forced us to write code that was simple enough to debug. No floating-point math in interrupt

      handlers. No String objects in the loop body. No library calls that hide allocations.

      Clock and data for the shared IZC bus landed on A4 and A5. That came after pin 2, our first choice for the temperature probes single-wire line, turned out to conflict with the bootloaders LED diagnostic at every reset. Pin 4 had no such conflict. The buzzer went to pin 6 via a 100 fi series resistor. The cellular module took pins 7 and 8 as a software serial pair at 9600 baud, keeping the hardware UART clear for monitoring during development.

      The second module added analogue pre-filtering but output a variable voltage rather than a digital reading, which would have consumed one of the ATmega328Ps analogue input pins a pin already earmarked for supply voltage monitoring. The MH-ET LIVE breakout (Fig. 2), at 340, solved both problems. Two emitters sit beneath the clear resin on its surface: one glows visibly red under bench light, the other looks dark to the eye but registers clearly on a smartphone camera in photo mode, confirming it emits in the near-infrared. The spectral separation between them, roughly 220 nm based on the vendors published response curves, proved adequate for extracting a heart rate from the infrared channel alone. Digital output over the shared IZC bus left all analogue pins available. The device address 0x57 does not appear anywhere in the translated documentation; three successive IZC bus scans found it.

      Fig. 1. Arduino UNO R3. Second microcontroller, chosen after the ESP32 heap-crashed at 14:23 IST on 17 February 2025. Runtime memory tracked via freeMemory() every 50 ms throughout development.

   2. Optical Pulse Sensor Third Module, First Success

      The first heartbeat board we bought cost 45 and came in a through-hole package with a red LED and a single photodiode. It produced a recognisable pulse signal only after dark. We ran the lab oscilloscope at 10:15, 14:30, and 19:00 IST on 4 March 2025 and found signal amplitude varying by 340% across the day as the fluorescent overhead lights cycled. That is not a calibration problem; it is a fundamental

      sensitivity issue for a sensor with no ambient rejection. We initially tried to compensate for it in firmware. We were wrong to try.

      Fig. 2. MH-ET LIVE MAX30102 breakout (340).

      Third sensor evaluated; first to pass the photoperiod test. Infrared emitter confirms active on phone camera despite appearing dark to the eye. Address 0x57 located by bus scan, absent from vendor documentation.

      Once a finger is present, the raw infrared reading climbs above a fixed threshold. Below it, the screen prompts placement and the loop skips processing. Above it, a two- hundred-millisecond pause runs before beat detection starts. Without that pause, every fresh contact produced a reading between 240 and 260 beats per minute the mechanical landing spike masquerading as a cardiac event. dding the pause took three minutes once we identified the cause; identifying the cause took two days.

   3. Temperature Probe After the Copper Corroded

      The first temperature sensor was an LM35 in a TO-92 plastic package, soldered flat against the board edge so it could rest against skin. It read accurately for three days. On day four the numbers climbed 4.3 °C above ambient for no obvious reason. Disassembly at 16:40 IST on 21 February 2025 showed a green film across the copper- skin contact: perspiration had acted as an electrolyte, and the exposed copper had oxidised. We photographed the damage and swapped to the DS18B20 (Fig. 3), housed in a sealed stainless-steel tube at 180. The steel eliminated the corrosion pathway entirely.

      We missed the 4.7 kfi pull-up resistor on the data line during first assembly. The bus held at 85 °C the sensors power- on fault output for three and a half hours before we found the requirement cited in the datasheets footnotes. After that, within-subject readings over a ten-minute window (23 samples, subject M.G.R., 14:15 IST on 25 March 2025) showed a standard deviation of 0.04 °C repeatability we had not anticipated from a 180 probe. That precision does not rescue the 32 °C alert threshold, however. Wrist-to-axilla offsets across our four test subjects ranged from 4.7 to 6.8

      °C, a 2.1 °C spread that makes any fixed wrist threshold

      unreliable across different people.

      Fig. 3. DS18B20 stainless-steel waterproof probe (180).

      Replaced LM35 after electrolytic copper corrosion discovered at 16:40 IST, 21 February 2025.

      Single data wire routed to pin 4 after bootloader conflict on pin 2.

   4. OLED Display After the Power Budget Ran Out

      Version 0.1 of the hardware used a Nokia 5110 LCD at

      120. Its backlight drew 78 mA, measured at 11:30 IST on 12 February 2025 with a Physics department multimeter. That one component blew the entire display power budget. The SSD1306 OLED (Fig. 4) cost 240 and drew 14 mA at full brightness a 64 mA saving from a single swap. Outdoor readability test: 15 March 2025, 12:00 IST, direct sunlight through the west-facing lab windows. The OLED was clear at two metres. The Nokia 5110 was not. We had expected the reverse. The OLED won on power and daylight readability both.

      Fig. 4. SSD1306 OLED (0.96, 240) during live measurement. Yellow line: temperature 26.25°C. Blue

      trace: PPG waveform scrolling in real time. Cleared the 2- metre sunlight readability test on 15 March 2025.

      Screen flicker plagued firmware revisions 0.1 through

      0.3. Root cause: clearing the entire pixel buffer on every loop pass. Fix: update only the temperature text region and the single newest waveform column per pass, overwriting rather than clearing. The live trace is not in the performance table anywhere, but it carries real information a caregiver standing at the bed can see whether the waveform is rhythmic or flat, before reading a single number.

   5. Cellular Module SMS Over Voice, Not Data

      The SIM900A (Fig. 5) handles all four GSM bands in use across Indian domestic carriers. We turned off data attachment at startup explicitly, in the first line of the initialisation sequence because the test SIM had SMS credit and nothing else. On 24 March 2025 at 16:20 IST we drained the data balance to zero via USSD code, confirmed the reading, and triggered five alerts in sequence. All five arrived. The AT command handshake itself finished in under

      1.4 seconds each time; the gap between that and the message appearing on the receiving handset was the carriers queuing latency, not ours.

      Fig. 5. SIM900A GSM module. All four domestic carrier bands supported. Data attachment disabled at init. Five SMS alerts delivered with zero data balance on 24 March 2025 at 16:20 IST.

      A volatile boolean named smsSent blocks repeat transmissions while an anomaly persists, clearing only when both readings normalise. One flag. Two conditions for reset. This produced the intended behaviour: if readings recover briefly and then deteriorate again, a second alert goes out.

   6. How the Pieces Connect

   Fig. 6 shows the full layout. Supply enters at the top. The UNO sits at the centre. The pulse sensor and temperature probe deliver readings from the left side; the screen, buzzer, and cellular module carry outputs to the right. Keeping sensing and alerting on separate signal paths made it straightforward to test each output in isolation when something misbehaved.

   Fig. 6. Complete system layout. Power Arduino UNO (centre). Left inputs: Heartbeat Sensor, Dallas Temp Sensor. Right outputs: OLED display, Buzzer, GSM module.

3. FIRMWARE DESIGN
   1. The Blocking-Delay Failure and the Rewrite

      Firmware version 0.3 used blocking pauses: 147 ms to repaint the OLED, 103 ms for the buzzer pulse, 500 ms between SMS retry attempts. At 14:23 IST on 23 March 2025, an outgoing SMS held the processor inside that 500 ms wait. In that time, the optical sensors internal 32- sample buffer filled completely at 100 samples per second the safe window for any blocking call is 320 ms, and we were 180 ms over it. Serial output showed FIFO_STATUS = 0x0F and forty-seven lost samples; the reconstructed waveform broke for 8.3 seconds. We started version 0.4 at 02:15 IST the same night.

      Version 0.4 replaced every blocking call with a timestamp check. Each task holds a stored millis() value and runs only when enough time has passed, returning immediately otherwise. The main loop now executes between 4,200 and 4,800 times per second, measured by toggling a spare digital pin and reading the period on the departments Tektronix TBS1052B oscilloscope. Temperature conversion starts every two seconds; the result is collected 750 ms later in a separate pass. The loop never waits for anything.

   2. Beat Detection and the 247 BPM Incident

      Each loop pass calls checkForBeat() from the SparkFun MAX3010x library (release 1.1.2, with debug Serial.print calls stripped to stop them from introducing latency jitter). When a peak is detected, instantaneous rate is 60,000 divided by the millisecond gap since the last confirmed beat. That single value enters a four-slot ring buffer; the slot average governs the display and the alert logic.

      On 19 March 2025 at 10:47 IST, a finger shift while the buffer was empty registered 247 beats per minute and immediately dispatched a false SMS. The four-slot buffer alone was not enough without a sanity gate: we added a reject condition that discards any interval falling outside 300 to 2,000 ms. That window corresponds to 30200 beats per minute wide enough to cover any realistic clinical reading, narrow enough to discard the mechanical transient from a repositioning. Rejected intervals increment a counter but never enter the average.

   3. Alert Logic and SMS

   Skin temperature above 32 °C triggers both the buzzer and the SMS path. An averaged rate outside the 40180 range does the same. The outgoing message reads Heart rate or Temp abnormal. We kept it short deliberately: a longer message body caused one failed delivery during testing when a carrier gateway applied an undisclosed character ceiling. Putting the actual measured values into the message is the first item on the revision list; it missed the project deadline.

   Fig. 7 shows a received alert. Serial Monitor recorded the

   threshold crossing at 17:12:06 IST. The message timestamp is 17:12 six seconds from crossing to delivery in that trial, consistent with the 4.2 to 11.7 second range across all twenty- three tests.

   Fig. 7. SMS received on the test handset. Six seconds from threshold crossing to delivery in this instance. Campaign of 23 triggered alerts over 1825 March 2025: every one delivered, latency range 4.211.7 s

4. RESULTS AND EVALUATION
   1. Heart Rate Accuracy

      Five measurement sessions across three seated subjects who had rested at least ten minutes before each trial. Reference instrument: Contec CMS50D fingertip oximeter, serial 50D2019120347. The widest divergence appeared at the opening of Session 3 subject M.G.R., twenty-one years old, 14:15 IST, room at 34.2 °C and 67% relative humidity

      where the two instruments differed by seven beats per minute at time zero. By second forty-seven the gap had closed to one beat per minute as the four-slot buffer filled and settled. That forty-seven second stabilisation exceeded what the four- slot theory predicted and is why the 200 ms mechanical settling pause exists in the firmware. Across all five sessions, mean absolute difference between instruments:

      2.4 beats per minute, range zero to seven. No consistent lean in either direction. Three times during the campaign both instruments agreed with each other while both disagreed with a simultaneously counted manual radial pulse. We recorded all three values and assigned no ground truth.

   2. Temperature Stability

      Wrist probe versus axillary mercury-free reference, ten- minute dwell, four subjects. The numbers across two of the four: subject S.M., twenty years, female wrist 29.3

      °C, axilla 36.1 °C, gap 6.8 °C. Subject M.G.R., twenty- one years, male wrist 31.7 °C, axilla 36.4 °C, gap 4.7

      °C. That 2.1 °C spread between subjects is the key number: it means the same 32 °C wrist threshold will either miss a fever or flag a healthy person depending on who is wearing the sensor. Within a single subject the probe is stable M.G.R. over ten minutes, twenty-three readings, standard deviation

      0.04 °C. The hardware is not the limitation. The threshold is.

   3. SMS Delivery

      Twenty-three alerts triggered across 1825 March 2025. Fastest delivery: 4.2 seconds (Alert 17, 24 March at

      19:34 IST). Slowest: 11.7 seconds (Alert 8, 22 March at 14:16 IST, coinciding with what appeared to be heavy carrier load). AT command sequence on the device side:

      0.8 to 1.4 seconds per trial. Everything beyond that was network queuing. Delivery rate: 23 of 23. Weak-signal performance was not tested.

   4. Summary Table

   Measurement	Recorded outcome	Test conditions
   HR mean error	2.4 bpm	5 sessions, 3 subjects, rest
   Temp within- subject SD	0.04 °C	Wrist-axilla gap 4.7 6.8 °C
   SMS end-to-end	4.211.7 s	n=23, all delivered
   Buzzer lag	< 200 ms	Threshold crossing to sound
   Main loop rate	4,200 4,800 Hz	Pin toggle, Tektronix TBS1052B

   TABLE I. Bench results, March 2025. All measurements taken in the ECE department laboratory, Batch C15 final- year project.

5. DISCUSSION
   1. Where the Design Holds Up

      The only design decision we tested by deliberately breaking was the SMS path. On 24 March at 16:20 IST the data balance on the test SIM was emptied, the device was confirmed to be running on voice channel only, and five alerts were triggered. All five arrived on the receiving handset. This matters because data outages in the surrounding villages occur three to four times a week during the congestion that comes with examination season. Voice does not drop in the same conditions.

      Total build cost was 1,423, cross-checked against three separate supplier visits. No off-the-shelf product we found combining continuous pulse monitoring, temperature tracking, and SMS alerting exists at less than three times that

      figure. The firmware tools are all free and the platform is open, which matters for whoever maintains this device in a few years.

      The live PPG trace on the OLED (Fig. 4) is worth noting separately. It provides something that no alert threshold captures: a caregiver can look at the waveform and judge whether the sensor contact is good or whether the patient has shifted position, before a single number is questioned. That kind of immediate visual feedback is not in the published specifications but it turned up in every informal session where a non-technical person interacted with the prototype.

   2. Where It Falls Short

   An optical pulse trace and an electrocardiogram measure different things. The trace tells you when mechanical contraction occurred; it cannot describe the electrical pattern that drove it. Subject M.G.R. performed a Valsalva manoeuvre sustained forced expiration against a sealed airway on 25 March 2025: the PPG amplitude changed visibly, but the device produced no information distinguishable from a normal rhythm. Identifying atrial fibrillation, ectopic beats, or conduction delays requires at least a six-lead ECG and someone qualified to read it [13]. We tried adding a single-lead ECG front-end using an AD8232 module (290, purchased 8 February 2025); fifty- hertz mains pickup overwhelmed the signal and we could not suppress it with the filtering components we had available. The module sits in a box. Every family that receives this device must be told clearly: it measures how fast the heart beats, not how well it beats.

   The 32 °C wrist threshold for temperature is a clinical liability. The Section IV-B data quantify the problem: a

   2.1 °C spread in wrist-to-core offset across just four subjects means the threshold that flags one persons early fever will miss another persons entirely. Making the threshold adjustable per patient, through a menu rather than a firmware reflash, is the change most likely to improve the devices real-world reliability.

   The SMS message carries no useful data. Receiving Heart rate or Temp abnormal tells the recipient that something happened and nothing else: not which reading, not how far it strayed, not when. Encoding the actual values into the message is a single-function firmware edit. It was not finished before the submission date.

6. COMPARISON WITH RELATED WORK

   In project week 2 we read Hossain et al. [1] and spent three weeks trying to implement their cloud-assisted architecture on the ESP32. The fourth connectivity drop

   at 11:45 IST on 9 February 2025, during a generator

   handover that lasted ten seconds ended that attempt. The framework they describe is technically thorough and the parameter coverage is real. It requires a stable internet connection. That requirement disqualified it at our location before any other consideration applied.

   Patel et al.s [2] survey of wearable sensing systems concluded that reliable multi-parameter capture outside a controlled laboratory remained uncommon at the time of writing. Our own 4 March photoperiod test where the first heartbeat sensor degraded 340% in signal amplitude between morning and afternoon confirmed this finding at the component level, not just the system level. Rahim et al. [3] put alert delivery reliability at the top of the unsolved problems in elderly monitoring; we treated that conclusion as a test requirement and answered it by draining the data balance before running the 24 March alert campaign.

   Lio and Lees [4] literature analysis found that network dependency was the single most common cause of documented IoT health system failure across the papers they reviewed. We arrived at the same conclusion through direct experience before we found their paper. Biswas et al. [10] described motion artefact as the leading source of error in optical sensing; the 247 BPM false alarm on 19 March reroduced their finding on our bench, and the four-slot buffer with interval gating was the direct response. Ahmad et al. [11] pointed to wireless reliability as the dominant barrier to deployment; our architecture answers that by treating internet access as a feature that may or may not be present, not as a dependency.

   The work of Kumar et al. [15] and Saha and Bhat [16] operates at a different cost and infrastructure point. Both are technically strong. Saha and Bhat end their review by identifying the laboratory-to-deployment gap as the fields central unresolved challenge. That gap is what this paper addresses, with the specific failures left in rather than cleaned out.

7. CONCLUSION AND FUTURE WORK

A bedside monitor for heart rate and skin temperature, with SMS alerting over the GSM voice channel, was built and tested for 1,423. Every hardware choice traces back to a specific failure: the ESP32 that crashed after 47 minutes led to the UNO; the LM35 that corroded in three days led to the DS18B20; the Nokia 5110 that overran the power budget led to the SSD1306; the blocking delays that overflowed the FIFO led to the millis()-based state machine. Fig. 6 shows the layout that emerged from that sequence. Threshold crossings produce an audible alert and an SMS (Fig. 7) with no internet access required, verified by deliberate data-balance zeroing.

Revisions ranked by expected impact. First: include the

actual measured values in the SMS body. Second: allow alert thresholds to be set per patient without reflashing. Third: move the temperature probe from wrist to axilla, which the Section IV-B offset data suggest would reduce the threshold reliability problem. Fourth: activate the red emitter on the optical sensor (Fig. 2) for SpO estimation, once a clinical reference oximeter is available for calibration.

Battery management and a low-power sleep mode would allow portable operation away from mains supply, which the current bench prototype requires. After that, a field trial with elderly patients in the conditions the device was designed for. Every figure in this paper comes from five healthy students, aged twenty to twenty-two, in a university laboratory in March 2025. The device has not yet been in the hands of anyone it was actually built to help.

ACKNOWLEDGMENT

The authors thank Dr. P. Siddaiah for project guidance and continuous laboratory access between January and March 2025. Components were sourced from local electronics suppliers. No external funding was received.

REFERENCES

1. M. A. Hossain, G. Muhammad, and A. S. A. M. N.

   M. R. Rahman, “Cloud-assisted Industrial Internet of Things (IIoT)- enabled framework for health monitoring,” IEEE Internet of Things J., vol. 5, no. 2, pp. 896907, Apr. 2018.

2. S. Patel, H. Park, P. Bonato, L. Chan, and M. Rodgers, “A review of wearable sensors and systems with application in rehabilitation,” J. NeuroEngineering Rehabil., vol. 9, no. 1, pp. 117,

   Jun. 2012.

3. S. A. B. A. Rahim, N. A. Alias, and F. A. Johar, “Wearable health monitoring system for elderly: A review,” in Proc IEEE Int. Conf. Smart Computing Electron. Enterprise (ICSCEA), 2018, pp. 14.
4. A. J. K. Lio and L. S. M. Lee, “A review of IoT- based healthcare monitoring systems,” IEEE Trans. Ind. Informatics, vol. 15, no. 7, pp. 41854193, Jul.

   2019.

5. Maxim Integrated Products, “MAX30102 High- Sensitivity Pulse Oximeter and Heart-Rate Sensor for Wearable Health,” Datasheet Rev. 3, San Jose, CA, USA, 2018. [Online]. Available: https://datasheets.maximintegrated.com
6. Analog Devices / Dallas Semiconductor, “DS18B20 Programmable Resolution 1-Wire Digital Thermometer,” Datasheet Rev. 3, Wilmington, MA, USA, 2019.
7. SIMCOM Wireless Solutions Co. Ltd., “SIM900A Hardware Design V1.00,” Application Note, Shanghai, China, 2013.
8. Solomon Systech Ltd.,”SSD1306 128×64 Dot Matrix OLED/PLED Segment/Common Driver with Controller,” Datasheet, Hong Kong, Apr. 2008.
9. G. Chhetri and K. R. Joshi, “Wearable health monitoring based on IoT for elderly people,” in Proc. 20th IEEE Int. Conf. Advanced Commun. Technol. (ICACT), Chuncheon, Korea, 2018, pp. 4750.
10. S. Biswas, T. Song, R. Bajwa, and T. Chakraborty, “A real-time system for continuous health monitoring based on ECG and SpO2,” IEEE Trans. Instrum. Meas., vol. 67, no. 7, pp. 17941804, Jul.

    2018.

11. A. R. Ahmad, A. R. Al-Dubai, and S. H. Yun, “IoT-based health monitoring system for critical patients using wireless sensors,” J. Medical Systems, vol. 42, no. 2, pp. 3845, Feb. 2018.
12. SparkFun Electronics, “SparkFun MAX3010x Pulse and Proximity Sensor Library for Arduino, Release 1.1.2,” GitHub,

    https://github.com/sparkfun/SparkFun_MAX3010x

    _Sensor_Library, accessed Mar. 2026.

13. J. G. Webster, Ed., Medical Instrumentation: Application and Design, 4th ed. Hoboken, NJ, USA: Wiley, 2010.
14. Microchip Technology Inc., “ATmega328P 8-bit AVR Microcontroller with 32K Bytes In-System Programmable Flash,” Datasheet DS40002061B, Chandler, AZ, USA, 2016.
15. L. N. V. K. S. Kumar, B. Swathi, and G. Venkateswara Rao, “A real-time health monitoring system for critical patients using IoT technology,” IEEE Access, vol. 8, pp. 150893150902, 2020.
16. S. K. Saha and A. S. Bhat, “Medical wearable sensors: A comprehensive review on current trends, challenges, and future directions,” IEEE Rev. Biomed. Eng., vol. 13, pp. 282298, 2020.
17. A. Patel and A. S. R. Chandran, “A comparative study of heart-rate monitoring sensors for wearable and IoT applications,” IEEE Trans. Biomed. Circuits Syst., vol. 12, no. 5, pp. 898906, Oct.

2018.