Bluetooth Implementation

[horseshoe7]

This is my first CoreBluetooth project (iOS/OSX) and I've been implementing the BT LE spec provided by Concept2.

With Bluetooth, one can ask to be notified about properties changing, or request their current state immediately, if I've understood that correctly.

If I ask to be notified about characteristics (for example the General Status 0x0031), it seems it just gets sent at a specific rate (which can also be specified via 0x0034).

Which means that when I want to be notified when a specific state changes, (say workout state, which is part of the data payload of the general status characteristic), I would have to continually be parsing this characteristic's data then generating events for each changing property inside that payload if it has changed from one timestamp to the next? Would it then make sense to set a higher refresh rate?

I guess this is a sort of best practices question. How did the firmware developers intend for us to work with Bluetooth data?

[dxpack]

For 0x0031, 0x0032 and 0x0033 you could change the sample rate via 0x0034.
You could subscribe then unsubscribe at your leisure/based on an internal timer (effectively providing longer refresh rates than 0x0034).
You could subscribe then unsubscribe after receiving the very next notification (providing on demand notification).

Other characteristics such as 0x0035, 0x0036 (stroke), 0x0037, 0x0038 (interval) only notify when intermediate data has been updated (i.e. after each stroke or interval) and 0x0039 and 0x003A (workout summary) are only triggered once after a workout is finished (actually, the spec says those last 2 could be triggered a second time 1 minute later if an HRM is active to allow capture of a Recovery Heart Rate value - but I haven't tested that).

The data delivered in the 3 General characteristics are mainly progress information pertaining to a workout. I can't speak for the firmware developers, but I'd imagine the intent is to enable a connected device to have access to continually updated workout data, if subscribed. Some data in those characteristics may not change over the course of a workout, and if you don't need any of the other data in that characteristic you can unsubscribe after collecting the data you do need.

Note though, that delivery of notifications for those 3 characteristics does not appear to be exclusive to intermediate updates - once you subscribe you will receive notifications at the rate set in 0x0034 even when none of the notification values have changed (for example, before the rower wheel moves).

I think best practices in this case are dependent on what you want to accomplish.

[horseshoe7]

thanks dxpack! That gives me some food for thought.

I'm trying to accomplish an "SDK" of sorts, which means it's general enough to accommodate hopefully a lot of users. I want to abstract away the bluetooth implementation and make it easy and fun to work with the Concept2 PM5. My hope is that not every new app requires a coder to do their own implementation of boring low-level stuff each time.

[Piboo]

Thank too for the details !! Very useful.

One other question: I'm trying to define the distance on my iPhone and to display it on the PM5 like doing 2000m. I want to set it up on the PM5 and start the decreasing of the distance.

On which adress must I have to write ?
How to write data from iPhone to PM5 in SWIFT ?

Thank you for your help

Regards

[dxpack]

In order to set programs such as distance you'll need to write to Bluetooth characteristic 0x0021 with valid CSAFE commands. CSAFE commands applicable to the PM5 are described in the Concept2 PM Communication Interface Definition document, which is available in the Concept2 SDK: http://www.concept2.com/service/softwar ... opment-kit

I would characterize issuing CSAFE via Bluetooth as non-trivial, and there may be bugs in the current PM5 firmware (version 19), see: http://www.c2forum.com/viewtopic.php?f=16&t=93541