Marc's Public Blog

Renault:

Toyota:

Peugeot:

Mercedes:

Citroën:

the many year winning WRC champion car, cool

That was a good match for Sébastien I had just met :)

ok, doesn't get older than that :)

I remember playing this

Arkanoid, I was good at this!

Out Run, that used to be the game I thought was so cool and pretty back then

I actually finished Super Mario 64 in 1997

Good times...

this is one of the things I found for my dad

early Xmas gifts for the kids

let's not screw around here, there's some cooking to do :)

Jennifer, trying out for Cabaret :)

We were then invited by friends of my dad's:

Jennifer enjoyed holding their rabbit (which didn't enjoy it nearly as much :)

Yum!

Just a few days later, it was time for more of this for New Years Eve. It was tough to keep up with the food :)

When then took advantage of great sunny weather and unseasonably high temperatures during the winter to visit Paris:

Jussieu, one of Paris' main universities is being rebuilt from the ground up to remove all the toxic asbestos. Doesn't look shabby right now:

We then went towards Sacré Coeur to see if we could climb to the top this time, something I had tried 3 times already but failed due to chronic Xmas absentees, preventing staffing for ascent to the top. It was beautiful weather:

The views from the top were great that day:

Sainte Chapelle

Grand Palais and La Défence

After that we headed to the Panthéon, which I had never seen inside (bad me). Lots of famous people are burried in the crypt, and the foucault pendulum is cool:

and we then went through the jardins du luxembourg towards tour Montparnasse:

We unfortunately got to the top a tad late, just as the sun was setting, but we raced to get some pictures while the light was fading:

Pont Alexandre 3 and Grand Palais

Notre Dame

La Défence in the background

Louvre and Jardin des Tuileries leading to l'obélixe

Centre Georges Pompidou and Tour St Jacques

The next day we went to the Musée des arts forains and Court St Emilion

After that, we walked the Champs Elysées from the Obélix up to see all the little Xmas shops, and then went to see some of the displays in the last section:

Piggie!

We then went to the Grand Palais to see a computer game expo and the faire in the main hall:

and finished the night with Duck Choucroute and foie gras

A few days later, with another nice day, we went to the Sacré Coeur for some great clear views of Paris and seeing their own Xmas shops:

Centre Georges Pompidou

More piggie!

We then went to the nearby Place du Tertre:

Yet another day, we went to Musée Grévin:

Then, we walked through Passage Verdeau, Jouffroy, and Passage des Panoramas, and we finished at the Louvre's shopping gallery:

That's all folks. 'till next year.

We had a nice Xmas lunch:

Birds thought it was spring already :)

the electric bike

the scooter had plenty of pull

they still have their race car

They definitely have good technology, I hope they do well in helping spreading electrically powered vehicles to the consumer.

Since I had been working on arduino, I happened to have one of those 3.3V FTDI USB-serial converters, and was able to make a cable that connects my bedside Zeo to my server closer via a custom cable going through my existing Cat-5 wiring.

The example code they gave is however, while very fancy, not that simple to borrow from for a more simple application that simply needs to keep track of the sleep stage.

So, after finding the relevant info, I compiled the code below, which I'm posting for others to use (you can also download it here: zeo raw data code sample).

#!/usr/bin/python

# This is based off the Zeo Raw Data Library at the bottom of
# http://zeorawdata.sourceforge.net/starting.html
# This script is a much simpler version of how to log basic data than the cool
# and pretty GUI_Viewer from http://zeorawdata.sourceforge.net/examples.html
# This script is an easier example to steal from for simple logging/integration.

# By Marc MERLIN <marc_soft@merlins.org> / 2011/12/17
# License: GPLv3.

#gandalfthegrey [mc]$ ./logsleep.py
# 2011-12-17 12:19:10: HeadbandDocked
# 2011-12-17 12:19:15: HeadbandUnDocked
# 2011-12-17 12:19:22: Sleep state: Undefined
# 2011-12-17 12:19:52: Sleep state: Undefined
# 2011-12-17 12:20:22: Sleep state: Undefined
# 2011-12-17 12:20:52: Sleep state: Undefined
# 2011-12-17 12:21:22: Sleep state: Undefined
# 2011-12-17 12:21:52: Sleep state: Undefined
# 2011-12-17 12:22:22: Sleep state: Undefined
# 2011-12-17 12:22:52: Sleep state: Undefined
# 2011-12-17 12:23:22: Sleep state: Undefined
# 2011-12-17 12:23:52: NightStart
# 2011-12-17 12:23:52: Sleep state: Awake
# 2011-12-17 12:24:22: Sleep state: Awake
# 2011-12-17 12:24:52: Sleep state: Awake
# 2011-12-17 12:25:22: Sleep state: Awake
# 2011-12-17 12:25:52: Sleep state: Awake
# 2011-12-17 12:26:23: Sleep state: Awake
# 2011-12-17 12:26:32: HeadbandDocked

# System Libraries
import time
import sys

# Zeo Libraries
from ZeoRawData import BaseLink, Parser
from ZeoRawData.Utility import *

# User customizable variables
port = '/dev/ttyUSB0'

class Callbacks:
    def logtime(self):
	return time.strftime("%Y-%m-%d %H:%M:%S: ", time.localtime())

    def SliceCallback(self, slice):
        if slice['SleepStage']:
	    print self.logtime() + "Sleep state: " + slice['SleepStage']

    def EventCallback(self, logtime, version, event):
	print self.logtime() + event

if __name__ = "__main__":
    link = BaseLink.BaseLink(port)
    parser = Parser.Parser()

    callbacks = Callbacks()

    # Add Callbacks and Start the Link
    link.addCallback(parser.update)
    parser.addSliceCallback(callbacks.SliceCallback)
    parser.addEventCallback(callbacks.EventCallback)
    link.start()

    # Infinitely loop to allow the script to run continuously
    while(True):
        time.sleep(5)

Android team took matter in their own hands, and brought snow to their building.

It was kind of cool to see how huge blocks of ice were turned into something that mostly looked like snow :)

The end result:

A few days later, it was mostly gone, as expected, but still, it was a fun stunt :)

Now, because I need to wear a retainer every night anyway after I got my teeth moved, I figured I might as well get a sleep appliance again (think of a retainer with hardware that forces your bottom jaw forward) and improve my airway and room for my tongue when I sleep, just in case that helps further.

I was due for a sleep study at Standford, so we did a split night, first half withe sleep appliance and second half without it. While it's true that my sleep is not the same at the begining of the night vs the end, my sleep is usually deeper at the beginning of the night.

Apnea results

Long story short, my sleep was clearly worse with the sleep appliance than without. My AHI/RDI was 15.5 along with SPO2 drops with the appliance (That counts as apnea), while it went down to an almost normal 9 without SPO2 drops without the appliance.

So, there are 3 possibilities:

So let's have a look at the stanford graph, knowing that I removed the appliance around 03:00 but took almost 30mn to sleep again after that (and got up once to drink around 03:20):

Stanford vs Zeo

I brought my Zeo sleep monitor and the tech allowed me to wear it on top of their sensors to record the night on my phone while they were recording it themselves.
Let's compare the two (note that the Zeo monitor which consolidates stages 1 and 2 as light sleep, and 3 and 4 as deep sleep):

Having a quick look the Zeo does a reasonable job, even if not perfect:

Zeo has a quick explanation on their consolidated stages of sleep, and what each means and more articles on sleep stages.

Verdict for Zeo? I'd say it wasn't bad considering, especially since it is designed to smooth and average data, while Stanford is meant to show raw data.

Stanford vs Bluetooth Pulse Oximeter CMS50EW

This brings us to my SPO2 saturation. I used a CMS50EW finger clamp SPO2 monitor which actually worked a bit more reliably than the stanford sensor which dropped signal a couple of times during the study.

The drop around 03:20 is because I god unhooked, but the drops at 03:00 (to 60%?) and later around 06:00, look like monitoring issues. It seems that the tech who did the report did reject them as such.

Here are the dumps from my own monitor for that night:

My graph, first part of the night, with sleep appliance

Stanford graph

My graph, second part of the night, without sleep appliance

Comparing the results, my monitor did show the drops at 23:35, 00:55, but it missed 01:25 and 03:00. I'm not sure who's right there, you'd think Stanford obviously has more sensitive equipment, but I also think it might be too sensitive. I think their sensor might show big drops when it'd bumped wrong, or the analog plug is touched.
At 03:20, I was unplugged so that drop is expected. After that, the big drops around 06:00 seem to be bad data which my own monitor did not record.
Because my own recorder was built in and did not rely on wires that would be messed with when I move, I actually think I got better SPO2 readings than they did. Too bad it's soo uncomfortable to wear and requires a good amount of tape to make sure I don't have it drop off my finger, or move enough to affect its readings.

Verdict?

what a mess :)

This is why I've been working on my own recording at home so that I can get as much data as I can over several nights and average that out.

Now, because I need to wear a retainer every night anyway after I got my teeth moved, I figured I might as well get a sleep appliance again (think of a retainer with hardware that forces your bottom jaw forward) and improve my airway and room for my tongue when I sleep, just in case that helps further.

I was due for a sleep study at Standford, so we did a split night, first half withe sleep appliance and second half without it. While it's true that my sleep is not the same at the begining of the night vs the end, my sleep is usually deeper at the beginning of the night.

Apnea results

Long story short, my sleep was clearly worse with the sleep appliance than without. My AHI/RDI was 15.5 along with SPO2 drops with the appliance (That counts as apnea), while it went down to an almost normal 9 without SPO2 drops without the appliance.

So, there are 3 possibilities:

So let's have a look at the stanford graph, knowing that I removed the appliance around 03:00 but took almost 30mn to sleep again after that (and got up once to drink around 03:20):

Stanford vs Zeo

I brought my Zeo sleep monitor and the tech allowed me to wear it on top of their sensors to record the night on my phone while they were recording it themselves.
Let's compare the two (note that the Zeo monitor which consolidates stages 1 and 2 as light sleep, and 3 and 4 as deep sleep):

Having a quick look the Zeo does a reasonable job, even if not perfect:

Zeo has a quick explanation on their consolidated stages of sleep, and what each means and more articles on sleep stages.

Verdict for Zeo? I'd say it wasn't bad considering, especially since it is designed to smooth and average data, while Stanford is meant to show raw data.

Stanford vs Bluetooth Pulse Oximeter CMS50EW

This brings us to my SPO2 saturation. I used a CMS50EW finger clamp SPO2 monitor which actually worked a bit more reliably than the stanford sensor which dropped signal a couple of times during the study.

The drop around 03:20 is because I god unhooked, but the drops at 03:00 (to 60%?) and later around 06:00, look like monitoring issues. It seems that the tech who did the report did reject them as such.

Here are the dumps from my own monitor for that night:

My graph, first part of the night, with sleep appliance

Stanford graph

My graph, second part of the night, without sleep appliance

Comparing the results, my monitor did show the drops at 23:35, 00:55, but it missed 01:25 and 03:00. I'm not sure who's right there, you'd think Stanford obviously has more sensitive equipment, but I also think it might be too sensitive. I think their sensor might show big drops when it'd bumped wrong, or the analog plug is touched.
At 03:20, I was unplugged so that drop is expected. After that, the big drops around 06:00 seem to be bad data which my own monitor did not record.
Because my own recorder was built in and did not rely on wires that would be messed with when I move, I actually think I got better SPO2 readings than they did. Too bad it's soo uncomfortable to wear and requires a good amount of tape to make sure I don't have it drop off my finger, or move enough to affect its readings.

Verdict?

what a mess :)

This is why I've been working on my own recording at home so that I can get as much data as I can over several nights and average that out.

I had already read a fair amount about Steve, but I was still impressed by the details of how Steve would believe in something that seemed unachievable strongly enough that he would manage to convince his engineers that it was achievable, and they would often make it happen.

I also didn't know that all Apple devices were not upgradable, or even meant to be opened, because Steve believed they were works of art that should not be disturbed since they were perfect as is :)

I never was a Steve fanboy, but I do admire the guy for some of what he did, and all in all, it was a quite interesting evening.

TL;DR: gcc-avr 4.5.3 breaks Arduino NewSoftSerial on 328p. I had to downgrade back to 4.3.5.

Full story:
I had my arduino mobsendat board (328P based) working fine and after uploading some changes, it startsending a few of my characters over my Xbee, mixed with garbage. Most characters actually seemed lost.

In other words, I got less traffic than I should, a few were original characters, and some were garbage on a board and Xbee that were sending traffic at 38,400bps just fine for the last year.

I used my xprotolab to decode the sending pin on the xbee directly to rule out RF issues, and I see the garbage there too. If you want to know what I mean, look at the last picture on http://www.gabotronics.com/product-info/xprotolab-pictures.htm

So I was bit confused. The Xbee worked fine separately from the board and the serial bits getting to the xbee pins were damaged before they were sent on a simple program like this:

#include <NewSoftSerial.h>

const int XBEE_SLEEP          = 8; // pin 14

NewSoftSerial mySerial =  NewSoftSerial(2, 3);

void setup(void)
{
  Serial.begin(38400);
  mySerial.begin(38400);
  // Switch pin to digital mode with pullup.
  pinMode(XBEE_SLEEP, OUTPUT);
  digitalWrite(XBEE_SLEEP, LOW);
  while (1)
  {
    Serial.println("AB12");
    mySerial.println("AB12");
    delay(1000);
  }
}

void loop(void) { }

Arduino IDE is 0.22ubuntu0.1 on ubuntu oneiric. I thought that maybe an update to the arduino IDE broke it when I went from ubuntu marverick/natty to oneiric, but that wasn't it.

Then I thought that maybe I damaged my hardware (maybe the clock/crystal is messed up, but then I suppose serial over USB wouldn't work either, and it does work), or if upgrading ubuntu recently broke NewSoftSerial in some subtle way, but I verified I had NewSoftSerial 10, and upgrading to 11 beta did not help.

This is where it got wild: if I listened to the serial traffic going to the xbee from NewSoftSerial (I had version 10), and if I used the RX UART decoding pin of my Xprotolab, it could see the traffic ok. If I used the TX pin on the Xprotolab, then the same traffic mostly looked like garbage (actually most characters were lost). Putting 2 stop bits did not help.

I talked to Gabriel Anzziani who made the Xprotolab and he said 'The RX and TX decoding are done differently in the Xprotolab. The RX is done by the XMEGA hardware, and the TX is done in firmware.'

So clearly, there was a timing issue in what NewSoftSerial was doing at 38400 even though it had worked with the same NewSoftSerial library for about a year and NewSoftSerial 11 did not help.

So, out of desperation, I took the nfs backup from my laptop before I upgraded from ubuntu maverick to ubuntu oneiric. While it was a bit hard to get the arduino IDE to work over an NFS chroot, I eventually got it to run, compile and upload my same Hello world serial program. And it worked!

From there, it took a binary search to pin this down to the gcc-avr upgrade.

gandalfthegrey:/var/local/src/arduino# dpkg -i gcc-avr-4.3.5-1.deb
dpkg: warning: downgrading gcc-avr from 1:4.5.3-2 to 1:4.3.5-1.

My guess is that the new gcc-avr changes some compilation timings/optimizations in a way that NewSoftSerial breaks :(

this was what I made

the glass blowing was interesting and hard

To be honest, I'm getting tired of this 'without loud music to drown out the entire room and dancing or nothing'. It's the same thing every year :( It's really too bad because it was otherwise a nice party.

Some went to hide in the small room next door, the scotch bar, but it was way too small for the number of people wanting to hide there.

Since talking was mostly impossible at that point, Jennifer wanted to try some fake gambling, so we played some blackjack where I 'won' ten times my original bid before we had enough of the noise and just went home.