Levo Gen 2 Specialized Levo (2019+) Bluetooth interface

[Sepp62]

If somebody is interested in decoding the bluetooth interface of a Specialized Levo: I wrote a small decoder and data logger based on a M5Core2 microcontroller (Espressif ESP32).

You can find the software here:
Sepp62/LevoEsp32Ble

This is the hardware: M5Stack Core2 ESP32 IoT Development Kit

 

[Sepp62]

A new version is available: I succeded to identify some more data messages and the library can now read and write specific data. Assistance data can also be read and written:

 

[Zimmerframe]

This is really cool. I know it's not what it's intended for, but it could also be away for some people to have a very cheap but small bike display if they wanted one on a Levo.

Do you know if this works with the SL also ? I think they use the same TCU, so the underlying codes used might be similar ?

 

[Sepp62]

I think the protocol will be pretty similar.

Currently the library has a small "flaw": You cannot select a specific bike, since the code should also run on devices w/o display and keyboard. For that reason ist scans all devices and checks the "manufacturer" for "TURBOHMI". This string might (!) be different on a SL. But probably it runs without any changes.

If there is interest, I can work out a way to load the binary code on the unit, w/o having the complete development system installed.

 

[Sepp62]

I made a (pre-)release with binaries and uploader to M5Core2. With this package the program can be uploaded to the hardware without installing all the arduino stuff:

Release Release V0.95 of LevoEsp32Full · Sepp62/LevoEsp32Ble

Binary for the LevoEsp32Full example with uploader to M5Core2

github.com

I tested it in my enviroment but not on a "clean" system. So be prepared for suprises.

 

[Sepp62]

It went quite a bit further. There were a few corrections to the bluetooth values, but now I am pretty sure that everything fits for current, voltage and power. The library has been corrected and can be found in the usual place.

Also the logger app has some new features.

In addition to altitude and inclination, a number of "trip" values are measured (some maximum, minimum and average values). Also battery consumption values are determined and there is an experimental "remaining range indicator". Whether this is useful in practice has to be proven still..

 

[cuaion]

Super cool!!!

I can see you have a Garmin, is it possible to use that instead? Lots of people have Garmin or similar, so guess that could be very useful

 

[Sepp62]

I think you wouldn't like to use this device instead of a Garmin.

The user interface is really "nerdy" and unergonomic. The hardware is not waterproof. Battery life is about 4 hours (w/o modifications) and the display is not as bright as Garmin's (though it is not too bad). Navigation features are missing and there is no cloud ecosystem to store all your activities. Etc etc.

It is thought as a proof of concept, but probably the one or other is encouraged to build another application on the software or the interface description.

Where I see a benefit of the Levo's BLE interface is evaluating the performance data of the motor (current, voltage, power, temperature). Blevo is the only application which makes use of this data since several years.

Let's see, if somebody will develop some nice ideas to use the interface.

 

[MarkoPetejan]

I did a similar thing painstakingly myself (but as a phone browser app with maps and cheap media remote for control buttons) and lost it all just last week, due to PC failure, with no backup.
I'm angry AF but you sir saved my day(s).
You even solved the acceleration response formula, I was scratching my head over with no result.
Same with group 3 and 4. Interestingly, I was also getting an additional null byte in eco (02 03 xx 00), but not in trail or turbo, not sure why.

You are missing "assist level OFF" in your code, not sure if it is 02 00 or 02 02 or something, but I know there is such a message.
When OFF, motor will still report 1-3W to power the electronics and will never be 0, so your deduction about electric input power looks right to me, except it is the input power of everything, not just motor. After some 15 minutes or so in OFF if there is no movement, electronics will go to sleep and BT connection is lost. But if you ride, it will not go to sleep and still communicate, register distance, speed, etc.

Might experiment the ESP route now (but must add GPS and sensors) to offload phone battery, as BT and C for me was such a PITA I did not even try. (Browser app works really well and looks really nice but navigation and map drawing is power hungry and can't turn screen off without loosing GPS and BT because security issues and can't access barometric sensor because not implemented in standard)
So, again, thank you SO much!

 

[Sepp62]

Nice to hear, that my work is useful for somebody. It would be interesting see your results. Maybe you want to post it here.

 

[malc101]

Hey, this is awesome! I've spent quite a bit of time writing ESP32 LORA, BLE, GPS, and IOT uploader stuff. From IOT I drop data onto a google map. I never know of this all-in-one display and micro. About get get a LEVO in a few days and I will be using this info to help do all day rides and better understand how to maximize range. One pretty neat thing is to create a BLE service on your ESP that allows you to send throttled data points to your phone. That allows a store and fwd technique where at some point you upload your data, via LightBlue app, to Adafruit or other backbone, when you have cell service.

 

[malc101]

I think you wouldn't like to use this device instead of a Garmin.

The user interface is really "nerdy" and unergonomic. The hardware is not waterproof. Battery life is about 4 hours (w/o modifications) and the display is not as bright as Garmin's (though it is not too bad). Navigation features are missing and there is no cloud ecosystem to store all your activities. Etc etc.

It is thought as a proof of concept, but probably the one or other is encouraged to build another application on the software or the interface description.

Where I see a benefit of the Levo's BLE interface is evaluating the performance data of the motor (current, voltage, power, temperature). Blevo is the only application which makes use of this data since several years.

Let's see, if somebody will develop some nice ideas to use the interface.

I need to merge some of your stuff with my ESP32 code. I was using mine to plot RF signal strength of a LORA radio unit to determine actual range and dBm of signal.

 

[JohnnyP]

Sorry, not a clue what you're on about

 

[danlorek]

Nice to hear, that my work is useful for somebody. It would be interesting see your results. Maybe you want to post it here.

I'm sure this is useful for many, including me!

I used an M5Stack not too long ago for a project on my Kenevo. I wanted to setup my suspension with a bit more science than just feeling so I made a logger to capture the fork/shock travel and a few other sensors like a barometer + thermometer, a couple of accelerometers and a magnetometer for bike pitch/attitude and measuring the magnitude of vibrations at the bars, and a GPS. The ESP32 is really amazing... I was able to log most of these at about <100ms intervals.

Now that the suspension is pretty dialed I can repurpose the hardware leveraging your awesome work, so thanks!

Speaking of your awesome work, I noticed you had a repo with some work on the Levo and the CAN bus. Where did you happen to get the IDs and meaning of the byte values? Did you just reverse engineer it?

I made a dual CAN bus device where I can capture traffic from and to the TCU to observe the data from boot, etc., but deciphering the information is going to take a pretty big effort so any pointers that can reduce that would be super appreciated!
Thanks in advance!

 

[Sepp62]

Really cool project !!!
I once investigated a little bit to decode CAN battery message. You find my (poor) results attached.

It would be nice, if we had a CAN bus thread with all collected knowledge. Some time it could be useful i.e. to build a custom levo battery.

 

[Nando]

This is very cool, thanks for sharing.
Though that this type of details was only available via the ANT+ LEV.

 

[malc101]

Really cool project !!!
I once investigated a little bit to decode CAN battery message. You find my (poor) results attached.

It would be nice, if we had a CAN bus thread with all collected knowledge. Some time it could be useful i.e. to build a custom levo battery.

Do you know who makes the connectors for Specialized? Did you just cut into the harness and splice some signal wires onto the existing ones? I'd love to get a maie/female pair so that I can insert a tap into the CAN and Speed sensor cables. thanks!

 

[Sepp62]

I made a pluggable adapter with a pair of Rosenberger connectors (male/female). But this cannot be used while driving, since the crank will collide with the adapter.

Instead of splicing the harness, you can make an adapter at the TCU, which also has the CAN signal. I once made some experiments with slightly modified Higo connectors: comparing 6 mm HIGO Mini-B with JULET Gen-1 connectors

 

[malc101]

I made a pluggable adapter with a pair of Rosenberger connectors (male/female). But this cannot be used while driving, since the crank will collide with the adapter.

Instead of splicing the harness, you can make an adapter at the TCU, which also has the CAN signal. I once made some experiments with slightly modified Higo connectors: comparing 6 mm HIGO Mini-B with JULET Gen-1 connectors

 

[malc101]

Oh, excellent work! Did you ever document the pin allocations on the green TCU cable? I’ve ordered a short M/F extension cable and I intend to cut it half and monitor with Arduino and CAN interface. Thanks?

 

[malc101]

I made a tap cable for the TCU green cable using an extension cable. I found can+, can-, ground, 31v,12v. The 31v and 12v pins are a mystery to me. I’d expect like 38v. Maybe the 12v powers the TCU. Time to connect my cheap can monitor to it now.

 

[malc101]

I'm sure this is useful for many, including me!

I used an M5Stack not too long ago for a project on my Kenevo. I wanted to setup my suspension with a bit more science than just feeling so I made a logger to capture the fork/shock travel and a few other sensors like a barometer + thermometer, a couple of accelerometers and a magnetometer for bike pitch/attitude and measuring the magnitude of vibrations at the bars, and a GPS. The ESP32 is really amazing... I was able to log most of these at about <100ms intervals.



Now that the suspension is pretty dialed I can repurpose the hardware leveraging your awesome work, so thanks!

Speaking of your awesome work, I noticed you had a repo with some work on the Levo and the CAN bus. Where did you happen to get the IDs and meaning of the byte values? Did you just reverse engineer it?

I made a dual CAN bus device where I can capture traffic from and to the TCU to observe the data from boot, etc., but deciphering the information is going to take a pretty big effort so any pointers that can reduce that would be super appreciated!
Thanks in advance!

I've just put together some spreadsheets on the CANBUS messages. I recorded three 30 second data sets, including: Idle, Wheel Spinning, and Pedalling. I've figured out the wheel speed message and will be looking into more. What is interesting is that all of the messages so far are scheduled at regular intervals, with the exception of the wheel speed one (201), which becomes scheduled at 100ms if motion is detected. I am guessing that one of the less frequent messages (3 second) is used as the time base that all other signals synchronize to. There appears to be no query/response type of activity during normal operation, everything happens at regular intervals anywhere between 3 seconds and 30 ms. There are 15 unique messages during normal operation. Perhaps others send during a fault.

 

[malc101]

It appears that the 3-second interval 666 message begins the sequence, perhaps acting as the time base for the rest of the messages thereby preventing collisions. There are five messages from different sources that follow it, which then run on their own preset intervals until the next 666 comes along 3 seconds later. I am guessing that the 6xx messages come from the TCU, but no way to know until I split the traffic with two CAN devices.