Hacking the Bafang display IO -- new independent research?

Joined
Oct 8, 2023
Messages
8
Location
Seattle Area
So, funny story: I have a 500C display with a BBSHD motor. Worked great, got left in the rain, the LCD layer died from water incursion but the backlight is totally fine (but useless *and* too bright!), and all of the buttons for changing PAS level and on/off work perfectly. I don't know how much voltage is left on my battery, how fast I'm going, or which power level I'm in (except by what would be referred to as dead reckoning in the Age of Sail), but the bike was still perfectly usable for a week so far. I already have one of the new EKD01 displays on the way for now, but I've been thinking a lot about an alternative solution.

I've already 'hacked' the extremely complicated brake cutoff circuit with a big red button I can use like a 'clutch' while shifting gears under power (to cut torque off except from my legs), and I've been researching the throttle interface and am fairly confident I can do some fun stuff with another momentary button that overrides the throttle with +3V from a second circuit (because, seriously, how much time do you spend with a thumb throttle pegged to ~90% of the range? Potentially a lot!), but the display is really the thing I want to get funky with, but it's...too much like modern digital kitchen appliance controls and not enough like the simple caveman electrical systems I already understand confidently.

I'm fine with there being a normal ebike display somewhere on the bike, something you accessed while stopped to look at your odometer etc, but if I could have parallel PAS +/- controls and a better/different power button (so, replicate the right signals on each of those circuits), I think I could do some really cool alternative buttons/switches/etc. on a steampunk or post-apocalyptic art-Ebike for example, or make something extremely weather-proof for something more in the dirt bike/motorcycle class in the future.

Before I spend a ridiculous amount of time teasing what I need to know out of spare controllers/displays on the workbench, does anyone...know how those controls work, already? Are those buttons just momentary switches and the controller just reads each press as a "gimme one more/less PAS level"?

What about the interface the display uses to tell you the PAS level, voltage, etc.? I'm just not sure where to start looking to start untangling that, because it would be so much less work than keeping track of all of that separately (I'm picturing it being very easy for unforeseen errors desynchronizing the actual PAS level from my janky way of tracking it). What's...that area of software/interface on systems like this even friggin' CALLED? Google sure hasn't been getting me anywhere further than where I am now...

I just want to be able to have a few color-coded LEDs and some satisfying clicky ruggedized buttons without needing to learn and master Arduino programming first, but the language barrier is reminding me why I never became an electrical engineer.
 
Last edited:
So, funny story: I have a 500C display with a BBSHD motor. Worked great, got left in the rain, the LCD layer died from water incursion but the backlight is totally fine (but useless *and* too bright!), and all of the buttons for changing PAS level and on/off work perfectly. I don't know how much voltage is left on my battery, how fast I'm going, or which power level I'm in (except by what would be referred to as dead reckoning in the Age of Sail), but the bike was still perfectly usable for a week so far. I already have one of the new EKD01 displays on the way for now, but I've been thinking a lot about an alternative solution.

I've already 'hacked' the extremely complicated brake cutoff circuit with a big red button I can use like a 'clutch' while shifting gears under power (to cut torque off except from my legs), and I've been researching the throttle interface and am fairly confident I can do some fun stuff with another momentary button that overrides the throttle with +3V from a second circuit (because, seriously, how much time do you spend with a thumb throttle pegged to ~90% of the range? Potentially a lot!), but the display is really the thing I want to get funky with, but it's...too much like modern digital kitchen appliance controls and not enough like the simple caveman electrical systems I already understand confidently.

I'm fine with there being a normal ebike display somewhere on the bike, something you accessed while stopped to look at your odometer etc, but if I could have parallel PAS +/- controls and a better/different power button (so, replicate the right signals on each of those circuits), I think I could do some really cool alternative buttons/switches/etc. on a steampunk or post-apocalyptic art-Ebike for example, or make something extremely weather-proof for something more in the dirt bike/motorcycle class in the future.

Before I spend a ridiculous amount of time teasing what I need to know out of spare controllers/displays on the workbench, does anyone...know how those controls work, already? Are those buttons just momentary switches and the controller just reads each press as a "gimme one more/less PAS level"?

What about the interface the display uses to tell you the PAS level, voltage, etc.? I'm just not sure where to start looking to start untangling that, because it would be so much less work than keeping track of all of that separately (I'm picturing it being very easy for unforeseen errors desynchronizing the actual PAS level from my janky way of tracking it). What's...that area of software/interface on systems like this even friggin' CALLED? Google sure hasn't been getting me anywhere further than where I am now...

I just want to be able to have a few color-coded LEDs and some satisfying clicky ruggedized buttons without needing to learn and master Arduino programming first, but the language barrier is reminding me why I never became an electrical engineer.
Yeah you're right about how the buttons work, they connect to input pins on the microprocessor in the board. The microprocessor/controller then does all the updates to the display and sends a message to the motor controller to change the assist level. Since this is entirely digital now it sends the message via a form of serial communication called UART. You aren't going to be able to do much UART stuff without a microcontroller somewhere unfortunately.

Wouldn't be that hard to intercept the button press or add your own buttons with your own fairly simple circuit that turns on some LEDs. As long as both your circuit and the display reset to the same PAS level when power is lost and no other app or anything else is used to change the assist level I can't really see it getting out of sync that much. Though is it really the end of the world if it does?

I hope I did an okay job keeping it simple with the lingo, I'd be happy to clarify anything.
 
Yeah you're right about how the buttons work, they connect to input pins on the microprocessor in the board. The microprocessor/controller then does all the updates to the display and sends a message to the motor controller to change the assist level. Since this is entirely digital now it sends the message via a form of serial communication called UART. You aren't going to be able to do much UART stuff without a microcontroller somewhere unfortunately.

Wouldn't be that hard to intercept the button press or add your own buttons with your own fairly simple circuit that turns on some LEDs. As long as both your circuit and the display reset to the same PAS level when power is lost and no other app or anything else is used to change the assist level I can't really see it getting out of sync that much. Though is it really the end of the world if it does?

I hope I did an okay job keeping it simple with the lingo, I'd be happy to clarify anything.
You actually put the last piece of the puzzle where it needed to go with the UART interface.

Definitely sounds like hiding a display somewhere and making my own alternative buttons and lights makes the most sense. Also, a fun 'this steampunk electric bike is in a holodeck program and I'm fooling with the settings' vibes when you reveal it.

I just got the EKD01 in the mailbox and managed to hook everything up and find the secret 'actually change the tire size' password (It's "2-0-2-0" in case anyone is googling this in several months like I was for fifteen minutes, lol), so luckily I won't need to try any of this right away.
 
I'm fine with there being a normal ebike display somewhere on the bike, something you accessed while stopped to look at your odometer etc, but if I could have parallel PAS +/- controls and a better/different power button (so, replicate the right signals on each of those circuits), I think I could do some really cool alternative buttons/switches/etc. on a steampunk or post-apocalyptic art-Ebike for example, or make something extremely weather-proof for something more in the dirt bike/motorcycle class in the future.

You can wire momentary N.O. switches in parallel with any or every switch in the display, or handlebar controls, etc., and put those switches wherever you like. Every time any switch in that parallel circuit is closed it will trigger whatever the original one did.



Before I spend a ridiculous amount of time teasing what I need to know out of spare controllers/displays on the workbench, does anyone...know how those controls work, already? Are those buttons just momentary switches and the controller just reads each press as a "gimme one more/less PAS level"?
Yes, they are momentary switches, *but* the controller doesnt' read them. The display MCU does, and serially communicates this data to the controller.



What about the interface the display uses to tell you the PAS level, voltage, etc.? I'm just not sure where to start looking to start untangling that, because it would be so much less work than keeping track of all of that separately (I'm picturing it being very easy for unforeseen errors desynchronizing the actual PAS level from my janky way of tracking it). What's...that area of software/interface on systems like this even friggin' CALLED? Google sure hasn't been getting me anywhere further than where I am now...

UI or GUI (User Interface / Graphic ...) is the general area of interface systems design. It's hard to get right for general usage, most designers don't understand it or get it right, many don't appear to try but instead just make something "look cool" for marketing, rather than making it really usable in the specific situations it's intended for. (I've worked hard to get various companies / designers to do it right or fix things in software and hardware over the decades, but almost always to no avail; I rarely try anymore).

Most use a serial interface of some type, sometmies called UART, sometmies a different serial bus liek CANbus, or one of the various one-wire interfaces (SPI, I2C, etc).

See below for some info on decoding.


I just want to be able to have a few color-coded LEDs and some satisfying clicky ruggedized buttons without needing to learn and master Arduino programming first, but the language barrier is reminding me why I never became an electrical engineer.
That's the problem I have with all the projects I now want to do--they all require some form of programming (which I know the basics of from decades ago, but not for modern systems....and I really don't like doing programming either).

But if you want to have a different kind of UI than the the LCD, you will have to use something (arduino, ESP, ATT, etc) to read the serial data from the controller and send it to the UI you want. You dont' have to read the switches and do all the processing to send those as serial data to the controller, if you keep the original display's MCU board (hidden in a box or bag somewhere, etc), as it can still do that job. The switches can simply be wired directly to that original board in parallle with the original switches.

To decode the data, you can use a "logic analyzer" software on the computer (see another recent thread I posted in
doing something similar; sorry i can't remember the name so no link) to read the serial data for each new thing that shows up on the display, and then write your software for the LED driver MCU to decode the specific data to drive specific LEDs, etc.

There are also some general "protocol" threads that may help

and this


Something that will also help is the various open-source projects that make replacement display software to let different displays work with different controllers, and vice-versa, some of them on Github, some of them here on the forum, like these:

etc.
 
You can wire momentary N.O. switches in parallel with any or every switch in the display, or handlebar controls, etc., and put those switches wherever you like. Every time any switch in that parallel circuit is closed it will trigger whatever the original one did.




Yes, they are momentary switches, *but* the controller doesnt' read them. The display MCU does, and serially communicates this data to the controller.





UI or GUI (User Interface / Graphic ...) is the general area of interface systems design. It's hard to get right for general usage, most designers don't understand it or get it right, many don't appear to try but instead just make something "look cool" for marketing, rather than making it really usable in the specific situations it's intended for. (I've worked hard to get various companies / designers to do it right or fix things in software and hardware over the decades, but almost always to no avail; I rarely try anymore).

Most use a serial interface of some type, sometmies called UART, sometmies a different serial bus liek CANbus, or one of the various one-wire interfaces (SPI, I2C, etc).

See below for some info on decoding.



That's the problem I have with all the projects I now want to do--they all require some form of programming (which I know the basics of from decades ago, but not for modern systems....and I really don't like doing programming either).

But if you want to have a different kind of UI than the the LCD, you will have to use something (arduino, ESP, ATT, etc) to read the serial data from the controller and send it to the UI you want. You dont' have to read the switches and do all the processing to send those as serial data to the controller, if you keep the original display's MCU board (hidden in a box or bag somewhere, etc), as it can still do that job. The switches can simply be wired directly to that original board in parallle with the original switches.

To decode the data, you can use a "logic analyzer" software on the computer (see another recent thread I posted in
doing something similar; sorry i can't remember the name so no link) to read the serial data for each new thing that shows up on the display, and then write your software for the LED driver MCU to decode the specific data to drive specific LEDs, etc.

There are also some general "protocol" threads that may help

and this


Something that will also help is the various open-source projects that make replacement display software to let different displays work with different controllers, and vice-versa, some of them on Github, some of them here on the forum, like these:

etc.
Ooh! Extremely cool. Thanks!

Also, wow, I don't think I've ever had such a strong "and that's why you should use a Tongsheng on the next ebike," epiphany than just now. The BBS02 little brother to the BBSHD fat bike can wait, I wanna get into that open source community.
 
IIRC, BBS has OSF too, but I've not kept up with the threads, so not sure if that's just for the displays or includes the controllers as well.

Note that mechanically the TSDZ systems (all versions so far) suffer greatly from typical poor engineering understanding, so there are multiple design flaws that make them unsuitable for some usages. The worst is the circlip grooves on the axle/BB shaft, so that the repetitive circular cycling stresses of pedalling will fracture and break the axle at that groove, without user-modification of the system to add outboard bearings to support the axle (see Elinx (?) posts about that), or replacing the axle with a user-made version that has no weakpoint circlip grooves, etc. If you are not "really" pedalling, and just letting the system do the work for you, it's not much of an issue. But for "real pedallers" that exert significant torque on the cranks, it's going to fatigue that axle there, and break while you're riding, leaving that whole crank arm laying on the road with your foot and leg and you unsupported, almost certainly on a powerful downtroke moment. :(
 
Yeah there is OSF for the bbsx motor controllers themselves, not just the display.

Are you familiar with TTL logic chips? If no, I apologize for a heavy dose of lingo. If yes though you could use a decade counter chip and BCD to seven segment display converter chip to make a simple circuit that displays the assist level on well, a seven segment display. The only thing I would be worried about is ensuring it would show level zero on power on. Oh and debouncing the button presses. Okay maybe it wouldn't be the simplest circuit in the world, but there wouldn't be a microprocessor or any code involved :p Would also be pretty cheap, I would say <$20 in supplies though I haven't bought TTL chips in a long time.

For voltage you could always get a sweet old school dial voltmeter and slap that on the handlebars. Same with current. Very steampunk.
 
A circuit like that would "work" but as you previously noted, it may not remain synced with the actual state of the controller. To do that you'd need to use something to read the serial data stream to/from the display/controller. It wouldnt' have to be an MCU, but it could be complicated to build one out of discrete logic, and probably quite large. :(



But if you really wanted to build just a discrete-logic display system, I'd actually use the CMOS 4000 versions of the chips, since many of those don't require straight 5v to run, and can run on up to 15v+. (not all can, but most of the 4000-series have versions that can, vs the 74xx series, whether TTL or CMOS). Makes it easier to power by battery, more tolerant of voltage variations.

You can probably even salvage all the chips out of old circuit boards if you're willing to poke around inside really old stuff if you have any laying around. ;) It would probably be cheaper to buy modules already designed for the purpose (see places like adafruit and sparkfun, or even mouser, digikey, etc****), but less fun. I used to do this quite a lot because I didn't have any money to buy new parts; nowadays it's much harder to find things with these parts so if I ever did need to do it again I'd probably just buy new parts. :/ (plus I have less patience or time or energy for all the salvaging, evne though it is much more fun)

7-seg LED drivers and displays are often built into ancient cable boxes, for instance. Other logic chips may be in very old computer or "digital" equipment; even some decades-old VCRs, radios, cd players, etc., have some discrete logic chips in them.

Most of the old LED displays are not daylight readable, though, so you might need a sunshade over it. Some modern ones are pretty good...but if you ride both day and night I'd put an automated dimmer on there with a photocell. (the old Forrest Mims books have circuits for that, if you find them online).
 
Back
Top