smorgasbord
Well-Known Member
- Region
- USA
This will be 2 Posts: One on the decoding procedure and results, and then a starter post on how to tune based on the revolutionary new discovery. I predict (and hope!) that this thread will get quite long as people re-evaluate their own tunings in light of the new information presented here, and make new, improved, tunings.
Part 1:
The Bafang Ultra motor has been around since at least 2017, maybe even earlier. Yet, what has been published to date by everyone about the Torque Tab is, to be blunt, flat-out wrong.
How could this be? Well, it starts with Bafang extending the Basic/Pedal/Throttle interface for their previous set of hub motors (BBS01, BBS02 and BBSHD) to add a new tab for the Ultra. Then, while a bunch of reverse engineering went into figuring out how the Basic, Pedal, and Throttle tabs worked for the cadence-sensing BBS01 and BBS02, almost none has gone into the Ultra - at least none that has been reported on the internet. Compounding the problem is that it seems people just assumed things in the existing tabs were the same, when in fact the Ultra motor with its torque sensor is quite different than its predecessors. Whatever the reasons, the fact remains that incorrect advice has been given by everyone - hackers and even by bicycle OEMs - on tuning this motor.
How did I find this out? (Or, more bluntly, how can I be sure of myself?) Here's the long story long:
My wife and I have had our Ultra-powered bikes for a few years now. I read all the guides and played around with tuning, but frankly, I mostly saw limited change and hardly any improvement except for the PAS levels. Promises of torque-controlled, "smooth" powering, etc. were all empty promises in my experience. Then a couple months ago a sharp-edged wiring grommet caused a short-circuit that fried the controller board. That led me to getting an Ultra professionally repaired, which as a result was set back to the default controller settings. And so I was looking at redoing the prior mods and pondering, again, why these mods weren't delivering the promised results. I came across a post on another eBike forum by @ProphetZarquon, which helped me to understand how the Delta Voltage section works, but the Spd Table portion was still very much a mystery to me. Then, Zarquon claimed something about the Spd table that was not just different from what everyone has posted, it was actively contradicted by one of the early Ultra tuners. I asked him about that contradiction, and he suggested I test it to prove it to myself.
And so I did. But, the results surprised both of us!
If you've done Ultra tuning in the past, you might be familiar with the Torque tab. If you're using the pretty commonly available Windows software, it looks like this:
I use an EggRider (which I highly recommend), so the layout is different, but the fields are the same. The top section is the Delta Voltage table. I have previously described how that works and have suggestions on how to set it up here.
Now some of how the Spd Table works is pretty straightforward. When you press on the pedals, the Ultra's torque sensor outputs a voltage based on the force being applied. The Delta Voltage table specifies how that voltage is converted to a Kg, and that Kg number is used by the Spd Table's Start, Full, and Return parameters to return what I call a Percentage of Current (POC) as determined by the MinCur, MaxCur, and KeepCur parameters to be sent down the controller pipeline. It's mostly pretty straightforward:
The Prophet told me that was wrong. I decided to find out for myself. Even if it was indeed cadence related as everyone else said, I wanted to get a feel for what pedal rpms mapped to which columns to help me decide what settings were best for me.
I started by devising a set of Spd Table values to isolate what was happening. Essentially, I made MinCur=0 and MaxCur=1 for all Spd table columns except one (Spd40). That way I'd get motor assist only when that column was active. I found that Spd40 was the easiest to safely test on flat roads, and I set MinCur at 50% and MaxCur at 100% there so the power on would be noticeable. With a low PAS level for controller safety (to limit the max amps that could possibly be sent to the motor), I'd ride out in the lowest gear I have (50 tooth rear cog) from a stand still up to as fast as I could pedal, trying to note when power came on and went off. Then I'd repeat the test in the highest gear (10 tooth rear cog) and note the difference in when the power came on. I could use the display's KPH readout as a proxy since the 5X cadence to bike speed difference in the two extreme gears should show up easily there.
So I rode out in bottom gear, and power ramped up starting at about 6 KPH, going away at about 13.5 KPH. It was a ramp-up, ramp-down effect, which was nice. Then I rode out in top gear down the same stretch of road. If the gurus were correct, the power should have ramped-up at about 30 KPH (18-19MPH) (since bike speed in top gear would be 5X bottom gear at the same pedal cadence).
Well, damn if the power didn't ramp-up at the same 6 KPH, and down at the same 13.5KPH! WTF!?!?
OK, so repeat the test and get the same results.
Hmm, I edit the Torque tab to make Spd20, and then Spd60 the only active column and sure enough, it didn't matter how fast I was turning the pedals, the power-up/power-down moments came at the same bike speed within each SpdXX range.
@ProphetZarquon believed the XX in SpdXX were a percentage of the specified Pedal Tab's Speed Limit (either directly via a number or vectored to the display's Speed Limit setting), but my testing found no difference in SPDXX column engagement by changing those Speed Limit values. I have video I can share.
But, then it got even weirder! To see if it really was bike speed related I changed the Wheel Diameter in the Basic tab since that would change the bike speed calculation (number of wheel sensor pings per unit of of time multiplied by wheel circumference). But yet again, the SpdXX colums ramp-up/ramp-down points were at the same KPH!
So, it wasn't actual bike speed that was in control, it was Wheel RPM. I confirmed this by setting the number of Wheel magnets in the Basic tab to 2, even though I still only had 1. Now my Display's KPH was wrong, so I used a GPS speed app on my phone, but sure enough now the ramp-up for Spd40 was at 12 KPH and ramp-down at about 27 KPH - both about double the previous setting's results. With the Ultra thinking it took 2 magnet pings to get a single wheel revolution, I had to go twice as quickly to get the same engagement results.
This is astounding. It's taken 6-7 years to finally figure out what the SpdXX columns represent in the Bafang Ultra's Torque Table. They represent Wheel RPM.
By running my single column isolation test 6 times to cover all 6 SpdXX columns I was able to reverse engineer the values:
Now, these values are approximate. First, the purview of the columns overlap as you can see in the results above. I mentioned earlier that with just one column actionable the power would ramp up as the bike speed entered the KPH range and ramp down as the bike speed exited the KPH range. I believe this is an intentional feathering so that if you have wildly different values in adjacent columns the motor's reaction won't be abrupt, but will feather/ramp/scale between the two columns' values. Nice. Second, I'm riding and looking/recording the display, and there are lags all over the place. When does the display report applied motor power? How quickly do the KPH values update? What's the screen refresh rate on my iPhone (about 40 fps, btw)? I don't have access to a stationary bike trainer with integrated power output, but that combined with some controllable/repeatable motor to drive the Ultra's crankshaft would be a more scientific way to approach this. Third, I had a slightly (10%-ish) incorrect Wheel Circumference in my Display.
To conclude Part 1, since the real deal is Wheel RPM and not Bike Speed, those bike speed numbers should be converted into Wheel RPM (just math):
Here's what the controller activates on:
The Out Wheel RPM seems pretty linear at 10, 20, 30, 40, but then 55/56.
And again, multiple disclaimers on the above:
Part 1:
The Bafang Ultra motor has been around since at least 2017, maybe even earlier. Yet, what has been published to date by everyone about the Torque Tab is, to be blunt, flat-out wrong.
How could this be? Well, it starts with Bafang extending the Basic/Pedal/Throttle interface for their previous set of hub motors (BBS01, BBS02 and BBSHD) to add a new tab for the Ultra. Then, while a bunch of reverse engineering went into figuring out how the Basic, Pedal, and Throttle tabs worked for the cadence-sensing BBS01 and BBS02, almost none has gone into the Ultra - at least none that has been reported on the internet. Compounding the problem is that it seems people just assumed things in the existing tabs were the same, when in fact the Ultra motor with its torque sensor is quite different than its predecessors. Whatever the reasons, the fact remains that incorrect advice has been given by everyone - hackers and even by bicycle OEMs - on tuning this motor.
How did I find this out? (Or, more bluntly, how can I be sure of myself?) Here's the long story long:
My wife and I have had our Ultra-powered bikes for a few years now. I read all the guides and played around with tuning, but frankly, I mostly saw limited change and hardly any improvement except for the PAS levels. Promises of torque-controlled, "smooth" powering, etc. were all empty promises in my experience. Then a couple months ago a sharp-edged wiring grommet caused a short-circuit that fried the controller board. That led me to getting an Ultra professionally repaired, which as a result was set back to the default controller settings. And so I was looking at redoing the prior mods and pondering, again, why these mods weren't delivering the promised results. I came across a post on another eBike forum by @ProphetZarquon, which helped me to understand how the Delta Voltage section works, but the Spd Table portion was still very much a mystery to me. Then, Zarquon claimed something about the Spd table that was not just different from what everyone has posted, it was actively contradicted by one of the early Ultra tuners. I asked him about that contradiction, and he suggested I test it to prove it to myself.
And so I did. But, the results surprised both of us!
If you've done Ultra tuning in the past, you might be familiar with the Torque tab. If you're using the pretty commonly available Windows software, it looks like this:
I use an EggRider (which I highly recommend), so the layout is different, but the fields are the same. The top section is the Delta Voltage table. I have previously described how that works and have suggestions on how to set it up here.
Now some of how the Spd Table works is pretty straightforward. When you press on the pedals, the Ultra's torque sensor outputs a voltage based on the force being applied. The Delta Voltage table specifies how that voltage is converted to a Kg, and that Kg number is used by the Spd Table's Start, Full, and Return parameters to return what I call a Percentage of Current (POC) as determined by the MinCur, MaxCur, and KeepCur parameters to be sent down the controller pipeline. It's mostly pretty straightforward:
- The rider-applied pedal force is converted into the POC using a linear mapping: Start(Kg) produces MinCur(%) while Full(Kg) produces MaxCur(%). Values between Start and Full result in values appropriately between MinCur and MaxCur.
- That POC is multiplied by the current PAS level's "Limit Current(%)" (specified on the Basic tab), which is then multiplied by the "LimitedCurrent(A)" [really Current Limit, in Amps], which is also specified on the Basic tab, to arrive at an actual Current value, in amps
- That Current essentially controls the power output of the Ultra motor (Volts * Amps = Watts, a unit of power)
The Prophet told me that was wrong. I decided to find out for myself. Even if it was indeed cadence related as everyone else said, I wanted to get a feel for what pedal rpms mapped to which columns to help me decide what settings were best for me.
I started by devising a set of Spd Table values to isolate what was happening. Essentially, I made MinCur=0 and MaxCur=1 for all Spd table columns except one (Spd40). That way I'd get motor assist only when that column was active. I found that Spd40 was the easiest to safely test on flat roads, and I set MinCur at 50% and MaxCur at 100% there so the power on would be noticeable. With a low PAS level for controller safety (to limit the max amps that could possibly be sent to the motor), I'd ride out in the lowest gear I have (50 tooth rear cog) from a stand still up to as fast as I could pedal, trying to note when power came on and went off. Then I'd repeat the test in the highest gear (10 tooth rear cog) and note the difference in when the power came on. I could use the display's KPH readout as a proxy since the 5X cadence to bike speed difference in the two extreme gears should show up easily there.
So I rode out in bottom gear, and power ramped up starting at about 6 KPH, going away at about 13.5 KPH. It was a ramp-up, ramp-down effect, which was nice. Then I rode out in top gear down the same stretch of road. If the gurus were correct, the power should have ramped-up at about 30 KPH (18-19MPH) (since bike speed in top gear would be 5X bottom gear at the same pedal cadence).
Well, damn if the power didn't ramp-up at the same 6 KPH, and down at the same 13.5KPH! WTF!?!?
OK, so repeat the test and get the same results.
Hmm, I edit the Torque tab to make Spd20, and then Spd60 the only active column and sure enough, it didn't matter how fast I was turning the pedals, the power-up/power-down moments came at the same bike speed within each SpdXX range.
@ProphetZarquon believed the XX in SpdXX were a percentage of the specified Pedal Tab's Speed Limit (either directly via a number or vectored to the display's Speed Limit setting), but my testing found no difference in SPDXX column engagement by changing those Speed Limit values. I have video I can share.
But, then it got even weirder! To see if it really was bike speed related I changed the Wheel Diameter in the Basic tab since that would change the bike speed calculation (number of wheel sensor pings per unit of of time multiplied by wheel circumference). But yet again, the SpdXX colums ramp-up/ramp-down points were at the same KPH!
So, it wasn't actual bike speed that was in control, it was Wheel RPM. I confirmed this by setting the number of Wheel magnets in the Basic tab to 2, even though I still only had 1. Now my Display's KPH was wrong, so I used a GPS speed app on my phone, but sure enough now the ramp-up for Spd40 was at 12 KPH and ramp-down at about 27 KPH - both about double the previous setting's results. With the Ultra thinking it took 2 magnet pings to get a single wheel revolution, I had to go twice as quickly to get the same engagement results.
This is astounding. It's taken 6-7 years to finally figure out what the SpdXX columns represent in the Bafang Ultra's Torque Table. They represent Wheel RPM.
By running my single column isolation test 6 times to cover all 6 SpdXX columns I was able to reverse engineer the values:
| SpdXX | In KPH | Out KPH |
|---|---|---|
| Spd0 | 0.01 | 4.5 |
| Spd20 | 2 | 8.5 |
| Spd40 | 6 | 13.5 |
| Spd60 | 10 | 18 |
| Spd80 | 16 | 25 |
| Spd100 | 20 | > 40 (never stopped) |
Now, these values are approximate. First, the purview of the columns overlap as you can see in the results above. I mentioned earlier that with just one column actionable the power would ramp up as the bike speed entered the KPH range and ramp down as the bike speed exited the KPH range. I believe this is an intentional feathering so that if you have wildly different values in adjacent columns the motor's reaction won't be abrupt, but will feather/ramp/scale between the two columns' values. Nice. Second, I'm riding and looking/recording the display, and there are lags all over the place. When does the display report applied motor power? How quickly do the KPH values update? What's the screen refresh rate on my iPhone (about 40 fps, btw)? I don't have access to a stationary bike trainer with integrated power output, but that combined with some controllable/repeatable motor to drive the Ultra's crankshaft would be a more scientific way to approach this. Third, I had a slightly (10%-ish) incorrect Wheel Circumference in my Display.
To conclude Part 1, since the real deal is Wheel RPM and not Bike Speed, those bike speed numbers should be converted into Wheel RPM (just math):
Here's what the controller activates on:
| SpdXX | In Wheel RPM | Out Wheel RPM |
|---|---|---|
| Spd0 | 0.01 | 10 |
| Spd20 | 4.5 | 20 |
| Spd40 | 13.5 | 30 |
| Spd60 | 22.5 | 40 |
| Spd80 | 36 | 56 |
| Spd100 | 45 | ? - No limit, presumably |
The Out Wheel RPM seems pretty linear at 10, 20, 30, 40, but then 55/56.
And again, multiple disclaimers on the above:
- My Display's Wheel Circumference was about 10% off
- The KPH On/Off speed from which these were calculated were based on watching the Display
- Even recoding the display for later playback doesn't help much with accuracy, due to display KPH update lag, screen fps (Frames per second), etc.
- I did round the numbers off and didn't perform enough runs to get a statistical average.
Last edited:
