Marc's Public Blog - Arduino Hacking

Funny thing though is that I am used to falling asleep on my tummy (I don't fall asleep easily on my back), but then I will turn on my back while I'm sleeping, every single night. When I half wake up, I'll go back on my tummy and when I sleep again, go on my back again, making my apnea worse (mind you, sleeping on my tummy is not so good for my neck muscles and spine, but I can deal with that). One would say that I should sleep on my side, but that's an unstable position for me and I don't stay there long.

This is where rematee comes in: I got the Rematee Bumper Belt.
It is a belt with air pouches that you put on your back and that are supposed to stop you from turning on your back at night. I figured I'd give it a shot, but I soon found out that I quite obviously turned on my back anyway and woke up sleeping on the belt, which hurt my back a fair amount and just gave me an even worse night ("obviously" due to back pain and waking up on my back). One is supposed to wear that belt under the armpits, but for me it didn't make a huge difference, except for where the resulting back pain would be.

This was discouraging, but I thought I'd give it another shot and got the next size up from rematee. My size is 36, so the large belt with 3 smaller air pouches was technically a little bit too big for me, but my rationale was that once I have the momentum to turn on my back, a few air pouches in my back aren't going to stop me, and apparently I stay sleeping on them and just get a back acke. It made sense at the time that if the air pillows spilled over to my side a bit, they would be more likely to stop my initial rotatioin to my back.

Long story short, some testing showed that I still turned on my back with the 3 pouch belt. I didn't do detailled testing between the two, but while it seemed to work slightly better, it wasn't good enough.
At that point, I came to wonder if things would work better with wearing both belts. Long story short is that yes, things worked better with both belts. My suggestion to the designers however, is would for the large belt to have 2 big pouches on the outside to provide maximum leverage against body rotation, and a smaller pouch in the middle to fill the void (the extra large belt does have 3 large air pouches, but that one is just too big for my body).

both belts

So the big question, is how do you get quantitative data on this? Well, I just happened to be working on an arduino microcontroller board that had a built in 3 axis accelerometer amongst other things. While it was originally meant for attaching to rockets and location tracking with GPS, I figured I could also use it to simply track my body position at night, so I wrote some code to do that (and log it both to the sdcard on the board as well as send the data wirelessly via Xbee to my computer so that I don't have to pull out the card and read it every day).

You can read this page on Xbee Power Consumption on my Mobsendat Board for details on the board I've been using but basically I get this end result from the board:

"2011/05/24 06:20:04",,X:0.11,Y:-1.00,Z:0.13,V:4.97,left,rssi:0(DC:2),assoc:843(avg:842)
"2011/05/24 06:20:09",,X:0.10,Y:-1.00,Z:0.13,V:4.96,left,rssi:0(DC:3),assoc:843(avg:842)
"2011/05/24 06:20:14",,X:0.04,Y:-0.54,Z:-0.90,V:4.92,down,rssi:903(DC:0),assoc:843(avg:842)
"2011/05/24 06:20:19",,X:-0.05,Y:0.39,Z:-0.93,V:4.96,down,rssi:903(DC:0),assoc:841(avg:842)

The important part is the "left" which changed to "down" (Y axis went from -1g to less than .5, and Z went from 0 to -0.9g). I then have a script that parses the output and gives a summary for each night which I then enter in my detailled spreadsheet.

gandalfthegrey [mc]$ ./scan_file night63_twobelts_home_sun.csv 
up,     down,   left,   right,  unkwn,  pos changes,     hours sleep
11.4%,  52.6%,  26.9%,  09.0%,  00.0%,   19 pos chg,     7.7 H sleep

the microcontroller and battery pack fit nicely inside

what it looks like inside

And the results are that I slept an average of 26% of my night on my back without belts, 13% with one belt, and down to 7% with both belts. On one side, this is encouraging, although on the other side, it's a bit eery that I still manage to sleep 7% of my night on my back, either by rotating the belts just enough, or by plain sleeping on them. You'll however see if you check the detailled spreadsheet that with the belts on, I have many nights when I didn't sleep on my back at all, and that the average gets messed up by a few nights when I slept more than 20% of the night on my back. It is possible that the optiona shoulder straps will help fix that.

So how much better is my sleep? That one I don't have quantitative numbers for since I haven't been able to get an SPO2 sensor that I can interface with yet, or easily measure my breathing patterns vs my body position (I did use nose canulas in other take at home sleep tests and I tended to rip them out by sleeping on my face anyway).
While I don't have exact data, my sleep did feel better with the belts, I also know that my apnea is worse when I'm on my back, so it's fair to say that belts help. How much exactly? Not sure yet, I'll get more data on that later hopefully. I also have to note that my data isn't perfect because at the same time I had to wear a heavy dental piece at night that kept my teeth from moving back to their old place (this is related to my post MMA surgery dental works). I was able to stop using that bulky mouthpiece at day 51, and my sleep improved noticeably at that time.

So while the data is not perfect since I at least changed the mouth piece part during the samples, here's my summary spreadsheet, and the detailled spreadsheet.

Interesting bit I got from the data are: I tend to flip-flop about the same amount regardless of whether I have the belts on, and outside of the amount of time on my back, the belts didn't change other sleep parameters I was measuring:

Position: back tummy left right unknown hours slept position changes Sample Count No Belts 26.24% 49.93% 19.44% 3.35% 1.03% 7.46 15.08 12 3 cushion belt around chest 13.00% 51.83% 32.07% 2.83% 0.30% 7.42 12.50 7 both belts 6.94% 55.91% 32.18% 4.26% 0.67% 7.67 14.19 37 Average 15.39% 52.56% 27.90% 3.48% 0.67% 7.52 13.92

Longer version:
I've been using my Mobsendat Board to log my [sleep positions|], and both for fun, and because I'm lazy, I've been using Xbee to send data from the mobsendat to my PC.
I used some Xbee Pro modules because I wanted to get as long a range as possible, and because the data may have to go through my body, which is some kind of RF shield.

First, I tried the Xbee 1 modules, because they were easier to get and a bit easier to program since more people were using them. My mobsendat board was using 33mA and with the Xbee 1 module, would go between 80 and 110mA. This is of course a fair amount of power.

I then upgraded the modules to Xbee 2.5 ZB Pro modules, and that shaved off 10mA or so. It was however clear that I would have to put the modules to sleep to save further.

To do this, I used some of the free pins on the AT mega 328, and wired up:

Xbee sleep works like this: bringing DTR up puts the module to sleep if it's not in the process of sending/resending data (that's nice, you don't have to worry about waiting for an ACK which you can't read in AT mode before putting the device to sleep, you can just fill its buffer, give it the sleep signal and it'll go to sleep when it's done sending).

This works great: by putting the module to sleep for 95% of the time or so (I transmit every 5 sec), the power use goes back to 33mA for most of the time (with quick peaks to 100mA during send).

Now, for how to deal with sleep more intelligently:

If you have AI/RSSI LEDs and your module is not associated, you can easily see that sleep will not put the module to sleep after sending data until all the retries have failed.
In my case, I wired the RSSI and Assoc outputs to my arduino inputs so that I could read the analog values. If you're sending data from an end device, you can read RSSI as a poor's man ack value by keeping track of last time it was high (defined as between 32 and 1024 on my system since it a signal strength value and anything below 32 has been noise in my experience). What this means is that by reading RSSI multiple loop cycles in a row, I can detect when I'm not receiving any data (and therefore missing acks) and not put the module to sleep at all with the hope that it will "reconnect" on its own.

One might thing that you can read the Assoc value to guess whether AI=0 (associated) or not. Note that the LED actually shows solid when not associated and will blink when associated, so it's not as easy as just getting an on/off value. To deal with this one, I actually read the LED output value multiple times, average it, and if it's flashing, I'll get less than 800 avg (out of 1024).

Now, this is where it gets more counter intuitive: AI (association) unfortunately does not go back to unassociated when I remove the router or coordinator in my network. What this means is that I can't detect if my module can't talk to the network by using AI (only getting ACK return values can really tell me that, and I'd have to switch to API mode for that). But, there is a trick: if the module is waiting for ACKs, it will not go to sleep, and AI will normally flash. When that happens, I will read Assoc analog values that are less than 800 and by averaging a few, I can tell that the LED is flashing and therefore that the module isn't going to sleep.
Neat, eh?

This is what my data looks like when I have RF issues:

"2011/05/24 05:53:29",,X:0.13,Y:-1.00,Z:0.11,V:4.96,left,rssi:904(DC:0),assoc:847(avg:844)
"2011/05/24 05:53:34",,X:0.15,Y:-1.00,Z:0.14,V:4.92,left,rssi:904(DC:0),assoc:844(avg:844)
"(DC:4),assoc:0(avg:337|ANS)
"2011/05/24 05:53:59",,X:0.14,Y:-1.00,Z:0.13,V:4.97,left,rssi:0(DC:5),assoc:842(avg:337|ANS)
"2011/05/24 05:54:04",,X:0.14,Y:-1.00,Z:0.12,V:4.97,left,rssi:0(DC:6|RNS),assoc:842(avg:336|ANS)

Next step is lowering down the Mobsendat power base consumption from 33mA to 12mA by simply disabling two of its status LEDs.

While there actually are expensive-ish dedicated PC adapters, the short story is that most folks actually use the same Xbee chips that you put on your arduino shields, and use an adapter that can be connected to USB.

For this you have two to chose from, and I'll explain them both (I got both to try them out, and each has its strong points and weaknesses). This is what they look like (the sparkfun one is red):

Sparkfun

Ladyada

On the plus side, there is no FTDI chip on there, so they're cheap ($10) and you can use a 3rd party 5 pin adapter cable you may already have, or if you buy one now, you'll be able to reuse it later to flash some arduinos like the AT mega 328.

If you're planning on mostly plugging your Xbee into a breadboard, the Ladyada option is cheaper since you can solder header pins and use the adapter without ever paying for an FTDI cable (or more generally share one cable for multiple modules).

Hardware Reset

I ended up foldering a PC jumper on both modules as shown in the pictures, and that would be a worthwhile addition to both modules by default.

The procedure for blind flashing is explained here and there: