Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Continuously message "insufficient data" #446

Closed
WouterJD opened this issue Nov 30, 2023 · 23 comments
Closed

Continuously message "insufficient data" #446

WouterJD opened this issue Nov 30, 2023 · 23 comments
Labels

Comments

@WouterJD
Copy link
Owner

WouterJD commented Nov 30, 2023

Hi @WouterJD, love this app, 99% of the time ...
I was doing a Zwift race this morning when the app froze up (continuously read "insufficient data"), and reported 234W indefinitely.
I quickly checked all the cables and restarted the app, which got me dropped, and it continued just outputting 234W. I just let it run out the race while I tried to pedal, hoping it'd reconnect and tapping stop/start and find hardware ....
I ended up rechecking all the cables several times and having to restart the app several times and also disconnect/reconnect from the Zwift connection panel. I honestly don't know what finally got it back working.
It was just extra frustrating a few km from the finish of a race. Everything was plugged directly into my laptop usb ports. I don't know what other tricks I can try to get a more consistent connection??

Setup: Windows 10, Fortius T1932 head unit, 2x ANT+, FortiusAnt.exe

Originally posted by @ktippey-hzdr in #14 (comment)

@WouterJD
Copy link
Owner Author

For a starter, I'm happy that you love this app; I see you are training quite some on Zwift/Strava.
Nice work!

FortiusAnt communicates through the USB-cable with the headunit of the trainer.
The "insufficient data" message means that records from the headunit are incomplete.
We discussed this in #441.

I do not know what start-up parameters you use (e.g. ..\pythoncode\FortiusAnt.py -g -a -A -H0)
-A activates the pedal stroke analysis, which causes a high read-freqwuency on the headunit. You may try to remove that flag and see whether it makes a difference. Although most T1932's handle this option well, there may be headunits that get confused on high speed reading.

Please let me know what parameters you use.

@ktippey-hzdr
Copy link
Contributor

I admit I'm not certain which commands are being triggered, I primarily use the defaults set for the FortiusAnt executable. It indeed had pedal stroke analysis enabled this morning but even when I disabled that and restarted it was reading insufficient data. I usually just modify the start parameters by clicking the settings gearbox and saving setting to json file, and restart if I change anything.

Any advice you can offer on better tuning the settings I'm all ears.


The log file from this morning is quite large and my laptop is old, it froze a few times trying to read it. Here is where it switches from working to not working:

08:28:05,690: Sleep(0.02) to fill 0.02 seconds done.
08:28:05,690: Trainer recv hdr=0x21303 data="array('B', [68, 2, 68, 0, 0, 2, 0, 0, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 30, 4, 0, 0, 0, 0, 3, 19, 2, 0, 0, 0, 0, 0, 124, 32, 0, 0, 23, 6, 23, 6, 102, 8, 1, 0, 84, 14, 2, 85, 100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])" (len=64)
08:28:05,690: Trainer send data="01 08 01 00 66 08 01 00 02 55 10 04" (len=12)
08:28:05,690: tacx mode=2 target=2150 pe=1 weight=85 cal=1040
08:28:05,720: Sleep(0.02) to fill 0.02 seconds done.
08:28:05,750: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:05,750: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
08:28:05,892: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:05,893: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
08:28:06,033: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:06,033: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
08:28:06,173: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:06,173: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
08:28:06,315: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:06,315: Tacx head unit returns insufficient data, len=0
08:28:06,315: To resolve, try to run without Pedal Stroke Analysis.
08:28:06,316: Trainer send data="01 08 01 00 66 08 01 00 02 55 10 04" (len=12)
08:28:06,317: tacx mode=2 target=2150 pe=1 weight=85 cal=1040
08:28:06,318: Tacx2Dongle; Processing time 0.599 is 0.579 longer than planned 0.020 (seconds)
08:28:06,362: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:06,362: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
08:28:06,502: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:06,502: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
08:28:06,641: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:06,641: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
08:28:06,782: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:06,782: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
08:28:06,923: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:28:06,923: Tacx head unit returns insufficient data, len=0
08:28:06,923: To resolve, try to run without Pedal Stroke Analysis.

After turning off pedal stroke analysis, this error:

08:37:54,448: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:37:54,448: Tacx head unit returns insufficient data, len=0
08:37:54,448: To resolve, check all (signal AND power) cabling for loose contacts.
08:37:54,555: No motorbrake version message received from head unit
08:37:54,555: FortiusAnt applies the MotorBrake power curve
08:37:54,556: Trainer send data="01 08 01 00 00 00 00 00 00 00 00 00" (len=12)
08:37:54,556: tacx mode=0 target=0 pe=0 weight=0 cal=0
08:37:54,693: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:37:54,693: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
08:37:54,848: Trainer recv hdr=-0x1 data="array('B')" (len=0)
08:37:54,848: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)

Here are the contents of the json file from which it loads start values

{
"ant": {
"device ID": ""
},
"bluetooth": {
"bless": false,
"nodejs": false
},
"general": {
"autostart": true,
"debug": "8",
"export TCX-file": false,
"gui": true,
"home trainer": false,
"hrm": "",
"imperial": false,
"steering": ""
},
"simulation": {
"manual grade": false,
"manual power": false,
"resistance": false,
"simulate": false
},
"trainer": {
"auto calibrate": true,
"calibrate rolling resistance": "",
"factor": "100",
"grade factor": "100",
"grade factor downhill": "100",
"pedal stroke analysis": false,
"power mode": false,
"runoff": {
"dip": "2",
"max speed": "40",
"min speed": "1",
"power": "100",
"time": "7.0"
},
"transmission": "34-50x34-30-27-25-23-21-19-17-15-13-11",
"type": ""
},
"version": "1"
}

@WouterJD
Copy link
Owner Author

Hmmm...
Settings seem OK.

It does look like transmission error between head-unit and FortiusAnt or a faulty head-unit.
Where is the trainer located, errors are also reported by somebody because the trainer was in a cold basement.
It does look like hardware failures, which I cannot resolve.

The "Retry because short buffer" is given in function at:
https://github.com/WouterJD/FortiusANT/blob/master/pythoncode/usbTrainer.py#L2468

After retrying upto 4 times, an empty buffer is returned.
You might try to reconnect (see #441 (comment)) and see what happens.

This issue was not reported before, but there must be a first time!

@ktippey-hzdr
Copy link
Contributor

Hmm ok, so aside from double checking all the connections there may not be much else I can do (if it's a hardware thing). Yes, I suppose I could try adjusting error recovery but I don't know how much I could improve that as it already looks quite reasonable.

The trainer is located in my office in my apartment. It can get a little chilly when I'm not riding but not particularly cold. It had run just fine for ~ a workout a day prior to this, which is why I was surprised when it flaked this morning. I don't know if it could related to the intensity of the workout; this race was going faster/longer than I had tried before

@WouterJD
Copy link
Owner Author

I have a Fortius / T1932 myself and never had such an experience after an hour.
Errors usually occur at the start.

I assume the trainer is old; you might check the headunit and/or connectors for corrosion...
As stated, it appears hardware so remote analysis is difficult.

But there is good news too: you always managed to restart after the error period, which in itself is a recovery routine.
So reconnecting the USB device might help.

If you want I can see whether I can add it to usbTrainer.py; which should not be a too big job.
Would be fun to have your problem resolved,

@ktippey-hzdr
Copy link
Contributor

I started looking into the code some, I'm just at a loss for how to reproduce my problem and test potential fixes. For USB disconnection events I need to restart the app (I tried a few ways around this but gave up). For temporary power loss it recovers just fine as is. But suddenly returning insufficient data is difficult to replicate, so I'm still stuck not knowing exactly what happened

WouterJD added a commit that referenced this issue Nov 30, 2023
@WouterJD
Copy link
Owner Author

WouterJD commented Nov 30, 2023

Hi Kristy

I have created a branch USB-recovery and modified usbTrainer.py for you.
I cannot reproduce your exact problem, but when I disconnect the USB-cable a lot of errors are displayed. As soon as I reconnect, the recovery-routine is executed and FortiusAnt proceeds.

I did NOT create an executable yet, so please test whether this works using python.
I assume you manage to do so.

Ref: https://github.com/WouterJD/FortiusANT/blob/USB-recovery/pythoncode/usbTrainer.py#L2558

19:34:18,999: Tacx head unit returns insufficient data, len=0
19:34:19,001: To resolve, try to run without Pedal Stroke Analysis.
19:34:19,003: Write to USB trainer error: 'bool' object has no attribute 'write'
19:34:19,004: Read from USB trainer error: 'bool' object has no attribute 'read'
19:34:19,123: Read from USB trainer error: 'bool' object has no attribute 'read'
19:34:19,229: Read from USB trainer error: 'bool' object has no attribute 'read'
19:34:19,337: Read from USB trainer error: 'bool' object has no attribute 'read'
19:34:19,445: Read from USB trainer error: 'bool' object has no attribute 'read'
19:34:19,445: Tacx head unit returns insufficient data, len=0
19:34:19,448: To resolve, try to run without Pedal Stroke Analysis.
19:34:19,450: Try to reconnect to Tacx head unit
19:34:19,451: Find and initialise USB head unit
19:34:19,464: Connected to Tacx Trainer T1932
19:34:19,895: Tacx head unit returns incorrect header 0x21303 (expected: 0xc03)

@ktippey-hzdr
Copy link
Contributor

ktippey-hzdr commented Dec 1, 2023

Wow, thanks!! I will give this a pull and try it a try this morning :)

EDIT: checked it out and tried it out and at least in testing the USB reconnect works great
HOWEVER: running from python I can no longer connect to Zwift. Using python FortiusAnt.py -g -a -H0

EDIT AGAIN: Now I'm trying to reinstall Zwift because it freezes up entirely when I try to connect anything :(. Even when it loads (rarely) ANT+ is not recognized no matter how I initialize FortiusAnt. I just see the (!) next to the ANT stick

LAST EDIT: ok unplugging and replugging the ANT+ sticks back in while running FortiusAnt AND Zwift got things connected this morning.

@ktippey-hzdr
Copy link
Contributor

I haven't had any new instances where the head unit froze up since this implementation (I did get a complete Zwift 30s freeze-up but that was likely due to my old computer or the internet connection). As far as I can tell, I think it's a good fix

@WouterJD
Copy link
Owner Author

WouterJD commented Dec 6, 2023

Good to hear and I saw your freeze on Strava.

Did you experience a re over-action?
You should have seen a bunch of messages in the black console

@ktippey-hzdr
Copy link
Contributor

Update: so it actually disconnected this morning in warmup and managed to reconnect all on its own. Got a handful of messages but nothing that seemed like an overaction

@WouterJD
Copy link
Owner Author

WouterJD commented Dec 7, 2023

Great to hear. I had a successful training yesterday and had no issues, your training was saved by the recovery (next time please share the copy of the console) so the update seems OK.

I have create a pull request
I have invited you to collaborate; please accept
I can then ask you to validate the PR

This because of your interest to join in development

ktippey-hzdr added a commit that referenced this issue Dec 7, 2023
Issue #446 USB-error recovery, version 1 successfully recovers dropped connections from Fortius head unit T1932
@ktippey-hzdr
Copy link
Contributor

Done! Thanks for the invite. Will screenshot or save debugging log next time

@WouterJD
Copy link
Owner Author

WouterJD commented Dec 7, 2023

Great, I'll leave this issue open for so long.

@ktippey-hzdr
Copy link
Contributor

ktippey-hzdr commented Dec 7, 2023

somewhat unrelated, but I was trying to build the EXE using the bat files from the Development folder. I get a TON of warnings that pyinstaller couldn't find packages that I know are installed (if I pip install them they show up as already installed). I tried adding my scripts folder to --paths when building the spec, but still get all the warnings (for example, it can't even find numpy)

Got pretty lost messing with it and just made a bat file to run it with good arguments. When launching from the commandline I always forgot to run it with debugging

@WouterJD
Copy link
Owner Author

WouterJD commented Dec 7, 2023

I'll create the exe shortly and let you know. On my system it's running for years now, but perhaps I can give a hint

@ktippey-hzdr
Copy link
Contributor

ktippey-hzdr commented Dec 9, 2023

Sorry to bug you so much. I have a new problem though. My HRM is no longer recognized in Zwift. FortiusAnt reads it but it doesn't broadcast right. Every once in a while Zwift has a signal for a second then it drops again. I tried cleaning my HRM, connecting with and without -H0 option, unplugging/repluggin ANT+ sticks, tried straight from python vs with the executable ... I don't know what else to try. I guess it's possible the HRM just died but it seems kind of sudden since switching PC's. Also just tried new batteries, still no connection

I don't know if it matters but this is a new miniPC with Windows 11, otherwise same ANT+ sticks, 1932 head unit

EDIT: Upon further testing, it indeed seems to be PC-specific issue, works still on my old laptop. I need to find a way to get it to work on the Windows 11 PC though because the laptop is dying
Potentially related: FortiusAnt broadcasts from my husbands HRM. In fact, it picks up my husband's HRM too well to the point that it won't recognize mine unless I specify it with -H11896, which, again, works fine on the old laptop but not the Win11 PC.

I'm just stuck

UPDATE: ok it was a line-of-sight issue. when i put the ANT+ sticks in a powered usb hub away from the pc it works again

image

@WouterJD
Copy link
Owner Author

Hi, I see HRM arrived in Strava today so problem seems solved.

Note that Zwift connects to the trainer, which is FortiusAnt. There are three devuces: trainer, power meter, speed/cadence.

Zwift also connects to HRM. Directly, FortiusAnt is not involved there.

Do you use an ANT or BLE HRM?
I assume ANT.
Note that BLE usually connects to one device only. So if your watch is linked, Zwift will not see it (BLE!)

@WouterJD
Copy link
Owner Author

I read your edit now.
👍

@ktippey-hzdr
Copy link
Contributor

Real issue this time: Trainer froze up at 267W. Gave it a minute to try to figure it out itself. Restarted app twice to no avail (it continued to output last known reading). Unplugged and replugged in USB and restarted app and it reset correctly. App initialized with python FortiusAnt.py -g -a -dau -H11896. Oddly, despite USB read errors, it never logged 'Try to reconnect to Tacx head unit'. I don't know what to make of things?

Here it was still working:
07:41:12,984: ANT Dongle:Unknown channel: synch=164, len= 9, id=0x4f, check=210, channel=0, page=51(0x33) info="00 33 ff ff ff ff b3 4f ff"
07:41:12,985: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "03", "01", "03", "e6"]
07:41:12,985: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe6, info="03 01 03" (ch=3, msg=0x1)
07:41:13,059: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "00", "01", "03", "e5"]
07:41:13,059: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe5, info="00 01 03" (ch=0, msg=0x1)
07:41:13,070: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "06", "01", "03", "e3"]
07:41:13,070: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe3, info="06 01 03" (ch=6, msg=0x1)
07:41:13,212: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "02", "01", "03", "e7"]
07:41:13,212: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe7, info="02 01 03" (ch=2, msg=0x1)
07:41:13,222: devAntDongle.__ReadAndRetry() returns ["a4", "09", "4e", "01", "04", "00", "ad", "09", "25", "0b", "a7", "a2", "69"]
07:41:13,222: Dongle receive: synch=0xa4, len= 9, id=0x4e Broadcast Data , check=0x69, info="01 04 00 ad 09 25 0b a7 a2" (ch=1 p=4(HRM Previous Heart beat))
07:41:13,232: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "03", "01", "03", "e6"]
07:41:13,232: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe6, info="03 01 03" (ch=3, msg=0x1)
07:41:13,234: Sleep(0.25) to fill 0.25 seconds done.

Here it started outputting constant watt-stream:
07:41:13,277: Trainer recv hdr=-0x1 data="array('B')" (len=0)
07:41:13,277: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
07:41:13,308: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "00", "01", "03", "e5"]
07:41:13,309: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe5, info="00 01 03" (ch=0, msg=0x1)
07:41:13,321: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "06", "01", "03", "e3"]
07:41:13,321: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe3, info="06 01 03" (ch=6, msg=0x1)
07:41:13,418: Trainer recv hdr=-0x1 data="array('B')" (len=0)
07:41:13,418: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
07:41:13,461: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "02", "01", "03", "e7"]
07:41:13,461: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe7, info="02 01 03" (ch=2, msg=0x1)
07:41:13,467: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "01", "01", "02", "e5"]
07:41:13,467: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe5, info="01 01 02" (ch=1, msg=0x1)
07:41:13,478: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "03", "01", "03", "e6"]
07:41:13,478: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe6, info="03 01 03" (ch=3, msg=0x1)
07:41:13,559: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "00", "01", "03", "e5"]
07:41:13,559: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe5, info="00 01 03" (ch=0, msg=0x1)
07:41:13,561: Trainer recv hdr=-0x1 data="array('B')" (len=0)
07:41:13,561: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
07:41:13,570: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "06", "01", "03", "e3"]
07:41:13,570: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe3, info="06 01 03" (ch=6, msg=0x1)
07:41:13,702: Trainer recv hdr=-0x1 data="array('B')" (len=0)
07:41:13,702: Retry because short buffer (len=0) or incorrect header received (expected: 0x21303 received: -0x1)
07:41:13,711: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "02", "01", "03", "e7"]
07:41:13,711: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe7, info="02 01 03" (ch=2, msg=0x1)
07:41:13,711: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "01", "01", "09", "ee"]
07:41:13,711: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xee, info="01 01 09" (ch=1, msg=0x1)
07:41:13,725: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "03", "01", "03", "e6"]
07:41:13,726: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe6, info="03 01 03" (ch=3, msg=0x1)
07:41:13,808: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "00", "01", "03", "e5"]
07:41:13,808: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe5, info="00 01 03" (ch=0, msg=0x1)
07:41:13,814: devAntDongle.__ReadAndRetry() returns ["a4", "09", "4f", "00", "33", "ff", "ff", "ff", "ff", "90", "4f", "ff", "f1"]
07:41:13,815: Dongle receive: synch=0xa4, len= 9, id=0x4f Acknowledged Data , check=0xf1, info="00 33 ff ff ff ff 90 4f ff" (ch=0 p=51(Track Resistance))
07:41:13,820: devAntDongle.__ReadAndRetry() returns ["a4", "03", "40", "06", "01", "03", "e3"]
07:41:13,821: Dongle receive: synch=0xa4, len= 3, id=0x40 Channel Response , check=0xe3, info="06 01 03" (ch=6, msg=0x1)
07:41:13,841: Trainer recv hdr=-0x1 data="array('B')" (len=0)
07:41:13,841: Tacx head unit returns insufficient data, len=0
07:41:13,841: To resolve, check all (signal AND power) cabling for loose contacts.

@WouterJD
Copy link
Owner Author

As you can see in usbTrainer.py:
The read-routine retries 4 times and then reports the retry-error if still unsuccesful.
If this happens 4 times consequetively, the reconnect occurs.
But if succesful reads occur in the meantime, this is NOT done - it is not usefull to reconnect when succesfull reads are possible

@WouterJD
Copy link
Owner Author

I was trying to build the EXE

Building EXE on Windows 10 still works, perhaps some checks required for Windows 11.

@WouterJD
Copy link
Owner Author

The USB error recovery is implemented and published including EXE in 6.8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants