Code: “GettingStartedProject” with delay set to 100ms
Hardware: PulseSensor circuit to record data as stipulated for above example. See https://pulsesensor.com/pages/code-and-guide
Software: PuTTY (serial logging to .csv), Excel, Overwatch
Spreadsheet Data: Download Here
This week, my task is to find a good use for a PulseSensor; a device that uses a light sensor and green LED to determine your heart beat.
At first glance, I wasn’t totally sure how I could use the sensor beyond translating a beat into sensory phenomena. Strictly using the device as a heartbeat monitor did not appeal to me, so I began to explore ways that the device could be used differently to track bodily behaviors.
Turns out it also works relatively well as a speed radar! Since the light sensor is measuring changes in light, the device effectively can be used to determine how fast an object passing over the sensor is with ‘BPM’. It might not be the most standard unit of measurement, but it inspired me to observe ways I could accurately measure using the device.
In a previous project I worked with Ultrasonic sensors to measure the distance between it and objects. One of the notable quirks of the ultrasonic device was that it required a relatively flat surface to reflect its signals off in order to function most accurately. The PulseSensor tends to behave in a similar fashion, working best when the sensor is aimed upward and away from objects.
I tested out the sensor inside of the finger-sized device I made for my previous blog post and it was relatively successful in tracking the activity of my finger as I moved it, so I thought it would be interesting to better secure the device inside the “finger pocket” and record the data it collected into a spreadsheet. I wasn’t entirely sure whether the device would be accurately recording the behaviour of my heart or the movements of my finger but I was interested in studying the analog behavior nonetheless.
PuTTY presented itself as a viable solution, having the option to send serial data to a printable output log file; all I had to do was send it to a .csv instead of a log file and open the .csv with Microsoft Excel in order to retrieve the data output. For the sake of getting an accurate reading without too many data points, I chose to use the “GettingStartedProject” example in the PulseSensor arduino library with a serial delay of 100ms, which provides the value of the sensor as received by the Arduino’s analog input pin.
I recorded the data with PuTTY in two sessions: one consisting of relaxed typing activity comprised of cataloging records in an online music archive and another consisting of activity recorded while playing the computer game Overwatch in its Deathmatch game mode.
I plotted the information I collected into the line graphs above and below, clipping data collected when setting up the device and restricting the view to information between analog values 650 and 350 (the Y-Axis). The numbers along the X-Axis relate to the sample number and constitute about 5 1/2 minutes of time (since each sample is recorded every 100ms). The graphs seem to indicate that Regular Activity (RA) values gravitated towards an analog value of 520, whereas Gaming Activity (GA) values tended to be slightly lower on average. However, GA did exhibit more consistent spikes in activity as well as much more obvious fluctuations, waving up and down versus RA’s relatively flat behaviour. While RA did have several periods of high level spikes, it seems likely that they do not act as clear representatives and could possibly be due to some human error on my part (sometimes the device was adjusted during this first trial, and the end of the RA data constitutes taking the device off).
In order to get a better view of this data behaviour, I overlayed the two graphs and reduced the information collected to a representative sample between X values 2100 and 2600, which seemed to further support my understanding of the behavior of the recording data.
Ultimately, this experiment provides visual insight into data that a user may not be able to examine while preoccupied with an activity. Although this data is largely technical in scope, it does leave me imagining ways of using data collected via bio-metrics that does not express itself instantaneously and rather leaves its findings to be reflected upon at a later time. The obvious comparison would be to medical or sports analysis devices applied to a user, but I am interested in how such devices integrate in ways that do not interfere with their analysis and how they might move beyond the sterile environment of scientific analysis.
Perhaps such a device could monitor and save data over a period of time (with an SD card instead of a serial connection) and if it crosses a particular threshold over a sustained period of time create some sort of alert that may be informative to a user. Especially if this device is a more long-term use product such as an insulin pump, it could be interesting to explore how such devices could be better adapted to everyday human use.