Night of the Biocybernetic Zombies

Last month we played host to our project partners in REFLECT, an EU research project aimed at the development of pervasive-adaptive systems (NB. Ferrari + heart monitor = awesome). For the evening festivities a Shiverpool tour was arranged. Shiverpool is a Liverpool based theatre performance in which the audience is taken on a night tour of the city by a spirit guide who regales his audience with stories about Liverpool’s supernatural past. The guide is also accompanied by several ghoulish friends (or fiends, depending if your the target of the next scare or not). To add a little bit more spice to the evening we brought along the heart monitors and wired up five members of our group to see once more Who’s afraid of Ghost Stories? Unfortunately not everything went to plan, we had a few issues with the hardware causing a significant level of data loss preventing a detailed commentary about individual responses as was done with Ghost Stories, so instead I thought it would a good time to talk about the heart monitors we use and the software platform that runs The Body Blogger which we used for this event.

The Heart Monitor in Question

Of late I’ve been doing a number of presentations about my experience as The Body Blogger . I haven’t really talked about the equipment we use and with my inbox overflowing with requests (apologies to all I haven’t got back too yet, I’m still going through my inbox)  its about time I write something about it. To cut to the chase so to speak, we use BM Innovations BM-CS5 heart monitor paired with a BM-USBD1 which is a USB dongle based radio receiver. The BM-CS5 is a chest-strap based heart monitor which outputs in real-time the wearer’s average heartbeat rate and IBI data (i.e. as series of millisecond intervals between individual beats) via a low power radio transmitter with an update frequency of ca. 1.1Hz (i.e. transmits every 0.9 second). When we started this project we were on the look out for a reasonably priced wireless heart monitor which had its own software development kit, to which this product fit the bill.

Originally I was looking at Alive Technologies electrode based heart monitor which uses Bluetooth to send a real-time ECG signal to a mobile phone. Having already played around with this device from my time at Lancaster University this seemed to be the obvious choice however I never managed to get a response from the company to my inquiries so we had to shop elsewhere. Given the type of experiences we wished to facilitate: always recording, always manipulating, the Bluetooth interface would of been the optimum transmission medium as its easy to integrate into a mobile phone. And a mobile is easier to carry around than a laptop acting as receiver for the heart monitor (or in my case a netbook). Eventually my research turned up the eZ430 Chronos Watch, a programmable digital watch with a low power radio transceiver, this of which allows the device to be integrated into supported wireless sensor frameworks. Looking through the technical specs I found that the watch supported the BM-CS series of heart monitors, and subsequently I came across BM Innovations TeamStart Lite package which included all the necessary kit to wirelessly monitor a user’s heartbeat rate while they were within the range of the provided USB dongle. After talking to their technical team we had the API for the dongle and began development on The Body Blogger platform.

Working with the BM-CS5

After using the device continuously since March, I have a lot of respect for the BM-CS5 and accompanying dongle as the sensor is perfect for applications requiring low fidelity signals (NB. IBI data can be used to derive more complex measures but I’ve not yet investigated how precise the sensor actually is as the average measure is sufficient for our work, heart rate is detected on an IRQ trigger so technically the device should be as  good as a sensor with a very high sample rate which is needed for FFT analysis), and the manufacturing quality is second to none. For starters, I’ve been running the device for over 9 months now, and excluding the several corruptions in the database hosting my physiology (not the devices fault) and the time I’ve spent outside the range of the base station which all told I’d estimate at between 168hrs and 336hrs (1-2 weeks of data at device’s transmission frequency ca. 1.1Hz),  the device has logged an impressive 102 days of data without incident in a whole slew of different environments (e.g. being waterproof it can transmit while your in the shower). Also the initial battery it was supplied with finally died in October (which is easy to replace), and so it operated for a least 1824 hrs (76 days) on a single charge which is double the listed 730 hours by the manufacturer (i.e. 1 hour a day for 2 years).

The effective transmission range of the BMI hardware is not bad either. In an ideal environment the BM-USBD1 is suppose to be able to pick up a signal from 100 meters away with the BM-CS5 having  a transmission range of 800 meters, however if you’ve ever worked with wireless sensors you’ll know the effective range greatly depends on whether you have line of sight between the devices, the intermediate physical environment, atmospheric conditions and the antenna design (e.g. during BioS-Play, the dongle underwent some remodeling when my backpack was bumped which cut the recieving range down to a meter or so). The system is run in the main from two places, my office and my home, using the dongle I’ve found the transmission range to be effective within a radius of roughly 15-35 meters. At home I have full coverage around the house and then some, the office not so much as I’m down the end of a corridor with a bunch of concrete walls between me and anything else. However for the majority of my day I’m within transmitting range and so I don’t have to worry about repositioning the base station. As the Shiverpool event revealed I really need to perform some tests to judge the effective transmission range of the device in an open air environment and as soon as I can rope someone into helping me out I shall do so. Sadly it won’t be exciting as when I was helping out a friend testing their low power radios, for some reason we climbed to the top of the largest hill in Lancaster with two coat stands with huge antennas crudely strapped to them. It was all very Doctor Who.

The only real issue I have with device is its mobility, on an average day using my current setup I would lose about 2-4hrs of data while I was migrating the system between locations or was outside the range of the base station. If I wanted true 24×7 recordings I would have to carry my netbook with me everywhere which I’ll only do on special occasions. Although I originally wanted a heart monitor supporting Bluetooth so I could interface it with a mobile phone (thereby solving the mobility issue), there are downsides to this. For one Bluetooth consumes a lot more power than the radio the BM-CS5 uses and an equivalent heart monitor using Bluetooth wouldn’t last anywhere near as long before requiring a recharge (i.e. looking at days instead of months). When I get the time I intend to address this problem by using the Chronos watch to capture data when I go outside the range of the base station. Another issue I have with Bluetooth, is slightly more  nebulous. Being a higher power transmitter I do have a genuine concern about long term exposure to such an electro-magnetic (EM) source operating directly over my heart. From a purely paranoia perspective I’m happier using a lower power transmitter rather than a higher power one. I’ve read several studies on the effects of EM fields on the human nervous system and while the results are often inconclusive what I have read doesn’t really sound good (e.g. increased sympathetic dominance) so better safe than future mutant zombie. An electrode based device may alleviate some of these fears (as the power source is located elsewhere on the body), however a chest-strap is both easier to set up and more durable (e.g. no need to tap any electrodes to the skin to minimise movement artifacts).

Purchasing the BM-CS5

BM Innovations runs  two websites: and The BM Innovations site  provides technical information on their hardware, e-commerce for the BM CS5-R (short range version of the CS5 — ideal for the Chronos) and a range of sensor components; the site also hosts their data acquisition software and driver updates. The Acentas site previously provided e-commerce  for all their hardware and heart monitoring packages however they appear to of removed this; now the site only describes what  packages and analysis software they offer. You should be able to make purchase orders via the listed sales team contact.

In terms of costing the unit prices are as follows: BM-CS5 98 Euros, BM-USBD1 129 Euros, BM-CS5-R 49 Euros. We bought the TeamLite Start package which comes with 2 BM-CS5 heart monitors, a BM-USBD1 USB dongle and their monitoring software: this cost us £270. The API for the dongle was free on request. A note of caution their are two versions of the API I’m currently aware of. I’m using the earliest version I have which only returns the average heartbeat rate. The later API returns the IBI values, however from what I can remember it does not return the signal strength or sequence number of received packets which I use in my work.

The Software Platform

With The Body Blogger I decided to keep things really simple as my interests lie in the application and not the underlying technology. The core of my platform is a local web server running a MySQL database. Physiological data is forwarded from the dongle to the database in real-time and is sorted according to the receiver ID and time of day. Applications need only run a MySQL query to get at the data. Applications are designed in PHP and are run on the local web server through my browser. Normally I run 2 applications concurrently, The BodyBlogger and a real-time visualisation feed. Developing applications in PHP is a natural choice for this project as I’m already running a web service, and their all contained within the browser rather than clogging up my desktop. As MySQL runs as its own service I’ve de-coupled the sensor from the application allowing me to easily develop and plug in new devices and applications.A diagram of the system architecture can be seen below.

Figure 1 The BodyBlogger Software Architecture

Shiverpool Tour

We had opted for the Hope Street tour which takes you from the Philharmonic pub on Hope Street (Liverpool, UK)  to the Metropolitan Cathedral and then finally down to the graveyard at Liverpool Cathedral. Along the way the spirit guide stops at a number of supernatural related landmarks to describe their gory past. The tour takes about an hour to complete and covers a mile of walkway. For our tour we wired up 5 people in our group (of ca. 15) with a wireless heart monitor to see how they would react to the horrors that would unfold on the tour. I was using the The Body Blogger platform to run data collection with a few minor adjustments such as a mobile broadband dongle to live stream the event to my newly minted Pachube account. Of late I’ve been experimenting with Pachube, a real-time data visualisation service to stream my vitals in finer detail but I’ll talk more about that on at a later date. This time I wouldn’t be wearing a heart monitor,  instead I would be carrying the base station collecting everyone’s data and making sure everything runs smoothly.  The weather was calm and we had a clear night sky with the moon out. After the tour finished we headed out to a nearby restaurant with the system still running , this was to be used as a comparison data-set to the tour data.

So how indeed, did the heart monitors perform on the night?

Packet Analysis

Well as I mentioned earlier on, things didn’t exactly go to plan. Packet loss was nearly 50% for all 5 sensors on a recording of 1 hr and 20 mins. While the formation of the group was highly mutable with everyone constantly moving around the receiver I was hoping that the lack of surrounding walls or material would allow the sensors to work effectively within the relatively small space the wearers were clustered around the base sation. However this was not the case as can be seen in the below performance table.

Wireless Packets Heartbeat Rate (BPM)
Label Receiver ID Recv % Loss Avg TOR Max TOR Min Max Avg
S05 10522 2699 49.39 6.32 158 81 128 100.31
S03 10559 2734 48.73 5.94 190 64 111 73.78
S04 10615 2703 49.32 6.2 161 58 87 71
S06 10624 2785 47.78 6.26 205 70 112 90.16
S02 11342 2593 51.38 6.73 187 70 118 85.74

Table 1 Sensor Performance During Shiverpool Tour (TOR – Time out of Range)

The majority of the data loss occurred when the group was on the move, which was when we were being funneled in a straight line down the walkway. This can be seen in the received packet graph below. You can see that whenever data loss begins en-mass everybody’s heart rate increases and when the data comes back heart rate decreases. This behaviour is characteristic of a group moving from a stationary position to a moving one and vice versa. While there are many variables which may of caused data loss to be so high (which we obviously didn’t control for) I would imagine that being funneled into a straight line over a space of 10-30 meters didn’t help (e.g. transmitters need perfect alignment with their receiving  antenna for the strongest signal at long distances, which we wouldn’t of had).

Figure 2 Shiverpool Tour – Received Packets (Click to expand to full size)

By comparison, packet loss during the evening meal was 8% over the course of 2 hrs 20 mins. This is artificially high as the data set I’m using for analysis includes a few minutes of travel time from outside the restaurant, this of  which you can see in the raw data graph below. During the meal everyone was seated within a radius of 0-10 meters of the base station. Packet loss was probably closer to 1% in this situation; the stats in this dataset were actually being used for something else so if anyone is interested in the true loss rate I can calculate the numbers later on.

Wireless Packets Heartbeat Rate (BPM)
Label Receiver ID Recv % Loss Avg TOR Max TOR Min Max Avg
S05 10522 8562 8.26 0.66 42 83 122 98.06
S03 10559 8633 7.50 0.61 92 62 104 71.47
S04 10615 8537 8.53 0.73 68 56 93 68.17
S06 10624 8568 8.20 0.63 33 71 108 89.13
S02 11342 8652 7.30 0.61 111 73 112 86.94

Table 2 Sensor Performance During Evening Meal (TOR – Time out of Range)

Figure 3 Dinner – Received Packets (Click to expand to full size)

Group Analysis

My original plan for analysing the Shiverpool tour was to provide a commentary on individual physiological responses in comparison to the groups. However with 50% of the data set missing this can’t be done so I’m only going to provide a commentary on the group. In order to do this I’m going to convert everyone’s raw data to a percentage change over a baseline recording which will be averaged out over the group. This will in effect highlight any action the group takes as a whole. As we didn’t take a “proper” baseline being the event was supposed to be more fun than experiment, I’ve used 5 minutes of relatively stable activity from the dinner data set (before the food arrived with everyone sat down). Zero on the y-axis in the graphs below would therefore represent an activity similar to that of the baseline, in this case the group sitting down. Positive percentages represent the group with a higher heart rate and negative pecertenages with a lower heart rate.

As the data set is very fragmented, I’m going to average percentage changes over ten second periods (large averages lose resolution, and in this case data points) and will only include a person’s data in the average if >50% of the expected packets are received (i.e. 6).  In the graph below you’ll find 3 scatter plots, each one represents the minimum number of sensors that meet these conditions (e.g. 1-Recv plot shows where only 1 sensor was found to be transmitting 6 packets or more over the current period). As can be seen in the graph for the majority of the tour when data was being received it was being received from all the sensors.

Figure 4 Shiverpool Tour – % Change using “Sitting Baseline” (Click to expand to full size)

Our tour started with a brief ten minute introduction (19:00-19:10) by our spirit guide to Liverpool’s supernatural underbelly outside the Philharmonic pub. For the period, we were standing relatively still, huddled around the guide.  As can be seen in the graph, the group heart rate was 5-10% above the baseline which would be appropriate for the situation (i.e. standing induces a higher heart rate in comparison to sitting). This signal is relatively stable every time the group stops as can be seen at  ca. 19:32-19;35, 19:42-19:45 and 20:00 to 20:15. Every time there is an extended period of data loss you can also see the hallmarks of cardiac acceleration and deceleration before and after data loss begins, indicating the group is moving and stopping respectively. While the current setup I use doesn’t support the automated collection of context (e.g. pictures, audio), something of which we’ll be addressing at a later date, there are 3 items of interest that can be picked out from my own memory of the night.

  • At 19:06 there is a 5% increase in the group’s heart rate which seems out of place compared to any other time the group is standing still. During the introduction, one of our group was teased as part of the performance which generated quite a chuckle from the rest of the group, as such this emotional outburst is highly likely to be the cause of the increase.
  • Between 19:50 and 19:55 the group heart rate decreases below the baseline. Before arriving at the graveyard, the tour stops in front of a long line of benches which the guide allows the group to rest on while he tells the next story. As we’re sitting down its expected that the group heart rate falls to the baseline (which also describes the group sitting down). However it drops 5% below the baseline which is likely a result of the group playing a passive part in the performance. In the baseline sample the group is actively chatting away while they are sitting down, and here they are not which involves less motion and subsquently a lower heart rate by comparison.
  • While we are sitting on the benches the number of transmitters meeting the sample critera drops from 5 to 3. While the transmitters are omnidirectional, signal strength is more effective with direct line of sight between the receiver and transmitter which is illustrated by the poor performance seen here when a mass of bodies line up with the transmitters all facing forwards with the base station parrallel to them.

Figure 5 Dinner – % Change to “Sitting Down” Baseline” (Click to expand to full size)

Finally while the dinner data set is not as interesting as the Shiverpool Tour, there are 2 items of interest which can be picked out.

  • At 21:10 the group heart rate increases by 5% for a few minutes, this was representative of the group eating their starters.
  • At 21:45 the group heart rate increases by 10-15% for a much longer period, this was representative of the group eating their mains.

Final Word

While the heart monitors were not as effective as I hoped in a mobile situation such as this, aggregating data over the group did manage to restore some semblance of the activites carried out during the night. If you have any questions about this post, the hardware we use, the BodyBlogger platform or anything else please use the comments section below. If any of our group from the tour would like to add their own interpretation on the data please send me an e-mail or add a comment below and I’ll integrate it into the post.