Adding support for VO2Master Pro

[Erik Botö]

Hi all,

I'm considering adding support for the VO2Master Pro devices to GoldenCheetah. This device can be used to e.g. perform VO2Max tests, and some of those metrics seems standard enough from VO2-measurement equipment that I think it might make sense to support them in Train view and as part of ride files:

- Respiratory Frequency

- Respiratory Minute Volume

- Volume of Oxygen Consumed

- Volume of Carbon Dioxide Produced

Most of this work would be generic and could be useful for other types of VO2-measuring equipement, and then a small part would be support this specific device.

My idea of approaching this would be something like this:

1. Add support for new metrics in RealTime data and make NullController emit dummy values, and of course the rest of the bits and pieces to make it usable during training.

2. Add support for the new metrics in RideFile etc, so it can be written and read etc.

3. Add support for the actual device (it's a BLE device which from a quick look at the BT40* classes looks quite straight-forward to support)

4. Potentially add some configuration options for the device. There's two settings that needs to be set after powering the device, which could be nice to support for GC bit it could also be set from their phone app before connecting from GC.

A few questions I have are:

1. Would adding support for this be welcome?

2. As for the RideFile support, when should something be added as XDATA and when is something added using the regular RideFilePoint?

All feedback is welcome :-)

Cheers,

Erik

[Ale Martinez - No direct email please]

El miércoles, 25 de septiembre de 2019, 15:56:56 (UTC-3), Erik Botö escribió:

Hi all,

I'm considering adding support for the VO2Master Pro devices to GoldenCheetah. This device can be used to e.g. perform VO2Max tests, and some of those metrics seems standard enough from VO2-measurement equipment that I think it might make sense to support them in Train view and as part of ride files:

- Respiratory Frequency

- Respiratory Minute Volume

- Volume of Oxygen Consumed

- Volume of Carbon Dioxide Produced

Most of this work would be generic and could be useful for other types of VO2-measuring equipement, and then a small part would be support this specific device.

My idea of approaching this would be something like this:

1. Add support for new metrics in RealTime data and make NullController emit dummy values, and of course the rest of the bits and pieces to make it usable during training.

2. Add support for the new metrics in RideFile etc, so it can be written and read etc.

3. Add support for the actual device (it's a BLE device which from a quick look at the BT40* classes looks quite straight-forward to support)

4. Potentially add some configuration options for the device. There's two settings that needs to be set after powering the device, which could be nice to support for GC bit it could also be set from their phone app before connecting from GC.

A few questions I have are:

1. Would adding support for this be welcome?

I think so.

 

2. As for the RideFile support, when should something be added as XDATA and when is something added using the regular RideFilePoint?

IMHO to add new data to RideFilePoint should be the exception now, you have to find very good reasons to justify the impact it has over most of the code to be of any utility, this is much easier with XData as it becomes automatically available for User Data, Custom Metrics, R&Python Charts, etc.; and it seems a good fit for data which will be used only in very special cases.

[Erik Botö]

Hi again,

I'm glad XDATA was the way to go, was soo much simpler than trying to add it to RideFilePoint :-)

I've done step 1 & 2 and pushed it to a WIP Pull Request: https://github.com/GoldenCheetah/GoldenCheetah/pull/3173 . Even though this could be merged without step 3-4, I guess it doesn't make sense until there's at least one real way of getting the data from a real device.

Next up is step 3.

Cheers,

Erik

[Karl-Axel Zander Persson]

Great initiative! I'm happy to help test this if needed when you manage to complete task #3

[Erik Botö]

Small update of progress:

Initial read-only support is implemented. This means that the device has to be configured using their own app prior to connecting to GC, since it doesn't remember setting between power cycles.

There are two different protocol version depending on the device firmware, both should be supported but only the older one has been tested with a real device (thanks to Karl-Axel).

It still hasn't seen much testing, just minor tests to see that it records values.

Next on my list is to solve device configuration from GC. I'm not sure what way is best, but I think a pop-up that opens when the device is connected that show current configuration and also allows you to change it prior to starting the data collection should be enough and not be intrusive changes to the device concept in general.

I might get access to a new device for testing, which would allow me to iterate a bit faster during development, and also allow me to do a lot more testing.

Cheers,

Erik

[Erik Botö]

Hi again,

So it's starting to look fairly complete now, I've got access to a device now to do proper testing myself.

I cleaned it up some, rebased on top of current master and updated the PR: https://github.com/GoldenCheetah/GoldenCheetah/pull/3173

I've implemented configuration of, and detailed logging from, the device using a separate window that opens once it's detected and connected. There the different settings can be configured, and a detailed log from the device can be viewed and saved to file.

Cheers,

Erik

[Erik Botö]

Hi,

I feel this is ready for review/merging now. If there's any feedback, feel free to leave a review or comment on the PR.

Cheers,

Erik

[Ivor Hewitt]

Apologies for bumping up an ancient thread.... but I noted the comment about on the "old protocol" had been tested so wanted to check/find out if the new protocol was actually working?

I'm asking because I've been playing with (and having great fun with) a DIY VO2 device (https://github.com/ihewitt/VO2max) for a few years and have just updated the code to work with both GoldenCheetah and the VO2Master app... however, using the multipliers in the GC code for the ANT messages I've noticed that I have to multiply the vo2 value by 100 to work with the VO2 master app (but obviously values are then out by 100 for GC). Hence curious who's currently using this feature, and if they are running with the new protocol.

Cheers

Ivor

[Erik Botö]

Hi Ivor,

First of all, what a cool project!

You mention the ANT-protocol, but I guess you mean the BLE-protocol?

I'm not really using the VO2Master that much with GoldenCheetah at the
moment, and I still only have the same unit as when I added the
support so I can't speak for any newer versions of the hardware. My
unit uses the "new protocol", which means it's using the "Gas Exchange
Char" and not the legacy "Data Char", but since my unit doesn't
actually support CO2 measurements VCO2 and FeCO2 is always set to 0.

In the protocol description description I have VO2 is sent as a uint16
(mL/min) both in the "Gas Exchange Char" and the "Data Char", so there
shouldn't be a scaling difference. But, given that I haven't had a
unit using the "Data Char" there is of course a possibility that the
docs I got for that char was wrong, and that there is indeed a factor
100 missing somewhere in the implementation.

If you could point to exactly which bytes in which characteristic you
are having issue with I could check again with the docs I.

Cheers,
Erik

> --
> You received this message because you are subscribed to a topic in the Google Groups "golden-cheetah-developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/golden-cheetah-developers/Z1ELkSlhBYY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to golden-cheetah-dev...@googlegroups.com.
> To view this discussion, visit https://groups.google.com/d/msgid/golden-cheetah-developers/074b7230-705d-4045-95b0-4c5c19230091n%40googlegroups.com.

[Erik Botö]

Hi again,

I had a quick look at your implementation, and it looks like you send
the value normalized to body weight but it should be an absolute value
(mL/min). Perhaps this can explain what you are seeing, and that you
think it works ok in GC because you interpret the value as ml/min/kg
there?

Cheers,
Erik

[Ivor Hewitt]

Just noticed I hadn't replied-all from my phone! 🤦 adding mailing list back, and typing a bit more.

Just wanted to say "doh", many thanks for spotting that! That was indeed the mistake, I'd seen mL/min/kg on the vo2master app GUI and assumed those were the units, not that it was expecting the non-normalised data. and as you say I was reading the GC value as ml/min/kg.
Superb, it's working well now, although I'm currently "full of cold" so can't get a workout done to show the GoldenCheetah data.

In a few days(ish), I'll get some graphs saved and show what it looks like now.

Cheers

Ivor