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 https://github.com/cagnulein/qdomyos-zwift/issues/756#issuecomment-1103689406

[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.

[cagnulein]

@IProgrammedOnce thanks! This thread will be so useful for the community!

Ok so that's my plan: I would like to transcribe the capture file in a text file grouping the bytes with the same timestamp so we can easily create a parser.

does the ttl/rs232 usb cable arrived?

[IProgrammedOnce]

If you look in the text files (Session9Channel0.txt and Session9Channel1) above they are in comma delimited format with all the timestamps. They were also produced by the Logic software. Easy to group by times from that? I will have to look if the software will timestamp RTC instead of from capture start.

Usb to rs232 cable arrived. I am thinking the current setup is good unless there is other software you prefer? I can tie into the RS232 if needed. Currently my wires connect to the TTL.

Today was frustrating. I cannot get the current Windows version of Zwift 1.24.2 to see dircon. Neither the Wahoo adapter or from QZ on iOS or Android. This was just after reassembling the Kickr and I thought I damaged it until I tested with QZ and then found Zwift on Android worked just fine.

My plan was to have Wireshark, the Logic analyzer, and Zwift all going at once thus seeing the same data logged as serial and dircon wifi packets. Bluetooth was working on my Laptop but nothing I could think to do got it working. I don't know if the update broke it or if I broke something.

https://forums.zwift.com/t/dircon-not-working-o-1-24-2-100840-for-windows/583412

[IProgrammedOnce]

[cagnulein]

If you look in the text files (Session9Channel0.txt and Session9Channel1) above they are in comma delimited format with all the timestamps. They were also produced by the Logic software. Easy to group by times from that? I will have to look if the software will timestamp RTC instead of from capture start.

hah ok, perfect! This will save time!

Usb to rs232 cable arrived. I am thinking the current setup is good unless there is other software you prefer? I can tie into the RS232 if needed. Currently my wires connect to the TTL.

mmm if you are confident that the logic analyzer is working good (i'm referiing about the frame errors) yes, otherwise I will give it a go with a putty or similar software with the rs232 cable

Today was frustrating. I cannot get the current Windows version of Zwift 1.24.2 to see dircon. Neither the Wahoo adapter or from QZ on iOS or Android. This was just after reassembling the Kickr and I thought I damaged it until I tested with QZ and then found Zwift on Android worked just fine.

grrrr

My plan was to have Wireshark, the Logic analyzer, and Zwift all going at once thus seeing the same data logged as serial and dircon wifi packets.

this will be the heaven of every reverse engineer :D

Bluetooth was working on my Laptop but nothing I could think to do got it working. I don't know if the update broke it or if I broke something.

I guess bluetooth is useless right now

[cagnulein]

ok i played with python and the result is awesome! logicanalyzer.py.zip

Channel0.txt Channel1.txt

now we have to give a name to every byte :)

[IProgrammedOnce]

@cagnulein I do not understand the context of your comment "I guess bluetooth is useless right now" Connection to Zwift for Windows was still working via bluetooth just not via dircon.

As far as the errors from the logic analyzer I would expect either trying to analyze at the wrong baud or a bad connection. My usb cable seemed sensitive to wiggling. Or perhaps I had the sampling rate incorrect. I believe I was using 100Ksamples/second. The Analyzer device says 24Mhz on it as a maximum. The software also has a glitch filter I can try.

I will rig up a cable for RS232 when I get a chance.

[cagnulein]

"I guess bluetooth is useless right now" Connection to Zwift for Windows was still working via bluetooth just not via dircon.

I mean having also the bluetooth logs while we are testing the serial communication is quite useless because, we just need the serial data and the metrics (cadence and power) that we can collect from Zwift for example. Or, if you want, we can use bluetooth to collect them directly with QZ. In this way we can have a deeper look at the metrics since QZ can provide a full log

As far as the errors from the logic analyzer I would expect either trying to analyze at the wrong baud or a bad connection. My usb cable seemed sensitive to wiggling. Or perhaps I had the sampling rate incorrect. I believe I was using 100Ksamples/second. The Analyzer device says 24Mhz on it as a maximum. The software also has a glitch filter I can try.

My idea is since we have to use a RS232 cable at the end, probably we should use it to collect data because is less sensitive and so we can have probably more stable data (without framing error maybe). I mean, the logic analyzer, maybe wants very precise data, and a oscillator a RS232 couldn't be.

[IProgrammedOnce]

The analyzer does not need to match the signal frequency. It measures at a fixed sample rate. This speed needs to be high enough not to miss single bits. I think I did the first one at 100kS/s. I am now using 200kS/s (200 thousand samples per second). I tried 250 but I get timeout errors so either there is too much data for the usb connection or my cheap adapter cannot keep up.

[IProgrammedOnce]

This probably belongs here

Here is some capture data which I hope can help. A short 50 second workout of 10 seconds each of 100, 110, 120, 130, 140 watts using ERG. The watts did jump around a bit. The folder has serial capture and Wireshark capture of the dircon adapter .88 and the laptop .29

QuickTest1_capture.zip

[IProgrammedOnce]

I did another capture. This time I unplugged the Kickr, then I started Zwift, Wireshark, and Logic2, I plugged in the Kickr so the captures should start at similar times although there could be some MDNS handshaking and TCP traffic before any actual data is sent. Then I paired Zwift with WahooDircon and did the same test as above.

QuickTest2.zip

[IProgrammedOnce]

I will leave the above comment for continuity but ignore the analysis. I now realized that by capturing at 200kS/s I was able to see the real speed is 115200 baud and there are no frame errors.

This is the same capture but the correct data. I was unable to do the cut and paste because the clipboard is limited to 10000 lines and this is 13000 now. There is a csv file with the corrected data.

QuickTest2.zip

[cagnulein]

ok @IProgrammedOnce i changed the branch #796 to 115200, let's see if we can setup on linux, probably we need also to change the serial port name from COM4 to something like /dev/ttyUSB4 Let me know when you have the serial port available in ubuntu (you need to forward it from windows to ubuntu)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.