Bafang BBSHD BBS02 mid drive -- Flexible OpenSource firmware

[casainho]

There is a standard for wireless ebike: ANT+ LEV, but that has a license to be paid for using it, so, would manufacturers do it? Only big brands and no cheap ebike components like this DIY motors.

We use the ANT+ LEV on our EBike wireless controller, as also ANT+ Controls on the wireless remote, to control the cycling GPS display, for changing the pages.

 

[tomjasz]

Hey Krusty

If there's any interest in this project and sharing the dev work on it I'd be happy to put it out there.

Your work is very interesting. Maybe you can renew the TSDZ2_wireless app from opensourceebike.github.io, with your findings? The app is a great start, but it lacks at

I my opinion it doesn't make sense to put further development into systems that are Bafang UART based. They announced to only produce CAN based controller and communication in the near future, at least for Bafang Ultra G510. Due to this, an alternative firmware like this OpenSource (TDSZ) firmware is a must.

Cheers

Bafang BESST used to work offline and online. But now Bafang BESST can only be used online and with an access limited to approved users. The motors I love and support I hate!

 

[raylo32]

The parallel here is Bafang behaving like Apple, trying to lock down their ecosystem. The other part of the parallel is that like Apple, Bafang will tell you that you don't need a feature that you really really want and would be really really useful, like a torque sensor. And all the Bafang fanboys who don't like to pedal bikes chime in to echo that party line. That's why as good as the motors seem at the price point, I will never own one. Now maybe they'll surprise me and create a torque upgrade for the BBSHD... but I am not holding my breath.

Cheers

Bafang BESST used to work offline and online. But now Bafang BESST can only be used online and with an access limited to approved users. The motors I love and support I hate!
[/quote]

 

[tomjasz]

Most Bafang DIY BBSxx series buyers could give a shit about torque sensing. They buy the BBSHD because it's a fast motor. A majority of buyers are throttle users. And that's from 6 years of providing support to kit buyers. But as always your mileage may vary.

 

[raylo32]

I know all that. But the question is why Bafang leave out a significant *additional* market. So us riders who like to pedal and ride with others have to go TSDZ2 on the low end and CYC on the higher end. Bafang should make a torque version of BBSHD as a +$75 option. They'd sell a lot more units.

Most Bafang DIY BBSxx series buyers could give a shit about torque sensing. They buy the BBSHD because it's a fast motor. A majority of buyers are throttle users. And that's from 6 years of providing support to kit buyers. But as always your mileage may vary.

 

[AZeBikeGuy]

I always pedal, 100% of the time, have ridden torque sensor bikes and don't like them at all, vastly prefer cadence sensing... always pedaling and a preference for cadence sensing are far from mutually exclusive

 

[COAR]

I always pedal, 100% of the time, have ridden torque sensor bikes and don't like them at all, vastly prefer cadence sensing... always pedaling and a preference for cadence sensing are far from mutually exclusive

What do you prefer about the cadence sensor? I've always assumed torque sensing would be better for mt biking but I've only ridden one only briefly around a parking lot.

 

[tomjasz]

I know all that. But the question is why Bafang leave out a significant *additional* market. So us riders who like to pedal and ride with others have to go TSDZ2 on the low end and CYC on the higher end. Bafang should make a torque version of BBSHD as a +$75 option. They'd sell a lot more units.

Most Bafang DIY BBSxx series buyers could give a shit about torque sensing. They buy the BBSHD because it's a fast motor. A majority of buyers are throttle users. And that's from 6 years of providing support to kit buyers. But as always your mileage may vary.

Sales are brisk and unless they see a demand they won't oblige. I'm not convinced that sales would spike.

 

[AZeBikeGuy]

What do you prefer about the cadence sensor? I've always assumed torque sensing would be better for mt biking but I've only ridden one only briefly around a parking lot.

Fair question

There's more than a few reasons but for the most part this sums it up:

I don't like having to adjust pedal pressure to increase or decrease the amount of assist - I just use the buttons or if I need fast or fine response just use the throttle to control the amount of assist while still pedaling...

I also like when I press harder on the pedals I do get more power to the pedals albeit it's only my own power being the additional. I typically run fairly low power for assist, generally only 150-350W so my pushing is a significant fraction of that and I can feel the effects of my work.


To be clear the only times I'm not pedaling is coasting when the motor isn't providing any power... if the motor is turning so are my legs whether throttle for controlling the amount of assist or just leaving it up to the PAS... unless the terrain is varying like MTB single track I'm using the PAS and often have it on even when on MTB trails - when they get steep and gnarly where I'm doing fine technical stuff I'll generally just use the throttle to control the assist amount since it's so precise and responds instantly but in this case I want the motor to respond with complete predictably to my wrist movement and not have a torque sensor trying to out-think me or contaminate my wrist commands and force I'm applying with my legs so to speak

I'm past 7000mi on the BBSHD build but have ridden a lot of other bikes including some torque sensing (like Ultra)... didn't like them at all... gave them a chance thinking I just need to get used to them but I just don't like them and hope I never have to deal with one on my own bike...

I think it's a matter of personal preference and I've come across plenty of folks in the same camp as I am sometimes for similar reasons and sometimes for completely different reasons... I know folks that prefer the torque sensing and I think you're right in that most of them come from a lot of MTB riding. I've ridden MTB's since they first came out around 1980 but I'm very cross sport and while I've got plenty of MTB time I've got vastly more time doing other sports so perhaps that changes things... or not...

 

[krusty]

There is a standard for wireless ebike: ANT+ LEV, but that has a license to be paid for using it, so, would manufacturers do it? Only big brands and no cheap ebike components like this DIY motors.

We use the ANT+ LEV on our EBike wireless controller, as also ANT+ Controls on the wireless remote, to control the cycling GPS display, for changing the pages.

Casainho, I did some light research on ANT+ LEV, BLE and alternatives today. I have to say I'm not wild about any of them for various reasons. ANT is controlled by Garmin, which is a big negative in my book. Nothing against Garmin in particular but if we learned anything in the '80s and '90s it is that individual companies should not control specifications. Bluetooth is maybe a little better in that regard (not 100% sure on that) but in any case their license fees are absurd: $4000 just to be able to distribute a device regardless of the size of the company. They have no provision for smaller applications or open source users that I could find.

On the tech side, the advantage of ANT is that it lets devices pair and talk to multiple controller/displays. The disadvantage (based on my brief investigation) is that the device definitions seem inflexible so to do anything beyond basic data relay you'd have to tack on the "ANT FS" file sharing protocol. I'm thinking in particular about how to allow for changing arbitrary settings in the motor controller by the display (and ideally allow for remote firmware updates). But, at least for me, an even bigger disadvantage is that my phone (Pixel 4) doesn't support ANT! It seems that older Android devices used to have it but over time it has been disappearing, though Samsung phones still have it.

Also, from my perspective it doesn't make a lot of sense to use a dedicated device like those Garmin units, at least not at the prices they charge. I think a throwaway Android phone gives you a whole lot more for the money: better display, processor and the ability to run any app you want. To be honest I'm surprised Garmin is still in business, but their stock has been shooting up so I guess their products must sell. For my part I'd rather stick to general purpose devices running a relatively open OS.

BTW I noticed a bit of convergent evolution: your man-in-the-middle unit has the same guts as my Nano33 BLE (Nordic nRF52840). That device also supports IEEE 802.15.4, which means it can do Zigbee and a few other protocols. Since I'm souring on Bluetooth due to its licensing I'm thinking I might rewrite my stuff to use something open source for the radio carrier layer. Any interest in collaborating on the man-in-the-middle piece to come up with a cross platform device + app? I was thinking it would be really fun to use this module and have a sweet little display right on the unit: https://www.makerfabs.com/makepython-nrf52840.html

-krusty

 

[casainho]

On the tech side, the advantage of ANT is that it lets devices pair and talk to multiple controller/displays. The disadvantage (based on my brief investigation) is that the device definitions seem inflexible so to do anything beyond basic data relay you'd have to tack on the "ANT FS" file sharing protocol. I'm thinking in particular about how to allow for changing arbitrary settings in the motor controller by the display (and ideally allow for remote firmware updates). But, at least for me, an even bigger disadvantage is that my phone (Pixel 4) doesn't support ANT! It seems that older Android devices used to have it but over time it has been disappearing, though Samsung phones still have it.

Also, from my perspective it doesn't make a lot of sense to use a dedicated device like those Garmin units, at least not at the prices they charge. I think a throwaway Android phone gives you a whole lot more for the money: better display, processor and the ability to run any app you want. To be honest I'm surprised Garmin is still in business, but their stock has been shooting up so I guess their products must sell. For my part I'd rather stick to general purpose devices running a relatively open OS.

BTW I noticed a bit of convergent evolution: your man-in-the-middle unit has the same guts as my Nano33 BLE (Nordic nRF52840). That device also supports IEEE 802.15.4, which means it can do Zigbee and a few other protocols. Since I'm souring on Bluetooth due to its licensing I'm thinking I might rewrite my stuff to use something open source for the radio carrier layer. Any interest in collaborating on the man-in-the-middle piece to come up with a cross platform device + app? I was thinking it would be really fun to use this module and have a sweet little display right on the unit: https://www.makerfabs.com/makepython-nrf52840.html

I think the EBikes uses ANT+ LEV to follow a standard but any specific manufacturer configuration or data is sent by Bluetooth. We are just doing that on TSDZ2, configurations using a mobile app (Bluetooth) and ANT+ LEV for the displays that support it.

Yes, Garmin devices are very expensive but include advanced features and metrics for cycling. Anyway, with our EBike wireless controller, the user can use our mobile app and optionally an ANT+ LEV cycling display as there are few brands, not only Garmin, still I think we developers only have Garmins.

Note that Garmin cycling GPS displays are very popular on the cycling because they do develop very specific hardware and software (fitness metric algorithms) for cycling. There are very high tech and expensive sensors, like pedal power meters with costs over 500 euros, or even ANT+ tire pressure sensors.

I am not very experienced to be able to structure and start a big project as you mention. Also I do not believe on our own display, for the same reasons you did mention, like phones are more powerful and much easier ans faster to develop for.
Developing for a Garmin device is much faster, but the costs is then passed to user because the devices are expensive. Anyway, why would I be developing so much, taking a lot of my life, just to save money to final user while he would pay nothing for it??
Also the Garmin devices has important features that I would never be able to implement, like GPS map navigation. The true is that EBike brands like Bosch are developing their own GPS navigation displays (very expensive!!) but we will never be able to do that, so, better to join Garmin and let the user pay the fair price for all the advance features. For the users not wanting the advanced feature, then the basic mobile app is free and easy to have it working.

Good luck on your project but I am not experienced enough and I do not have energy for such project.

 

[qwerkus]

I don't get the whole hype about going wireless just to use expensive garmins. Wireless is never as responsive as wired, and you'll require an extra battery for each peripheral you want to integrate. 10 years ago, some high end manufacturers in europe like simplon went wireless ant+lev, and they quickly dropped it for a good reason. The battery hassle and connection problems are just not worth the few extra cables you need. To be fair, ebike protocols are rather simple, so even a canbus is overkill in my opinion. But maybe I'm missing an important point ?

But back to the topic. I don't think there is a need for a bbs open source firmware. The stock one is programmable, and works just fine with pas. Sure you could tweak it to make it maybe a tad smoother, but not worth the effort in my opinion. Torque sensor would be nice, but I don't think bafang is going to deliver one, since they're pushing heavily their integrated mid drives and go all the way down the locked path. Some alternate products, like the lightest ebike kit might replace it at some point, though at a premium and with nowhere the same power levels.

 

[krusty]

I am not very experienced to be able to structure and start a big project as you mention. Also I do not believe on our own display, for the same reasons you did mention, like phones are more powerful and much easier ans faster to develop for.
Developing for a Garmin device is much faster, but the costs is then passed to user because the devices are expensive. Anyway, why would I be developing so much, taking a lot of my life, just to save money to final user while he would pay nothing for it??
Also the Garmin devices has important features that I would never be able to implement, like GPS map navigation. The true is that EBike brands like Bosch are developing their own GPS navigation displays (very expensive!!) but we will never be able to do that, so, better to join Garmin and let the user pay the fair price for all the advance features. For the users not wanting the advanced feature, then the basic mobile app is free and easy to have it working.

Good luck on your project but I am not experienced enough and I do not have energy for such project.

Sir, you are far too modest! I think the amazing firmware stuff you've done is far more impressive and difficult than the display/app side. I disagree that a dedicated unit has any advantages over a phone, though. For example you mentioned GPS navigation but actually that's pretty easy to add into Android apps using Google Maps or another map provider. In fact I was planning on doing that in my display app in phase 2, if I ever get to it, Really I can't imagine that the hardware in a dedicated unit would even match, let alone surpass, what you get ridiculously cheap in a phone these days (e.g. $129 Xiaomi Poco.) To me the question is why Garmin doesn't sell their software to run as an app, but the answer is obvious: $$$!

But no worries, I'm also only doing this for fun and I already spend too much time coding at work. I'll keep banging away on my setup when time permits and see where it leads. Keep up your great work!

Krusty

 

[krusty]

I don't get the whole hype about going wireless just to use expensive garmins. Wireless is never as responsive as wired, and you'll require an extra battery for each peripheral you want to integrate. 10 years ago, some high end manufacturers in europe like simplon went wireless ant+lev, and they quickly dropped it for a good reason. The battery hassle and connection problems are just not worth the few extra cables you need. To be fair, ebike protocols are rather simple, so even a canbus is overkill in my opinion. But maybe I'm missing an important point ?

But back to the topic. I don't think there is a need for a bbs open source firmware. The stock one is programmable, and works just fine with pas. Sure you could tweak it to make it maybe a tad smoother, but not worth the effort in my opinion. Torque sensor would be nice, but I don't think bafang is going to deliver one, since they're pushing heavily their integrated mid drives and go all the way down the locked path. Some alternate products, like the lightest ebike kit might replace it at some point, though at a premium and with nowhere the same power levels.

Qwerkus, in general I agree but the reason I went with Bluetooth in my project is that I tried using a direct connection first and found a big problem: you can't charge the phone and connect it at the same time! I found I could easily use a phone to control the Bafang through a UART-USB bridge but I couldn't find any bridges that also allow charging (at least not in the right direction). So to get around this I switched to using Bluetooth and the man-in-the-middle device but the real reason was only that I wanted to keep the charge port free.

Later I realized there are some other advantages to this setup: the middleman keeps doing its stuff even if the display is not connected or off. That means you can still record all kinds of data and you don't lose, e.g. trip distance, etc. if the display is off. And you can more easily go headless, which I wouldn't be interested in but it seems a lot of people are.

As for latency it isn't too bad. Passive stuff broadcast from the middleman is plenty fast; the real concern is with interactions--will the controller get its orders quickly enough? In my implementation you can easily see the latency because after I send a PAS+/- command it only shows the new PAS level once it has been confirmed by querying the controller. I haven't clocked it but it is definitely in the usable range, probably something like 300ms from pressing the button on the phone to seeing the digit change on the display.

Krusty

 

[Tomblarom]

To be fair, ebike protocols are rather simple, so even a canbus is overkill in my opinion. But maybe I'm missing an important point ?

I my opinion latency isn't a real issue anymore. There are companies like SRAM, with wireless shifting systems, that are surely fast enough without any noticeable delay. Battery was also a concern, when I heard about it the first time, but to be honest: They last very long and aren't that much of a hassle to swap half a year. I'm doing a lot of Enduro MTB and avoiding cables everywhere possible is freeing up your bike. Falling, getting caught or even ripping cables, isn't fun.

UART may not be that slow, but the Bafang implementation definitely is! You could use UART better implemented, but CAN is a lot more robust, especially when hooking up multiple devices onto the bus.

you can't charge the phone and connect it at the same time!

I use this wireless Quadlock moto charger. Rock solid and easy to use!

@krusty do you received my private message?

 

[casainho]

Sir, you are far too modest! I think the amazing firmware stuff you've done is far more impressive and difficult than the display/app side.

No I am not. The display firmware is complex, uses linked lists which I do not known how to implement... because the structure of the firmware was done by a experienced developer... I am being learning a lot with others while doing this projects.

 

[danielnilsson9]

I'm still stuck on the weird sporadic throttle readings and have grew kind of tired of this and is not really actively working on it anymore. I have been unable to implement any good filtering as the stack space on this microcontroller is so ridiculously small (128 bytes) that I can basically do no more calculations without heavily optimizing the rest of the firmware. Setting medium or large memory model in SDCC seem to produce non working code, or I have not found the correct parameters.

I have been going through a disassembly of the original firmware and have obviously found the throttle reading code and have implemented a version which matches it closely but to no help. So my best guess would be that they had the same issue in the original firmware and managed to filter it out somehow. My 8051 assembly reading skills are too bad though to follow the additional processing of the sampled value which may be present... anyone able and willing to give it a go?

 

[casainho]

I'm still stuck on the weird sporadic throttle readings and have grew kind of tired of this and is not really actively working on it anymore. I have been unable to implement any good filtering as the stack space on this microcontroller is so ridiculously small (128 bytes) that I can basically do no more calculations without heavily optimizing the rest of the firmware. Setting medium or large memory model in SDCC seem to produce non working code, or I have not found the correct parameters.

I have been going through a disassembly of the original firmware and have obviously found the throttle reading code and have implemented a version which matches it closely but to no help. So my best guess would be that they had the same issue in the original firmware and managed to filter it out somehow. My 8051 assembly reading skills are too bad though to follow the additional processing of the sampled value which may be present... anyone able and willing to give it a go?

Sad to see you are blocked. I can not help.

And about the original signal, where you able to log it and see the issue on the logged value? I would suggest for you to log it over UART, at the max sample frequency possible and then show here a graph. With that data log and visual image, we can then think on a possible solution and even simulate some simple math filter on Octave/Mathlab and run that data log over the Octave/Mathlab, to see how the possible math filter behaves and if it actually works.

 

[Cybernetica]

Hey guys,

Has there been any updates on this?
I'm super exited about this project but I'm running BBS02 motor. Is there original firmware for newer BBS02 motors floating around so I could test this BBSHD firmware on BBS02?

 

[tomjasz]

Hey guys,

Has there been any updates on this?
I'm super exited about this project but I'm running BBS02 motor. Is there original firmware for newer BBS02 motors floating around so I could test this BBSHD firmware on BBS02?

With what goal in mind?

 

[Cybernetica]

With what goal in mind?

For me personally the biggest benefit would be 2 different modes for assist (Legal/Off road setting) without this I'm risking hefty fines every day I ride. This is so important to me, that if this thing is ever finished I would be easily willing to spend 50$ for it.

Recently due to popularity of super fast electric scooters going above 60KM/H local law enforcement has been giving more attention to legality of electric vehicles on the streets. Even though I'm trying to be responsible biker never going fast on sidewalks and bike properly fitted with safety equipment I simply cannot accept the fact that I can't sometimes use my motor over 25 km/h in traffic if I can easily pedal over that without an motor and it's even legal to do so until 50km/h in city traffic.

Then came the idea of somehow setting up 2 different profiles, one that allows riding over speed limits and one that does not. With these set up, just maybe I can talk my way out of a ticket.

I'm yet to find another viable solution other than switching my brand new 850C display unit to Eggrider that costs another 100$ and has way inferior display unit itself with very small non-color display.

 

[tomjasz]

Dillenger came out with a device that allowed a quick change but it seems to have bombed. I sent my sample to California eBike but Doug sold the shop and I never got it back to test. You might try them.

I don’t know if any firmware solution to you desired function.

If you get busted speeding what good does a dumbed down version do? Guessing you’re down under or in the EU?

 

[tomjasz]

https://www.pedelecs.co.uk/forum/threads/bbs02-tuning-for-muppets-dillenger-switcheroonie.24807/

 

[Cybernetica]

Dillenger came out with a device that allowed a quick change but it seems to have bombed. I sent my sample to California eBike but Doug sold the shop and I never got it back to test. You might try them.

I don’t know if any firmware solution to you desired function.

If you get busted speeding what good does a dumbed down version do? Guessing you’re down under or in the EU?

Yes, EU.

Thing is, that you can pedal to 50 KM/H just your motor cannot assist over 25 KM/H.
I know it's stupid, but when caught "speeding" I can say I just used my pedals.

 

[danielnilsson9]

I'm still stuck on the weird sporadic throttle readings and have grew kind of tired of this and is not really actively working on it anymore. I have been unable to implement any good filtering as the stack space on this microcontroller is so ridiculously small (128 bytes) that I can basically do no more calculations without heavily optimizing the rest of the firmware. Setting medium or large memory model in SDCC seem to produce non working code, or I have not found the correct parameters.

I have been going through a disassembly of the original firmware and have obviously found the throttle reading code and have implemented a version which matches it closely but to no help. So my best guess would be that they had the same issue in the original firmware and managed to filter it out somehow. My 8051 assembly reading skills are too bad though to follow the additional processing of the sampled value which may be present... anyone able and willing to give it a go?

Sad to see you are blocked. I can not help.

And about the original signal, where you able to log it and see the issue on the logged value? I would suggest for you to log it over UART, at the max sample frequency possible and then show here a graph. With that data log and visual image, we can then think on a possible solution and even simulate some simple math filter on Octave/Mathlab and run that data log over the Octave/Mathlab, to see how the possible math filter behaves and if it actually works.

Good news! I got some time and energy to pick up this project again and I have finally found the issue which caused me to abandon this previously.

Interrupts! Dangerous on 8051 with SDCC. You are not allowed to do int 16/32 multiplications or divisions inside interrupt service routines or bad things will happen (stack or register corruption). This caused other calculations in the main code to give the wrong result causing various weird glitches.

Anyway, I will continue to work on finishing this firmware now!