Raspberry PI - Kettler Run-S

Question

Raspberry PI - Kettler Run-S

Opened this issue 8 years ago · 15 comments

tompijls commented 8 years ago

Hi,

I compiled the cli.rs file on my raspberry pi3.

I pair my Run-S with the Raspberry PI and get following message:

Paired successfully, but this device has no services which can be used with Raspberry Pi.

Running the program on the Raspberry Pi gives following error:

Search for devices...
thread 'main' panicked at 'No devices found', /buildslave/rust-buildbot/slave/stable-dist-rustc-cross-host-linux/build/src/libcore/option.rs:705
note: Run with RUST_BACKTRACE=1 for a backtrace.

Any idea?

Answer 1 · 2017-01-28T17:05:15.000Z

The program should automatically find and pair with any device that has a name starting with `TOUR`, `RACER`, `RUN`, .... Maybe the case of the device-name-letters is wrong?

Answer 2 · 2017-01-28T17:30:59.000Z

The name in bluetooth settings is 'RUN S', so that can't be it.

Any other ideas?

Thanks for the fast reply!

Answer 3 · 2017-01-28T17:39:03.000Z

You can try to run the example in https://github.com/ChangSpivey/bluetooth-serial-port, if that doesn't find a device, then it's a bug in the bluetooth library. Also, try to connect/run the executable without pairing the device first. Because I don't have a RUN 7 in my surroudings anymore (or any other SPP bluetooth device), I can't really debug these problems... :(

Answer 4 · 2017-01-29T20:45:32.000Z

Ok, got a step further :-)

Connecting is a bit random, takes a while before it detects the treadmill, so i need to restart the cli.rs app a few times.

Now I get following output. Any guidance where I should start looking?

Search for devices...
Connect to "RUN S" ("2F:21:2D:52:DE:8C")...
Connected!
E: unsupported value integer 1
E: wrong CRC received:8A:76 vs computed:8A:18 in package:00:22:03:00:02:00:0A:8A:76
E: wrong CRC received:D3:66 vs computed:EA:C4 in package:00:10:03:00:02:00:00:D3:66
E: wrong CRC received:D7:4D vs computed:0F:54 in package:00:0F:03:00:02:00:00:00:00:D7:4D
E: wrong CRC received:D3:66 vs computed:9B:9A in package:00:10:03:00:02:00:03:00:02:00:00:D3:66
E: wrong CRC received:C9:D6 vs computed:35:4B in package:00:1F:02:C9:D6
E: wrong CRC received:8A:18 vs computed:19:D9 in package:22:00:0A:8A:18
E: wrong CRC received:76:95 vs computed:11:89 in package:00:01:76:95
E: wrong CRC received:A1:07 vs computed:11:89 in package:00:01:A1:07
E: wrong CRC received:D3:66 vs computed:EA:C4 in package:00:10:03:00:02:00:00:D3:66
E: wrong CRC received:8E:33 vs computed:A9:B9 in package:00:1E:03:00:02:00:00:0A:8E:33
E: wrong CRC received:AC:E0 vs computed:71:5A in package:00:23:03:00:02:00:02:00:04:AC:E0
E: wrong CRC received:D7:4D vs computed:2C:FF in package:00:0F:03:00:02:00:00:00:D7:4D
E: wrong CRC received:8E:06 vs computed:8E:33 in package:00:23:03:00:02:00:0A:8E:06
E: wrong CRC received:D3:66 vs computed:EA:C4 in package:00:10:03:00:02:00:00:D3:66
E: wrong CRC received:8A:18 vs computed:44:BD in package:00:08:03:00:02:00:00:0A:8A:18

Answer 5 · 2017-01-29T21:00:16.000Z

You can adjust the timeout as a workaround here <https://github.com/ChangSpivey/bluetooth-serial-port/blob/master/src/linux/hci.rs#L61> (does that help?). Though the CRC failures indeed seem quite serious, you can try to ignore them this time. Just try to type in "incline" (without quotation marks) or "speed" or "speed_target" and see if there is sensible output (like "Some(x)" where x is a integer). Or try "speed=20" and see if something happens. Does your RUN S indicate that it is connected? (the RUN 7 changed from blinking bluetooth symbol to steady symbol)

Answer 6 · 2017-01-29T22:31:58.000Z

Ok, can't explain why I had the CRC errors, but they are gone.

CLI app works fine now. Will further play around with it. My goal is to write a small program, which reads a file containing interval training and then adjusts speed/incline for set durations.

As you seem to be quite familiar with rust + bluetooth, you wouldn't have an example of connecting and retrieving HR data from a polar bluetooth HR sensor?

I know the treadmill also returns pulse, but it is extremely inaccurate on my Run S.

Cheers

Answer 7 · 2017-01-30T05:24:30.000Z

This might have to do with the quality of the connection, though I'm not quite sure. I quick checked and the CRC errors indeed came from invalid packets (most of them have too many bytes/missing a byte). When testing I had the feeling the greater the distance the more invalid packets.

Well I wrote the bluetooth-serial-port library, but that only handles serial Bluetooth (="old bluetooth protocol"). A HR sensor probably uses Bluetooth low energy, which periodically sends all information to all devices in its range. I'm not familiar with that type and it needs a different crate (blurz looks promising).

Just a note: The RUN 7 receives pulse values from BLE signals and sends them to the computer (drastically improving the accuracy), so you might be able to query them with this library and the "pulse" value without more work.

Answer 8 · 2017-01-30T09:10:25.000Z

Distance may have had to do with it.

Are you sure the Run 7 receives BLE signals? The HR transmitter which got delivered with the device is a 5khz "traditional" transmitter, not bluetooth. Will check it out this evening if it really picks up BLE as well, but then why would it come with a traditional sensor?

Will check out blurz as well.

Cheers

Answer 9 · 2017-01-30T09:30:52.000Z

This might be different between our models. The RUN 7 didn't ship with an extra HR sensor, but ingrained in the "arms" of the treadmill there were metallic contacts. By pushing your hands on these contacts, the device would measure HR and send the value in the "pulse" value over serial bluetooth. As a seperate feature it can also automatically pick up values from BLE and send these instead.

Answer 10 · 2017-02-01T21:34:13.000Z

Tried it. While it does get a signal, it's very inaccurate. Read some remarks on different fora. At higher speeds, the heart rate measurement gets distorted easily. Will need to investigate blurz. Why did you build kdri ? How hard would it be to build the core functions on iOS? The Kettler provided apps are quite poor 😉 Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: ChangSpivey <notifications@github.com> Sent: Monday, January 30, 2017 10:30:52 AM To: ChangSpivey/kdri Cc: tompijls; Author Subject: Re: [ChangSpivey/kdri] Raspberry PI - Kettler Run-S (#2) This might be different between our models. The RUN 7 didn't ship with an extra HR sensor, but ingrained in the "arms" of the treadmill there were metallic contacts. By pushing your hands on these contacts, the device would measure HR and send the value in the "pulse" value over serial bluetooth. As a seperate feature it can also automatically pick up values from BLE and send these instead. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAyvCL78ULF1BDtnKzYJeYfuEduS3jciks5rXa3MgaJpZM4LwiwE>.

Answer 11 · 2017-02-01T21:55:38.000Z

Well, I built kdri to facilitate open-source Kettler training programs (mostly GoldenCheetah - but I like to keep things application neutral, hence a library). The Kettler provided ones are in the range from "bad-user experience" to "non-functional" and desperately need an upgrade, which closed-source software does not allow by a third-party (why are they closed-source in first place?). The basic protocol is actually really simple - the only thing that was hard to find out is how exactly the CRC checksum was computed (now nicely laid out for other persons in crc.rs). By reading the Rust source code, you will probably be quickly able to understand it. Some hints: a sequence starts with 0x02, then the actual packet follows and the sequence ends with 0x03, then there is a 2-byte CRC checksum after that. These 0x02/0x03 bytes inside the packet are escaped with 0x10 (took me long to realize that!!!). A packet has a `value`, which is something like "speed", "incline", "target speed" or "pulse" and after that the `operation` "read" or "write" or "error". After that some bytes follow which specify the wanted speed, incline, etc. This is more or less the whole protocol. It will still take some time and work to correctly implement it (which you shouldn't underestimate).

Answer 12 · 2017-02-03T21:36:50.000Z

I'm going through and the crc makes sense. As I haven't been able to find a properly working library yet for Bluetooth LE devices in rust, I'm considering building something in java or c++, as they have straight forward support for BLE. I'm struggling a bit wrt the steps to connect to the kettler device (which is due to my limited experience with classic Bluetooth as well as rust) Do you have a high level description of the steps involved to setup a connection with the kettler? Have a great weekend and don't hesitate to tell me if I ask too much of your time 😉 Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: ChangSpivey <notifications@github.com> Sent: Wednesday, February 1, 2017 10:55:39 PM To: ChangSpivey/kdri Cc: tompijls; Author Subject: Re: [ChangSpivey/kdri] Raspberry PI - Kettler Run-S (#2) Well, I built kdri to facilitate open-source Kettler training programs (mostly GoldenCheetah - but I like to keep things application neutral, hence a library). The Kettler provided ones are in the range from "bad-user experience" to "non-functional" and desperately need an upgrade, which closed-source software does not allow (why are they closed-source in first place?). The basic protocol is actually really simple - the only thing that was hard to find out is how exactly the CRC checksum was computed (now nicely laid out for other persons in crc.rs). By reading the Rust source code, you will probably be quickly able to understand it. Some hints: a sequence starts with 0x02, then the actual packet follows and the sequence ends with 0x03, then there is a 2-byte CRC checksum after that. These 0x02/0x03 bytes inside the packet are escaped with 0x10 (took me long to realize that!!!). A packet has a `value`, which is something like "speed", "incline", "target speed" or "pulse" and after that the `operation` "read" or "write" or "error". After that some bytes follow which specify the wanted speed, incline, etc. This is more or less the whole protocol. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAyvCMmY7xCYbj92qCKuR-OemoVdp0V1ks5rYP9bgaJpZM4LwiwE>.

Answer 13 · 2017-02-03T22:15:14.000Z

Connect via SPP/appropriate RFCOMM channel. After that you can proceed on the "send bytes" level.

First step: Send handshake bytes (reverse engineered from my RUN 7 - probably works with all device types), after that the connection is acknowledged by the device and won't disappear anymore [blinking BT symbol -> steady BT symbol on RUN 7].

Answer 14 · 2017-02-03T22:21:39.000Z

The uncommented bytes undergo a process in send_bytes to make it into a real packet (sequence start/end bytes, escape bytes, add CRC). The bytes in the comment are the resulting real bytes which are then send to the device (these were used when send_bytes didn't have the necessary capabilities).

Answer 15 · 2017-02-05T14:35:52.000Z

First step completed, manage to make a connection to my RunS from my java program [😊] (steady blue led) Now the hard part can start, converting the commands to actually get and set data. Gonna take me a while I think ;-)

…

________________________________ From: ChangSpivey <notifications@github.com> Sent: Friday, February 3, 2017 11:21 PM To: ChangSpivey/kdri Cc: tompijls; Author Subject: Re: [ChangSpivey/kdri] Raspberry PI - Kettler Run-S (#2) The uncommented bytes undergo a process in send_bytes to make it into a real packet (sequence start/end bytes, escape bytes, add CRC). The bytes in the comment are the resulting real bytes which are then send to the device (these were used when send_bytes didn't have the necessary capabilities). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAyvCB93iIphEybMn_7LwPi43N7ojgl7ks5rY6h0gaJpZM4LwiwE>.