Knowing what goes on inside a controller or a computer is the crux of debugging. A program was written which simply recorded the analog data from the heart sensor and “typed” it on the computer by pretending to be a keyboard. Most Arduino debugging like this is done with a serial port but the ATtiny85 doesn’t usually work like that. Acting like a keyboard takes processor time and slows down the whole process so it is not ideal. The simple program didn’t have any trouble spitting out raw data values and Numbers on Mac automatically scaled and zoomed so the output graph looked real nice. The heartbeat was apparent and repeated nicely.
That same simple program was copied and modified to output those same values but also pulse the motor on and off. This was to test if the activation of the motor caused problems with readings. It did. Significantly. The green line in the graph showed what happened when the motor activated, it all went south. The other line was data from a previous sample where the motor was inactive.
The problem was that the motor circuit was drawing too much power and therefore starving the sensor. To keep this from happening both halves, load and controller, needed to be using different power sources. This didn’t mean two batteries, the plan was to allow the controller to use its onboard voltage regulator while the load, the coil, would be run directly off a 9V battery. Even if the voltage from the battery dropped 30% it would still have plenty of voltage to keep the controller running, hopefully without problems.
After seeing that the code was capable of compiling and getting some useful data the upper and lower boundaries, or limits, became unusable quickly. The problem was they would be pushed away from the desired data if there were errant readings, like if I adjusted my finger. This lead to data that quickly deteriorated. To keep these limits tight I tried “creeping limits.” This probably has a technical term but I don’t know what that is so I am calling them “creeping limits.” The idea was that periodically the limits would move toward each other and the data would push it back out as necessary. This ensured that even if there was an errant reading the skew wouldn’t affect the reading for too long. The graph shows the upper and lower limits “creeping” down and up while the heartbeat data kept it in check.
This all seemed to be going well until it didn’t. Trying to get data via the virtual keyboard while monitoring an analog input (more time consumptive than a digital input) seemed to bog the controller down too much and data started to fall apart. Right now the plan is to try programming with an Arduino UNO and use serial output but write the rest of the code so that it can easily transfer back to the ATtiny85 after gutting the serial code. Over the last week I’ve been gradually packing up my apartment in order to move in with my girlfriend. That has taken a lot of time and sleep away. But I’ll talk about that in no more than one post.
The rest of the weekly summaries 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.
Graphical representation of raw analog input
That same simple program was copied and modified to output those same values but also pulse the motor on and off. This was to test if the activation of the motor caused problems with readings. It did. Significantly. The green line in the graph showed what happened when the motor activated, it all went south. The other line was data from a previous sample where the motor was inactive.
Same test with motor activating periodically
The problem was that the motor circuit was drawing too much power and therefore starving the sensor. To keep this from happening both halves, load and controller, needed to be using different power sources. This didn’t mean two batteries, the plan was to allow the controller to use its onboard voltage regulator while the load, the coil, would be run directly off a 9V battery. Even if the voltage from the battery dropped 30% it would still have plenty of voltage to keep the controller running, hopefully without problems.
Circuit to separate coil and controller power sources
It became apparent that all the control I wanted from the program wasn’t going to be easy, maybe not possible, with the stock code. Pseudo code was written to replace that which would be built from the ground up so that I would know/write every line. The code is posted below.
If Y is high
Take a reading
If it's below 10
Ignore, break
If it's above 1013
Ignore, break
Add to queue of Z stored readings
As soon as the queue is full
Calculate the MIN from the last Z readings
Calculate the MAX from the last Z readings
Set bit Y high so this isn't repeated every time
If Y is low
Take a reading
If it's below 10
Increment integer X
Break
If it's above 1013
Increment integer X
Break
If the new reading is less than MIN
Write MIN to the value of the new reading
If the new reading is greater than MAX
Write MAX to the value of the new reading
If the new reading is more than 3/4 of the way from MIN to MAX
Set bit T high
Otherwise
Set bit T low
If T is high
Activate an output or whatever
If T is low
Dectivate the output or whatever
Map the analog value from MIN↔MAX to 0↔255
Write the mapped value to an LED`
Pseudo code for reading heartbeat
After seeing that the code was capable of compiling and getting some useful data the upper and lower boundaries, or limits, became unusable quickly. The problem was they would be pushed away from the desired data if there were errant readings, like if I adjusted my finger. This lead to data that quickly deteriorated. To keep these limits tight I tried “creeping limits.” This probably has a technical term but I don’t know what that is so I am calling them “creeping limits.” The idea was that periodically the limits would move toward each other and the data would push it back out as necessary. This ensured that even if there was an errant reading the skew wouldn’t affect the reading for too long. The graph shows the upper and lower limits “creeping” down and up while the heartbeat data kept it in check.
Output with creeping limits
Heartbeat data from program with creeping limits. Data scaled by limits
This all seemed to be going well until it didn’t. Trying to get data via the virtual keyboard while monitoring an analog input (more time consumptive than a digital input) seemed to bog the controller down too much and data started to fall apart. Right now the plan is to try programming with an Arduino UNO and use serial output but write the rest of the code so that it can easily transfer back to the ATtiny85 after gutting the serial code. Over the last week I’ve been gradually packing up my apartment in order to move in with my girlfriend. That has taken a lot of time and sleep away. But I’ll talk about that in no more than one post.
Unusable data
The rest of the weekly summaries 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.
Comments
Post a Comment