Blog

articles and technical details

Real-time activity graph

A demo of real time plot of accelerometer measurements

Read More

Monbaby breathing detection via IPhone app

Demo showing Monbaby breathing and orientation detection on an IPhone app

Read More

Breathing analysis

Algorithmic Detection of Breathing Cycle

Our body moves in tandem with breathing. Especially in the upper torso area, the rise and fall of the chest is prominently associated with breathing. When placed near key spots, breathing cycle can be inferred from movement data alone. The xyz values from the accelerometer can be used to derive cyclical human breathing pattern.

The key elements of the algorithm is to filter out as much noise from the data as possible, and apply the appropriate algorithm on the transformed data. In practical implementation, the algorithm also has to run in realtime, and refine its estimation from streaming data. A person normally takes about 2-5 seconds (0.5 – 0.2Hz) to complete a full inhale and exhale cycle. Assuming a single breathing cycle completes within 2-5 seconds, you only need about 1-2 data points per second to detect a frequency in theory. With 5Hz sampling frequency, it becomes feasible to tackle breathing detection using captured xyz acceleration values.

The following plots illustrate this. From left to right, going down each row, you will see:

  • x acceleration values and its corresponding high and low pass filtered timeseries
  • y acceleration values and its corresponding high and low pass filtered timeseries
  • z acceleration values and its corresponding high and low pass filtered timeseries
  • plot showing the “activity level”, expressed by the euclidean norm of change in xyz values
  • all 3 axis aggregated by their proportional weight in the variances, where their collinearity is taken into account by eigenvalue-based weights
  • we zoom into a particular sample patch in the aggregated time series, where clean sinusoidal signal can be extracted
  • running discrete fourier transformation on the zoom-ed in sample, and the red bar highlights the prominent frequency

breathing-algo

 

The highlighted frequency coincides with the rate at which the subject was breathing. Our device was placed at various places on the body, while the sample was being collected in realtime. The strongest signal was obtained when our device was placed near the upper torso. The data transmission was done wirelessly at 5 times a second to an iPhone. The iPhone recorded all data received and persisted it into a csv file, which was used for this analysis.

The implementation of the algorithm can be done without much need for complex computation. Also, less than 2 minutes worth of 5 Hz samples (2*60*5 = 600 data points), need to be kept in memory to get sufficiently reliable readings. The data should be maintained in a queue, and the most recent data points should replace the older data points. We will be working on sample application to illustrate this algorithm in action.

Read More

Protected: Pitches

This content is password protected. To view it please enter your password below:

Read More

Heart rate detection prototype

Read More

Monbaby prototype – fall detection

Read More

MonBaby prototype 3.0 – latest videos

Read More

Heart Rate Data Analysis

I needed a way to collect real heart rate sample data for more in-depth analysis. I wanted to not only validate the Butterworth filtering algorithm, but also understand the sensitivity of its parameters and its robustness against other exogenous noise. Furthermore, having a good dataset will enable me to examine other possible algorithms in detecting the pulse accurately. The CC2540 implementation has a bug. Hopefully, I can use the dataset to identify the bug and modify the algorithm to make it work under my new implementation.

I’ve written some small python scripts to extract the raw data from both the Arduino and my implementation on CC2540. Fortunately, the SmartRF05EB board comes with access to UART so I was able to spit out the same data out to PC. From my linux box, I listen to the serial port over USB and just write the data out to raw text. Here’s the script that dumps data from the serial port.

#!/usr/bin/env python
import sys
import time
sys.path.insert(0,'/nas/dev/c/uC/8051/projects/cc2540/scripts/pyserial-2.6')
import serial

def readlines(ser):
  starttime = time.time()
  while True:
    text = ser.readline();
    difftime = time.time() - starttime
    sys.stdout.write("%f %s" % (difftime,text))

ser = serial.Serial(port='/dev/ttyUSB0', baudrate=115200, timeout=None)
readlines(ser)

ser.flush()
ser.close()

Once the raw text data is collected, another python script parses this data and writes it into tabular csv data. The csv data is much more ammenable for experimentation, and importing it is a snap on any statistical or computing environment of your choice. (for me it’s R) This is the script that reads from the serial port.

#!/usr/bin/env python
import sys
import re
import time
import os

path = sys.argv[1]
f = open(path, "r");

gotS = False
gotB = False
gotQ = False
data = []
row  = [ None, None, None, None]
ts = None

print ",".join(['ts','signal','filtered','hrv','bpm'])

while f:
  line = f.readline()
  tok = line.split()
  n = len(line)
  if n == 0:
    break
  if len(tok) < 2:
    continue
  s = tok[1]

  # when we detect the first S, the rest is part of the same row
  if s[0] == 'S' and gotS == True:
    gotS = False
    print ",".join(str(i) for i in [ts]+ row)
    # data.append(row[:])  # copies

  if s[0] == 'S' and gotS == False:
    ts = float(tok[0])
    row[0] = int(s[1:])
    gotS = True

  if s[0] == 'F' and gotS == True:
    sign = -1 if s[1] == 'N' else 1
    row[1] = sign*int(s[2:])

  if s[0] == 'B' and gotS == True:
    row[2] = int(s[1:])

  if s[0] == 'Q' and gotS == True:
    row[3] = int(s[1:])

The pulse is detected whenever the filtered data line crosses zero. The algorithm refines the raw data by filtering it so that pulse detection is easier.

The data from CC2540 gives almost the same result.

Another difference to note is the scale of the raw data. The ADC values (signal) from Arduino hovers around ~900, whereas the CC2540 values hover around ~300. The differences are due to the reference voltage, and the operating voltage among other things. Arduino uses 5V by default for the reference voltage, whereas CC2540 uses 1.25V by default. Arduino runs at 5V, CC2540 runs at 3V.

Read More

Article on DIY galvanic response, skin conductance

DIY galvanic response, skin conductance

Read More

Monbaby Android BLE demo

Here is a link to a quite crude, but functional demo of a monbaby sensor transmitting accelerometer measurements wirelessly over BLE to a smartphone that routes it to the web/cloud.

Monbaby android presentation

Read More

Kickstarter is loosing it’s appeal

Kickstarter is loosing it’s appleal,

but according to comments, so is gizmodo

Read More

Y-Combinator – Frighteningly Ambitious Startup Ideas

Very interesting Paul Graham article on Frighteningly Ambitious Startup Ideas, please note idea #7.

Read More

A new X-prize competition

A new X-prize <a title=”x-prize” href=”http://www.engadget.com/2012/05/25/nokia-and-x-prize-put-medical-sensors-on-the-spot-for-next-chall/”>competition </a>have been announced with collaboration with Nokia, prize is $2.25 million.

Read More

Metawatch with BLE support

A new version of <a title=”metawatch” href=”http://www.metawatch.org/forums/thread/455/using-the-metawatch-as-bluetooth-host-device-ble”>metawatch </a>came out that supports BLE now.

Read More

scanadu.com developing real life medical tricoder

Remeber Star Trek <a title=”tricoder” href=”http://en.wikipedia.org/wiki/Tricorder”>tricoder</a>? Scanadu developing a real life <a title=”scanadu tricoder” href=”http://techcrunch.com/2011/11/08/scanadu-raises-2m-check-your-body-as-often-as-your-email/”>one</a>.

Read More

TI CC2541 launch

TI’s second Bluetooth low energy single-mode SoC IC, <a title=”CC2541″ href=”http://e2e.ti.com/blogs_/b/bluetooth_low_energy_blog/archive/2012/02/15/cc2541-now-released-including-support-for-bluetooth-low-energy-and-proprietary.aspx”>CC2541</a>,  have been launched.

Read More

Venture lab final presentation

Monbaby is a baby health monitor, wireless wearable monitor specifically designed for babies and parents. It keeps track of the baby’s vital signals and alerts you upon critical events. Our product aim is to reduce parents anxiety about their babies and SIDS, and to help parents to monitor their babies’ health with highest reliance but least amount of effort.

We are building a wireless monitor based on Bluetooth LE wearable as an ankle bracelet. It measures baby orientation and ambient temperature, then transmits measured signal to a Bluetooth capable receiver, such as IPhone, or Android smartphone or a Bluetooth Smart baby monitor. Unlike existing product on the market that send alert when baby stops moving, at which point it maybe too late to react, Monbaby warns parents if baby turned around and sleeping face down, giving parents plenty of time to go and turn baby face up.

We are former colleagues and NJ neighbors, and we met with an idea to pursue projects outside of work that combine wireless hardware, software and firmware programming, as we share love and passion about those technologies. By day, we are engineers and quantitative program traders, who are experienced in diversified software and hardware development, quantitative analysis and problem solving with combined 20 years of experience in Wall Street finance. We love to come up with new ideas, and convert these ideas into real life applications.

 

 

The idea for Monbaby product came as an attempt to address risks related to Sudden Infant Death Sindrome, or SIDS, as we all are parents to small children and all had anxiety associated with SIDS. We remember waking in the middle of the night just to check on the baby. We have submitted several ideas to bluetooth competition but Monbaby was noticed the most.

We got a pretty good feedback on this idea so far, as we were finalists in last year bluetooth competition, http://remnart.com/2012/02/bluetooth-iwc-competition/ and we were noticed and invited to CES 2012, http://remnart.com/2012/01/monbabyinces_2012/ to Freescale booth.

 

Now we want to take this product further. We were excited to participate in this class to get feedback from unique blend of entrepreneurial community and get a taste of silicon valley spirit.
Now we want to see Monbaby to fruition and to take it from a prototype into a product.

Read More

Developing for CC2540: Part II

A Bit About GAP and GATT

The entire BLE stack uses HAL to communicate with the hardware and the associated peripherals such as LED’s, LCD, and push buttons. The OSAL layer is the glue that lets different tasks and layers of software to interact with each other. The innards of the Bluetooth LE protocol is largely divided into two software layers:

  1. GAP (Generic Access Profile)
  2. GATT (Generic Attribute Profile)

The combination of those two layers implement the connectivity and the inter-device communication standards of the Bluetooth LE protocol. These two layers define what it is to be a bluetooth device, and by doing so, it ensures interoperability across various bluetooth-enabled devices that are built using the same specifications.

The CC2540 masks most of the underlying details of the link layer. The specifics of the wireless characteristics of bluetooth such as frequency hopping, secure pairing, and subsequent encryption process, are all implemented within a closed-source compiled library. This library is provided as a linkable binary only for IAR Workbench. And for this reason, the development for CC2540 is only possible with IAR Workbench. With open source code, it would have been possible port the software stack for other compilers such as SDCC.

Mind the GAP

The GAP layer defines specific set of roles each BLE device can assume. In the wireless device-to-device connection stage, each node can take one of the following roles (or profiles):

  1. Broadcaster
  2. Peripheral
  3. Observer
  4. Central

Without going too much into detail, it’s helpful to remember that the Observer/Central are the ones that will look for devices to connect to – they act as the master nodes in the pairing process. On the other hand, the Broadcaster/Peripheral node is the one that will sit there and advertise its existence, acting as the slave. The only difference to note among these profiles is that both Broadcaster and Observer are non-connectable.

What’s GATT?

The GATT layer sets up standards for data and inter-node communication flow between the nodes. It’s this layer that enables various bluetooth devices to share information with one another in a common “language”. Without this common language, devices manufactured by different vendors will speak their own langauges and will not be interoperable. The GATT specifications give definition and structure to both the data and functions each node in the connection can perform. Within this paradigm, any Bluetooth LE device can discover the identity and the functionality of any other Bluetooth LE devices.

 

BTTool

Here are the commands necessary to start receiving data from the heartrate monitor GATT profile.

 

* discover characteristic by UUID
Characteristic UUID = 37:2A (from HEARTRATE_MEAS_UUID define below)

* heart rate sensor comes back with “10 11 00 37 2A”
- 10 : means notify only
- 11 00 (0×0011) : is the handle for characteristic value
- 37 2A (0x2A37) : is the UUID

* in order to enable notifications, client need to write 0×0001 to
server characteristic config descriptor. The handle for this
config descriptor immediately follows the characteristic value’s
handle. So in this case, it is: 0×0012
- chracteristic value handle : 0×0012
- enter into write text box : 01:00
- once the write succeeds, the heart rate is transmitted

Read More

Mission for longer life

Life expectancy in US have reached 80 years and some experts claim that babies born in 2011 are 8 times more likely to reach a lifespan of  100 years. The world is getting older and more healthy and we at, at Remnart technologies, want to make sure that every newborn baby would have a chance for a long and healthy life.

We’ve been putting our time and effort into Monbaby product, which was envisioned and designed to prevent Sudden infant death syndrome (SIDS).

SIDS is the third leading cause of infant death for 2007 and the first leading cause of death among infants ages 1–12 months. A total of 2,453 SIDS deaths occurred in 2007, according to http://www.sidscenter.org/Statistics.html. It’s a tragedy and the most alarming aspect of it is absence of any explanation. There is just not enough data.

MonBaby was created to address the problem of the lack of data and try to mitigate the risk of SIDS.

It works like this: an ankle bracelet or a wristband with a clasp containing our sensor is worn around baby’s arm or an ankle, similar to existing bracelets worn by newborns to prevent baby theft. Clasp contains a sensor that monitors baby health and measures vital health signals. The signal is processed by a chip in a bracelet and send over Bluetooth wireless signal to a wireless reader in the vicinity. Wireless reader then records or transmits the data over WiFi and may trigger an alert if anything goes wrong.

This website and this blog covers our thoughts and our path to developing this product. We are trying to stay as open as possible in this endeavour and we are proponent of open source hardware movement. We will try to establish an acceptable solution and invite people to contribute to it.

As for the market potential of our product, recession or not, the field of medical health monitoring, and the medical electronic devices in general, is rapidly growing. According to DataBeans 2010 Medical Semiconductors report  the market of medical electronic devices, is expected to reach US$191.1 billion by 2015 with 8% annual growth rate.

The reasons behind the growth are increased average life span, aging population and growing demand from emerging markets.

We are hoping that our product will be both useful, popular and profitable.

Our mission statement is a quest for longer life.

 

Read More

Battery life and low power wireless tech

A very good reference about the battery life among different low power wireless technologies applications. Another reason why we use Bluetooth V4.0 (Bluetooth Low Energy) for our Monbaby product.

http://www.embedded.com/ContentEETimes/Documents/Schweber/C0924/C0924post.pdf

Read More