100% 0x10, 0x02, 0x0C, 0x01, 0x00, 0x64, 0x00, 0x83, 0x10, 0x03
45% 0x10, 0x02, 0x0C, 0x01, 0x00, 0x2D, 0x00, 0x4C, 0x10, 0x03
Each of these conrol packets is responded to immediately by the drive unit with something like:
0x10 0x02 0x00 0x0C 0x00 0x00 0x2D 0x02 0x36 0x00 0x83 0x10 0x03
It starts off with the begin packet bytes of 0x01, 0x02. Then 0x00 , 0x0c which would mean, from device 12 to device 0. Strange that it would reply to device zero when device 1 sent the command, but ?? Byte 6 of the packet is the speed, in the packet above it is byte 6 counting from the first byte being index . Bytes 7 & 8 are the power and they threw me for a loop. They’re in nibble form of the actual speed if you read it out loud. For example:
0x10 0x02 0x00 0x0C 0x00 0x00 0x62 0x17 0x81 0x01 0x18 0x10 0x03
Byte 6 is 0x62, for 98 percent and bytes 7 & 8 are 0x17 0x81, this reads as one, seven, eight, one or a power reading of 1,781 watts. Is that weird or what? I tried big endian, little endian, hex, some obscure rotations I’ve seen in the past and other stuff until I just happened to read it out loud and then look at the motor. Shocked is probably the correct term for my reaction.
So, to calculate the speed: Serial.print(((long)3450 * buffer) / 100); seems to work just fine. It’s a tiny bit off from the actual motor reading on its LCD sometimes, but I think that’s because of the calculations on the two devices being a little different. The power is right on for every instance I have tried.
That's two of their secret protocols I've put on the web now <link>; maybe I should think about hiding for a while...