Thanks for the positive feedback. I am an 55 year old unemployed, largely self educated hack. Finding a decent job without a degree in this economy is not easy. I do this to keep my mind alive.
The hardware is an X16-1C from Gulf Coast Data Concepts, LLC. It's bigger and heavier than I would like but it's also ½ to to 1/3 the price of the next better choices.
http://www.gcdataconcepts.com/xlr8r-1.html I really can't tell you much other than there is a AA battery making it bulky, a 2GB sdcard, and probably a ADXL345 accelerometer based on info in one of the files that it came on the sdcard. There are multiple modes of operation but as I use it I am required to press a recessed button with a pen pint or other similar slender object to start it. A press and hold stops the recording. Then I plug it into a USB port and suck up the CSV file that has been generated.
This page
http://www.basementdwellinggeek.org/CPA ... iewer.html has a little history of my application. I'll update it in the next few days with more info about the accelerometer. This thread has some of the back story
viewtopic.php?f=1&t=78584&p=715068#p715068 about the accelerometer. It shows an early test of the data being displayed in the tool, a java JAR file, that comes with the data logger. It was easy enough to see that tilt could be derived via the force of gravity on a single axis. My first implementation only considered the X axis. The first few nights of experimentation consisted of a lot wheel spinning and not much traction. The attachment to my headgear failed, so no data. I did capture "good" data the second night but using the default configuration I ended up with way more data than I wanted to deal with and in multiple files to boot. The third night I had the device configured to what I thought was reasonable. The important items were sample rate, deadband, and deadbandtimeout. The default sample rate of 50/sec is way over kill for my needs. I would have gone slower but 12 was the minimum. Sample rate determines how often the the X,Y,Z values are checked, not necessarily written to the log. The deadband setting specifies how much change, in any axis, is required to cause another measurement to be logged. I though 0.1g was sufficient. Fewer writes equal longer battery power. As I get a feel for magnitude of changes and what they mean I may crank that up. The third parameter that I altered, deadbandtimeout, specifies how often to log a sample when the system has not changed enough to exceed the deadband. I picked 1 second, but may crank that up as well.
I patched my application to scale the X axis data, manually synchronize to the timestamps of the other data sources and draw a waveform. The "master" clock is the CPAP machine. I have controls to shift the other data sources to align with the "master". Zeo needs a 127 second adjustment and the data logger a 375 second adjustment. The adjustment for the Pulse/OX varies by long it takes to finish starting the record mode.
It didn't take long to figure out that a second axis was required. A single axis can give tilt but can't tell you whether you are face up or face down.
I spent many hours with this image and its corresponding CSV file. The X axis, the red line shows a series of movements I used to figure out what was happening when. Holding the device level I started it, then rotated 90 degrees to the left and held it there for a while, then rotate right back to the original position again holding for a moment. Then repeat the process except rotate right initially. During the first phase the line dipped then returned to normal. Second phase the line rose then returned to normal. Then rotate through 360 degrees to the right returning to normal the right end of the image. The Y axis, blue line, didn't do much but wobble around as the center of the device moved up and down. The Z axis, green line, is 90 degrees from the angle of the X axis. Therefore, the Z axis being negative tells me that I have rotated past vertical and am now facing down.
Through the wonders of cut and paste I created a stripped down application to read the data and experiment on how to display it. I visited many many web pages searching for information on how to translate values returned by the accelerometer to tilt or angle or orientation... I found a formula that I will paraphrase. Divide the reading by the force or gravity and take the arc sin of the quotient. This gives angle in radians. Then to convert to degrees multiply by 180 divided by Pi. This gives basic tilt. Then factor in the value of the other Axis. In my case as I had the device mounted this was the Z Axis. Depending on how you mount the device and what normal is and how you rotate will determines which two axes you will need to use. You may need to diddle with some signs in places to make it all work.
After that is was just a matter of learning how to draw a bitmap at a angle of rotation and devising a scheme to select when to show the body position symbol. I thought about moving averages and showing a symbol when the magnitude of change exceeded some preset amount. It seemed like a lot of work. I settled on dividing the time displayed into 20 spaces and showing one symbol for each based on a single sample at that location. By contracting the timebase more detail is revealed. I can drag the time buy small increments and watch the symbol roll over.
I've nudged jedimark with the basic info. How soon, or if it gets incorporated into SH is out of my hands. Well not really, with SH being open source I could implement my code but it would be a long hard uphill battle learning the environment he works in.
I've uploaded
http://www.basementdwellinggeek.org/CPA ... %20out.zip. It is a zip VS2010 project with sample data. Buried inside is "finger this out.exe". Run it, chick the button and navigate to DATA-007.CSV. AccelDebug.cs has most of the code for dealing with the accelerometer.
