Java Python BMET2922/9922
Computational Analysis for Biomedical Signals
Pulse Sensor Requirements
Wearable IoT PPG System: Requirements Specification
This document sets out the minimum requirements of the wearable IoT PPG system.
1. Microcontroller Requirements
| Reqt # | Description |
| 1 | The microcontroller must sample the sensor and switch (button) with a period of 20ms. |
| 2 | A pulse rate calculation (BPM) must be implemented on the microcontroller and sent to the host in the Bluetooth data packet each second (see requirement 18). This must be implemented even if this pulse rate calculation is not the one used by the host computer application. An example technique is the threshold detection implemented in labs 3 and 4. |
| 3 | The switch must have a debounce count of 5, implemented on the microcontroller. |
| 4 | The pulse waveform. data is to be printed over the serial USB connection by the microcontroller, in a form. that can be displayed in the Arduino IDE Serial Plotter. If threshold detection is used for bpm calculation on the microcontroller, the threshold must be printed and viewable in the plotter along with the pulse waveform. |
| 5 | The LED and switch behaviour are for your group to decide. The button might also be used to send information to the host (see requirement 18). Some suggestions are: ● Switch connects/disconnects from host, with the LED indicating connection status. ● Multiple button functions, e.g. for single click, double click or hold down. ● Pulse displayed on the LED, as implemented in the labs. ● An LED alarm for high or low pulse rate, the button turns it off. Alarm does not trigger again until the pulse rate goes back into normal range then goes outside normal range again. ● LED on/off to indicate detection of plausible pulse rate. ● Button tells host to start/stop recording data. LED blinks when not recording and is solid when recording. Each group may use up to 3 buttons or 3 LEDs (one from each group member’s kit) in their system. |
2. GUI Requirements
| Reqt # | Description |
| 6 | All host information will be displayed in a single pysimplegui window. |
| 7 | Both the BPM and pulse waveform. must be displayed graphically, either as selectable alternatives on the same plot, simultaneously with different y axes on the same plot, or on separate plots. |
| 8 | The graphical display must be updated at least once per second. |
| 9 | The current pulse rate must also to be displayed in text format, and should be large enough to stand out at a glance. |
| 10 | Pulse rate is to be displayed with a precision of 1 decimal place. No more or less. |
| 11 | The GUI must contain a visual alarm for high and low pulse rates. |
| 12 | Display of information must have a latency of less than 2 seconds from the occurrence of the associated event in real life. E.g. the pulse waveform display on Host must occur within 2 seconds of the data being captured at the microcontroller. |
| 13 | The GUI must contain a system log window, that logs and displays events (normal packet arrival does not need to be logged). The format of logged messages must be: : age string> <> e.g. "Thu Sep 19 17:46:50 2024: Pulse Low". The time date stamp must be of the exact format in the above example. |
| 14 | An alarm within the GUI must be displayed if a packet has not arrived after 5 seconds. This alarm will cease when a new packet arrives. |
3. Communication Requirements
| Reqt # | Description |
| 15 | Communication between microcontroller and the host computer application will be Bluetooth SPP. |
| 16 | If the host computer application loses communications with microcontroller, it should continuously try to reconnect (you may need to look at pyserial.Serial.close(), pyserial.Serial.is_open and pyserial.Serial.open()). If the microcontroller comes back online, the host computer application should successfully reconnect and resume normal operation. |
| 17 | Once both host and microcontroller are available , comms will be established within 10 seconds. |
| 18 | The packets of data must be sent from the microcontroller to the host computer every second. This must include at least: 1. The latest pulse rate calculation from the microcontroller. 2. Raw sensor data recorded within the last second (since the last packet). This will be 50 integer data points (given the sampling period of 20ms) 3. A packet sequence number, so the host can detect if packets have arrived out of order. But may include more information. e.g. a field may be included in the packet that communicates commands from the user, entered via the button. The packets must also all be formatted to all be the same length in bytes. |
4. Signal Processing Requirements
| Reqt # | Description |
| 19 | Some effort must be made to address low frequencies that disrupt pulse rate calculations. Techniques may include: ● High or band bass filtering ● Using Fourier Transform. to calculate pulse rate ● Adaptive threshold detection. |
5. Additional Feature Suggestions
Name Description
“Researcher” tab
A tab in your GUI for researchers, that provides some additional real-time signal information. Examples might be pulse rate variability, second derivative of the signal, relative changes in signal amplitude, filtering (e.g. the output of a low-pass filter may capture user motion or respiratory information), the spectral intensities from real-time Fourier transform. (e.g. a spectrogram) or another method to provides real-time frequency content of the signal, etc.
Summary report on exit
The host computer application may provide a summary report on exit. It would not be worthwhile to just include pulse rate: the point here would be a chance to do some “offline” signal processing, if it is too difficult to do in real-time. For a given session: the app could record/write the raw data to a .csv file (which would also be available to the user), then on exit, perform. some automated signal processing on that dataset and create a report as a PDF. Suggestion: have a data recording start/stop mechanism (e.g