Kickr Serial Communication

[cagnulein]

Channel 0 RXD ( or TX from the Kickr) seems to follow 7 bytes (correct term?), pause about 0.3 seconds, then 0xA2, pause about 0.6 seconds, another 7 bytes, pause, 0xA2, etc. Edit: though occasionally a 0x82 replaces a 0xA2

Channel 1 TXD ( to Kickr ) seems to follow this pattern: 2 bytes, pause about 0.3 seconds, 3 bytes ( the third is 0xFF), pause about 0.6 seconds, repeat.

This is the SDK for the chip in the Wahoo dircon adapter.
NEW SDK v17
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/ble_sdk_app_csc.html

OLD SDK https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v4.x.x/doc/html/group__nrf51__characteristics__add__encoding.html

Originally posted by @IProgrammedOnce in #756 (comment)

[cagnulein]

The attached file was created, and viewable with https://www.saleae.com/downloads/

Let me know if that is helping. I think 14400 gives the least framing errors but I am guessing. You can alter it by editing the setting for each analyzer.

Pin 9, channel 0 is RX from the Kickr. Pin 10, channel 1 is TX to the Kickr.

DirconSerial.sal.zip

Session9_Channel0.txt

Session9_Channel1.txt

[cagnulein]

@IProgrammedOnce these signals are from the TTL to the nRF5284 ? because i don't think that https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v4.x.x/doc/html/group__nrf51__characteristics__add__encoding.html is about the protocol that the kickr and dircon are using. That protocol is the bluetooth one. What do you think?

[IProgrammedOnce]

Yes I think I read too much into the idea that the data just gets passed along. That there would be somewhat matching data coming to the chip to be sent out.

nRF5284 is a 52 series and uses the newer v17 SDK. The link for that is above the older one.

Perhaps I need to look inside the Kickr to get an idea of the hardware.

[cagnulein]

@IProgrammedOnce what about getting the tx and rx signal that are directly coming from the bike itself? if it's a rs232 you should see it in the logic analyzer, isn't it? I think that's the easiest way

[IProgrammedOnce]

The Kickr is a direct drive trainer so I don't understand the comment "from the bike itself".

The file DirconSerial.sal.zip IS the communication between the trainer ("bike"?) and the nRF chip. The signals are RS232 between the Kickr and the level changing chip in the dircon and then TTL between the level change chip and the nRF5284.

Since the Kickr has built in bluetooth I was thinking the protocol might start there. I guess it could be raw data over the serial too.......

[cagnulein]

The Kickr is a direct drive trainer so I don't understand the comment "from the bike itself".

yeah, sorry my bad: i'm following too much tickets every day and I made confusion in terms :) I mean from the trainer itself :)

The file DirconSerial.sal.zip IS the communication between the trainer ("bike"?) and the nRF chip. The signals are RS232 between the Kickr and the level changing chip in the dircon and then TTL between the level change chip and the nRF5284.

hah ok perfect

Since the Kickr has built in bluetooth I was thinking the protocol might start there. I guess it could be raw data over the serial too.......

It could be possible of course: in the DirconSerial.sal the trainer was still or you were riding? Because if you were still, we should see a repeating pattern, don't you think?

[IProgrammedOnce]

That thought crossed my mind. I am impressed you are working on so many items at once.

You can see from the filename this was the 9th capture, after I had everything stable and was aiming to get a good useable datastream. I believe I started the capture and cranked the bike by hand. I confirmed I was getting data. Not positive if the data was on QZ or Zwift....I really should have Zwift set to hardware dircon......I think I did but I am not positive I did. The same watts and cadence should have been on both bluetooth and hardware dircon though.

The pattern is in timing and byte count. The values change other than those I mentioned 0xFF and 0xA2. There are a few deviations but it was my first effort at identifying patterns.

Hopefully this is a good starting point?

I think I will take the Kickr apart to examine the hardware.

[cagnulein]

The pattern is in timing and byte count. The values change other than those I mentioned 0xFF and 0xA2. There are a few deviations but it was my first effort at identifying patterns.

Hopefully this is a good starting point?

yes absolutely, but we need a stable pattern with also stable data to start parsing them. I mean we have to recognise some data on it, so we need to collect still frames so we have to see stable data, then trying to ride, we should see these data changing. It's the only way to parsing them correctly. But yes, it's a good starting point!

[IProgrammedOnce]

Pulling the pulley to remove the Kickr flywheel and gain access to the circuit board is going to be a chore. Very tight. A project to finish tomorrow I hope.

I am learning this as I go so I apologize if I say something obvious or not useful. Last time I did any programming I was using QBasic or GW Basic. The only network related things were when I had a Linux box with Apache, firewall, and an email server, plus ethernet stuff at home. Add "upon a time" to the end of my user name lol. When I made the name I was only expecting to be reading Github not posting. Now my hobbies are more hardware than software.

I believe for that 9th capture I started the capture, then connected Zwift on Android via hardware dircon, then spun the cranks and saw watts showing, let it coast down, and then ended the capture. I am having doubts in my mind if I connected to Zwift but I think that capture was made after the new Zwift version for Android that had working dircon. I could not have connected to QZ as there is no dircon client. My laptop was doing the capture so I know Zwift was not on it. I did the capture, sent it, and rushed to work. I was trying to simulate a short ride. Once I put the Kickr back together I can try some more scenarios and keep better documentation.

I am wondering why Wahoo chose RS232. If there was always the intention to use an ethernet adapter then TTL would have been fine for such a short cable or they could have just installed an ethernet port unless there is not enough processor in the Kickr to handle it but that seems unlikely since there are multiple bluetooth and Ant+ connections. Was the plan for longer serial cables and if so to what? Does this provide hints as to protocol? Having a look inside the Kickr might help explain some of this. I think the dircon adapter is only for the newest Kickr so I don't know if legacy design influenced the RS232 connection?

I know it is a future project but having the dircon client in QZ would be useful now to see the same data on the serial connection and then again in QZ. This assumes the dircon data protocol is known to you rather than just being unknown data passed through QZ.

Although I don't need the serial connection myself at this time it is something I will do my best to help with. An interesting challenge.

[cagnulein]

You're doing very well! Most of my hw engineers at work aren't able to do what you did in these days! You have to be proud of your work so far!

I am wondering why Wahoo chose RS232

I guess because it's easy to implement and leave the scenario opened for all the purposes. I would probably did the same if I was a Wahoo engineer :)

Does this provide hints as to protocol?

If they were using RS232 as a general purpose protocol, as I guess, the protocol could be a custom one (as I guess actually) and it could easy when we understood some of them. You know now we are in a startup puzzle condition: we have a lot of pieces and noone is matching, but when we will find some pieces, everything will be easier! Guaranteed!

I know it is a future project but having the dircon client in QZ would be useful now to see the same data on the serial connection and then again in QZ. This assumes the dircon data protocol is known to you rather than just being unknown data passed through QZ.

Yes I agree with you, and you did right opening the #782

Although I don't need the serial connection myself at this time it is something I will do my best to help with. An interesting challenge.

Eheh yes we're doing this because this is challenging :) and we're doing this for the love of open source!

[IProgrammedOnce]

Inside the Kickr is similar to the DIRCON adapter. There is a SOC on a radio module that also outputs serial to a RS232 driver chip. I guess they use RS232 because in addition to the more powerful signal the driver chips have built in protection for the SOC data lines.

The only sensors are an optical speed sensor and a temperature sensor for the electromagnet coils.

You did not mention if you know the dircon packet protocol but I assume the data I captured from serial does not fit "bluetooth tunneled through tcp/ip" implying the data would be the same format and the hardware would just pass it through. That is what I was hoping for.