PyBushido code up

Overview of PyBushido:

bushido_logger.py

replicates Tacx TTS slope distance mode (headunit enters PC Communication mode)

functionality:

  • logs data to console
  • slope buttons (up and down arrows) implemented

bushido_middle.py

a simple man in the middle implementation for snooping on communication from the headunit to the brake.

to use:

  • start training on tacx headunit
  • run bushido_middle.py
  • you can optionally edit injections.py to modify data before retransmission

Source code

You can grab all the source code we are using to reverse engineer the Tacx Bushido here:

Cowboy Coders Github

Reverse engineering the Tacx Bushido

The Bushido is a top of the range turbo trainer from Tacx. It consists of a brake unit based around an alternator which is linked to a head unit mounted on the handlebars using the ANT protocol. The head unit can be used alone, or linked to a PC using the ANT wireless protocol. From the PC the user can design training programs and log data such as the rider power output, heart rate, cadence etc.

Unfortunately the PC software is expensive, runs only on Windows and crashes frequently. This led Will and I to reverse engineer the protocol allowing full control over the turbo trainer without using the Tacx software. More details will follow shortly, but for now we have documented the protocol here.

Update 24/10/12: We have almost completely documented the brake to the computer protocol (see link to the wiki above) using a “man in the middle” approach developed by Will. It appears that the brake sends back much more data to the head unit than is actually made available to the user. A graph showing the data sent back from the brake is shown below. Whilst we’ve identified which values correspond to those displayed on the head unit, we’re still trying to figure out what some of the other quantities are. We’ve uploaded an example log of brake only communication here, and the data from the graph below here, if you are interested in helping.

Key:

A: Related to power somehow?

B: Power (confirmed)

C: Very similar to A, left/right version of?

D:Roller speed (rps) of brake? Note: Assuming roller radius of 30mm, at a speed of 30kmph the roller rotates at 45rps, which is in good agreement with this assumption.

E: Unknown

F: Unknown

G: Actual wheel speed (confirmed) – note wheel speed displayed on head unit is computed from power. Actual wheel speed is used to calculate distance.

H: Cadence (confirmed)

I: Pedalling balance (confirmed) – affects bar at bottom of head unit

L: Some sort of counter: Doesn’t affect distance on head unit. Resets when pedalling is stopped.

M: Brake temperature?

Accelerometer controlled RGB Lamp

 This is an RGB Lamp assembly that I constructed based around the following parts:

The idea is that the accelerometer is used to calculate the lamp position in spherical polar coordinates, which are then used to control the colour of the lamp. The LED is driven by 3 switching converters coupled to the  PWM outputs of the ATmega8 through opto-isolators.

Anyway, enough details, here’s a video of the lamp in action:

Watch this video on YouTube.

And for those interested in the circuitry (picture taken prior to adding optos):

The blue board on right is the ADXL345 break out board, which also features a selectable 3.3V regulator and TWI pull up resistors. In this case the regulator is used because the ATmega8 I had lying around requires a minimum of 4.5V.  Fortunately the SDA and SCL lines of the TWI bus are open drain so there’s no need to worry about level conversion in this case. I was actually surprised at just how good the ADXL345 is. Not only does it have some cool stuff like tap detection, with a little bit of software filtering I can comfortably get an angular resolution of ~0.25 degrees after the conversion to spherical polars.

Also seen on the above picture are three little green boards which are the LED drivers, hooked up directly to the DC input in the bottom left hand corner which is 16V.  Originally I built my own switching converter, but it actually worked out cheaper (and faster!) to modify modules from DX by removing the rectifier and soldering a wire directly to PT4115 dimming pin for brightness control. Obviously, it’s a good idea to use an opto-isolater between the dimming pin and the MCU, not only in case the PT4115 fails, but because the dim pin registers ~5.3V and is about 1mm from the 16V supply!

Other things that you see are an ISP header in the lower middle, 16MHz crystal in the centre, an LED in the top left, and switch connection / UART headers in the top right. The UART header was used for debugging with a CP2102 USB to UART bridge. These are awesome little modules which are well worth investing in, especially if you don’t have a debugger.

The code for the project is now available here:

https://github.com/dougszumski/docLamp