Separate bluetooth services into different BT-devices

[gerokleindienst]

Hello,

first of all I would like to thank you for the marvelous work on this project. I am new to Indoor-Rowing and use it primarily as a supplement to running, as I hope to establish a consistent Zone-2-Training in the right HF-Zone easier on teh rower than with running and have a sort of core-training included the same way.

Installation of ORM was really easy and after successfully configuring my rower (with some interesting trials and errors on the way; i will write down some information on this in a separate post later), it works like a charm, with stable stroke detection and plausible metrics in general, which accidentally correspond quite well to the data on the monitor delivered with the rower (Focus Fitness Row6). I found that a little suspicious, as the general notion is, that apart from concept2 monitors, the metrics can not considered trustworthy in general.

I used a Polar Vantage M for running and upgraded to a Vantage V3 last week. With respect to connectivity, they behave equal.
What I found interesting is, that both watches do recognize the original rownig computer, which communctaes with te FTMS-Service, but do no process any data from it. Both watches do not recognize the two FTMS-Services and the PM5 services from ORM. I find that fact intersting as at least the FTMS-Service is standardized and thus on the aquisition level the data packages should be processed equally in general.

I also tested the CSC and CPS profiles on the ORM with my polar watch. Both services are recognized and can each be paired to the watch. As polar does apparently not support external sensor data for its "Indoor Rowing"-profile, Using the bike service wouls be a feasible workaround.
With the "Indoor Bike"-profile on my polar watch (with tire-diameter 10 mm configured) and CSC-Profile on ORM, the cadence is shown and saved on the watch. But the speed is not available, neither the distance as it is propably calculated from speed and elapsed time.
With the CPS-Profile on ORM, the watch shows power and cadence, which is usefull already as the distance can be manually added later. Although it would be nice, if speed and distance could be recorded as well.

I wondered, if the polar watch explicitly expects one BT-client with a cadence-service only and a separate BT-client with a speed-service as the manual only describes the pairing with their own somewhat outdated Polar speed and candence sensors. For other listed, supported devices, which are also somehow outdated, I did not find any information, if they transmit as a combined (speed and and cadence) sensor as one single BT-device or if each service is transmitted by an individual BT-device. From my point of view it would not make any sence with respect to the BT specification, as it explicitly describes a CSC-Service (Cycling speed AND cadence) and not a specified speed service and another differently specified cadence service. This is actually the question that bothers me most, as I do not understand, if Polar does no abide to the standards in general or does have additional requirements on device specific data, like manufacturer ids etc., which would be really awfull!

If my thoughts about this "problem" are correct, do you think, it would be possible and easy to establish a supplementary Profile, which offers two BT Services at once and can be configured with different names (ORM Power, ORM Speed). The ORM will currently be paired with different service descriptions for the CSC and CPS profiles of ORM but is stored as paired with "openrowingmonitor" for both on them. As a result, switching profiles on ORM does not result in different data aquisition on the watch but the client will not be found at all because it is propably internally stored with the mores specific descriptor of the service which it was paired with. Thus it is not possible to switch profiles before unpairing the openrowingmontor-device for the CSC-Profile and pairing it again with the CPS-Profile on ORM.

I would guess that this could generate more CPU load on the raspberry, so that data aquisition and processing might become unstable or tacky. Thus the easier way, without additional development effort, could be a second raspberry, where the BT-device name can be changed to something else than "openrowingmonitor" and the CSC-Service is truncated to transmit the speed (and distance?) only, hoping that the watch does process the speed data, as no other data is present.

I described my findings on the incosistency of FTMS connectibility and compatbility and the incomplete data for the CSC-Service and asked for additionl information, so that one could e.g implement an emulator/converter, which gathers different BT-Service data as a server and provides the data with as different clients. So far on my first less detailed request, Polar recommende to contact the manufacturer of the third-party-sensor. But as the original Focus Fitness computer does communicate well with e.g. kinomap and the implementation of ORM does obey to the BT-Specifications, I do not know, what can be done about the unsatisfying findings concerning the Polar BLE-Connectivity without further information, how the watch does process the BLE data.

Sure, Polar watches aim mainly on runners, and as some of them do triathlon, they support cycling and also swimming, while ambitious cyclist would prefer different products. But as the specifications für BLE-services are clear, I cannot see any real reason for not implementing the support for FTMS measurement services (although the controll point service would be nice for power testing on treatmills) and also implement the UUID 2AD1 for rowing data as long as the according software RAM is not so packed, that these few lines of code are technically not feasible.

To put it short: Does anyone have an idea, how this issue can be solved?

Regards,

Gero

PS: I have already created accounts for intervals.icu and rowsandall.com and try to get aquqinted with those sites, so that I do not rely on the unfortunatelly closed PloarFlow-World if necessary. But I got accustomed with it for quite a while and found it easy to use and well arranged....

[Abasz]

You are asking and stating a lot of things, and to be fair I dont fully understand a lot of these. I assume this is because you dont understand the different BLE Profiles.

So lets break things down

CPS and SCS and FTMS all are standards and Polar implements them correctly as well as orm. But the first two require wheel circumference the later is fully self sufficient.

All three include distance and cadence as data.

in addition to that CPS and FMTS includes power

in addition to that FTMS includes pace as a standalone data item, )but CPS and CSC has all information that is necessary for the watch to calculate pace).

In CPS and CSC distance is calculated from the rotation of bicycle wheel. Of course rowers do not have one, but these profiles require setting the wheel circumference to work properly. The data needed for distance calculation is manipulated artificially in the BLE package in a way that if you set the wheel circumference to 10mm, the correct distance is rerecorded.

So the question is whether you have set the wheel circumference when using CPS or CSC?

do you think, it would be possible and easy to establish a supplementary Profile, which offers two BT Services at once and can be configured with different names (ORM Power, ORM Speed).

Anything is possible, but this is pointless. This is not how CPS and CSC works. CPS can be considered an extension of CSC as it includes power data in addition to the data to CSC already has (technically CPS has more but from ORM perspective this is the difference)

What is important is that on watches allow different profiles to connect for different activities. For instance garmin only alows CPS and CSC on Cycling activities for BLE (i.e. nothing gets recorded if you select rower). Garmin does not support FTMS.

We provide two FTMS profiles: one is rower the other is Bike

So I suppose (but I dont have Polar watch) that you need to select the correct profile for the correct activity. If you select rowing I suppose you should use FTMS Rower, if you select bike you should use FTMS Bike.

PM5 mode is not supported by Polar. its a specific protocol. Polar can connect to PM5 of the Concept 2 rower erg via FTMS or ANT+ FE.

[Abasz]

Thanks for the detailed logs, please send me also your config.js file.

I have checked the logs and you indeed have power, speed and distance, etc data so your config seem to work. Data for CSC and CPS only updated once per stroke. In between it sends the same data every second.

Can you please start ORM in CSC mode, replay one of your test data via the replay feature and connect NRF and observe if here the data (wheel rev and time etc.) increases?

If NRF receives the data properly its the watch if not, there are different routes we can take to debug the issue.

[gerokleindienst]

Hello and a Happy New Year,

please excuse for not responding for a long time. I was quite distracted during the last months and did not manage to follow any of my different "projects" at all.

Meanwhile I bought an additional Raspi4 and a display and installed ORM 0.9.6 on it (Signal conversion by DST-1R4P-P 24V-3.3V). It worked fine with the previous config.js from the 0.9.6 installation. But it shows the same results on my watch (Power and cadence are shown with plausible values, Distance and speed is not present).

I kept the ORM 0.9.5 on the Raspi3 and connected it with a different optocoupler-module parallel to the rowers output signal. Thus I can compare the raw measurements between both slightly different setups. What I found is, that the ORM 0.9.6 on the Raspi3 with the different 1-channel optocoupler-module (https://www.amazon.de/dp/B0B79CX5GG?, optocoupler: PC817. Vin= 3.6 - 30 V, Vout=3,3 V), did not work immediately with the existing config.js and strokes were not detected. Although the recorded raw data from the same row from the 0.9.6 and 0.9.5 matched quite precisely, I had to adjust minimumStrokeQuality: 0.35 for stroke detection. For comparison on the 0.9.6 I get reliable and plausible stroke detection with minimumStrokeQuality: 0.8!

Due to this changes, I could not replay the raw data of the row I sent you earlier on the exactly same setup.

Thus I replayed the raw data 2025-06-02 on the current installation and configuration of 0.9.5 and recorded the BLE data for CPS and CSC and also with my Polar Vantage V3 (see attachment 2025-06-02.zip).

For comparison I recorded a shorter row (2026-01-05.zip).

As ORM is further developed with the changed BLE implementation, is it still worth finding the cause, that the number of revolutions and revolution time is somehow apparently not correctly updated within ORM as there are some singular small speed and distance measurements on my watch for low flywheel speeds?

One further finding I made is that the power value does not change when I stop rowing. For the raw data 2026-05-01 this results in a power value of 182 W recorded by my watch as long it collects data. Probably because the power value is not updated as no further stroke is detected at the final spindown of the flywheel. I currently have no idea, under which conditions the power value could be set to zero at the end of a row. Maybe the calculated power could drop exponentially with a time constant of 1-3 minrecoverytime after the last drive?

BLE behaviour on 0.9.6

When I first installed ORM 0.9.6 I was not able to connect my Polar V3 with it. The watch "saw" the sensor as advertised but did not connect to ORM. For some reason (no updates or config-changes). My watch connected to the server of ORM 0.9.6 with additional information of the service .. (CPS) oder (CSC) which is a nice advantage compared to the identical name in 0.9.5.

I configured

ftmsBikePeripheralName: 'OpenBike 0.9.6',
ftmsRowerPeripheralName: 'OpenRower 0.9.6'

When I connect to CSC, the sensor is registered as "OpenRower 0.9.6 (CPS) "

When I connect to CPS, the sensor is announced as "OpenRower 0.9.6 (CPS) 1F1BB" and registered as "undefined (CPS)" in the list of connected sensors. This seems odd.

Although I can connect both type of "sensors" when starting a training session, I get the message that no sensor was found. Therefore I cannot check, if the distance data might be received and evaluated correctly.

CPS data format

I have one further question. I tried to get as much information from specs and the ORM source code, how the CPS data is structured in each data packet to decode the data recorded by nRF. Meanwhile I think I understood it to decode the data.

At the beginning of each message is the feature flag and for CPS bit 4 and bit 5 are set TRUE (wheelRevolutionDataPresent: (0x01 << 4), crankRevolutionDataPresent: (0x01 << 5 in CpsMeasurementCharacteristic.js).

in the buffer builder of CpsMeasurementCharacteristic.js (Line 70) the feature flag is written with

bufferBuilder.writeUInt16LE(cpsMeasurementFeaturesFlags.wheelRevolutionDataPresent | cpsMeasurementFeaturesFlags.crankRevolutionDataPresent)

So the feature flag is 16 bits long?

Looking at the nRF-data the first four digits of the HEX-output is 3000, comprising 16 bits. As the data is defined as little endian, the first two digits 30hex represent the first byte and with 30hex = 110000bin it would fit the available features, as bit 4 and bit 5 are set. The last two digits represent the second byte, which is always zero for the given feature. (Meanwhile I found, that I have to evaluate the Feature flag considering it little endian and could decode it accordingly)

The next data block of 16 bits is for power. The first two digits in the 2026-01-05 data range from 00hex to B600hex, which corresponds to integer values of power up to 182 (as mentioned above). Thus as long power does not exceed 256 W, the last two bits are always zero. (Also here I could get consistent results when decoding the HEX-Value considering little endian byte structure)

The next data block of 32 bits contains the integrated number of revolutions. As I did further analysis of the data recorded with nRF i think I found the problem with the data transmitted via bluetooth:

The CPS-Specification requires total number of wheel revolutions in the UInt32LE data field. According to the ORM documentation, the wheel circumference should be set to 10 mm.

The CPSMeasurementCharakteristic.js contains the following line (75-76):

 // Wheel revolution count (basically the distance in cm)
      bufferBuilder.writeUInt32LE(data.totalLinearDistance > 0 ? Math.round(Math.round(data.totalLinearDistance * 100)) : 0)

When data.totalLinearDistance is in meters, multiplying it with 100 gives totalLinearDistance [cm]

The total distance travelled by a wheel is

totalLinearDistance [m] = n_total_revolutions * wheel_circumference [m]

which gives

n_total_revolutions = totalLinearDistance [m] / wheel_circumference [m]

equivalent to

n_total_revolutions = totalLinearDistance [cm] / wheel_circumference [cm]

n_total_revolutions = totalLinearDistance [m] *100 / wheel_circumference [cm]

thus with a configured wheel circumference of 10 mm = 1 cm, the data field is correctly implemented in CPSMeasurementCharakteristic.js and the correct number of revolutions should be transmitted via bluetooth and evaluated by my watch. But for some reason it does not.

But when I configure the wheel circumference in my watch to 100 * 10mm = 1000 mm and remove the factor 100 in

 // Wheel revolution count (basically the distance in cm)
      bufferBuilder.writeUInt32LE(data.totalLinearDistance > 0 ? Math.round(Math.round(data.totalLinearDistance * 1)) : 0)

then my watch shows an incrementing Distance which is plausible to the output in the journal log and the corresponding rowingData.csv.

So I solved a part of the problem for my case, although I do not understand, why I get plausible results with the adapted code but not for the original implementation which should give equal results for a circumference of 10 mm.
I also found, that the Speed calculated by my watch is not stable. It toggles between plausible values and Zero.

I hope this can contribute a bit to the development of ORM.

Best regards

Gero

ORM_0.9.5_2026-01-05.tar.gz
ORM_0.9.5_2025-06-02.tar.gz

[JaapvanEkris]

Although the recorded raw data from the same row from the 0.9.6 and 0.9.5 matched quite precisely, I had to adjust minimumStrokeQuality: 0.35 for stroke detection. For comparison on the 0.9.6 I get reliable and plausible stroke detection with minimumStrokeQuality: 0.8!

Please do not choke the algorithm. minimumStrokeQuality is intended just to prevent noise from triggering a stroke transition. The lesser you can get away with, the better. This is because you actually want the recovery slope to trigger the stroke phase transition, not its goodness of fit. We need the goodness of fit to prevent noise in the algorithm to accidentally trigger the transition, but that is about it. When set too high, it can block stroke detection permanently, making an entire session in one stroke. Our testing shows that this happens at lower dragfactors, so please take this into account.

In all honesty, there is no reason for this difference: when I look at the release notes and the underpinning change logs, nothing has changed in the engine, aside a single bugfix (drive and recovery related metrics were averaged too much).

Changing minimumStrokeQuality can have effects on stroke detection (obviously), which affects the recovery length, and thus the drag calculation, and thus linear distance. So changing that from one instance to another requires some consideration.

This is why for every rowing engine change we run a complete retest (around 1000 sessions, a total of 12.000 km of rowing) against the known result of a PM5. We want to get closer to those results, and any new formal release achieves that goal (at least as close, or closer to the PM5 across all sessions). Sometimes this does require a recallibration of the parameters used (like is the case with 0.9.7 which has a significant engine upgrade, reducing noise from 1.5% to 0.05%).

As ORM is further developed with the changed BLE implementation, is it still worth finding the cause, that the number of revolutions and revolution time is somehow apparently not correctly updated within ORM as there are some singular small speed and distance measurements on my watch for low flywheel speeds?

@Abasz developed this, so I have no extremely deep understanding of the algorithm used. But it isn't a simple approach. By far the simpelest approach is to basically trigger a report every centimeter. On most machines, our data is granular enough to do this. However, as a boat and flywheel speed vary a lot across the stroke, and the watch calculates its own speed, tricks are needed to communicate speed well without a JoJo effect. That is essentially what adds a lot of complexity.

One further finding I made is that the power value does not change when I stop rowing.

In the main engine this is by design and it depends on the situation. When you cross a finish in a planned session, the engine will keep reporting the last known value. In an unplanned stop, it will report 0 for power and speed. However, the BLE CPS/CSC simulators must do their own math as their reporting structure is extremely limited, so behaviour might be different.

[gerokleindienst]

Thank you for your explanation. I really did misunderstand the meaning of the parameter minimumStrokeQuality .

I made an interesting finding: I have currently two versions of ORM running. ORM 0.9.5 on a RPi3 and ORM 0.9.6 on a RPi4.
Last June I configured ORM 0.9.5 on the RPi3 with the recommended opto-coupler DST-1R4P-P (24V-3.3V) with very satisfying results. Later I installed ORM 0.9.6 on the RPi4 with this DST-1R4P-P and got similar data with the same configuration from the 0.9.5 installation (which one would expect). As the DST-1R4P-P was in use (and it needs more space than fits in a regular Raspi-Case) I attached the Rpi3 with ORM 0.9.5 parallel to the RasPi4 with ORM 0.9.6 on the signal line with a different (and much cheaper opto-coupler).

What I found was, that with the cheap opto-coupler and the existing and working configuration, I did not get plausible results and had to change the configuration especially with regard to minimumStrokeQuality . Then ORM gave back plausible data again.
During my latest "experiment" last weekend, I also replaced the DST-1R4P-P connected to the Raspi4 with the ORM 0.9.6 installation with the "cheaper" opto-coupler. And as a result, the calculated rowing data were not completely plausible again. With your information, that minimumStrokeQuality should be set as low as possible, I got all strokes detected, but drive length and Power were not in the expected range. Also the raw data seems to be much noisier than with the DST-1R4P-P. The main reason I changed the opto-coupler was, that it would fit in the Raspi-Case....

So my preliminary conclusion is, that the type of opto-coupler seems to have a significant influence on the data acquisition and later processing.

[JaapvanEkris]

So my preliminary conclusion is, that the type of opto-coupler seems to have a significant influence on the data acquisition and later processing.

Yeah. Cheaper optocouplers are often rated for a lower frequency, thus they might actually miss signals. Also the DST-1R4P-P triggers around 12V based on its component specs, allowing some margin to a 15V signal. Other components might cross over differently, making it less reliable.

[Abasz]

When I connect to CSC, the sensor is registered as "OpenRower 0.9.6 (CPS) "

When I connect to CPS, the sensor is announced as "OpenRower 0.9.6 (CPS) 1F1BB" and registered as "undefined (CPS)" in the list of connected sensors. This seems odd.

Although I can connect both type of "sensors" when starting a training session, I get the message that no sensor was found. Therefore I cannot check, if the distance data might be received and evaluated correctly.

Do you clear the previous sensor? You see the MAC of the device is the same. So if not, is well possible that Polar does not able to handle different sensors with the same MAC (which is totally realistic because I cannot just simply do this on my Garmin either I even have to restart the device before connecting to the new type).

on you other question. I am not 100% understand what is that your asking or stating. Can you please summarise it or make more specific what is that you are asking or saying?

But to also provide some information: As I said, the profiles are as per the spec. The sizes of the data, the bytes and bits and their places, the flags all of it. They are all in line with the spec. I have another project ESP Rowing Monitor, I use the same logic (though in c++). I have a web GUI for that where I do the inverse, i.e. translate these to metrics. They are on spec.

What you need to understand (and probably this would be clear for you if you read the BLE specifications for each sport profile properly) is that CPS and CSC behaves differently from FTMS.

This is because the former 2 does not report absolute values. and it does not report speed. Everything needs to be calculated on the client side. Further more, these two profiles do not have a concept of "distance" they only count revolution (crank and wheel). To be able to report distance properly I had to apply a trick where I translate distance to revolution (actually every centimetre is sent as one wheel revolution) so that is why you have to set the wheel circumference to 10mm. Now, the way centrals calculate speed for these profiles is that they check the delta distance (received wheel rev * wheel circumference) and the delta time and they can calculate the speed for that period.

The above also means that these watches are free to calculate distance the way they want (please see this issue: Abasz/ESPRowingMonitor#25) as there is no distance data in CSC and CPS we are just mimicking it by tricking the device. they may apply interpolation or what ever like Garmin.

In addition to the above, BLE broadcasts every second (this is totally fine from a BLE Spec perspective) but it broadcast the last stroke data until a new stroke comes in. This is necessary because unlike in FTMS which has a pace field (which we can choose to update whenever), CSC and CPS does not and if we update distance mid stroke we will have spikes (during the drive's second higher speed during the recovery's second lower speed, you can see a picture of this on the issue I linked).

But the point is that the reason we are able to get away with this is due to the fact that every decent company that implements CSC and CPS I have seen, disregards packets with the same data for a bit of time (e.g. Garmin does it for approx. 4 seconds) before triggering recalculation of previous vs. current distance and setting the speed/pace to zero. It is possible that Polar is not among these but I would be rather surprised because this issue has never been reported in the past 2 years. But to be transparent I never my self tested Polar because I dont have one.

You are referring to a data filed: is this official Polar or something that is from their ? Are you using Polar's built in native activity (sport profile) to start the session? Is it cycling or rowing? why are you not using FTMS as I think Polar supports that and it is superior compared to the other (which only exist because Garmin does not support FTMS at all....)

[gerokleindienst]

Thank you for your answer!

Unfortunately my browser froze, while I was tyipng and I extracted the last lines from an emergency-picture....

My first statement was false due to mistyping and everything seems to be fine with CSC:

When I connect to CSC, the sensor is registered as "OpenRower 0.9.6 (CSC) "

It will be implemented as a sensor in the training session "cycling" a the watch shows plausible values for cadence (but not for speed).

When I try connect to CPS, the sensor is found with the name "OpenRower 0.9.6 (CPS) 1F1BB" and after it is connected, it is registered as "undefined (CPS)" in the list of connected sensors. It will not be implemented in the training session "cycling" and the watch shows the error message that no power sensor/meter is available and no speed and cadence sensor is available. I tried this after removing "OpenRower 0.9.6 (CSC)" from the list of connected devices and also restarted/rebooted my watch. I wonder, why my watch sets the sensors name to "undefined" as the BLE data capture with NRF does contain all information according to the CPS specification.

As I said, the profiles are as per the spec.

Absolutely! I checked the data that was human readable in nRF and evaluated the power-, revolution-, cadence- and time-data send by BLE. And it was in accordance to the specification and contained the values that ORM calculated.

as there is no distance data in CSC and CPS we are just mimicking it by tricking the device

I understand this and it makes absolutely sense. Therefore I suspect my polar watch to cut off revolution data that might be not considered plausible for bike revolutions, although the wheel circumference can be set down to a minimum value of 10 mm.
I sent a request to polar whether any cut-off values are used for the differences between to reported n_wheel-values if they are not considered plausible for bicycles (as the change in subsequent values in n_wheels range from ~300 to 1200 rpm in my measurements, which might be considered as not plausible for cycling revolutions.

You are referring to a data filed: is this official Polar or something that is from their ?

The data named _Polar is downloaded from the PolarFlow Website, where the data from the watch is uploaded, can be analyzed and on demand be downloaded.

Are you using Polar's built in native activity (sport profile) to start the session?
Is it cycling or rowing?

The sports profile "indoor rowing" does not connect to any sensor. I asked Polar support about it and they said this is not supposed to work.
I use the "cycling" sports profile. Here my watch connects (for ORM 0.9.5 only in my case) to CSC and shows cadence, but no speed or distance. I does also connect to CPS and does show Power and cadence; but it does show distance and speed only, when I remove the factor of 100 in CPSMeasurementCharakteristic.js and the wheel circumference in my watch to 1000 mm as stated above:

// Wheel revolution count (basically the distance in cm)
      bufferBuilder.writeUInt32LE(data.totalLinearDistance > 0 ? Math.round(Math.round(data.totalLinearDistance * 100)) : 0)

why are you not using FTMS as I think Polar supports that and it is superior compared to the other (which only exist because Garmin does not support FTMS at all....)

I also contacted polar support on this question and git the answer, that it is not implemented:

Die Vantage V3 ist kompatibel und funktioniert nachweislich mit dem iPhone, dem Polar H10 und Stryd. Leider ist es mit diesem FMTS nicht implementiert oder getestet.

This is quite interesting as FTMS is implemented more and more in fitness machines and it would be a valuable function to retrieve speed and tilt from a treatmill or adjust its speed from the watch with respect to the implemented "running test" as this would give more consistent results compared to trying to run in the different required speed ranges for the running test outdoor. Or setting a training sequence for an indoor bike or a treatmill on the watch.

Best regards

Gero

<Edit: pictures of watch display added>

[Abasz]

OOOOHHHH this little bugger :) I found the issue.

openrowingmonitor/app/peripherals/ble/cps/CpsControlPointCharacteristic.js

Line 31 in 940489d

uuid: 0x2A55,

@gerokleindienst I must thank you for pushing this. Apparently we are not fully on spec.

"Support for this characteristic is mandatory if the Server supports Wheel Revolution Data or Multiple Sensor Locations features [...]"

This is a copy paste error from years ago. Basically I did not update the Control Point UUID from the CSC to the CPS specific when I made the changes...

I will create a fix shortly with everything. The only thing I cannot fix directly is the upstream error. I meant that repo is not very active so fix is questionable :)

@JaapvanEkris What I could do is that I create a fork of the ble-host repo make the changes submit a PR and while we wait we reference this fork repo in the package.json. If my changes get merged we can switch back.

[gerokleindienst]

@Abasz Thank you for your effort!

I could not reply in time, that the suggested changes in node_modules/ble-host/lib/internal/gatt.js did not improve anything.
Instead it caused the following behaviour: my watch recognized the BLE service either as ORM 1F1BB which lead to the error message, that it could not be paired. Or it was recognized as ORM (CPS) 1F1BB which paired (and afterwards was listed as undefined (CPS) as before). So maybe it works as it is with the fixed UUID within CpsControlPointCharacteristic.js.

Unfortunatelly I did not find the 2A66/2A55 difference earlier when comparing 0.9.5 and 0.9.6...

[Abasz]

I will create a separate branch for this with all the changes necessary and share the link so you can test that like a fresh start :)

The fact is that there is a bug. May be it is not the solution to the Polar issue but nevertheless its still wrong :D

[JaapvanEkris]

@JaapvanEkris What I could do is that I create a fork of the ble-host repo make the changes submit a PR and while we wait we reference this fork repo in the package.json. If my changes get merged we can switch back.

The Package list is far from frozen yet, and the engine and PM5 still undergo testing. We'll decide in a couple of weeks, hopefully somebody is still awake on their side and we can pick up the functioning version directly.

[gerokleindienst]

@Abasz I set node_modules/ble-host/lib/internal/gatt.js back to its original settings and changed uuid: 0x2A55 to uuid: 0x2A66 in CpsControlPointCharacteristic.js of my current ORM 0.9.6 installation.

As a result, the pairing of the announced ORM (CPS) 1F1BB was really quick (~1 s) and as for ORM 0.9.5 my watch immediately requested to set the wheel circumference (to 10 mm as I did not change the distance factor of 100 in the code in 0.9.6).
When starting a indoor cycling training session, the red bicycle icon (indicating the search for the sensor) lights up and after a few seconds changes to blue (indicating the sensor is connected). After the latest firmware update of my watch it also displays a overlay window which states undefined (CPS) - Open connection to this sensor after starting the actual training session and returns to the training session display. So the correction of the UUID did already improve things a lot as the connection and transmission of data generally works 👍

edit: Also the power drops to 0 after the last stroke, which was not the case in 0.9.5 :-)

There is only the "cosmetic issue" left, that the device name of CPS is still undefined (CPS).

And the fact, that the distance factor of 100 does not seem to work for polar devices, which we agreed to has its causes very ilkely in some filtering on the site of polar. I am curious if an what they will answer on my support request concerning the observation I made. Although it is reasonable to filter out unplausible values, it would be nice to know what the criteria are an why.
At ~100 W I have n_rev ~500 and t_rev ~ 2 s. With a circumference of 10 mm this would yield plausible distance and speed calculations. But it would be understandable if the polar algorithm already filters out high revolution differences according to an assumed "plausible" circumference of ~ 1000 mm for average bike wheels, as a revolution difference of ~500 would translate to a speed of 2600 m/s (which corresponds to ~15 W rowing power in my settings) up to more than 10.000 m/s ( ~100 W rowing power in my settings). I would assume that they implemented that kind of assumed filter not because of the BLE data but to filter out data spikes that origin from the sensors data acquisition as they do not want to be bothered with noisy data which lies in the responsibility of a third party manufacturer.

I am happy that I could contribute identifying a bug and will follow the development of ORM further, not only considering this actual issue. I realized that some interesting developments are going on for the next releases. As my time allows (@Abasz mentioned the wife acceptance factor...) I would be happy to contribute to current developments. As I mentioned, I am not a skilled programmer, but I used to do a lot of advanced data analysis earlier at university and was involved in controls engineering based on systems theory later. If I find anything I can contribute to or have look on, I would be happy to do so, as I think this is a outstanding project for the indoor rowing community and both of you contributed with a remarkable effort to keep ORM going on the progressing state of the Raspberry OS (and its underlying libraries) and improved its reliability and its function: a big thank you so far for all the work and time you invested so far!!!

[Abasz]

I set node_modules/ble-host/lib/internal/gatt.js back to its original settings [...] worked

That is very strange and I am not happy about it :)

Can you please add logging to the HciSocket so I can see what packets are being send and received?

This is the file to edit:
node_modules/hci-socket/lib/hci-socket.js

And this is how it should look like (its around the bottom of the page).

	var socket = new native.HciSocket();
	var res = socket.bind(devId, data => {
		if (data instanceof Buffer) {
      console.log('HCI Data:', data); // -> This is the new line
			this.emit('data', data);
		} else {
			this.emit('close');
		}
	});
	if (res < 0) {
		throwError('Could not bind socket hci' + devId, res);
	}

	this.write = function write(data) {
		// If error is returned, then the socket should be be closed soon automatically
    console.log('HCI Write:', data); // -> This is the new line
		return socket.write(data);
	};
	this.close = function close() {
		socket.close();
	};

I would need a comparison between changed and unchanged gatt.js. Always connecting as a fresh sensor and ORM restarted in between so there are no other commands.

So this is the testing flow:

1. Remove sensor from watch
2. Restart watch (2x if possible)
3. Start ORM without connection or search
4. Once ORM loaded search for sensor and connect
5. Wait a bit so all details (like manufacturer name etc.) are loaded in the watch

Then edit gatt.js with the proposed changes and do the same flow. There is no need to start activity. Also if possible dont start simulation on ORM. Set logging for Peripheral: 'debug' in config.js (its default is 'warn' hence the need for change).

you should see something along the lines of this:

CPS Connection established, address: CE:C2:5A:D0:2C:B3
HCI data: <Buffer 04 ff 05 55 00 00 40 00>
HCI write: <Buffer 01 1a 20 12 40 00 3a 52 f7 40 4c 01 7c fc 98 41 81 34 b6 ce 13 6f>
HCI data: <Buffer 04 3e 0d 05 40 00 00 00 00 00 00 00 00 00 00 00>
HCI data: <Buffer 04 0e 06 01 1a 20 00 40 00>
HCI data: <Buffer 04 08 04 00 40 00 01>
HCI write: <Buffer 02 40 00 15 00 11 00 04 00 1b 13 00 30 00 57 00 95 06 00 00 48 2d 02 00 95 13>
HCI data: <Buffer 04 13 05 01 40 00 01 00>
HCI write: <Buffer 02 40 00 15 00 11 00 04 00 1b 13 00 30 00 57 00 95 06 00 00 48 2d 02 00 95 13>
HCI data: <Buffer 04 13 05 01 40 00 01 00>
HCI write: <Buffer 02 40 00 18 00 14 00 04 00 11 06 01 00 08 00 01 18 09 00 0d 00 00 18 0e 00 1b 00 18 18>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 10 01 00 ff ff 00 28>
HCI write: <Buffer 02 40 00 0c 00 08 00 04 00 11 06 1c 00 28 00 0a 18>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 10 1c 00 ff ff 00 28>
HCI write: <Buffer 02 40 00 09 00 05 00 04 00 01 10 29 00 0a>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 10 29 00 ff ff 00 28>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
HCI write: <Buffer 02 40 00 1b 00 17 00 04 00 09 07 1d 00 02 1e 00 24 2a 20 00 02 21 00 25 2a 23 00 02 24 00 28 2a>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 08 1c 00 28 00 03 28>
HCI write: <Buffer 02 40 00 0d 00 09 00 04 00 09 07 26 00 02 27 00 29 2a>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 08 25 00 28 00 03 28>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
HCI write: <Buffer 02 40 00 09 00 05 00 04 00 01 08 28 00 0a>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 08 28 00 28 00 03 28>
HCI write: <Buffer 02 40 00 1b 00 17 00 04 00 09 07 0f 00 02 10 00 65 2a 12 00 10 13 00 63 2a 16 00 02 17 00 5d 2a>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 08 0e 00 1b 00 03 28>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
HCI write: <Buffer 02 40 00 15 00 11 00 04 00 1b 13 00 30 00 57 00 95 06 00 00 48 2d 02 00 95 13>
HCI write: <Buffer 02 40 00 0d 00 09 00 04 00 09 07 19 00 28 1a 00 55 2a>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 08 18 00 1b 00 03 28>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
HCI write: <Buffer 02 40 00 09 00 05 00 04 00 01 08 1b 00 0a>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 08 1b 00 1b 00 03 28>
HCI write: <Buffer 02 40 00 14 00 10 00 04 00 09 07 0a 00 02 0b 00 00 2a 0c 00 02 0d 00 01 2a>
HCI data: <Buffer 02 40 20 0b 00 07 00 04 00 08 09 00 0d 00 03 28>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
HCI write: <Buffer 02 40 00 1a 00 16 00 04 00 05 01 1c 00 00 28 1d 00 03 28 1e 00 24 2a 1f 00 01 29 20 00 03 28>
HCI data: <Buffer 02 40 20 09 00 05 00 04 00 04 1c 00 28 00>
HCI write: <Buffer 02 40 00 1a 00 16 00 04 00 05 01 21 00 25 2a 22 00 01 29 23 00 03 28 24 00 28 2a 25 00 01 29>
HCI data: <Buffer 02 40 20 09 00 05 00 04 00 04 21 00 28 00>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
HCI write: <Buffer 02 40 00 12 00 0e 00 04 00 05 01 26 00 03 28 27 00 29 2a 28 00 01 29>
HCI data: <Buffer 02 40 20 09 00 05 00 04 00 04 26 00 28 00>
HCI write: <Buffer 02 40 00 1a 00 16 00 04 00 05 01 0e 00 00 28 0f 00 03 28 10 00 65 2a 11 00 01 29 12 00 03 28>
HCI data: <Buffer 02 40 20 09 00 05 00 04 00 04 0e 00 1b 00>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
HCI write: <Buffer 02 40 00 1a 00 16 00 04 00 05 01 13 00 63 2a 14 00 01 29 15 00 02 29 16 00 03 28 17 00 5d 2a>
HCI data: <Buffer 02 40 20 09 00 05 00 04 00 04 13 00 1b 00>
HCI write: <Buffer 02 40 00 16 00 12 00 04 00 05 01 18 00 01 29 19 00 03 28 1a 00 55 2a 1b 00 02 29>
HCI data: <Buffer 02 40 20 09 00 05 00 04 00 04 18 00 1b 00>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
HCI write: <Buffer 02 40 00 1a 00 16 00 04 00 05 01 09 00 00 28 0a 00 03 28 0b 00 00 2a 0c 00 03 28 0d 00 01 2a>
HCI data: <Buffer 02 40 20 09 00 05 00 04 00 04 09 00 0d 00>
Static read characteristic has been called: Cycling Power Feature
HCI write: <Buffer 02 40 00 09 00 05 00 04 00 0b 0c 00 00 00>
HCI data: <Buffer 02 40 20 07 00 03 00 04 00 0a 10 00>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
Static read characteristic has been called: Sensor Location
HCI write: <Buffer 02 40 00 06 00 02 00 04 00 0b 00>
HCI data: <Buffer 02 40 20 07 00 03 00 04 00 0a 17 00>
HCI data: <Buffer 04 13 05 01 40 00 02 00>
HCI data: <Buffer 04 3e 0a 03 00 40 00 20 03 00 00 90 01>

[Abasz]

Peripherals: 'debug' exactly like this (i.e. with capital 'P')

It should be in config.js under loglevel:

  loglevel: {
    // The default log level
    default: 'debug',
    Peripherals: 'debug'
  },

Does this log include the watch trying to connect? I think this is just the setup there is no indication of connection. Also they are fully identical which could be good news because it means that changing the 2>>>0 and 16>>>0 to 4 and 18 does not make a difference and should have no impact.

[gerokleindienst]

Thank you for help. rfkill was unknown to me and it solved my problem.

Please find the results of the suggested test protocol attached.

Te ORM CPS-sensor get recognized and is paired with the correct name. listed as such in the list of paired devices and connects in the prestart display immediately 👍

So with your changes my polar watch connects as expected!

fix-ble_peripheral_debug.log

[Abasz]

Very good, thank you too! Few followup questions:

1. You succeed with the changed gatt.js as well right (actually based on the logs for you this should not matter because MTU is over 200 bytes so you should not be affected by that specific upstream bug. This explains the fact that your log is identical in the two scenarios)?
2. Is it bookworm or bullseye?
3. Where do these numbers come from in the name: '8A0822'

The sensor announced as "OpenRower 0.9.7 (CPS) 8A0822", paired/listed as "OpenRower 0.9.7 (CPS) and could be connected.

So basically BLE advertisement has two parts: 1. Classic advertisement 2. scan response
Both have a limit of how many bytes can there be. And longer names do not fit into the normal advertisement so we use two names a shorter that is in the advertised packet and a longer that is technically a scan response. That is why you see two I suspect.

[gerokleindienst]

@Abasz The loglevel was/is set exactly as you quoted.

Yesterday I tried to connect with/without the suggested changes in hci-scocket.js, which does not help. Sorry for confusion.

1. You succeed with the changed gatt.js as well

I just repeated the connection test with/without changes in gatt.js (loglevel still set to 'debug'). See the logs attached:

fix-ble_peripheral_debug_CPS_gatt_unchanged.log
fix-ble_peripheral_debug_CPS_gatt_changed.log

For both cases my watch could pair and connect to ORM. I have not done any measurements yet to check, whether they are positively influenced by the changed gatt.js.

For the changed gatt.js (4/18) I observed, that Two sensors are announced at the same time together:

a) "OpenRower ble-fix (CP 8A0822" , which can be paired and coupled
and
b) "ORM 1F1FBB", which can not be paired.

In my current 0.9.6 installation with the changes in gatt.js to 4/18 the device announced either as a) or as b) but not together and also only a) could be paired, when I remember correctly.

2. Is it bookworm or bullseye?

It is a fresh installation of bookworm.

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian

3. Where do these numbers come from in the name: '8A0822'

I don't know. It is nothing I set in the config or elsewhere. This addition was also new to me when trying to pair in 0.9.6

[Abasz]

Yesterday I tried to connect with/without the suggested changes in hci-scocket.js, which does not help. Sorry for confusion.

Does not help with what??? Does your watch work or not?

You said yesterday: Te ORM CPS-sensor get recognized and is paired with the correct name. listed as such in the list of paired devices and connects in the prestart display immediately 👍

As I said that change I asked (i.e. 2 -> 4 and 16 -> 18) should not affect your watch. It should be irrelevant i.e. it should work regardless of you changing.

The point of this confirmation was to understand whether this change breaks the connection or not.

It is a fresh installation of bookworm.

Thanks I will test bullseye

Two sensors are announced at the same time together

That is strange especially that the names differ. I suspect that the watch caches the connection nevertheless that the sensor has been removed. Though this does not explain the change of that 6 character id. Its may be generated by the watch automatically.

I don't know. It is nothing I set in the config or elsewhere. This addition was also new to me when trying to pair in 0.9.6

I suspect this relates to the mac address of the rpi. but in that case it should not change .

Can you run this command: hciconfig -a and post the output please.

[gerokleindienst]

Can you run this command: hciconfig -a and post the output please.

With the changed gatt.js (2>>4, 16>>18) hciconfig -a gives the following output:

hci0:   Type: Primary  Bus: UART
        BD Address: B8:27:EB:8A:08:22  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING 
        RX bytes:4598989 acl:0 sco:0 events:396 errors:0
        TX bytes:68637 acl:0 sco:0 commands:447 errors:0
        Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
        Link policy: RSWITCH SNIFF 
        Link mode: PERIPHERAL ACCEPT 
        Name: 'rowingmonitor'
Can't read class of device on hci0: Connection timed out (110)

Yesterday I tried to connect with/without the suggested changes in hci-scocket.js, which does not help. Sorry for confusion.

Does not help with what??? Does your watch work or not?

The watch does work. I just mixed up that the changes in hci-scocket.js do only result in more verbose output and that the differences in gatt.js were asked for. I realized that this morning and repeated the pairing for the changed/unchanged gatt.js (2->4 vs. 16->18) and attached the results above. As you said, both variants worked and ORM could be paired. The only difference I noticed (might be irrelevant but might also be confusing) that for the (16->18) variant, the two "sensors" mentioned above were recognized by the watch. The first "OpenRower ble-fix (CP 8A0822" could be paired, was in the list of paired devices in the watch and was successfully connected for a training session. The second "ORM 1F1FBB" could not be paired and resulted in an error message on the watch.

Out of curiosity I just tried to pair again with gatt.js (2->4 vs. 16->18) after removing the device from my watch and got announced "ORM 1F1FBB" as the only device, which could not be paired and resulted in an error message on the watch. Several following trials to pair always offered only the device "ORM 1F1FBB" for pairing.
Then I restarted ORM and in the following pairing-attempt I got announced two sensors again. The first "OpenRower ble-fix (CP 8A0822" could be paired as before.
I cannot evaluate if this is either just a cosmetic problem or might be related to some behavior in the upstream resources, that should be addressed.

As an intermediate result so far it seems that users of Polar watches do not benefit from the suggested changes in gatt.js as with the fixing of the UUID in CpsControlPointCharacteristic.js paring and connection works smoothly and unambigously.
Did you as a Garmin user discover any improvements in connecting your watch to ORM as device with the changed gatt.js ?

Its may be generated by the watch automatically.
The devicename with the postfix "1F1FBB" or "8A0822" appeared with ORM 0.9.6 the first time. In ORM 0.9.5 the device name was announced ans paired always as "openrowingmonitor". So this seems not a watch-specific behavior.

[Abasz]

thanks

Naming

The name is the last 3 byte of the Mac address. This is a polar thing. I suppose this is how they try to help you identify devices (which is funny because an average user does not even know what MAC is not to mention to find it where it is written. any way...) :D

8A:08:22

The second "ORM 1F1FBB" could not be paired and resulted in an error message on the watch.

This is a polar thing, it somehow saves/caches MAC addresses and the original names. This is an interesting behaviour in the sense that ORM allows changing the BLE characteristic and preference would be if Polar would forget the old one. But as I said before, normally sensor do not change their ble profiles (well, magene speed and cycling sensor can but this is rare). This is not an ORM matter purely Polar.

It will not be able to connect to the ORM 1F1FBB because that does not exist. but somehow it associates that device as well as the new name with MAC address and thinks its the same sensor.

This is will not be an issue in general usage as people dont tend to change this frequently anyway. So this working as intended.

The only mystery is why Polar thinks MAC has changed but from ORM perspective that is not relevant. MAC is backed in the firmware so it should not change in general. Any way this is not really relevant and outside of ORM control.

Did you as a Garmin user discover any improvements in connecting your watch to ORM as device with the changed gatt.js ?

Yes that is the only way to connect. Anyway that is a bug on the library side. The calculation of the data capacity is wrong. but with data capacity like Polar that uses 200+ bytes this is not an issue because the data to be sent is 42 bytes so there are no "chunks" everything can be sent at once (as the transfer capacity exceeds the maximum). Garmin uses transfer capacity of 23! so for garmin it does matter if chunk size is calculated incorrectly as it cannot fit 42 bytes in one message.

Thanks for your help. I think this issue is resolved. One bullseye test is waiting for me and then that is it.