Communication problems with emulated SIII

[groer99]

Hi, I don't own a Waterrower with S4 computer, I only have a WaterRower A1 with a broken display, so I am trying to emulate the serial SIII protocol with a microcontroller directly reading out signals from the sensor at the Waterrower rotor.

I have set communication to 1200 bps/8/N/1 and I am currently trying to simulate the distance command. However, I am not successful to get any useful communication with coxswain. With a terminal tool running on the same smartphone I can confirm I am successfully transmitting 0xFE 0x10 (distance of 1.6 m/s) once a second with the above mentioned communication settings.

Coxswain does connect to the USB/serial adapter and starts the workout after receiving the first packet but I am not seeing any change in the distance. Also, on the trace (https://github.com/svenmeier/coxswain/files/3624847/waterrower.trace.txt) I cannot recognize any correct identification of the commands I'have been sending (0xFE 0x10).

I know the failure is probably on my side but any pointer to what I should check for would be appreciated. S3 protocol is still labelled experimental - was it ever successfully tested? Is receiving of distance data not enough to show any progress on the coxswain screen?

Thanks
Alex

[svenmeier]

Hi Alex,
actually no, the S3 protocol hasn't been confirmed to be working. I just implemented it for fun based on available documentation.

Let me take a look at the implementation and I'm sure we'll be able to sort out the problem.

Sven

[groer99]

Hi Sven,
I think the USBTransfer class doesn't work properly for the connection through the USB-RS232 converter. I have implemented a SerialTransfer class making use of the USB-Serial for Android package (https://github.com/kai-morich/usb-serial-for-android). By that my converter is detected and I get better results - the transmitted values are now properly decoded by CoxSwain. Still, I don't see any change of the values on the screen but I believe I am getting closer. Will send you the updated code when I get it working.

Alex

[svenmeier]

I was never happy with the transfer code, but it worked for the S4 so I kept it that way.

These might be related:
https://stackoverflow.com/questions/25464531/android-usb-host-input-bulktransfer-fails-to-read-randomly-when-data-available
https://stackoverflow.com/questions/9108548/android-usb-host-bulktransfer-is-losing-data?rq=1
https://stackoverflow.com/questions/9108548/android-usb-host-bulktransfer-is-losing-data

[groer99]

Hi, I got it working now. Had some issues first with incomplete commands transmitted (e.g. a single byte out of a 3-byte command) but now it's fine.

Exception handling is still poor. Updated files are here:
updated_files.zip

I was using now the library: com.github.felHR85:UsbSerial:6.1.0
The other one didn't use timeouts properly.

Also added additional devices to the deviceFilter so Coxswain starts and connects automatically. Would be nice if you could add this to the main branch.

[svenmeier]

Instead of listing all possible devices, wouldn't it be easier if you changed VID/PID of your microcontroller to that of the Waterrrower (1240/10)?
With all those devices in the filter I'm afraid this might start Coxswain too often for other users.

[groer99]

For me personally it would be just the CP210x (). I couldn't change that VID/PID because it's the USB/serial converter chip on the microcontroller board. If someone uses a serial connection, he will use any of the converter chips supported by the driver library, but of course you're right that Coxswain will turn out every time a user connects one of the devices. Can that be set up in some dynamic way? Coxswain only opening when it was confirmed before?

[groer99]

Protocol3.zip

Here's another update adding energy/power calculation for Protocol3 according to the formular shown on https://www.reddit.com/r/orangetheory/comments/7cp37a/comparison_of_pace_to_wattage_on_the_waterrower/.

[svenmeier]

Right now I'm busy with support for bluetooth connection to the Waterrower. Once I've got that out of the way I'll take a look at SIII support.
Many thanks for your contribution.

[groer99]

Hi, here's another bugfix. When the strokes are becoming too short, there seems to be a division by zero in the RatioCalculator crashing the whole connection. Fixed by catching the Exception in the Protocol3.transfer-function.

Protocol3.zip