Understanding BLE characteristic values for cycle power measurement 0x2A63 - bluetooth

I am currently using Dart/Flutter BLE plugin to better understand BLE devices.
Plugin:
https://pub.dartlang.org/packages/flutter_blue
When I connect to my virtual cycle trainer I select the 0x1818 service and then I subscribe to the 0x2A63 characteristic for Cycle Power Measurement.
I am struggling to align the response list I get with the GATT documentation for this service/characteristics below. There is 18 values in this list, however there is only 17 in the GATTS list. Also the values don't seem to make any sense.
I also tried to convert the first two values '52','24' to a 16 bit binary to see if that aligns with the flags for the first field, but the result was the below which again makes no sense.
0x3418 = 11010000011000
https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.cycling_power_measurement.xml
This screenshot is when I first connect to the trainer.
This screenshot is when I am cycling lightly on the bike
This screenshot is when I stop cycling but the pedals and wheel are still turning.
The cycle trainer is the Cycleops Magnus, which doesn't have the Cycle Speed Cadence service 1816, but can provide virtual speed based on power.
My Question is this:
Which of the values in the list corresponding with the GATTS
characteristics and bonus question is, how would I infer speed or
cadence from the values in this service?

Based on section 3.55 of the Bluetooth GATT specs:
DEC - [52,24,40,0,58,29,59,0,0,0,107,136,23, 0,214, 81, 1,0]
BIT - 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Flag field = 24,52 (bit0 and bit1)
2452 = 00001001 10010100
section 3.55.2.1
the corresponding (1) equates to
- bit2 = Accumulated Torque Present
- bit4 = Wheel Revolution Data Present
- bit7 = Extreme Torque Magnitudes Present
- bit8 = Extreme Angles Present
- bit11 = Accumulated Energy Present
Then from section 3.55.2, you go down the list of bits based on the flags:
Instant Power is bits2 (40) and bit3 (0)
(Dec) 0040 == 00000000 00101000 == 40w
to decipher the rest of the bits, we then have to refer to the flags field since the remaining bits after the flags field and instant power have to depend on what the flags field says that the trainer is supporting.
Based on bit2 of the flags field which says that "Accumulated Torque Present" (
Present if bit 2 of Flags field set to 1) Hence the next 2 bits represents Accumulated Torque
Dec (2958)
The next data would then be based on bit4 of the flags field - Wheel Rev Data Present (Present if bit 4 of Flags field set to 1). This is wheel speed which would translate into speed once you taken into account wheel circumference. For Wheel Rev Data, this is represented by the next 6 bits.
Cumulative Wheel Revolutions - 4 bits
Last Wheel Event Time - 2 bits
like you mentioned, this trainer does not offer cadence service, hence that's why you do not see the flags field (bit5) to be 1. Hence you cannot infer cadence from this data set.
For Wheel speed, you would then decode the data from the 6 bits based on Cum Wheel Rev and Last Wheel Event Time. I can't offer you code on how to decode the 6 bits as you're using flutter and I've no experience in flutter language. (I do Swift) but can likely take a look at this code from GoldenCheetah and convert accordingly.
BT40Device::getWheelRpm(QDataStream& ds)
{
quint32 wheelrevs;
quint16 wheeltime;
ds >> wheelrevs;
ds >> wheeltime;
double rpm = 0.0;
if(!prevWheelStaleness) {
quint16 time = wheeltime - prevWheelTime;
quint32 revs = wheelrevs - prevWheelRevs;
// Power sensor uses 1/2048 second time base and CSC sensor 1/1024
if (time) rpm = (has_power ? 2048 : 1024)*60*revs / double(time);
}
else prevWheelStaleness = false;
prevWheelRevs = wheelrevs;
prevWheelTime = wheeltime;
dynamic_cast<BT40Controller*>(parent)->setWheelRpm(rpm);
}

Related

Bluetooth Low Energy Weight Measurement Characteristic Timestamps

I'm buffering data when my device is not connected so I need to implement timestamps so I can tell what was measured when.
fortunately the weight measurement characteristic includes a timestamp.
unfortunately it's not clear how to write this data to the package since it's not a normal data type, and it's surely not just a single byte.
https://www.bluetooth.com/wp-content/uploads/Sitecore-Media-Library/Gatt/Xml/Characteristics/org.bluetooth.characteristic.weight_measurement.xml
I'm using Adafruit's bluefruit arduino library, so I've tried just ignoring the schema and writing a unix timestamp after the SI weight but unsurprisingly it seems like the schema is not allowing that so I'm not seeing the timestamp when I receive the notifications (but i'm still seeing the correct weight readings)
Here's the link for the date_time characteristic, which is apparently the format it expects
https://www.bluetooth.com/wp-content/uploads/Sitecore-Media-Library/Gatt/Xml/Characteristics/org.bluetooth.characteristic.date_time.xml
I tried looking a bit in the nRF52 SDK so see if this is perhaps handled better through their API but the learning curve is a bit steep and I just need to finish this last bit to make my device work.
Update:
For anyone else with this issue the solution turned out to be that I was using the notify method the same way as it's written in the adafruit example
wmc.notify(notification, sizeof(notification))
because I was indexing through an N x 7 array of buffered data however notification is a pointer to the first element in the 1 x 7 array i was going to feed, so sizeof was always returning 4 (the size of the address I assume) instead of the length of the array originally written which was 7
The weight_scale service has two manadatory characteristics:
<Characteristic type="org.bluetooth.characteristic.weight_scale_feature" name="Weight Scale Feature">
<Requirement>Mandatory</Requirement>
<Characteristic type="org.bluetooth.characteristic.weight_measurement" name="Weight Measurement">
<Requirement>Mandatory</Requirement>
In the weight_measurement characteristic (uuid="2A9D"), the first byte is flags. Where <Bit index="1" size="1" name="Time stamp present"> needs to be 1 to say there will be a "Time Stamp" field. That "Time Stamp" field will be:
<Field name="Year"> <Format>uint16</Format> = 2 bytes
<Field name="Month"> <Format>uint8</Format> = 1 byte
<Field name="Day"> <Format>uint8</Format> = 1 byte
<Field name="Hours"> <Format>uint8</Format> = 1 byte
<Field name="Minutes"> <Format>uint8</Format> = 1 byte
<Field name="Seconds"> <Format>uint8</Format> = 1 byte
This makes the "Time Stamp" field 7 bytes wide.
To give a worked example of how to create the full packet if you wanted weight (in Kg) and a time stamp it will need to 10 bytes long:
<Field name="Flags"> <Format>8bit</Format> = 1 byte
<Field name="Weight - SI "> <Format>uint16</Format> = 2 bytes
<Field name="Time Stamp"> = 7 bytes
I've used Python to calculate the value of a packet:
import struct
flags = 0b00000010 # Include time. SI units
weight_raw = 38.1 # Weight of 38.1 Kg
weight = int((weight_raw/5)*1000) # Formula from XML
year = 1972
month = 12
day = 11
hour = 23
minute = 22
second = 8
packet = struct.pack('<BHHBBBBB', flags, weight, year, month, day, hour, minute, second)
print(packet)
Which would give a packet of 10 bytes long:
b'\x02\xc4\x1d\xb4\x07\x0c\x0b\x17\x16\x08'

Parsing heterogenous data from a text file in Python

I am trying to parse raw data results from a text file into an organised tuple but having trouble getting it right.
My raw data from the textfile looks something like this:
Episode Cumulative Results
EpisodeXD0281119
Date collected21/10/2019
Time collected10:00
Real time PCR for M. tuberculosis (Xpert MTB/Rif Ultra):
PCR result Mycobacterium tuberculosis complex NOT detected
Bacterial Culture:
Bottle: Type FAN Aerobic Plus
Result No growth after 5 days
EpisodeST32423457
Date collected23/02/2019
Time collected09:00
Gram Stain:
Neutrophils Occasional
Gram positive bacilli Moderate (2+)
Gram negative bacilli Numerous (3+)
Gram negative cocci Moderate (2+)
EpisodeST23423457
Date collected23/02/2019
Time collected09:00
Bacterial Culture:
A heavy growth of
1) Klebsiella pneumoniae subsp pneumoniae (KLEPP)
ensure that this organism does not spread in the ward/unit.
A heavy growth of
2) Enterococcus species (ENCSP)
Antibiotic/Culture KLEPP ENCSP
Trimethoprim-sulfam R
Ampicillin / Amoxic R S
Amoxicillin-clavula R
Ciprofloxacin R
Cefuroxime (Parente R
Cefuroxime (Oral) R
Cefotaxime / Ceftri R
Ceftazidime R
Cefepime R
Gentamicin S
Piperacillin/tazoba R
Ertapenem R
Imipenem S
Meropenem R
S - Sensitive ; I - Intermediate ; R - Resistant ; SDD - Sensitive Dose Dependant
Comment for organism KLEPP:
** Please note: this is a carbapenem-RESISTANT organism. Although some
carbapenems may appear susceptible in vitro, these agents should NOT be used as
MONOTHERAPY in the treatment of this patient. **
Please isolate this patient and practice strict contact precautions. Please
inform Infection Prevention and Control as contact screening might be
indicated.
For further advice on the treatment of this isolate, please contact.
The currently available laboratory methods for performing colistin
susceptibility results are unreliable and may not predict clinical outcome.
Based on published data and clinical experience, colistin is a suitable
therapeutic alternative for carbapenem resistant Acinetobacter spp, as well as
carbapenem resistant Enterobacteriaceae. If colistin is clinically indicated,
please carefully assess clinical response.
EpisodeST234234057
Date collected23/02/2019
Time collected09:00
Authorised by xxxx on 27/02/2019 at 10:35
MIC by E-test:
Organism Klebsiella pneumoniae (KLEPN)
Antibiotic Meropenem
MIC corrected 4 ug/mL
MIC interpretation Resistant
Antibiotic Imipenem
MIC corrected 1 ug/mL
MIC interpretation Sensitive
Antibiotic Ertapenem
MIC corrected 2 ug/mL
MIC interpretation Resistant
EpisodeST23423493
Date collected18/02/2019
Time collected03:15
Potassium 4.4 mmol/L 3.5 - 5.1
EpisodeST45445293
Date collected18/02/2019
Time collected03:15
Creatinine 32 L umol/L 49 - 90
eGFR (MDRD formula) >60 mL/min/1.73 m2
Creatinine 28 L umol/L 49 - 90
eGFR (MDRD formula) >60 mL/min/1.73 m2
Essentially the pattern is that ALL information starts with a unique EPISODE NUMBER and follows with a DATE and TIME and then the result of whatever test. This is the pattern throughout.
What I am trying to parse into my tuple is the date, time, name of the test and the result - whatever it might be. I have the following code:
with open(filename) as f:
data = f.read()
data = data.splitlines()
DS = namedtuple('DS', 'date time name value')
parsed = list()
idx_date = [i for i, r in enumerate(data) if r.strip().startswith('Date')]
for start, stop in zip(idx_date[:-1], idx_date[1:]):
chunk = data[start:stop]
date = time = name = value = None
for row in chunk:
if not row: continue
row = row.strip()
if row.startswith('Episode'): continue
if row.startswith('Date'):
_, date = row.split()
date = date.replace('collected', '')
elif row.startswith('Time'):
_, time = row.split()
time = time.replace('collected', '')
else:
name, value, *_ = row.split()
print (name)
parsed.append(DS(date, time, name, value))
print(parsed)
My error is that I am unable to find a way to parse the heterogeneity of the test RESULT in a way that I can use later, for example for the tuple DS ('DS', 'date time name value'):
DATE = 21/10/2019
TIME = 10:00
NAME = Real time PCR for M tuberculosis or Potassium
RESULT = Negative or 4.7
Any advice appreciated. I have hit a brick wall.

My Pressure Sensor Wont Output the Full Range of Values, Using a Raspberry Pi 3 and Python3

I have devised a circuit in which I am getting a pressure reading from a Dwyer 616kd-11-v Transducer with a Range of 0-500Pa, I am powering this with a 5v Power Supply and it shares a common ground to the Raspberry Pi. My ADC converter is a 16 Bit ADS1115 By Texas Instruments. I have connected the transducer and I am getting a reading which is similar to that I am getting on another External Airflow Pressure meter.
The problem is as soon as the Pressure reaches 324Pa or more the Reading in my Python Shell freezes at 324 and does not change until the value has dropped below 324Pa. The Transducer has a range of upto 500Pa meaning it should be able to read upto this value?
I will attach the code I use for this below and will include my basic circuit connections.
Full Code:
import time
import board
import busio
from adafruit_ads1x15.single_ended import ADS1115
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
Transducer = 17
GPIO.setup(Transducer,GPIO.IN)
i2c = busio.I2C(board.SCL,board.SDA)
adc = ADS1115(i2c)
while True:
r0 = adc[0].value
r1 = adc[1].value
ADC_Value = r0*0.01525878906
input_value = GPIO.input(Transducer)
time.sleep(0.5)
print("GPIO17: ", (input_value))
print("AIO: ", (r0))
print("AI1: ", (r1))
print("Pressure: ",(ADC_Value),"Pa")
Connections
the Vdd of the ADC converter has a 0.1uF capacitor with one end to GND and other end to Vdd.
Thanks!!
From the datasheet (http://www.dwyer-inst.com/PDF_files/P_616KD.pdf) it looks like the supply voltage should be 16-36V DC.
I think this will give you a 0-10V output under your current set-up. If you want a 0-5V output, you should connect the output pins 3 and 4 together. You need to make sure you can measure this voltage range on the ADS1115. The default range is only +-4.096V, so you will need to set the gain to its lower settings to read up to +5V.

Linux ALSA Driver using channel count 3

Am running my ALSA Driver on Ubuntu 14.04, 64bit, 3.16.0-30-generic Kernel.
Hardware is proprietary hardware, hence cant give much details.
Following is the existing driver implementation:
Driver is provided sample format, sample rate, channel_count as input via module parameter. (Due to requirements need to provide inputs via module parameters)
Initial snd_pcm_hardware structure for playback path.
#define DEFAULT_PERIOD_SIZE (4096)
#define DEFAULT_NO_OF_PERIODS (1024)
static struct snd_pcm_hardware xxx_playback =
{
.info = SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_SYNC_START,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
.rates = (SNDRV_PCM_RATE_8000 | \
SNDRV_PCM_RATE_16000 | \
SNDRV_PCM_RATE_48000 | \
SNDRV_PCM_RATE_96000),
.rate_min = 8000,
.rate_max = 96000,
.channels_min = 1,
.channels_max = 1,
.buffer_bytes_max = (DEFAULT_PERIOD_SIZE * DEFAULT_NO_OF_PERIODS),
.period_bytes_min = DEFAULT_PERIOD_SIZE,
.period_bytes_max = DEFAULT_PERIOD_SIZE,
.periods_min = DEFAULT_NO_OF_PERIODS,
.periods_max = DEFAULT_NO_OF_PERIODS,
};
Similar values for captures side snd_pcm_hardware structure.
Please, note that the following below values are replaced in playback open entry point, based on the current audio test configuration:
(user provides audio format, audio rate, ch count via module parameters as inputs to the driver, which are refilled in snd_pcm_hardware structure)
xxx_playback.formats = user_format_input
xxx_playback.rates = xxx_playback.rate_min, xxx_playback.rate_max = user_sample_rate_input
xxx_playback.channels_min = xxx_playback.channels_max = user_channel_input
Similarly values are re-filled for capture snd_pcm_hardware structure in capture open entry point.
Hardware is configured for clocks based on channel_count, format, sample_rate and driver registers successfully with ALSA layer
Found aplay/arecord working fine for channel_count = 1 or 2 or 4
During aplay/arecord, in driver when "runtime->channels" value is checked, it reflects the channel_count configured, which sounds correct to me.
Record data matches with played, since its a loop back test.
But when i use channel_count = 3, Both aplay or arecord reports
"Broken configuration for this PCM: no configurations available"!! for a wave file with channel_count '3'
ex: Playing WAVE './xxx.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 3
ALSA lib pcm_params.c:2162:(snd1_pcm_hw_refine_slave) Slave PCM not usable
aplay: set_params:1204: Broken configuration for this PCM: no configurations available
With Following changes I was able to move ahead a bit:
.........................
Method1:
Driver is provided channel_count '3' as input via module parameter
Modified Driver to fill snd_pcm_hardware structure as payback->channels_min = 2 & playback->channels_min = 3; Similar values for capture path
aplay/arecord reports as 'channel count not available', though the wave file in use has 3 channels
ex: aplay -D hw:CARD=xxx,DEV=0 ./xxx.wav Playing WAVE './xxx.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 3
aplay: set_params:1239: Channels count non available
Tried aplay/arecord with plughw, and aplay/arecord moved ahead
arecord -D plughw:CARD=xxx,DEV=0 -d 3 -f S16_LE -r 48000 -c 3 ./xxx_rec0.wav
aplay -D plughw:CARD=xxx,DEV=0 ./xxx.wav
Recording WAVE './xxx_rec0.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 3
Playing WAVE './xxx.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 3
End of Test
During aplay/arecord, In driver when "runtime->channels" value is checked it returns value 2!!! But played wavefile has ch count 3...
When data in recorded file is checked its all silence
.........................
Method2:
Driver is provided channel_count '3' as input via module parameter
Modified Driver to fill snd_pcm_hardware structure as playback->channels_min = 3 & playback->channels_min = 4; Similar values for capture path
aplay/arecord reports as 'channel count not available', though the wave file in use has 3 channels
Tried aplay/arecord with plughw, and aplay/arecord moved ahead
During aplay/arecord, In driver when "runtime->channels" value is checked it returns value 4!!! But played wavefile has ch count 3...
When data in recorded file is checked its all silence
.........................
So from above observations, the runtime->channels is either 2 or 4, but never 3 channels was used by alsa stack though requested. When used Plughw, alsa is converting data to run under 2 or 4 channel.
Can anyone help why am unable to use channel count 3.
Will provide more information if needed.
Thanks in Advance.
A period (and the entire buffer) must contain an integral number of frames, i.e., you cannot have partial frames.
With three channels, one frame has six bytes. The fixed period size (4096) is not divisible by six without remainder.
Thanks CL.
I used period size 4092 for this particular test case with channel count 3, and was able to do loop back successfully (without using plughw).
One last question, when I used plughw earlier, and when runtime->channels was either 2 or 4, why was the recorded data not showing?

RaspBerry pi B rev2 - Issue while sampling a LM335 (temp. sensor) thru a MCP3208 ADC via SPI in Python 3

I tried to interface a RaspBerry pi with a LM335 temperature sensor this week-end. I'm using a MCP 3208 micro controller (channel 0) to interface the sensor. My goal is to collect samples data in SPI mode with python 3 scripts (classes).
I've checked the wiring and everything seems OK for me, I'but I'am a beginner, not really aware of Electronic concepts.
On the software side , I've installed quick2wire that claims to be python 3 compatible. In fact I want to lead the micro-controller with Python 3 API's (not thru shell calls)
Components
Raspberry pi REV2 model B with Rasbian-wheezy / Quick2wire installed. /dev/spix.y devices are listed.
MCP3208 ADC : 12 bits ADC / SPI. I'm using CS0 from the GPIO. The sensor is connected to channel 0 (B). see datasheet.
LM335 : temperature sensor. Outputs 10mV / °K. Min 5muA / Max 5 mA. It's connected to the MCP3208 channel #0 (A). see datasheet
220 ohms resistor (C). set up regarding LM335 outputs and desired temperature range coverage with my own calculations : May be a problem ...
Schematics extract
The LM335 (zener diode like) is connected as :
Wiring
Components are wired as shown bellow. Note that the yellow link is connected behind the cobbler kit on the CS0 SPI channel.
Quick2wire
I use the bellow script to query the CS0/Channel 0 GPIO interface. Unfortunately, I've not found usefull informations on the quick2wire-python-api API's. I've just copy/paste an example found as it was written in the same goal. I'm not sure if it really works :
#!/usr/bin/env python3
from quick2wire.spi import *
import sys, time
try:
channel = int(sys.argv[1])
except:
channel = 0
MCP3208 = SPIDevice(channel, 0)
while True:
try:
response = MCP3208.transaction(writing_bytes(0x41, 0x13), reading(1))
print ("output = %i" % ord(response[0]))
time.sleep(1)
except KeyboardInterrupt:
break
The script outputs :
output = 0
output = 0
output = 0
output = 0
output = 0
....
The result is the same with the channel 1 ( with argv = 1)
As the MCP3208 Din (probe output) receives voltage (see bellow) quick2wire should read at 18°C (rawghly my home inside temperature today)
3,3 V / 2^12 = 805 muA as I understand as "digital step"
18°C + 273°C = 291 => 2,91 V on the micro controller Din pin
and then return 2 910 / 0.805 = 3 615
Am I wrong ?
Controls
I've no oscilloscope, the only measures I can read are :
Voltage is 2.529 V at B checkpoint and 0,5 V (+/-5%) on the other MCP3208 channels
Note : the adjust pin is not used on the LM335 so results way not be accurate but voltage is here !
Seems to be a problem on the quick2wire side I think. But which ?
Code
The quick2wire.spi.SPIDevice class lakes of détails on the transfers parameter in terms of structure, content and output response format.
def transaction(self, *transfers):
"""
Perform an SPI I/O transaction.
Arguments:
*transfers -- SPI transfer requests created by one of the reading,
writing, writing_bytes, duplex or duplex_bytes
functions.
Returns: a list of byte sequences, one for each read or duplex
operation performed.
"""
transfer_count = len(transfers)
ioctl_arg = (spi_ioc_transfer*transfer_count)()
# populate array from transfers
for i, transfer in enumerate(transfers):
ioctl_arg[i] = transfers[i].to_spi_ioc_transfer()
ioctl(self.fd, SPI_IOC_MESSAGE(transfer_count), addressof(ioctl_arg))
return [transfer.to_read_bytes() for t in transfers if t.has_read_buf]
Another question :
how to set SPI configuration values like mode, clock speed, bits per word, LSB ... and so on.
Thanks in advance for your help.
I know you probably intend to learn how to use the ADC, an so this isn't really an answer to your question (I will use your very rich post for sure - thanks), but I'm aware of temperature sensors that already pack data in GPIO serial line, that are best suited for the raspberry.
You really have to read this awesome tutorial, if you haven't already.

Resources