Smart trainer control via Bluetooth/FTMS - request for testing

[Ale Martinez]

Eric Boto has contributed this long awaited feature, and he is requesting testers using different trainers.

If you have a Bluetooth/FTMS enabled trainer (most modern units are), you are using GC v3.6 on Windows and want to collaborate, an installer is available from: https://ci.appveyor.com/project/Joern-R/goldencheetah-knhd8/builds/41006793/artifacts

Since this is based on current master it has all the features of last dev build plus new fixes. Only limitation is online services are disabled, but it can be used interchangeably with last dev build.

Feedback can be directed to: 

https://github.com/GoldenCheetah/GoldenCheetah/pull/4045

Thanks in advance, Ale.

[Poncho]

Is testing with a kickr core worthwhile? Or are wahoo trainers using a
different code path?

According to
https://support.wahoofitness.com/hc/en-us/articles/360000217839-KICKR-CORE-Firmware-Updates
the latest firmware should support FTMS

Kind regards,
Poncho

[Ale Martinez]

El martes, 5 de octubre de 2021 a la(s) 04:35:07 UTC-3, Poncho escribió:

Is testing with a kickr core worthwhile?

Yes, I think so

 

Or are wahoo trainers using a
different code path?

GC v3.6 already has support for the kickr specific control  protocol over BTLE and minimally we need to confirm there are no interference when both are available, I don’t know if it is possible to choose one.

[erik...@gmail.com]

I've updated the pull request with a commit that disables the other BLE profiles that support control, so that it's clear that the FTMS implementation is whats being used.

[erik...@gmail.com]

And here's a download link for a windows installer for this pull request: https://ci.appveyor.com/api/buildjobs/a9mjon9bwttcl1ag/artifacts/GoldenCheetah_v3.6-DEV_x64.exe

[erik...@gmail.com]

Small update.

Since some trainers can provide multiple ways of control I have implemented a kind of prioritization so that GC won't try to control a device using multiple ways. So if e.g. Tacx Neo support both FTMS and Tacx own solution, we will only connect to one of them using GC.

The latest version with prioritization solution can be downloaded here (Windows only): https://ci.appveyor.com/api/buildjobs/pn6pi6e0arf1dt5p/artifacts/GoldenCheetah_v3.6-DEV_x64.exe

Here are some use cases I would love for people to test:

- People with FTMS capable Kurt Kinetic trainers testing that everything works (as before), Kurt Kinetic protocol will take prio over FTMS so ideally no changed behavior should be seend

- People with Tacx trainers testing that everything works (as before), Tacx protocol will take prio over FTMS so ideally no changed behavior should be seend

- People with Wahoo trainers that everything works. For Wahoo trainers the new FTMS protocol will be used if available, instead of previous Wahoo-specific protocol.
- People with other FTMS trainers testing that controlling the trainers work

Cheers,

Erik

[Max Ka]

Hi,

I tested the last version with a Elite Suito on Windows along with a HeartRate strap. It worked like a charm!

Thank you for that feature!!

Cheers

Max

[Ale Martinez]

El miércoles, 27 de octubre de 2021 a la(s) 04:10:27 UTC-3, Max Ka escribió:

Hi,

I tested the last version with a Elite Suito on Windows along with a HeartRate strap. It worked like a charm!

Thank you for testing and feedback!

for Wahoo and TACX trainers we have BTLE support via their proprietary protocols (testing would be interesting anyway), but Elite and Saris trainers were missing and Erik contribution fixes this.

[erik...@gmail.com]

Thanks for testing!

The most recent version is available here: https://ci.appveyor.com/api/buildjobs/7c13v20qhcgj1vql/artifacts/GoldenCheetah_v3.6-DEV_x64.exe

The main changes is that if a trainer implements both FTMS and a regular Cycling Power Service the power/cadence will only be read via FTMS, since each device should really just have a single source of power/cadence data.

Cheers,

Erik

[erik...@gmail.com]

Here's the latest version: https://ci.appveyor.com/api/buildjobs/c9lwygvugsyqfnjf/artifacts/GoldenCheetah_v3.6-DEV_x64.exe

Changes since last build is that I've pulled in all other changes done outside or this work, and made sure that Kurt-devices will use their custom Kurt-protocols even if FTMS is supported too. This is done since those devices support calibration via the existing implementation and using FTMS would then remove that function which we don't want to do.

In the future I will probably try to add support for spin down calibration via FTMS, but since I have no device to test with it would have to be another crowd testing thing.

[Manu]

Hi, I tried on a Elite Direto XR-T (same as XR) with windows 10.

I can get Cadence and Power registered on GC, but without Speed. ERG doesn´t work.

Just take this with caution, maybe it´s my fault. Max Ka tested on an Elite Suito and worked well.

Thanks for the good work!!!!

[Max Ka]

Hi Manu, I did not check if ERG works. Did not need this so far...

For me power, cadence and speed works.

[erik...@gmail.com]

Hi!

Sorry for the late reply.

Do you think you could try again and capture some log output? Then maybe I can figure out what is going on. If I recall correctly all you have to do is start via a terminal and pass "--debug" to the binary.

Cheers,

Erik

[erik...@gmail.com]

I have an idea of what it could be, and if I get the log I should be able to easily confirm/deny that hunch. 

-- E

[erik...@gmail.com]

Hello all,

I've made an attempt at implementing the Spin Down Calibration part of the FTMS protocol. If you have a FTMS device which supports this I would really appreciate if you could help me test it, since I don't have any device that supports calibration.

The PR is here: https://github.com/GoldenCheetah/GoldenCheetah/pull/4073

And a Windows build of this PR can be downloaded here:  https://ci.appveyor.com/api/buildjobs/cxbaychm28jv3hi3/artifacts/GoldenCheetah_v3.6-DEV_x64.exe

Since I have never used calibration with any type of device I'd also be happy if anyone could explain how a spin down calibration is shown in the UI. Now I just tried to do what the Kurt Kinetic devices do, but for some parts of it I don't really understand how it's shown to the user.

Cheers,

Erik

[erik...@gmail.com]

And since I never manage to get things right the first time, here's an updated version that actually has a chance of working: https://ci.appveyor.com/api/buildjobs/a6h9wva6dxf8pb7o/artifacts/GoldenCheetah_v3.6-DEV_x64.exe

[Manu]

Hello Erik:

I did as you told.

Tried again and same result, cadence and power, but no speed or ERG.

I send you three files:

- Version.jpg: you can see GC and windows version.

-Log file. the device "Mi Smart Band 5"  is not mine, i suppose it belongs to a neighbour.

- Json file

About calibration, still new to the trainer, maybe in future could help.

hope it helps.

manu

[erik...@gmail.com]

Hi,

Thanks for the log files! It looks like GC find the trainer ok, and sends the commands to set the power target ok. However I am missing some log entries that I would expect to see when the Direto replies to those messages. I'm also missing the initial response to the "request control" message, where GC requests to have control over the trainer. 

But also, when looking at your example activity it's a bit hard to see it it tried to hold the target or not since the cadence is varying so much. With a varying cadence it will be hard for the trainer to hit the power tagets. If you try to hold e.g. 80 RPM steadily, can you then see if the power will settle in around the target power? Just so I don't try to track down an issue that doesn't really exist, even though I find it weird that I'm missing some replies (I'll try to verify how the replies look when I use my device, just as a reference, but I'm pretty sure I see the replies that I expect on that device).

You don't have any other device nearby that might have connected to the device before, and got the "control permissions"?

If you're not used to trainers and how the ERG-mode behaves, maybe you can try some more extremes like first setting it to 50W and then to 200W. That difference should be easy to feel, and won't leave any doubts about if the trainer is reacting to the changes. If you are certain of how the trainer behaves in ERG-mode you can just skip this comment.

Cheers,

Erik

[Manu]

Hi Erik,

Sorry for the delay, hard week.

I did another ride to verify. Same GC version.

I have no any other controllers nearby (no Garmin, no other PC mobile,...) This time it get two or three times to get connected properly but on the ride same as before, no ERG or speed, cadence and power seem to transmit OK, This time i hold 80 RPM and no response.

I use GC with ANT+ and no problem at all works fine.

Send you the logs. Hope it helps.

Manu

[erik...@gmail.com]

Ok, so it's something going wrong with the writing to the bluetooth device on Windows. It works when I develop on linux, but if I download the Windows executable from appveyor it doesn't work. Your seems to be failing silently, but on my windows machine I get an error everytime I try to write to the device. Reading works just fine, which is why it can get cadence and power ok.

So the good new is that I can reproduce it here, so hopefully I can debug it. I just need to get the time to set up a working windows development environment for GC.

Cheers,

Erik

[Mark Liversedge]

On Sunday, 28 November 2021 at 10:50:17 UTC erik...@gmail.com wrote:

So the good new is that I can reproduce it here, so hopefully I can debug it. I just need to get the time to set up a working windows development environment for GC.

Joern published pre-built libs and tools here, it will save you a lot of pain setting up on Windows:

https://github.com/GoldenCheetah/WindowsSDK/releases

Mark

[erik...@gmail.com]

Yes those are nice, I think I even used some newer versions I found by looking at the CI-build last time I did this. 

Turns out I still have a setup already on my laptop since some previous testing with GC on Windows, so now I just need to get to debugging.

Cheers,

Erik

[Ola Göök]

Just joined GC and tried connecting my FTMS capable Abilica Premium UB BT smart trainer and discovered that (power) control seems to work, but realtime data does not. At least nothing is shown in Cadence/Speed/Power.

Thus, I would need to be able to debug a bit. I see in the associated source code from the git patch that there are lots of qDebug() printouts that hopefully end up somewhere... maybe I need to add a flag to the invocation, maybe it just ends up in a file somewhere. I'll dig further while waiting for pointers.

I have some prior knowledge of FTMS and ANT+ as I have recently programmed a Nordic dongle to act as an interface between my Garmin watch (ANT+) and my FTMS capable indoor trainer.

Regards,

/Ola

[Ale Martinez]

El lunes, 21 de noviembre de 2022 a la(s) 12:28:04 UTC-3, ola....@gmail.com escribió:

Just joined GC and tried connecting my FTMS capable Abilica Premium UB BT smart trainer and discovered that (power) control seems to work, but realtime data does not. At least nothing is shown in Cadence/Speed/Power.

Thus, I would need to be able to debug a bit. I see in the associated source code from the git patch that there are lots of qDebug() printouts that hopefully end up somewhere... maybe I need to add a flag to the invocation, maybe it just ends up in a file somewhere. I'll dig further while waiting for pointers.

qDebug goes to goldenchhetah.log, parallel to your athlete’s folders, in release version, or to the launching terminal/console if —debug command line parameter is used.

[Ola Göök]

Indeed. Thanks you for your response.
After some trial and error I managed to build GC myself and added some qDebugs leading to the following conclusion:
There are a few things missing to get my trainer running:
1. A request for control mode 7 (start) has to be added in order for real time data to actually be emitted by the trainer.
2. When receiving the notification data, the first two (flag) bytes indicate what fields are present. This is correctly handled in ftms.cpp, reading speed, but not in BT40Device.cpp where the flag is once again read. Thus, speed is always zero.

Point 1 could possibly be a property of my trainer and not required by the standard but point 2 is a bit surprising as I would expect at least someone to be using the FTMS feature already.

While I'm at it, I am having difficulties in getting the rlv video player running when having a .tts file selected. Does it require speed in order to start the video? Video plays flawlessly if I do not select the tts file.
Also, I am having difficulties in building with vlc support. Is there a guide somewhere? I get problems already when adding the repos:
 sudo add-apt-repository ppa:jonathonf/ffmpeg-4
...yields... <snipp>
(appstreamcli:2110): GLib-CRITICAL **: 22:56:32.484: g_variant_builder_end: assertion '!GVSB(builder)->uniform_item_types || GVSB(builder)->prev_item_type != NULL || g_variant_type_is_definite (GVSB(builder)->type)' failed

(appstreamcli:2110): GLib-CRITICAL **: 22:56:32.484: g_variant_new_variant: assertion 'value != NULL' failed

(appstreamcli:2110): GLib-ERROR **: 22:56:32.484: g_variant_new_parsed: 11-13:invalid GVariant format string
Trace/breakpoint trap (core dumped)
Reading package lists... Done
E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi'
E: Sub-process returned an error code

Any further help appreciated.

Regards,
/Ola

[Ola Göök]

Found it: posting solution here in case someone else has the same problem...
sudo apt-get install --reinstall libappstream4

[Ale Martinez]

El lunes, 21 de noviembre de 2022 a la(s) 18:59:59 UTC-3, ola....@gmail.com escribió:

Indeed. Thanks you for your response.
After some trial and error I managed to build GC myself and added some qDebugs leading to the following conclusion:
There are a few things missing to get my trainer running:
1. A request for control mode 7 (start) has to be added in order for real time data to actually be emitted by the trainer.
2. When receiving the notification data, the first two (flag) bytes indicate what fields are present. This is correctly handled in ftms.cpp, reading speed, but not in BT40Device.cpp where the flag is once again read. Thus, speed is always zero.

Point 1 could possibly be a property of my trainer and not required by the standard but point 2 is a bit surprising as I would expect at least someone to be using the FTMS feature already.

While I'm at it, I am having difficulties in getting the rlv video player running when having a .tts file selected. Does it require speed in order to start the video? Video plays flawlessly if I do not select the tts file.

Yes, off course, the idea of videosync is video advancing at your pace…  you can enable simulate speed from power if you don’t have a speed sensor, also a Robot device is useful for testing.

[Ola Göök]

I now have most things up and running, rlv is playing in correlation with speed input from my FTMS BTLE trainer. Great fun!

However, when trying the included workouts (which are great by the way), the video keeps restarting every 10s or so.

Manual erg and manual slope mode works fine but not the other workouts.

Any idea why?

Regards,

/Ola

[Ale Martinez]

El lunes, 28 de noviembre de 2022 a la(s) 17:11:37 UTC-3, ola....@gmail.com escribió:

I now have most things up and running, rlv is playing in correlation with speed input from my FTMS BTLE trainer. Great fun!

However, when trying the included workouts (which are great by the way), the video keeps restarting every 10s or so.

Which included workouts are you talking about?

 

Manual erg and manual slope mode works fine but not the other workouts.

Any idea why?

This also happens using the Robot device or only when using the FTMS BTLE trainer? 

[Ale Martinez]

I could reproduce this with ERG type workouts and fixed in https://github.com/GoldenCheetah/GoldenCheetah/commit/f947b6bd3167b3f08135e3495e4dd2bdf9051464

Video sync was originally developed for matching CRS (distance-slope) type workouts, the use with ERG type workouts it is not likely too much tested or used.

[Ola Göök]

Indeed. Works perfectly. Nice fix.
Thanks

[Eric Christoffersen]

WRT needing speed for video progress...

There's been some philosophical confusion in the past about where speed comes from. Some argue that we should always trust the speed reported by the machine, and I maintain most will be happiest if speed comes from power and gc's physics model.  The difference matters a lot if you're using a non-smart trainer with power reported by cranks. Is much nicer to worry about a given trainer reporting power correctly, than to worry that power is correct and all trainers implement the same model.

Currently the way speed is obtained is controlled by a 'simulated speed' checkbox. Need to make sure that both paths are tested.

WRT your slope fix. There's a bad legacy habit of encoding format (like CRS) as a shorthand for general functionality or even trainer mode. We should try and move away from it and focus on what the data means, not the mode of the trainer. Ideally 'mode' should get disappeared completely and we ask the workout what it means.

Gradient has two ways to be interpreted. The strict workout mode (as defined by original CRS files) interprets all slopes between points as fixed. The other mode interpolates a smooth altitude curve between points and queries curve for current slope. I've ridden crs both ways and I think both interpretations have merit depending on the workout. Might be someday we add a modifier to crs to specify smooth gradients?

Test for data behavior by asking the source file what its intent is:

ergFile->StrictGradient

Should find that workouts sourced from rlv, gpx, ttx and json set strict gradient to false. Everything else including crs and manual slope mode should have it set to true.

[Ale Martinez]

El martes, 29 de noviembre de 2022 a la(s) 22:46:05 UTC-3, zak...@gmail.com escribió:

WRT needing speed for video progress...

There's been some philosophical confusion in the past about where speed comes from. Some argue that we should always trust the speed reported by the machine, and I maintain most will be happiest if speed comes from power and gc's physics model.  The difference matters a lot if you're using a non-smart trainer with power reported by cranks. Is much nicer to worry about a given trainer reporting power correctly, than to worry that power is correct and all trainers implement the same model.

Currently the way speed is obtained is controlled by a 'simulated speed' checkbox. Need to make sure that both paths are tested.

Agree and I think it is particularly relevant in this case where an ERG type workout is being used with a smart trainer since "wheel" speed is essentially irrelevant: within the limits of regulation, "wheel" speed can be anything you want at the same power.

 

WRT your slope fix. There's a bad legacy habit of encoding format (like CRS) as a shorthand for general functionality or even trainer mode. We should try and move away from it and focus on what the data means, not the mode of the trainer. Ideally 'mode' should get disappeared completely and we ask the workout what it means.

This case was a data problem: for ERG type workouts Duration is time, not distance as the code treated it.

[Eric Christoffersen]

WRT your slope fix. There's a bad legacy habit of encoding format (like CRS) as a shorthand for general functionality or even trainer mode. We should try and move away from it and focus on what the data means, not the mode of the trainer. Ideally 'mode' should get disappeared completely and we ask the workout what it means.

This case was a data problem: for ERG type workouts Duration is time, not distance as the code treated it.

The fix is totally right, just should be habit to create a method to advertise the property (in this case, maybe bool hasDistance() or hasGradient()) from ErgFile instead of testing an ergfile field against CRS. Just style comment.

The case of videosync on a timed workout... its pretty weird case. No gradient means its not so far removed from just playing video at its standard speed. It might be better than staring at a graph but better yet is if power actually caused correct progress against the gradients in the video.

I think core issue is the train ui. I wish UI let us bucket sim-rides as a triple. Today user is free to mix an erg workout with video A and videosync B - which is not useful. If user could create their own 'simride triple' <gpx/tts, video, videosync> then user could be free to also select an erg workout to do while riding the simride, and workout progress would still track users power. SimRide object would also be a great (runtime) place to hang workout parameters for example rabbits.

[Ale Martinez]

El viernes, 2 de diciembre de 2022 a la(s) 19:36:35 UTC-3, zak...@gmail.com escribió:

WRT your slope fix. There's a bad legacy habit of encoding format (like CRS) as a shorthand for general functionality or even trainer mode. We should try and move away from it and focus on what the data means, not the mode of the trainer. Ideally 'mode' should get disappeared completely and we ask the workout what it means.

This case was a data problem: for ERG type workouts Duration is time, not distance as the code treated it.

The fix is totally right, just should be habit to create a method to advertise the property (in this case, maybe bool hasDistance() or hasGradient()) from ErgFile instead of testing an ergfile field against CRS. Just style comment.

I think we have been though this before: when fixing bugs on piece of code I didn't write I prefer to respect the style used by the developer and do the minimum changes for the fix, I think to mix restructuring/reformatting only adds confusion. And we are (very?) near to release now.

The case of videosync on a timed workout... its pretty weird case.

Yes, but users tend to do weird things, IME.

 

No gradient means its not so far removed from just playing video at its standard speed. It might be better than staring at a graph but better yet is if power actually caused correct progress against the gradients in the video.

I think core issue is the train ui. I wish UI let us bucket sim-rides as a triple. Today user is free to mix an erg workout with video A and videosync B - which is not useful. If user could create their own 'simride triple' <gpx/tts, video, videosync> then user could be free to also select an erg workout to do while riding the simride, and workout progress would still track users power. SimRide object would also be a great (runtime) place to hang workout parameters for example rabbits.

 

Agree, it seems a good idea, lets talk about it for v3.7, thank you.

[Andrew Lamarche]

I've tested GC 3.6 RC3 on both Linux (a laptop) and Windows (my desktop) with my Kickr Core. Both systems have been used with Zwift and MyWhoosh in the past. This post is for the run on Linux, where Bluetooth capabilities seem to be operating as expected, but communicated power setpoint to the trainer appears not to change.

Config:

Ubuntu 22.04.1

Running as an AppImage

GC 3.6 RC3, AppImage downloaded from GitHub

Log:

https://pastebin.com/GyfqT5uP

Screenshot of power profile in GC:

I will make a separate post when I have a chance for the Windows version, where the Kickr seems to work well as a power + cadence sensor, but will either not pair or work as a controlled device

Let me know if you need any additional info or tests to be run, I'd be happy to help out.

-Andrew

[Ale Martinez]

El miércoles, 7 de diciembre de 2022 a la(s) 04:13:34 UTC-3, andrew....@uconn.edu escribió:

I've tested GC 3.6 RC3 on both Linux (a laptop) and Windows (my desktop) with my Kickr Core. Both systems have been used with Zwift and MyWhoosh in the past. This post is for the run on Linux, where Bluetooth capabilities seem to be operating as expected, but communicated power setpoint to the trainer appears not to change.

Config:

Ubuntu 22.04.1

Running as an AppImage

GC 3.6 RC3, AppImage downloaded from GitHub

Log:

https://pastebin.com/GyfqT5uP

Screenshot of power profile in GC:

I will make a separate post when I have a chance for the Windows version, where the Kickr seems to work well as a power + cadence sensor, but will either not pair or work as a controlled device

Let me know if you need any additional info or tests to be run, I'd be happy to help out.

-Andrew

Thanks for your feedback, hope Eric finds it useful. 

Since we are approaching v3.6 release I think we should make FTMS support disabled by default so the native protocol can be used to control the Kickr with the ability to enable it in Train > Preferences for testing and experimentation.

Ale.

[Andrew Lamarche]

After experimenting further, I was able to get GC to control to the setpoints specified by the workout. The issue was that when you are actively editing a workout that has not yet been saved, you are in "Manual Erg Workout" mode. As soon as I saved the workout and selected it in the sidebar, GC was able to control to setpoint just fine via the FTMS protocol.

GC was receiving power and cadence from the trainer just fine, but seems to not have been estimating speed despite having that checkbox ticked in GC (or receiving trainer speed messages from the trainer). I'm a bit of a GC newbie, so it's possible I may be doing something wrong.

The last thing I've noticed is that unless the disconnect button (graphically represented as a power button in the interface) is pressed prior to closing GC, my computer remains connected to the Kickr Core per the LEDs on the device. It might be a good idea to design a feature to automatically disconnect any BTLE devices connected at the start of the session prior to exiting the application.

-Andrew

[Kristian Jörg]

Hi! I'm experimenting with getting my Tacx T1932/T1901 trainer (magnetic brake with white/blue head unit) working. I have hooked the USB up to a Raspberry Pi that runs FortiusANT (an open source program for emulating a Bluetooth BLE/ANT+ device). It should be broadcasting from the Raspberry internal BLE device.

When I add a Bluetooth device on my Win10 computer with CG and start the training session it connects to *something*.  But it is not the trainer, and I have everything else with Bluetooth powered down, even my mobile. Even when I power down the Pi it connects to *something*. Starting GC with --debug gives me nothing at all in the log file.
So, I have no clue to what is going wrong or what happens...

It seems to me that a pairing of some sorts needs to be done in GC, it should not just connect to whatever. What if there are two trainers in the same room for instance?
Or am I missing something obvious? (I might be since I have only used Tacx TTS program up until now.)

[Ale Martinez]

El martes, 17 de enero de 2023 a la(s) 09:52:05 UTC-3, kristi...@gmail.com escribió:

Hi! I'm experimenting with getting my Tacx T1932/T1901 trainer (magnetic brake with white/blue head unit) working.

GoldenCheetah v3.6 has direct support for Tacx Fortius as explained in FAQs (https://github.com/GoldenCheetah/GoldenCheetah/wiki/FAQ-TRAIN#how-can-i-use-my-fortius-trainer-on-windows-10), if you search this forum will find several threads about it and perhaps other Fortius users can help you.

 

I have hooked the USB up to a Raspberry Pi that runs FortiusANT (an open source program for emulating a Bluetooth BLE/ANT+ device). It should be broadcasting from the Raspberry internal BLE device.

When I add a Bluetooth device on my Win10 computer with CG and start the training session it connects to *something*.  But it is not the trainer, and I have everything else with Bluetooth powered down, even my mobile. Even when I power down the Pi it connects to *something*.

That message only indicates the device changed to connected state and searching for supported sensors, additional messages appear when they are detected and paired.

 

Starting GC with --debug gives me nothing at all in the log file. So, I have no clue to what is going wrong or what happens...

--debug redirect debug messages to the launching console instead of the log file 

 

It seems to me that a pairing of some sorts needs to be done in GC, it should not just connect to whatever. What if there are two trainers in the same room for instance?

Currently that is not supported on BTLE, only ANT+

 

Or am I missing something obvious? (I might be since I have only used Tacx TTS program up until now.)

See above 

[Ale Martinez]

BTW, BTLE Sensor pairing is explained in https://github.com/GoldenCheetah/GoldenCheetah/wiki/FAQ-TRAIN#how-to-pair-btle-sensors

[Mick Drake]

Works straight out of the box without fortius ant, just install these drivers, plug in USB then select Fortius

https://github.com/switchabl/t19xx_usb

[Kristian Jörg]

Hi,

I have the https://github.com/switchabl/t19xx_usb drivers installed. The "VR_interface" driver of Tacx was exchanged for "Tacx T1932". Added device as "Tacx Fortius" with FortiusSWPID1942Renum.hex from my TTS installation referenced. When I start a session I get some connection data:
Motor brake unit Firmware=6402 Serial=0 year=2000 type=T190 Version2=0 MotorBrake=0. However most connection attempts returns connection failure. Also, when actually conected, it fails after a minute or so. Even when connected and I start a session and start pedalling - no feedback of speed or cadence or anything. Not working...

This may be due to the fact that my trainer is an "i-Flow" that is with the "VR" head upgrade (https://www.amazon.com/Tacx-Upgrade-Kit-Flow-Trainer/dp/B002KF9Q4O) with the simpler magnetic brake without power connection. The T1901 I believe it is called. The "real" Fortius has a power connected brake motor.

Also tried the "Tacx iFlow" device type. No connection, tried both libusb and Tacx default drivers.

I guess I'm out of luck with the connection here? ...which puts me back to the question why BTLE with FortiusANT doesn't worl. As stated earlier, GC connects to *something* on startup, but what I don't know. Even if I disconnect *everything* bluetooth it still connects to something - but obviously not the FortiusANT device.

[Ale Martinez]

El miércoles, 18 de enero de 2023 a la(s) 05:10:31 UTC-3, kristi...@gmail.com escribió:

 ...which puts me back to the question why BTLE with FortiusANT doesn't worl. As stated earlier, GC connects to *something* on startup, but what I don't know. Even if I disconnect *everything* bluetooth it still connects to something - but obviously not the FortiusANT device.

So you didn't read my answer to that same question before nor the FAQ on BTLE sensors pairing, did you? 

[Kristian Jörg]

Sorry, I did read it all. But I confess I forgot that detail about BTLE not "pairing". With all the information flowing around and trying to sort out issues with both the FortiusANT stuff,  the other two Tacx device types with USB connection that does not work either in GC, days of google searching etc, my brain did not cope. Sorry about that. I am really, really trying to get this to work in some fashion and I am failing to do so. I am not the type of guy to give up easily, I have spent days on this and I am prepared to put some more effort in also. But in this case where I get no feedback from the logs or anything I am basically clueless how to procede.

I guess the "Tacx Fortius" and "Tacx iMagic" device types for direct USB connection are NOT compatible with my hardware? As stated before it has a T1932 head unit and the most basic magnetic roller brake. A T1901 I assume. I think that combo is called an "i-Flow" but Tacx has so many variations and names of their older products that it is a mess to put it mildly. Since this brake is different from the Fortius that has a motor brake it is not the same as what you have support for? The other iMagic device type finds nothing on a scan.

[Ale Martinez]

El jueves, 19 de enero de 2023 a la(s) 06:27:50 UTC-3, kristi...@gmail.com escribió:

Sorry, I did read it all. But I confess I forgot that detail about BTLE not "pairing". With all the information flowing around and trying to sort out issues with both the FortiusANT stuff,  the other two Tacx device types with USB connection that does not work either in GC, days of google searching etc, my brain did not cope. Sorry about that. I am really, really trying to get this to work in some fashion and I am failing to do so. I am not the type of guy to give up easily, I have spent days on this and I am prepared to put some more effort in also. But in this case where I get no feedback from the logs or anything I am basically clueless how to procede.

My impression is FortiusANT is not working in your setup and that’s the reason it doesn’t get discovered by GC, there is not much you can do in GC using BTLE until you find a solution for that.

I guess the "Tacx Fortius" and "Tacx iMagic" device types for direct USB connection are NOT compatible with my hardware? As stated before it has a T1932 head unit and the most basic magnetic roller brake. A T1901 I assume. I think that combo is called an "i-Flow" but Tacx has so many variations and names of their older products that it is a mess to put it mildly. Since this brake is different from the Fortius that has a motor brake it is not the same as what you have support for? The other iMagic device type finds nothing on a scan.

This is a thread about BTLE-FTMS, to discuss about Fortius direct support please search for threads about Fortius where you can find answers from developers of that feature, since you seems so committed, you could build from source to enable debug logs.