When the motor activated, even though the simple Blink program, the light on the pulse sensor would visibly dim. This was the suspected problem since the sensor relies on reading varying light levels. To test this a reading was taken from the analog input pin without the pulse sensor program. The goal was to look for a pattern in the heartbeats then revise the program to activate the motor periodically and watch for interference.
In order to get data into the computer from the ATtiny85 controller the Digispark keyboard example was loaded then modified to “type” the raw analog data. This was basically just like running the serial monitor except it output the numbers to a text document instead of the serial monitor. Since the keyboard example program was at the forefront as the program loaded all the text was typed there.
Recorded data was copy-pasted into a spreadsheet and charted to a line graph. The graph showed a very clear heartbeat pattern which was excellent. Copying data from the middle of the recorded set, after the sensor had a chance to acclimate, removed the wide swing of erroneous numbers and the graphing function automatically trimmed the unused portion of the analog scale. In other words, the spreadsheet program made a clean graph of the heartbeat without adding the unnecessary numbers above and below the heartbeat numbers which were only a small fluctuation.
After a clean heartbeat was graphed the keyboard program was further modified to pulse the output pin where the vibrating motor and transistor were still soldered. This was done without the delay function since that would interfere with the readings. While the motor was active the sensor’s light dimmed noticeably as expected. The readings from the controller showed that instead of continuing to display a clean heartbeat the readings would drop to zero while the motor was active. In addition to that bad news the signal seemed to spike right before it dropped so it looked like another heartbeat until the timing was changed to be slower than an average human heart.
To do:
The rest of the posts for this project have been arranged by date.
First time here?
Completed projects from year 1.
Completed projects from year 2.
In order to get data into the computer from the ATtiny85 controller the Digispark keyboard example was loaded then modified to “type” the raw analog data. This was basically just like running the serial monitor except it output the numbers to a text document instead of the serial monitor. Since the keyboard example program was at the forefront as the program loaded all the text was typed there.
Recorded data was copy-pasted into a spreadsheet and charted to a line graph. The graph showed a very clear heartbeat pattern which was excellent. Copying data from the middle of the recorded set, after the sensor had a chance to acclimate, removed the wide swing of erroneous numbers and the graphing function automatically trimmed the unused portion of the analog scale. In other words, the spreadsheet program made a clean graph of the heartbeat without adding the unnecessary numbers above and below the heartbeat numbers which were only a small fluctuation.
Clean heartbeat from a graphing program
After a clean heartbeat was graphed the keyboard program was further modified to pulse the output pin where the vibrating motor and transistor were still soldered. This was done without the delay function since that would interfere with the readings. While the motor was active the sensor’s light dimmed noticeably as expected. The readings from the controller showed that instead of continuing to display a clean heartbeat the readings would drop to zero while the motor was active. In addition to that bad news the signal seemed to spike right before it dropped so it looked like another heartbeat until the timing was changed to be slower than an average human heart.
Heartbeat with motor interference
To do:
- Record set of analog input data showing heart sensor readings. 2mS readings
- Rerecord at same location with vibrator motor activating periodically and observe any discrepancies in signal due to motor use
- If the motor activation causes a problem the project may not work without a second voltage regulator
- If there is no problem
- Take second reading at different body location
- Take third reading at different body location
- Compare data
- Write pseudo code for extracting heart rate
- Program with Arduino UNO
The rest of the posts for this project have been arranged by date.
First time here?
Completed projects from year 1.
Completed projects from year 2.
Disclaimer for http://24hourengineer.blogspot.com/
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All
information in this blog, or linked by this blog, are not to be taken
as advice or solicitation. Anyone attempting to replicate, in whole or
in part, is responsible for the outcome and procedure. Any loss of
functionality, money, property or similar, is the responsibility of
those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes
the intellectual property of Brian McEvoy. Any information contained
within these messages may be distributed or retained at the discretion
of Brian McEvoy. Any email sent to this address, or any email account
owned by Brian McEvoy, cannot be used to claim property or assets.
Comments
to the blog may be utilized or erased at the discretion of the owner.
No one posting may claim claim property or assets based on their post.
This blog, including pictures and text, is copyright to Brian McEvoy.
2016-03-08 (Tu)
Comments
Post a Comment