Nach langem Warten und zusätzlichem Warten auf den Zoll habe ich das Beddit, das ich bei Indiegogo gebackt hatte, endlich da. Ich hatte mir gleich zwei Units gesichert, eins für mich zum benutzen, eins für Experimente, auseinandernehmen, hacken oder für shared dream Schlafexperimente – schlafhacking-Gadgets sollte der Nerd immer gleich doppelt haben.
Kurzgefasster erster Eindruck: die Hardware ist toll, Software ist (noch) mau.
Das Gerät wird zwischen Matratze und Bezug auf die Matratze geklebt. Man spürt es überhaupt nicht, daher stört es auch nicht beim Schlafen. Es muss über USB mit Strom versorgt werden, die Daten werden über Bluetooth an die App geschickt, das Smartphone oder Tablet ist also die ganze Nacht dabei, Daten einzusammeln, die Auswertung erfolgt ebenfalls auf dem Smartphone/Tablet. Obwohl die App darauf besteht, dass das Smartphone am Strom stecken soll, muss das nicht unbedingt sein (das iPad verliert pro Nacht 10% Akkuladung, das iPhone 5 ~60%, man hält also locker eine Nacht durch; das Beddit selbst kann auch mit einer Powerbank betreiben, es eignet sich also gut auch für mobilen Einsatz im Hotel).
Bisher liegt nur die iOS app vor, und die kann noch so gut wie gar nichts. Am Ende der Nacht liegt eine grobe Klassifikation vor, wie lange man geschlafen und wie oft man das Bett verlassen hat sowie die Angabe des Ruhepulses. Keine Echtzeit-Herzfrequenz. Keine Rohdaten. Langweilig.
Datenfiles der (vermutlich) Rohdaten liegen unter 17A2A955-2F18-4F7F-B330-F5A26B88FF20/Documents auf dem iOS Device. Beddit Support vertröstet auf künftige Releases und eine im Sommer erscheinende “Cloud API” für den Zugriff auf die Rohdaten. Das ist enttäuschend und zwingt den Schlafhacker dazu, das Gerät auseinander zu nehmen, Bluetooth Protokoll und Firmware zu reversen und selbst auf die Messwerte (Herz- und Atemfrequenz, Sleep state estimations, Snoring, …) dieses schönen Sensors zuzugreifen.
Denn dass das mit dem Beddit gehen muss, zeigen beispielsweise diese Quellen. Wer ein beddit hat und mithacken möchte, melde sich bitte. Ziel ist ein opensource Treiber, der ohne die mediocre App von beddit auskommt und Rohdaten liefert 😉
The device shows as a normal RFCOMM Bluetooth serial port and accepts ASCII commands.
I know of these commands (newline-terminated):
Command: OK
Output: OK
Command: INFO
Output: INFO VERSION: 1.0; CHANNELS: normal, gained; SAMPLERATE: 140.0; SERIAL: xx:xx:xx:xx:xx:xx; BUILD: 037d7f8
Command: START
Output: Starts to produce sample data in binary format, probably in some kind of packets (have yet to decode).
Ok, here’s an analysis of the packet format. Each packet looks like this:
dword packetNum
word payloadLength
byte payload[payloadLength]
dword crc32
The payload is raw sample data of 16-bit samples. My Beddit seems to always send 64 byte chunks of payload. Words 0, 2, 4, … are samples from the “normal” channel, while words 1, 3, 5, … are samples from the “gained” channel.
At least with my bluetooth connection some data is frequently lost, so the listening side needs to be able to detect missing data and resynchronize. The amount of lost data can be calculated from the gap in packet numbers. The 64-byte packets contain 2*16 samples, and at 140 Hz that’s worth of 0.114 seconds of data.
Awesome, thanks for the reply!
Your github project is awesome, too 🙂
https://github.com/sliedes/beddit-driver