FortiusANT message "Tacx returns insufficient data, len=24" on T1932 head unit

[RogerMNP]

Hello Wouter,

I'm Roger from Valkenburg in the Netherlands. I recently found out Tacx ended support for TT4 and was happy to find FortiusANT. I bought 2 ANT+ sticks and ran FortiusANT and Zwift. Basically everything is working, but when I cycle in Zwift speed doesn't get higher than 3 to 5 kph. My head unit is a T1932.

When I run FortiusANT.exe with default parameters the logfile shows only 24 bytes data is received from the trainer with the message the message "Tacx returns insufficient data, len=24". The FortiusANT GUI doesn't show speed, cadance or power when I'm cycling. Log file for this situation:

FortiusANT.2020-09-09.19-52-46.log

When I don't provide the FortiusANT.exe -A parameter for pedalstroke analysis the FortiusANT GUI actually shows correct speed, cadance and power when I'm cycling. In the logs than I see 24 as well as 48 bytes information is received from the trainer. The speed in Zwift is still wrong though. Log file for this situation:

FortiusANT.2020-09-12 16-26-12.log

I hope you can help me. Except from this issue everything seems to work great!

Thanks in advance,

Roger

[WouterJD]

Hi Roger

I will look into it shortly, will be earliest next week.

Ciao!

[vinyl78]

Hi Wounter,

I am Vincent from Paris / France and I have the same issue with a T1942 head unit.

FortiusANT.2020-09-10 18-02-12.log

Thanks a lot, Vincent

[Jaturman]

Hi Wounter,

I am Javier front Spain and I have the same issue with a T1932 head unit. FortiusANT.2020-09-12 19-49-44.log

Thanks

[RogerMNP]

Hello Wouter,

I took a look at the logs myself and noticed that the trainer sends 24 and 48 bytes of data. When the 24 bytes of date is received it wasn't ignored, only the message "Tacx returns insufficient data, len=24" was written to the console. I changed the code to ignore the 24 bytes data and made a new FortiusANT.exe. The speed in Zwift is much better now, though it is still a few kph lower than shown on the FortiusANT GUI.

I can push my commit (which is in a separate branch) to GitHub and create a pull request for you to review if you want. I currently don't have those rights on the repository.

Regards,

Roger

[vinyl78]

Hello,

on my side, I also have an issue with the FortiusANT GUI. The speed/power stop for a few seconds and then come back to normal.

regards, Vincent

[Jaturman]

I have the "Tacx returns insufficient data, len=24" message and every 1 minute in console:

....... xx:xx:xx,xxx: Tacx returns insufficient data, len=24 ....... 18:56:42,332: Tacx returns insufficient data, len=24 18:56:48,856: Target=100W Speed= 0.0kmh hr= 0 Current= 0W Cad= 0 r= 0 T= 15 18:56:48,856: AntDongle.Write exception (message lost): [Errno None] b'libusb0-dll:err [submit_async] submitting request failed, win error: El dispositivo no reconoce el comando.\r\n' 18:56:48,856: devAntDongle.read exception: [Errno None] b'libusb0-dll:err [submit_async] submitting request failed, win error: El dispositivo no reconoce el comando.\r\n' 18:56:48,856: ANT Dongle not available; try to reconnect after 1 second 18:56:50,481: ANT Dongle reconnected, application restarts 18:56:51,051: Dongle - Using CYCPLUS dongle 18:56:52,207: FortiusANT broadcasts data as an ANT+ Controlled Fitness Equipent device (FE-C), id=57591 18:56:52,394: FortiusANT broadcasts data as an ANT+ Heart Rate Monitor (HRM), id=57592 18:56:52,581: FortiusANT broadcasts data as an ANT+ Bicycle Power Sensor (PWR), id=57596 xx:xx:xx,xxx: Tacx returns insufficient data, len=24 .......

regards, Javier

[WouterJD]

Hi @RogerPleijers, @vinyl78, @Jaturman

I experienced very occasional 24-byte buffers, created a retry and they did not appear 4 times in a row. With pedal-stroke analysis active, the trainer is polled much faster than without pedal-stroke analysis (-A flag). Perhaps, some headunits cannot process this quick poll and generate the error.

Note that the -A flag is on by default when no flags are specified at all.

So please try the following:

• specify -g flag (showing the GUI, so -A is not on by default)
• check whether the problem occurs again

@RogerPleijers I have seen your code-update suggestion, let's check the answers from the others first.

[vinyl78]

Thanks a lot Wouter,

this solved my problem. I didn't ride long but the speed and power seem ok in the FortiusANT GUI and Zwift.

Cheers, Vincent

[Jaturman]

Hi WouterJD unfortunately, this didn't work for me It's the first time I've installed FortiusAnt I execute "Python FortiusAnt.py" without flags in console. When I start pedalling, calibration starts then I stop pedalling and the wheel keeps turning around. Console returns "Tacx returns insufficient data, len=24" continuously. After one minute approx, console returns:

"19:42:56,178: Tacx returns insufficient data, len=24 19:42:56,681: Tacx returns insufficient data, len=24 19:42:56,682: AntDongle.Write exception (message lost): [Errno None] b'libusb0-dll:err [submit_async] submitting request failed, win error: El dispositivo no reconoce el comando.\r\n' 19:42:56,683: devAntDongle.read exception: [Errno None] b'libusb0-dll:err [submit_async] submitting request failed, win error: El dispositivo no reconoce el comando.\r\n' 19:42:56,691: ANT Dongle not available; try to reconnect after 1 second 19:42:57,744: GetDongle - Try dongle: manufacturer=CYCPLUS, product= ANT USBStick2, vendor= 0xfcf, product=0x1008(4104) Traceback (most recent call last): File "FortiusAnt.py", line 552, in parent.ListenToChild() File "FortiusAnt.py", line 379, in ListenToChild gui_command = self.MainCommandFromGui() File "FortiusAnt.py", line 335, in MainCommandFromGui command = self.app_conn.recv() File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1729.0_x64qbz5n2kfra8p0\lib\multiprocessing\connection.py", line 250, in recv buf = self._recv_bytes() File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1729.0_x64qbz5n2kfra8p0\lib\multiprocessing\connection.py", line 305, in _recv_bytes waitres = _winapi.WaitForMultipleObjects( KeyboardInterrupt 19:43:22,447: connected, application restarts 19:43:24,114: FortiusANT broadcasts data as an ANT+ Controlled Fitness Equipent device (FE-C), id=57591 19:43:24,294: FortiusANT broadcasts data as an ANT+ Heart Rate Monitor (HRM), id=57592 19:43:24,475: FortiusANT broadcasts data as an ANT+ Bicycle Power Sensor (PWR), id=57596 19:43:24,655: FortiusANT broadcasts data as an ANT+ Speed and Cadence Sensor (SCS), id=57595 19:43:25,090: Tacx returns insufficient data, len=24 19:43:25,594: Tacx returns insufficient data, len=24 19:43:26,098: Tacx returns insufficient data, len=24"

And the calibration process fails. No matter how many times I try this process, it always goes wrong

FortiusANT.2020-09-14 19-41-31.log

[WouterJD]

FortiusANT polls the trainer every 0.25 second. You can see this in logfile (19:41:42,526 -> 19:41:42,774). The trainer returns short buffers (4x) and then the error is given and the buffer is padded with zeros - resulting in incorrect readings. Then the trainer returns a short buffer and a normal buffer.

See usbTrainer.py, line 1555. The comment states that the buffer is ignored (but it is used, padded with zeros causing incorrect readings). Reason for this code that on my system it accidently happened so I never get to 4 retries.

You could try:

• increase the retry count
• add a short delay, e.g. time.sleep(0.1)

Please let me know

[RogerMNP]

Hi @WouterJD ,

On my Fortius I get to 4 retries very often, as you can see in the second logfile in my post opening this issue. I for now solved this by not processing the 24 bytes results at all. I created a pull request of the change I made so you can review it.

I can also try your other options with the retry count or delay. I can't look into that before next week, though.

Regards,

Roger

[Jaturman]

Hi WouterJD I'm afraid it's still not working I've tried by using Zwift.

1. exe "python FortiusAnt.py -n"
2. Zwift detected all the sensors (power, cadence...)
3. However, during the training, the connection goes on and off continuously

Find attach the console during the training. I can't thank you enough for all your attention and help

console.txt

[vinyl78]

Hello Jaturman,

I experienced the same issue using a CYCPLUS Ant dongle. It has been solved by changing the dongle.

Vincent

[Jaturman]

Thanks Vicent In console is a CYCPLUS Ant dongle but really is this: https://www.amazon.es/gp/product/B01M4NFENM/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1

[vinyl78]

I bought the same one at first And I changed it with this one : https://www.amazon.fr/dp/B01NAIDN73/ref=cm_sw_r_cp_taa_tFqzFb8JHBD0X

[totalreverse]

One receive 24 byte frames, if the head unit has not received a valid frame from the power back since the last data poll from the host. This typically happens, if you poll too fast. But 0.25s is slow enough to get a long 48 byte frames for every poll.

But as I wrote above the unit has to receive VALID frames. Maybe the connection between the power back and the head unit is somehow disturbed (broken cable, broken socket or some kind of radio interference). The serial connection uses a 3.3V TTL/CMOS level, which is very sensitive to noise.

[WouterJD]

@totalreverse thanks for your observation.

I suggest we conclude:

• 24 byte frames occasionally happen and when retried it does not occur again
• If 24 byte frames happen and retry does not help (the message is given) first try to work without pedal-stroke analysis; not all headunits can provide the data that quick. PDA seems to challenge the headunit at max specs.
• If the 24 byte frames happen without pedal stroke analysis, check all connections.

Without additional feedback; I will close this issue.

[Jaturman]

Ok. Thanks

[RogerMNP]

Hello @WouterJD,

Turning off pedal stroke analysis didn't work for me (as in my starting post). I already checked all connections which seem fine. I was using TTS4 about 2 weeks ago which seemed to be fine as well.

I just commented on your question in my pull request, I solved it there in usbTrainer.py by adding an else: on line 1567. Hope you can give me some time to also check your suggestions to increase retry count or add a delay (I've been away several days since last Friday).

Regards,

Roger

[WouterJD]

Just checked the differences on github, saw the additional indent but did not realize the meaning. Good suggestion, I will pick it up. Since I never got through the 4x retry, the current implementation did not bother me.

But your suggestion is better; it remains a question though why your interface causes so many retries...

[RogerMNP]

Hello @WouterJD ,

I tried your suggestions tonight. Below are my findings.

Increase the retry count

I increased the retry count from 4 to 10 on usbTrainer.py line 1560. FortiusANT now receives 24 bytes 10 times instead of 4 times and the behavior in Zwift was equal to the retry count of 4. I didn't try even higher retry counts, but I doesn't seam increasing the retry count will resolve the issue for my trainer. I have attached the log file: FortiusANT.2020-09-26 18-06-13.log

Add a short delay, e.g. time.sleep(0.1)

I added this delay on usbTrainer.py line 1565. This seems to work. FortiusANT now receives most times receives 24 bytes 1 or 2 times before it receives 48 bytes. Zwift seems to be working with this option. I have attached the log file: FortiusANT.2020-09-26 19-38-00.log

Only process trainer data when sufficient data was received

This was my own suggestion, which I implemented in branch Issue_104_FortiusANT_message_Tacx_returns_insufficient_data for which I made a pull request which you already saw. In this solution I added an else: on usbTrainer.py line 1568. Zwift seems to working with this option as well. I have attached the log file: FortiusANT.2020-09-26 19-47-02.log

Conclusion

Both adding a short delay or only processing trainer data when sufficient data was received seem to work. I'm not sure which option would be preferable to implement.

With both options although the speed in Zwift is ok, it is still mostly between 2 an 4 kph below the speed FortiusANT is showing. I'm not sure if that is related to this issue, though.

[WouterJD]

Great study; I will adopt the delay and the else...

Difference in speed:

• FortiusANT takes speed from wheel
• Zwift calculates power/grade --> speed So the figures will always differ.

[WouterJD]

Note that zwift provides a grade, the bike provides the speed and FortiusANT calculates the required power and hence required resistance.

Then the actual power is transmitted to zwift, where zwift (knowing the grade) calculates the speed.

Obviously it will not be a perfect match, since the used formula's are not equal (compatible).

Note also that, when grouping zwift riders, two riders on the same track, same grade have same speed (stay together) although one produces more power than the other. There must be speed-discrepancy in that case.

[RogerMNP]

Note that zwift provides a grade, the bike provides the speed and FortiusANT calculates the required power and hence required resistance.

Then the actual power is transmitted to zwift, where zwift (knowing the grade) calculates the speed.

Obviously it will not be a perfect match, since the used formula's are not equal (compatible).

Note also that, when grouping zwift riders, two riders on the same track, same grade have same speed (stay together) although one produces more power than the other. There must be speed-discrepancy in that case.

Thanks for explaining @WouterJD. In general I'm very happy with FortiusANT since it means I can continue using my Fortius trainer. Setup of FortiusANT is very easy as well. Thanks for you work on FortiusANT!

[totalreverse]

One more Information: the brake only sends an answer after receiving a command from the head unit. And the 1942 head unit only sends a command to the brake after receiving a frame from the host. You furst have to increase the send rate to receive more frames (answers) from the brake.

[WouterJD]

Thanks @totalreverse for guidance.

I have updated usbTrainer.py; @RogerPleijers please test. (+else, +sleep, +logfile guidance); sorry did not use your branch since still not handy with that side of github.

[RogerMNP]

Thanks @WouterJD, your change looks good. I will test it and let you know the result.

No problem with the branch, I have Git experience but it also took me some time to find out you have to fork repositories on Github to be able to make changes.

[RogerMNP]

Hi @WouterJD,

I tested the changes tonight. At first I encountered some problems creating the FortiusANT Windows executable, which I will describe first. Than I will go into my test results.

Problems for creating the FortiusANT Windows executable and my solutions:

• FortiusAntBody.py line 277 return ((AntDongle.OK or (not clv.Tacx_iVortex AND (clv.manual or clv.manualgrade))) \. This resulted in an error about the AND keyword which shouldn't be in capitals and manualgrade which should have a capital G. I changed this line to return ((AntDongle.OK or (not clv.Tacx_iVortex and (clv.manual or clv.manualGrade))) \

• usbTrainer.py line 1584 if self.PedalStrokeAnalysis:. This resulted in an error stating PedalStrokeAnalysis doesn't exist on self. I changed this line to if self.clv.PedalStrokeAnalysis:

After fixing this I could create the Windows executable. You're changes to usbTrainer.py are working for me. Zwift was working fine. Attached you find the log file of my test: FortiusANT.2020-09-28 18-53-42.log

For me with these changes the issue can be closed. Obviously the problems creating the Windows executable need to be fixed before a new release can be made, if you need a pull request for this let me know. Maybe it's also good to test FortiusANT with these changes on someone else's trainer.

[WouterJD]

Typo's corrected; sorry for sloppy change. I will undust my Tacx and do verifications, this was quick but dirty.

[hosnor]

Hi WouterJD unfortunately, this didn't work for me It's the first time I've installed FortiusAnt I execute "Python FortiusAnt.py" without flags in console. When I start pedalling, calibration starts then I stop pedalling and the wheel keeps turning around. Console returns "Tacx returns insufficient data, len=24" continuously. After one minute approx, console returns:

"19:42:56,178: Tacx returns insufficient data, len=24 19:42:56,681: Tacx returns insufficient data, len=24 19:42:56,682: AntDongle.Write exception (message lost): [Errno None] b'libusb0-dll:err [submit_async] submitting request failed, win error: El dispositivo no reconoce el comando.\r\n' 19:42:56,683: devAntDongle.read exception: [Errno None] b'libusb0-dll:err [submit_async] submitting request failed, win error: El dispositivo no reconoce el comando.\r\n' 19:42:56,691: ANT Dongle not available; try to reconnect after 1 second 19:42:57,744: GetDongle - Try dongle: manufacturer=CYCPLUS, product= ANT USBStick2, vendor= 0xfcf, product=0x1008(4104) Traceback (most recent call last): File "FortiusAnt.py", line 552, in parent.ListenToChild() File "FortiusAnt.py", line 379, in ListenToChild gui_command = self.MainCommandFromGui() File "FortiusAnt.py", line 335, in MainCommandFromGui command = self.app_conn.recv() File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1729.0_x64qbz5n2kfra8p0\lib\multiprocessing\connection.py", line 250, in recv buf = self._recv_bytes() File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1729.0_x64qbz5n2kfra8p0\lib\multiprocessing\connection.py", line 305, in _recv_bytes waitres = _winapi.WaitForMultipleObjects( KeyboardInterrupt 19:43:22,447: connected, application restarts 19:43:24,114: FortiusANT broadcasts data as an ANT+ Controlled Fitness Equipent device (FE-C), id=57591 19:43:24,294: FortiusANT broadcasts data as an ANT+ Heart Rate Monitor (HRM), id=57592 19:43:24,475: FortiusANT broadcasts data as an ANT+ Bicycle Power Sensor (PWR), id=57596 19:43:24,655: FortiusANT broadcasts data as an ANT+ Speed and Cadence Sensor (SCS), id=57595 19:43:25,090: Tacx returns insufficient data, len=24 19:43:25,594: Tacx returns insufficient data, len=24 19:43:26,098: Tacx returns insufficient data, len=24"

And the calibration process fails. No matter how many times I try this process, it always goes wrong

FortiusANT.2020-09-14 19-41-31.log

Did you manage to fix this? I have the exact same issue. The 'Tacx returns insufficient data, len=24' error also pops up without the presence of an ANT+ dongle. (I bought the Anself dongles from Amazon which turn out to be just the buggy CYCPLUS dongles).

[WouterJD]

1. Use newest version 3.3 uploaded yesterday
2. Cycplus; no solution known

[hosnor]

1. Use newest version 3.3 uploaded yesterday

2. Cycplus; no solution known

I'll try when I receive the new dongles. Is it possible to test without an ANT+ dongle?

[WouterJD]

Yes, ref manual. -m = manual power mode

[hosnor]

Yes, ref manual. -m = manual power mode

Well, it keeps printing the error :( To be on the safe side I ordered a RJ12 cable to connect the head unit to the brake unit.

[WouterJD]

Good idea to Check all connections

[WouterJD]

@hosnor in the meantime; I'm always curious where FortiusANT is used and who I am working with, please introduce yourself and tell me where you are located. What tacx do you use?

[hosnor]

@WouterJD I live in the Netherlands and am using a Tacx Fortius with the white head-unit with the blue circle of buttons (the top right one in the manual p. 20). Since the laptop which had TTS4 on it was repurposed, I'm trying to get it to work with something else (e.g. Zwift or perhaps something more basic)

[WouterJD]

Welcome @hosnor I'm from ELst near Arnhem with the same type of Fortius

[hosnor]

Welcome @hosnor I'm from ELst near Arnhem with the same type of Fortius

Well, then the problems aren't location or type specific ;)

[hosnor]

Good idea to Check all connections

Well, I received two new ANT+ dongles today, and now it seems to be working! I also found out that the cadence sensor connected to the brake-unit wasn't aligned properly. The error messages are still there though... Tomorrow I'll receive a new RJ12 cable, but it appears to be working already. I'll have to check whether the calibration is correct and the reported speeds in zwift are somewhat accurate, but I can use the Tacx at least 👍

[mattipee]

I saw the same repeated error on two occasions during my ride last night, @WouterJD . Both times happened to be when I was "changing gear" with the head unit buttons (several consecutive presses). Both times I pressed Ctrl-C to quit, restarted and continued with my ride.

[WouterJD]

Hi mat; what is the reason to restart FortiusANT. The short messages should be ignored and not impact operation. Ciao!

[mattipee]

Hi mat; what is the reason to restart FortiusANT. The short messages should be ignored and not impact operation. Ciao!

Power was no longer being reported to Zwift... Zwift was stuck on the last power reading it received, until I restarted FortiusANT.

You can see this happen on the trace below:

[WouterJD]

Should be resolved in current version https://github.com/WouterJD/FortiusANT/wiki#version-33-released-october-16th-2020

[mattipee]

Should be resolved in current version https://github.com/WouterJD/FortiusANT/wiki#version-33-released-october-16th-2020

I fetched and pulled master last night before I started. I will reproduce and investigate next time I ride.

[WouterJD]

https://github.com/WouterJD/FortiusANT/blob/master/pythoncode/usbTrainer.py#L1652 should do the job...

Are these the messages you get?

[mattipee]

Yes, but repeated. Ie nothing but those. Hence software restart to resolve.

[WouterJD]

Aha. According TotalReverse the headunit will only return a correct message AFTER having received a command. According that idea, repeating a receive does not work but a message should be sent first.

Perhaps https://github.com/WouterJD/FortiusANT/blob/master/pythoncode/usbTrainer.py#L373 (385) to be repeated after a failure?

(As if your head unit completely resets)

[mattipee]

Easiest way I have to reproduce is to long-press up or down button (2-3 seconds).

This is conceivably consistent with what I was doing last night which was to press up or down several times in a row as the Innsbruck course I was riding has a few abrupt and significant grade changes. A long button press or multiple sequential button presses are possibly starving something?

[WouterJD]

A Tacx head unit button press is not like a keyboard where three presses provide three characters. A button is pressed or is not. If the button is pressed for a second and you received from the trainer 4x (250ms each) then the button is reported 4 times.

Since I assume that you press, then release, then press sub-sequent buffers with "key pressed" are ignored. In other words: a button press ends when a no-button-pressed message is received. If you continue pressing a button; FortiusANT would "freeze". Perhaps not nice, other suggestion welcome. This is implemented because a long button-press was interpreted as a repeated button press.

https://github.com/WouterJD/FortiusANT/blob/master/pythoncode/usbTrainer.py#L1180