Strange 09 inserted in csafe

[tijmenvangulik]

Hi,

I have a problem that my pm5 ergometer returns strange 09 values which I think do not follow the csafe definition (or may be there is some thing that I do not know). in am sending the following csafe commands to my pm5 ergometer:

f11a01891a018d1a019f1a018e1a01cf1a01a01a01a31a01a0a1d8f2

And it returns in hex:

f1091a038901031a038d01011a039f01001a038e01ff1a04cf0200001a07a005f3000a0000091a07a30532000000091a07a005f3000a000009a1035e00246af2

I have set all commands on separated lines for clarity. The second byte is the length. The first commands with length 03 and 04 go right. And then a command with length 7 is returned.After these commands I expect the next command , just like the first commands. But here it inserts an extra 09 byte and then the real command follows. I can not find the 09 in any csafe definition and it is the same command with just a different length. It looks like some kind of bug or is it an hidden feature?.

f1
09 status (also strange value first 4 bits has a value from 0-8 and not 9, but not a real problem since I ignore it)
1a 03 89 01 03
1a 03 8d 01 01
1a 03 9f 01 00
1a 03 8e 01 ff
1a 04 cf 02 00 00
1a 07 a0 05 f3 00 0a 00 00
09 <- here it inserts an extra 09 which should not be there
1a 07 a3 05 32 00 00 00
09 <- here it inserts an extra 09 which should not be there
1a 07 a0 05 f3 00 0a 00 00
09 <- here it iserts an extra 09 which should not be there
a1 03 5e 00 24
6a crc
f2

Pm5 with Firmware = 22, Hardware = 340, connected using usb

I hope you can help me with this so I can make more stable connections using ergometer-space.org

Thanks

[Citroen]

You're probably more likely to get a response by sending that mass of diagnostic info by email to rowing@concept2.com

[tijmenvangulik]

thanks, I drop an mail

[pm5hacker]

Here's the deal. The PM expects an HID format request and provides an HID format response. You show no sign of sending this format - the "09" is
a report ID, and controls the allowed USB frame length. "09" is 0x80 + 0x01. The 0x80 indicates an error, and the 0x01 says that the PM is expecting a
20 byte packet. Evidently, the PM assumes that a request packet with no report ID means use code 01, or else you are going through HID-aware software on your (unknown) host that uses that ID. Your request is longer than 20 bytes, so an error occurs after that part of your request. You sent one request, it got processed as several, in a somewhat strange way, and you got 4 responses, each prefaced by an "09" report ID. The PM firmware does not deal with this sort of stuff very well. I had related problems before I figured out what "report IDs" were all about. The USB descriptor for the PM5 lists the following report IDs, with these lengths:
1- 20 bytes
2- 120 bytes
3- 2 bytes
4- 62 bytes

You didn't say what system you are on, so I can't help you with sending report IDs. On Linux, using Libusb-1.0, I send everything with report ID 2. Both
requests and responses use this value, and things work great. If you are stuck with an implied 0x01, you will need to send more, but shorter requests,
and deal with more, but shorter, responses to deal with the 20 byte limitation