I unfortunately missed Armin when he came to Ruby Skye last year due to being sick, but I made it this year. In the meantime, Armin has become even more popular, so he had to come two days in a row, and it was packed both days.
His performance was quite good. Sometimes, it's difficult for a top DJ to meet expectations, and to play the popular tunes that most want to listen to, but the DJ might get slightly tired of :)
Either way, Armin did a good job playing a good set of catchy tunes, that were synchronized to video displays with the lyrics of some of the tunes.
In the end, Armin did a very enjoyable 4H set.
trying to look like his sticker on his laptop
The lyrics to the 'songs' were a nice bonus
The one track before last, Armin came out of the back to shake some hands, and sign autographs from the mob. It looked barely safe, but he got out in one piece :)
Since my sleep apnea turned out not to be fully cured by my MMA surgery (it helped, but it wasn't entirely enough), the two other known fixes that do not include CPAP are to stop my tongue from being lazy and roll back in and partially my airway, and sleep on my back, which causes the previous point to be worse.
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:
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.
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:
Although the weather has been unseasonably cool (never mind a good rain mid-May, which is more than rare here), I got my ass in gear (ha!) for bike to work day.
While I wasn't in great biking shape, and wasn't pushing that hard, I did the 8 miles (13km) in 29mn, which wasn't bad.
Google had a nice reception and swag for riders:
The ride home (uphill, and just after 1h of bootcamp where my legs were already tired), was more painful and took 38mn.
TL;DR: By using Xbee pin sleep, I was able to bring my board power consumption from 100mA-ish to 35mA-ish average by ensuring that the Xbee radio is off most of the time (unfortunately, it doesn't have a mode where you can just have it be send only and wake up the RF radio only when you give it serial data).
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:
AT Mega Pin 14 (Digital 8) -> Xbee DTR
AT Mega Pin 16 (Analog 2) <- Xbee RSSI
AT Mega Pin 17 (Analog 3) <- Xbee Assoc
The Xbee was flashed with the latest ZB end device AT firmware with pin sleep (be careful, the default setting of cyclic sleep puts the module to sleep as soon as it's flashed, so even X-Ctu can't re-read its settings without having the module be reset). See my page Xbee Adapter page with reset pin hack.
I left the pullup resistor enabled in the Xbee, so I was able to use simple wires to connect the pins.
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:
It shows rssi dropping to 0 with DC:5 (down count due to RSSI being 0), and assoc average having dropped from 844 to 337 (we don't see instant low assoc values since they were not transmitted outside of the truncated line).
Next step is lowering down the Mobsendat power base consumption from 33mA to 12mA by simply disabling two of its status LEDs.
When I was getting into Xbee, it wasn't too clear to me what was the recommended interface for the PC size.
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
The sparkfun adapter costs a bit more, but it has the built in FTDI chip, so it comes with a mini USB connector and it ready to connect to your PC: no fuss. It also comes with a very handy set of LEDs: serial RX/TX, and RSSI (which shows if RF data was received). The big plus is also that it's already all soldered and ready to use. Oh, the module also easily supports longer Xbee Pro modules.
Its only shortfalls are the lack of AI LED (which comes in handy to show that the module has joined an active network) and no reset jumper, which can be required to blind flash modules or reset modules with ZB END device firmware (which goes to sleep by itself and can't be talked to with X-Ctu without a reset).
Ladyada
Those modules need to be soldered. It's not very hard, but it's time consuming and it's easy to put solder inside the xbee headers. One of my modules wasn't working right until I figured that the problem were the headers had a bit of solder and prevented a consistent good contact. The other shortfalls are the lack of serial RX/TX LEDs which are crutial for knowing that your blind flashing is working, and the default build doesn't accomodate Xbee Pro modules well (you have to bend the resistor and capacitor out of the way like in the picture above).
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
Sometimes you have a flash a non responsive Xbee module, it may be a ZB End device firmware that is in sleep all the time, or you just don't know the module speed and don't feel like finding out, you can flash the module with X-ctu and reset the module when it tells you to.
But to do this, you need a reset switch, which neither of those two modules has.
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:
Set speed to 38400, API disabled
in modem conf, select right firmware
set baud rate in serial interacing option to 38400
set always update firmware and start write with module not plugged in
when error message on pushing reset appears, plug module in
