Tapping into MIMO Smart Baby Monitor

This is a bit of a question on data ownership, but mostly just a practical question of utilizing monitor data. We have a new baby in the house and purchased a MIMO Smart Baby Monitor. The sensor is called a “turtle” and utilizes Bluetooth Low-energy (BTLE) to communicate with a WiFi bridge/hub called a “lillypad”. The “lillypad” sends the data to a cloud service where it is presented back to a phone app.

My desire is to eliminate use of the “lilllypad” and instead simply capture the data and locally generate alarms and trigger actions. This makes me feel more secure as it isn’t relying on my Internet service to forward me alerts. It also means I can integrate a bunch more actions.

I’m using a BeagleBone Black and a BTLE dongle to perform the interface to the “turtle”. I’m using a Python library called “bluepy”. So far, I’ve been successful at extracting a live data stream from the “turtle”, but I’m unable to easily recognize patterns in the data stream to know how to interpret the data.

Does anyone have enough familiarity with this sensor to help make sense of the data stream?

Below is a link to the output stream and the simple Python routine I’ve used to fetch it.

Hi Jason!

I should be able to help a bit here. I’m one of the co-founders of the company behind Mimo, and am thrilled to see that you are using the product — we’ve been hoping to have more hacker dads in our user network!

I’ve included below a quick breakdown of the format of the data that the Turtle sends across. It should be fairly straight forward to decode the information from the sensors. Unfortunately, most of our processing does happen on our servers, so the data that you’ll be able to see will be the raw sensor values, and the Turtle won’t be able to directly give you any of the alerts that are generated in the app.

I also do have to note that while we’re more than happy to provide information where we can, using the product like this isn’t a supported use case, and you’re doing it at your own risk.

I would love to hear your thoughts about Mimo and how we can make it more useful. We love getting feedback!

Byte    Name            Description
=========================================================
00      Turtle ID       3 byte TurtleID
01
02      
--------------------------------------------------------
03      Packet Identifier
04      
---------------------------------------------------------
05      Respiration     5x 16-bit samples, starting
06                      with the oldest, big-endian
07      
08      
09      
10      
11      
12      
13      
14
---------------------------------------------------------
15      Acceleration    One byte per axis, in order of
16                      X, Y, Z, signed
17      
---------------------------------------------------------
18      Temperature     Relative scale
---------------------------------------------------------
19      Battery         0-100%


For example:
aaed18009d0a3b0a3a0a370a350a380300b99558

aaed18 - Turtle ID
      009d - Packet identifier
          0a3b - Respiration #1
              0a3a - Respiration #2
                  0a37 - Respiration #3
                      0a35 - Respiration #4
                          0a38 - Respiration #5
                              03 - X axis
                                00 - Y axis
                                  b9 - Z axis
                                    95 - Relative temperature
                                      58 - Battery
1 Like

I’m so impressed you replied to me with such straight-forward useful information! Thanks!!! I’ll be sure to post some hacks promoting your sensor with BeagleBones.

It took me a second to understand from your note that the ‘009d’ packet identifier wasn’t a packet sequence number, ie., it wasn’t meant to be an incrementing or random number meant to let you know where you were in the data sequence, but instead was simply saying that “this packet is providing X data”.

Any hints on what packet identifiers ‘00ab’, ‘00a6’, ‘00a1’ and ‘0101’ are? I guess they aren’t fundamentally needed for what I want to do, but you’ve got me curious now. :smile:

How do I have confidence I’m not dropping respiration samples? I’ve got bit of a DSP background, but nothing specifically monitoring respiration. For me to do signal analysis, my expectation is that I’d know when I’d missed any data. I’ll remove my wait within my read loop, but I really don’t understand where I’d be blocking within my operating system and what my risks are for dropping samples or mechanism for identifying dropped samples.

Thanks again. My first project will be to tie up a speaker and a voice synthesizer to tell me when our baby isn’t providing good respiration data to the sensor, with increasing alarms if data doesn’t start coming in. Something like “you might want to check on the baby” and “I haven’t detected respiration in X seconds”. After that, I plan to do my own bottle warmer hack based on detecting a waking baby.

Not sure where you guys left off with this but I have +12wks of paternity leave and would be more than happy to throw in on this. Can I get a status update as to where everyone left off with an API and device connectivity?

Cheers, Jd

I and my DW are looking for Good baby Monitors for our New House.Bluetooth baby monitors sound like a good idea, but some of my friends told me it May not have longer range on other room.Anyone has suggestions?
And what brand of Baby monitors has the longest range?