This project looks like its got a lot of history, between its close source, partial open source and APIs for accessing the data. The Protocols "are out there.." I am just not sure if they are hiding in plain site in a text document already.. or need a bit of study.
I have almost talked myself into believing the Raw data is available.. but that hinges on whether the headbands for the bedside unit are the same as the headbands for the mobile units. And I'm not sure how to check that.
--
Had some good back and forth with CyberMike today.. his LUA dissector script for Wireshark is showing real promise at turning the Bluetooth messages into usable data.. that means the protocol behaviors can be studied... which he's already gone a long ways towards that goal.
He also doesn't think the Mobile is anything like the Bedside Headband... well good.. then won't have to go down that path for now. The test modes are of some interest.. but hasn't seen any evidence of them being used in a long sequence of use.
The last time I looked at LUA was so long ago.. it looks practically brand new. It looks and feels like 'C' code but its not.. but decoding with it might be a good way of prototyping a parser for code on lots of platforms and for lots of apps.
The key thing about all this is I did not know you could use a "scripting" language like LUA to prototype protocol parsers in Wireshark. I thought they always had to be compiled modules.
It turns out all of the default "dissectors" are precompiled, however the plugins directory (there is a "global plugin directory" and a private "user plugin directory") can contain user supplied LUA scripts which are 'C' like and have recursive and object oriented structures. In general a script declares an init function and a callback function which Wireshark can use when it comes across a situation that indicates it should be parsed by this protocol parser.
In this case Bluetooth is being used like a serial port or wireless comm communications device called an RFCOMM channel. The parser is "attached" to this protocol declaration as a subtype which can also be called by "forcing" Decode As.. and selecting the subtype.
The subtype in this case is called "zeo headband protocol"
The protocol from what I can see is not too far removed from ANT+ in that messages and types are declared which determine how sequential packets are processed back into frames to deliver their payload.
Some of it is status, some of it contains sleep records.
From reading the Users Manual in very fine print in the installed App on an Android Phone.. one method of triggering a download of sleep data is to tap the single button on the side of the unit once data collection has ended. This is mainly for the situation where the device looses battery power before the end of a night. The next day the device can be recharged and manually triggered to download the data. Normally it does a complete download of data at the end of a night.
The other is periodically the zeo pod will wake up from a deep sleep to send sleep data, according to the former CEO.. the Mobile model will do this every 5 minutes.
The Press release from one of the Nordic countries indicated the processor in the Zeo Mobile is the EFM32 M3 Cortex 'Gecko' with 128 MB of onboard flash memory, if sleep records take up around 1.5KB that is really a lot of storage space. But some of that space however will be taken up by actual program code.
A few links
Zeo, Inc. is using the EFM32 Gecko MCU in its Zeo® Sleep Manager™ Mobile.
- From a 95mAh rechargeable battery cell a time between headband battery charging of 4 days was achieved by product designers.
Zeo Sleep Manager Mobile uses Bluetooth -- not Bluetooth Low Energy
While the headband looks almost exactly the same, its guts couldn't be more different. Zeo's legacy model had all the processing power in the bedside display, while the new headband has the intelligence onboard. The processor coupled with Bluetooth makes for a more power-intensive device, but Rubin said that it can easily last the night and could hold its charge for at least an entire day and up to three. The device also includes an accelerometer for the first time, which enables it to track the wearer's movement at night and determine sleep position. The accelerometer can also help refine Zeo's algorithm. Since the processing power is local, the headband does not need to transmit continuously anymore -- it sends data to the smartphone every five minutes, Rubin said.US Patent - Systems and methods for sleep monitoring (Zeo > ResMed 12/2013)
Describes processing of the raw EEG data into sleep states
US Patent - Data-driven sleep coaching system (Zeo > ResMed 12/2013)
Zeo Bedside - Contains the equation for determining the ZQ value from acquired data.
US Patent - Multi-modal sleep system (Zeo > ResMed 12/2013)
Zeo Mobile
A Zeo Developer describing Signal processing - Stephen Fabregas
Developer API's (including Android) and Terms
FCC ID Exhbits for Hardware WH4ZEO101
Zeo Bedside
FCC ID Exhibits for Hardware WH4ZEO301
Zeo Mobile
