Right now we support all the sensors and peripherals that come with the kit. You can also add any 2 pin sensor to your board using the GPIO pins. This information is available in the www.mbientlab.com/docs section.
@samsgates I don't see the device reachable as a heartratesservice device, so if you want something standard GATT, it looks as if the firmware would need to be modded as well.
They might add specific support in the firmware, but I'm not sure what Laura is planning (has not told me).
To do the most standard thing, one would implement the Bluetooth SIG's HeartRate service and one or more of its characteristics. This would be what would be expected under the Bluetooth LE GATT spec
If one did that, the firmware would have to know where the sensor was going to be connected to the MetaWear, or use a command (through the writable COMMAND characteristic under the METAWEAR service) to change the I/O input it is expected on. For best compatibility, there would need to be a default location for the sensor that "just works", so that no "non-standard" setup would be necessary.
If the HeartRate stuff is implemented per the spec, then currently-existing HeartRate programs could just work.
Another way (which isn't standard, and would rule out use by any "standard" HeartRate client software) would be to Create a Register for it, like everything else and drive the output through notify_1 notifiable characteristic
{here I'm assuming you're familiar with the device API's posted on GitHub}.
Now that I've said something wrong, Laura or Eric will correct me!
IMHO, that's a cool sensor, but not for people who want a low power solution. The design's problem is that it uses an illumination LED to light up the skin and another device to see the fluctuations of light when the blood is pumped.
Neat idea, but not a low-power solution, as the illumination LED is just strapped across from VCC to gnd which will cause AT LEAST 10mA if not 20mA of drain.
Did anybody create a hack for the pulse sensor mentioned by Laura on September 4th? I need one so I can test it with an iOS app.
If anyone can create a hack by today at midnight eastern time I'd pay $200. If it's tomorrow by midnight eastern I'd pay $100.
The spec for the hack is to be able to add the pulse sensor to an iOS app to measure heart rate and to set a sampling rate of between 1 second and 30 seconds with a sample duration between 1 and 30 seconds. If not sampling then the HRM "rests". The deliverable is software that lets us plug and play an HRM.
I'm an ME not EE so excuse the extremely light spec. If anyone has any questions please message me here.
Laura, I'm trying to hook up the heart rate monitor and our programmer is gone. Is the Xcode metawear hack you did for the base metawear online for download?
Comments
@samsgates I don't see the device reachable as a heartratesservice device, so if you want something standard GATT, it looks as if the firmware would need to be modded as well.
Looking here:
https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.service.heart_rate.xml
Laura may correct me on that.
-e
They might add specific support in the firmware, but I'm not sure what Laura is planning (has not told me).
To do the most standard thing, one would implement the Bluetooth SIG's HeartRate service and one or more of its characteristics. This would be what would be expected under the Bluetooth LE GATT spec
If one did that, the firmware would have to know where the sensor was going to be connected to the MetaWear, or use a command (through the writable COMMAND characteristic under the METAWEAR service) to change the I/O input it is expected on. For best compatibility, there would need to be a default location for the sensor that "just works", so that no "non-standard" setup would be necessary.
If the HeartRate stuff is implemented per the spec, then currently-existing HeartRate programs could just work.
Another way (which isn't standard, and would rule out use by any "standard" HeartRate client software) would be to Create a Register for it, like everything else and drive the output through notify_1 notifiable characteristic
{here I'm assuming you're familiar with the device API's posted on GitHub}.
Now that I've said something wrong, Laura or Eric will correct me!
-e
IMHO, that's a cool sensor, but not for people who want a low power solution. The design's problem is that it uses an illumination LED to light up the skin and another device to see the fluctuations of light when the blood is pumped.
Neat idea, but not a low-power solution, as the illumination LED is just strapped across from VCC to gnd which will cause AT LEAST 10mA if not 20mA of drain.
We can do better....
-e