Bafang Ultra "Smooth" tune by Mike at Frey

[ProphetZarquon]

The Torque page has quite a number of disagreements:
1) The whole Delta Voltage thing is confusing.

2) Why does Prophet Zarquon have different Min Current % for different pedal cadences?

3) What does Current Decay actually do, and why is Zarquon different at different cadences?

Hope this is helpful. Let me know if there's another published setting I should include in the above tables.

Hi! Great to see someone else researching exactly what each of these settings actually do. I'll try to clarify, without getting long-winded:

1. The adjustable span of each "Delta Voltage" field (for instance, adjusting the span of mV that shall be assessed as 0-5Kg), allows us to calibrate\tweak the amount of pedal torque reported, relative to a specific mV passed by the load cell: Whatever mV value we specify in the "0-5 Kg" field, will mean that '5Kg' is reported when the pedal torque sensor reaches a value in mV equal to BaseVoltage + that specified mV value for "0-5 Kg".

Making the span of each "n-N Kg" field smaller, means that less actual pedal force is required, to reach the next range of pedal force reported; smaller Delta Voltage spans report more pedal force, larger spans report less pedal force, for the same amount of actual pedal force.

In my case, simply standing on the front pedal, is far more than enough to max out the load cell in the pedal torque sensor: Therefore I need all the torque sensing range available, & thus I have added a few digits to each mV span, so that the sum total of all spans combined (plus the base mV) equals the precise maximum mV my pedal torque sensor can output.

If I weighed significantly less than 60Kg (or if my legs were not strong enough to lift me up a step), I would instead set the spans smaller, so that less actual pedal force is required, to reach a reported '60Kg'.

Similarly, by increasing the mV span of the "0-5Kg" & "5-10Kg" ranges, while reducing the mV span of the upper ranges (such as"50-60Kg"), we can require more pedal force before '12Kg' is reported, while reducing the difference in actual effort between a reported '50' & '60' Kg.

Inversely, a large value for the "0-5Kg" span with a small value for the "50-60Kg" span, results in more precise power response at low amounts of pedal force & exaggerated power response near max pedal force. (I might prefer this.)

In other words, smaller mV spans reduce the pedal force required to report any Kg; larger mV spans increase the pedal force required to report that same Kg.

If for some reason, "5-10Kg" accurately reported 10Kg when 10Kg of actual pedal force got applied, & "30-40Kg" accurately reported 40Kg at an actual 40Kg of pedal force, but some value between "15-20Kg" was reported when only 12Kg of pedal force got applied, we could slightly increase the "10-15Kg" span & reduce the "20-30Kg" span by an equal number of mV, so that 12Kg of actual pedal force correctly reports as 12Kg, without affecting the already accurate reporting at 5-10Kg or at 30-40Kg.

Thus, the BaseVoltage & the DeltaVoltage settings, allow us to calibrate the 0 level & the Kg reported for each span of the pedal torque sensor's output range:

By setting the BaseVoltage to whatever mV value is shown in TqVoltate while at 0 pedal force, we set an accurate starting point from 0Kg.

By calibrating the precise mV size of each DeltaVoltage span, we can set an accurate (or preferred) measurement of 5Kg, 20Kg, 60Kg, etc.

2. None of the fields adjustable under "Spd0", "Spd20" etc, have any direct relation to pedal cadence. For example, the "MinCur(%)" field under the "Spd0" range, sets the minimum current applied when the motor is engaged at ~0 MPH (& on up to 19% of "max" MPH).

The MinCur% field under the "Spd20" range, sets the minimum current applied when the controller is told that our speed is between 20% & 39% of its programed max speed for that PAS level (in my case "Spd100"% currently equals 48 MPH, set at the display).

Since I want smooth starts & minimal chain strain, I have not only increased the "Slow Start Mode" to 7, but also set the MinCurrent% of Spd0, to 1%; this way, my lightest pedaling doesn't produce a minimum 10 or 15 percent of the max power allowed by each PAS level (the default).

Each PAS level (0-5 Eco + 0-5 Sport) has its own "LimitSpd%" & "LimitCurrent%" setting. As a result, "Spd20" (& "Spd100" etc) actually affects torque response at speeds between 20-39% (or ≥100%) of whatever LimitSpd% is assigned, for the PAS level we're in. Likewise, MinCur% is actually a minimum percentage of the LimitCurrent% that's been set for the PAS level we're in. For example:

On the "Basic" tab, all my PAS levels (including "PAS 0 Eco" & "PAS 0 Sport") have LimitSpeed% set to 100%. This means that even in PAS 0 or 1, the controller may continue to apply motor power all the way up to whatever max speed is set (48MPH, "By Display's Command"). This also means that no matter what PAS level I'm in, the fields adjustable under the "Spd20" section, always apply to the same range of speeds.

If PAS level 1 were set to a LimitSpeed% of 50% (24MPH) & all other PAS levels were set to a LimitSpeed% of 100%, then all the settings listed on the Torque tab under "Spd100", would apply at any speeds ≥24MPH in PAS 1 but ≥48MPH in other PAS levels.

For this reason, I keep all PAS levels set to the same LimitSpeed%; otherwise, the torque tuning would go grossly out of tune from one PAS level to another.

While in PAS 5 with LimitSpd%100, "Spd100" would still mean speeds ≥48MPH, but while in PAS 1 set to LimitSpd%50, "Spd100" would suddenly mean any speeds ≥24MPH. Spd20" would jump between applying from 20-39% of max speed & applying from 10-19.5% of max speed, depending which PAS level we were riding in at any given time. All our careful tuning of the lowest Spd0 fields, would be thrown very far out of whack when their speed values suddenly get multiplied by .5 (or .1 or .01) each time we switch to PAS modes limited to 50% (or 10% or 1%) of the usual speed limit.

(It would have made more sense for the Spd0\20\etc ranges, to remain fixed percentages of the "Speed Limited" value assigned on the "Pedal Assist" tab. Unfortunately, they don't; any reduction in LimitSpeed% for each PAS level, also reduces the speed at which Spd20\40\60\80\100 settings begin to apply.)

Relatedly, the "LimitCurrent%" for each PAS level, affects the percentile settings on the "Torque" tab as well: I have 1% set as the max current for PAS 0; this means that while in PAS 0, all the Cur% fields on the Torque tab under each Spd{%}, are a percentage of that 1% max current.

If we use the "Basic" tab, to set PAS 1 to a max LimitCurrent% of 10%, then use the "Torque" tab to set the "Spd0" MinCurrent% to 10%, the minimum power applicable in PAS 1, will be 1% (ten percent of ten percent). In any PAS level with a LimitCurrent% of 100%, the minimum power applicable at 10% MinCur, will be 10% (ten percent of one hundred percent).

Thus, we find that it is impossible to perfectly tune the pedal torque response for more than one PAS mode: Any change in LimitSpeed%, affects the speed at which the fields under each Spd0\20\40\60\80\100 are applied, & any change in LimitCurrent%, changes the percentage of a percentage applied by the MinCur\MaxCur\KeepCur settings.

3. Current Decay is the rate at which delivered current gets reduced from MaxCur to MinCur. (This is the part that does relate to cadence.) Increasing the CurDecy value, causes a faster decrease in power between pedal strokes. If pedal torque exceeding ReturnKg is reported before current decay ends, current is restored at a level proportional to pedal torque reported.

("Time of stop" is the delay before decay starts; "Stop Decay" is the duration over which the Current Decay occurs. A longer StopDecay duration stretches the CurDecy slope over a longer period.)

... Nope, not a short answer at all.
Sorry! I hope this helps.

 

[smorgasbord]

Wow, @ProphetZarquon, thanks so much for the information and corrections!

1) It's counter-intuitive to me how the Delta Voltage table works. And I have to admit even after trying out the "Smooth" settings that my experience confirmed my apparently wrong belief. That is those settings have high initial Delta Voltage values, but it felt to me like increasing pedal pressure ran out of steam early.

If I use the "Torque Live Data" page in my EggRider or the "Continuous Get" button the Windows App, you're saying the voltage values I see reported are what is actually being produced by torque sensors/cells and the Delta Voltage table maps those to Kg of torque, which is then used in Spd Table to calculate current percentage. Right? Do you know what the "Speed Signal Level" and "Speed Signal ACC" values I see in the EggRider page mean?

2) My mind is blown that the Spd table refers to bicycle speed, not pedal cadence (the latter is what Mike/Frey reported). I fully understand how the motor controller can calculate bicycle speed as it knows the wheel diameter and has a wheel rotation counter sensor), but why would Bafang want to have us adjust motor output by vehicle speed and not pedal cadence?

Does pedal cadence not factor in here? I mean, if I'm riding along at 20 mph in a high gear/lower cadence versus 20mph in a low gear/high cadence, wouldn't I want different motor behaviors? As Mike points out, it's hard to provide high pedal torque when the cadence is high - and in those two gearing difference cases the cadence differences could be significant.

3) You said "in my case "Spd100"% currently equals 48 MPH, set at the display." Is that set via the Display's "Speed Limit" setting? My interpretation of that was just that the display would tell the motor to stop supplying more power once the speed limit was reached, not that it set a range of possible speeds in the Torque Tab. My mind is blown on that! Are you also saying that the motor itself enforces the speed limit once that setting is made?

My confusion comes from the independence of many Display parameters from the Ultra motor's parameters. For instance, if I set Wheel Diameter in my display, that doesn't change the Wheel Diameter value in the Basic Tab. Heck, some displays let you set a wheel circumference instead, so that you can get a more accurate MPH reading on the display - but again that doesn't change anything you can see in the Bafang Settings App.

I'll stop here for now, but I've got a lot of questions still, sorry.

 

[ProphetZarquon]

If I use the "Torque Live Data" page in my EggRider or the "Continuous Get" button the Windows App, you're saying the voltage values I see reported are what is actually being produced by torque sensors/cells and the Delta Voltage table maps those to Kg of torque,

Yes. Spline shaft load cell sensor in crank gives a value between ~750mV at 0 load, & ~3240mV at max load (4300 would be nice, but nope). I do seem to get about 60Kg on the front pedal before reaching that max reading, & my 12 Kg of resting leg reads ~1270mV right in the middle of the "10-15Kg" span, so this part at least seems to do its job pretty well.

which is then used in Spd Table to calculate current percentage. Right?

The Tq calculated by adding up the ∆V spans, is used in the Spd table. The values set in each Spd% column, determine how much Tq is required to engage MinCur, & how much Tq to reach Full current, & how much Tq to restore proportional output while decay is occuring.

The decay settings are where cadence factors in:

On the "Pedal Assist" tab, I have kept the full 20×10ms "Time of Stop" delay before decay engages, & used an extra-long 20×10ms "Stop Decay", because I tend to crank slow & hard rather than light & fast:

A long delay prevents premature decay at middling cadence, & a long decay period reduces "drop off" feeling when decay does engage; makes assist feel more continuous.

With the right StartKg & MinCurrent% settings for Spd0, a low PAS 2 LimitCurrent% gives me buttery smooth takeoffs while a highish PAS 4 LimitCurrent% gives me manageable takeoffs uphill while full of cargo.

Spd20(to 39)% is the one I have really still been playing with; every tuning of the drive train or shift in PAS current limit, seems to favor a slightly different tuning for Spd20.

I almost never reach the Spd100 range (most of the time I do 12-15MPH, 28 at most); I only have the limit set to 48 MPH because I hate losing drive force at the rear-wheel while descending steep hills. Sacrificing assist on descents by dropping the speed limit to 30 MPH, would free up a lot more fine tuning of how much assist I get for a given pedal force, at a given speed.

Do you know what the "Speed Signal Level" and "Speed Signal ACC" values I see in the EggRider page mean?

Nope! I don't have one.

2) My mind is blown that the Spd table refers to bicycle speed, not pedal cadence (the latter is what Mike/Frey reported). I fully understand how the motor controller can calculate bicycle speed as it knows the wheel diameter and has a wheel rotation counter sensor), but why would Bafang want to have us adjust motor output by vehicle speed and not pedal cadence?

It's a torque-sensing assist: Output force varies based on our input force; crank speeds just multiply the work of those summed forces, they don't change their proportion to one another...

... except at lower\higher MPH speeds, which call for: less assist per leg force at low speeds, for smooth starts (it pulls like a tractor upon takeoff anyway); more assist per leg force at higher speeds, because power required to add 10 MPH roughly doubles for every 10 MPH above 15 MPH.

Does pedal cadence not factor in here? I mean, if I'm riding along at 20 mph in a high gear/lower cadence versus 20mph in a low gear/high cadence, wouldn't I want different motor behaviors? As Mike points out, it's hard to provide high pedal torque when the cadence is high - and in those two gearing difference cases the cadence differences could be significant.

Alas, our controller doesn't know what gear we're in.

When cadence is high, the motor RPM spins quite high too; the ratio between motor & crank never changes. If we pedal fast & light in a gear that spins easy & rolls slow, the motor spins fast using little amperage, consummate with our effort.

This is not a cadence-dependent system wherein high power output relies on high cadence; we get high power by pushing harder & less power by pushing lighter. If we want to go faster we either push harder, or we shift to a later gear which demands more force to get the pedals around resulting in higher assist output in keeping with our harder cranking.

With high powered torque-sensing ebikes, we don't need more assist at high cadences; we scarcely need high cadences at all. Almost any amount of assist at high cadence, does more work than we can muster with the pedals & just tops out the motor RPM right away. If we're at high cadence we're past peak caloric (& wattage) efficiency & should shift.

We do need comparatively tall chainrings & tall cassette spacings, to stay somewhere near a comfortable pedaling cadence; then we just pedal a bit harder or softer to change output (like a superhuman version of oneself).

As long as our torque response makes sense proportionally to the air drag or soft-takeoff requirements at a given speed, pedal force tells us all we need to know about how much motor amperage we need: If more amperage would be effective, more pedal force would be possible; if more pedal force isn't possible, we're in the wrong gear so the motor won't spin a ton faster anyway.

Given the reduction (18:1?), these motors feel like they have a pretty narrow RPM range. If I wanted more RPM to squeeze extra power from high cadences, 52 or 60 Volts is definitely what the motor would prefer anyway. At 48V, it's a bit like shifting a sport bike: Plenty of power to cruise along in a later gear, but wrapping up to max RPM so quickly means lots of shifting to get from a good starting gear to a good cruising gear (~400% shift ratio).

With poor calibration, torque sensing can feel like it leaps into action & tops out its level of assistance, early.

With good calibration, torque sensing goes from gear to gear as if every speed were an easy cruising speed, & pedaling a bit faster is something we only need when about to change gears.

3) You said "in my case "Spd100"% currently equals 48 MPH, set at the display." Is that set via the Display's "Speed Limit" setting? My interpretation of that was just that the display would tell the motor to stop supplying more power once the speed limit was reached,

Correct. The controller uses a magnet to find what RPM the wheel is spinning. The wheel size & RPM are fed to the display, which in my case is where the max speed limit is set (optional). Based on that data, the display tells the controller what speed we're going.

Once Spd100 is reached, no assist is applied; however the decay function means that the current levels & torque requisites actually still apply as a smoothing method preventing total sudden cutoff of power when Spd100% is hit. For this reason alone, I still find the Spd100 fields useful; if a bit strange.

not that it set a range of possible speeds in the Torque Tab. My mind is blown on that! Are you also saying that the motor itself enforces the speed limit once that setting is made?

Almost all of it takes place in the motor-controller, integrated inside the m620's case:

The speed limit set at the display (or optionally via the "Pedal Assist" tab under "Speed Limited") defines an absolute max speed at which motor power can remain active.

Then, on the "Basic" tab, the "Limit Spd(%)" for each PAS level, sets the value of Spd100 for each PAS level, to {SpeedLimited MPH} × {LimitSpd% of that PAS level}.

Then, on the "Torque" tab, the torque response levels chosen for fields under (for instance) Spd80, are applied when traveling at speeds from 80-to-99% of {SpeedLimitedMPH×LimitSpd%}.

That's weird. The pedal torque response would remain calibrated across different PAS levels, if Spd100 were exactly SpeedLimitedMPH instead of SpeedLimitedMPH×LimitSpd%.

Also, it's really weird that the Config Tool app (¿¡or the controller firmware!?) require that KeepCur% "must be" equal or less than MinCur%, since 1) by definition nothing can be less than MinCur & 2) the equivalent fields work the opposite way on the Pedal Assist tab, where (correctly) KeepCurrent% must be more than StartCurrent%... If anyone comes up with a fix for this (so that KeepCur% "must be" more than MinCur%) please let me know your method!

My confusion comes from the independence of many Display parameters from the Ultra motor's parameters. For instance, if I set Wheel Diameter in my display, that doesn't change the Wheel Diameter value in the Basic Tab.

Heck, some displays let you set a wheel circumference instead, so that you can get a more accurate MPH reading on the display - but again that doesn't change anything you can see in the Bafang Settings App.

Yeah, if I set my wheel size in the display, it overrides what I set in the app.

I expect the capability of accepting "speed" values from the display, makes it possible to use other speed measurement methods, such as displays that use GPS data, or air speed, multiple motors acting as an RPM-matched pair, etc. Bafang controllers needed to have wheel-size & speedo support earlier on, when available displays were more basic. Seems like these fields are a fallback option... (For instance, I think m620s can potentially run without any display?)

 

[smorgasbord]

Yeah, if I set my wheel size in the display, it overrides what I set in the app.

I believe it's more complicated than that.

The Wheel Size settings values in display and controller remain independent. I've used 3 different displays on my two Ultra bikes and in no case did setting the Wheel Size in the display change the Wheel Size in the Bafang configuration, or vice-versa. Some displays offer different options than the Bafang configuration, such as 27.5, so how would that be accommodated? Heck, the EggRider even lets you specify wheel circumference directly without choosing any Wheel Size (it remains blank), so how would that even be fed back to the controller, which doesn't have a circumference parameter?

I expect the capability of accepting "speed" values from the display, makes it possible to use other speed measurement methods, such as displays that use GPS data, or air speed, multiple motors acting as an RPM-matched pair, etc. Bafang controllers needed to have wheel-size & speedo support earlier on, when available displays were more basic. Seems like these fields are a fallback option... (For instance, I think m620s can potentially run without any display?)...
...The controller uses a magnet to find what RPM the wheel is spinning. The wheel size & RPM are fed to the display, which in my case is where the max speed limit is set (optional). Based on that data, the display tells the controller what speed we're going.

I'm curious - How are you determining that the display is sending bike speed data to the controller? That doesn't seem logical considering the real-time nature of bike speed and the ease of the bike speed calculation.
I interpret the parameter usage as the controller can get a one-time "Speed Limit" number from the display (optional as you say, but could also just be directly specified as a number in the controller), but that determination of bike speed and subsequent enforcement of that limit is done wholly inside the controller. The controller has direct access to the wheel size and real-time wheel sensor ping data - why would it send the wheel sensor data to the display to do the calculation for bike speed just to have it send that back to the controller when the controller could more easily just calculate the bike speed itself? And, can the motor really depend on the display to send a real-time speed to it? That seems a poor design at best.

Yes. Spline shaft load cell sensor in crank gives a value between ~750mV at 0 load, & ~3240mV at max load (4300 would be nice, but nope). I do seem to get about 60Kg on the front pedal before reaching that max reading, & my 12 Kg of resting leg reads ~1270mV right in the middle of the "10-15Kg" span, so this part at least seems to do its job pretty well.

It was pointed out to me in another thread that Kilograms (Kg) is not a unit of torque, it's a unit of weight (force). So, the length of the cranks comes into play in converting force on a pedal to a torque. I don't know if 170mm cranks are the "standard" for Ultras, but I do know that some people fit different length cranks, and that would affect torque values at the same weight/force applied to the pedals.

The Tq calculated by adding up the ∆V spans, is used in the Spd table.
The values set in each Spd% column, determine how much Tq is required to engage MinCur, & how much Tq to reach Full current, & how much Tq to restore proportional output while decay is occuring.

EDIT: See my follow-on post below. I believe the process is as you described even earlier, where the Torque sensor generates a voltage based on pedal force, that voltage is run through the Delta Voltage table to determine the Kg of force, and that Kg is placed proportionally between Start and Full in the appropriate Spd column, thus generating the same proportion of current between MinCur and MaxCur.

Alas, our controller doesn't know what gear we're in.

Well, the controller knows bike speed and obviously it knows pedal cadence, so, it could pretty easily calculate a gear ratio from those. But, I'd be surprised if it were that sophisticated.

That said, I'm very surprised that the SpdXX table is based on bike speed and not on pedal cadence. Especially since, as Mike/Frey's article (see first post in this thread for the link) talks about the difficulties human's have pedaling hard at high cadences, it would seem that the Spd table would be helpful to compensate for that (as Mike/Frey says he's doing, but now that's potentially at odds with Spd being bike speed instead).

Plus, I think it gets complicated that at a moderate bike speed (say 18 MPH), I could be in vastly different gearing and so the pedal cadence/motor rpms would be be vastly different and how much assist we'd want would be different, too.

Also, it's really weird that the Config Tool app (¿¡or the controller firmware!?) require that KeepCur% "must be" equal or less than MinCur%, since 1) by definition nothing can be less than MinCur & 2) the equivalent fields work the opposite way on the Pedal Assist tab, where (correctly) KeepCurrent% must be more than StartCurrent%... If anyone comes up with a fix for this (so that KeepCur% "must be" more than MinCur%) please let me know your method!

EggRider returns a "Bafang TorqueSettings write Error - (28)" when I make KeepCur(%) larger than MinCur(%) on the Torque tab and hit Write. So it would appear this is a Bafang controller restriction, not the application itself.

But, that brings up another question - the Bafang settings were initially established in the BBSHD days, and included just the Basic, Pedal, and Throttle pages. With the torque-sensor Ultra motor, they added the Torque page, but didn't remove any fields from the other pages.

So, now there are 3 fields on Pedal that conflict/overlap with Torque:

• Pedal's KeepCurrent(%) vs Torque's KeepCur(%) for 6 columns in the Spd table on Torque
• Pedal's CurrentDecay(%) vs CurDecay for 6 columns in the Spd table on Torque
• Pedal's Start Current(%) vs MinCur(%) for 6 columns in the Spd table on Torque

My question is whether the values on the Torque tab completely override the legacy values on Pedal or whether there's some interaction between them. Any thoughts here?

Thanks again - this discussion is much appreciated!

 

[smorgasbord]

So I took another look at the original Ultra tuning guide, from Karl Gesslein, which references his earlier document for the BBS02/BBSHD drives.

Here's what he states:
1) The "Limit Spd(%)" values on the Basic tab reference "motor rpm" speeds, aka pedal cadence, not road speed. I don't know what to make of this. My EggRider manual says these are road speeds.

2) Karl claims the Delta Voltage table to Spd table pipeline works as follows: "What the software does is takes this mV (millivolt) input and maps it to kilograms and then the rest of the settings use the kg variable NOT the mV input." Note this is what @ProphetZarquon said upstream here, so some confirmation of that.

3) As for whether the SpdXX ranges are pedal cadences or road speed, Karl says: "SPD0-SPD100: These columns represent the % of the highest RPM ability of the motor that it is currently spinning. Do not think that it has ANYTHING to do with the speed that the wheel is turning because it just doesn’t." Hmm.

Karl also includes a spec document:

And notes that the max rpm of the Ultra is 150 rpm, although the chart above shows 185.

I'm now thinking of an experiment where I change all the MinCur(%) and MaxCur(%) fields to 1, except for one Spd range at a time, for instance starting with Spd20, which I'll set to MinCur=20 and MaxCur=50. That should be enough for me to detect when power kicks on. Then I'll ride in a very low gear and note the RPM at which power kicks on, then stop. Then in a very high gear do the same thing and note whether power kicks on at the same bike speed or same pedal cadence.

Thoughts on running this experiment, including the safety of hurting the motor/controller with it, will be much appreciated.

 

[ProphetZarquon]

I believe it's more complicated than that.

The Wheel Size settings values in display and controller remain independent. I've used 3 different displays on my two Ultra bikes and in no case did setting the Wheel Size in the display change the Wheel Size in the Bafang configuration, or vice-versa. Some displays offer different options than the Bafang configuration, such as 27.5, so how would that be accommodated? Heck, the EggRider even lets you specify wheel circumference directly without choosing any Wheel Size (it remains blank), so how would that even be fed back to the controller, which doesn't have a circumference parameter?

Regardless of what speedometer settings are applied in the Config Tool app, so long as the "Speed Limited" field on the Pedal Assist tab is set to "By Display's Command" then the Spd20 settings come into effect at 20% of the speed limit set in my display.

The display we've got increments in whole inches, so "27" (not 27.5) is my current wheel size selection. As a result, any MPH figures I give are likely off by that much.

If I set "Speed Limited" to anything but "By Display's Command", the speedo method shown in these controller config menus is used instead of the controller using the speed calculated by the display.

I'm curious - How are you determining that the display is sending bike speed data to the controller?

Direct experimentation. It seemed strange, so I tested to confirm:

Changing the wheel size setting in the display, changed the speed indicated on the display & changed the real speed at which "Spd20" engaged (regardless of which gear/cadence we're at).

Changing the max speed set in the display, changed the real speed at which Spd20 engaged (as does changing the "Limit Spd(%)" on the "Basic" tab).

Setting the "Speed Limited" option to anything but "By Display's Command", caused the "Wheel Diameter (Inch)" setting in the Config Tool, to affect the real speed at which Spd20 engaged.

That doesn't seem logical considering the real-time nature of bike speed and the ease of the bike speed calculation.

Final speed is the biggest single factor to track, when decreasing assist for finer control at very low speeds & increasing assist for easy cruising at higher speeds. Remember that the work required to hold a given MPH, is more directly related to drag & climb height, than to motor RPM.

A single-ratio mid-motor with 18:1 reduction & just the tiniest bit of current, spins 18 times for each crank revolution. Extra current doesn't change the number of motor RPM per crank of the pedals. Applying more assist at higher cadence, wouldn't make the motor spin faster per crank, it would just reduce already scarce pedal force while using more watts & calories than shifting to the next gear would.

Requiring high cadence to get high assist despite tall gearing, would make the rider do inefficient work needlessly & decrease the "push harder get more assist" effect which pedal torque sensing provides.

Varying the pedal torque sensitivity of assist power, based on cadence instead of final speed, would leave the earliest granny & starting gears at max assist (very much not a smooth start) & the final fastest\hardest gears would get less assist than any gears below them that spin faster.

The whole point of the Spd0, Spd20, Spd80 etc settings, is to allow pedal torque sensitivity to scale relative to final speed, because that is essential to low speed controllability & high speed cruising ease.

If we wanted only
{pedal torque + cadence}
as our inputs, we could set all values under Spd0 & Spd 20 etc, to be the same as their neighbors, right across the whole row from Spd0 to 100. That would suck though, because we'd have to use non-optimal gears to get going & to hold top speed.

For this reason, torque sensing ebikes really need to know how fast they're going; the settings under Spd0 & Spd20 are really important to ride feel.

I interpret the parameter usage as the controller can get a one-time "Speed Limit" number from the display (optional as you say, but could also just be directly specified as a number in the controller), but that determination of bike speed and subsequent enforcement of that limit is done wholly inside the controller.

Only if "By Display's Command" is not selected.

The controller has direct access to the wheel size and real-time wheel sensor ping data - why would it send the wheel sensor data to the display to do the calculation for bike speed just to have it send that back to the controller when the controller could more easily just calculate the bike speed itself?

For the reasons I noted: Other types of speed measurement exist (especially in case of non-bicycle use cases), so letting the display send speed data to the controller allows the controller to support those other types of speed measurement if desired.

Why is it set to By Display's Command for the Frey we bought? I don't know for certain, but it's certainly more convenient to change wheel size & speed limit via the display, than to disconnect it & change them via the Config Tool.

And, can the motor really depend on the display to send a real-time speed to it? That seems a poor design at best.

Yeah, delays in updating the speed are pretty real, regardless of what device is doing it, due to the magnet only going past once per wheel revolution, by default. Adding magnets reduces the delay between updates, but doesn't really improve accuracy, at all (potentially worse, depending whether any passes get missed).

Even at abysmal connection rates, UART communication delays are miniscule compared to the mechanical delay of awaiting another pass of a magnet. The latency at which the display (& the torque sensor for that matter) are monitored, is much less than the latency at which the measurement itself can be performed.

It was pointed out to me in another thread that Kilograms (Kg) is not a unit of torque, it's a unit of weight (force). So, the length of the cranks comes into play in converting force on a pedal to a torque. I don't know if 170mm cranks are the "standard" for Ultras, but I do know that some people fit different length cranks, and that would affect torque values at the same weight/force applied to the pedals.

Yup. "Kg" is not really the right unit to use, but I didn't write the app; so, I have to describe its fields as they are labeled. ("Time of stop" is not an accurate label either; "Decay delay" would be a more accurate English-region label.)

I place known weights on the front pedal, when calibrating DeltaVoltage spans... No offsets actually needed so far; after calibrating Base Voltage, 10 Kg on the pedals equals "10 Kg" passed to the SpdN fields).

Sorry for being slow, but I'm having a hard time understanding in which direction the Delta Voltage table is working:
• What I originally thought was that Delta Voltage was a conversion from applied torque to a voltage level (Tq) that is then sent to the controller. In this case, changing the values in the Delta Voltage Table will change the Tq value sent to the controller. But, if so, changing the Delta Voltage table should also change the "Continuous Get" Tq values, which I doubt happens, but haven't yet verified one way or the other.

While the ebike is on, the controller continuously samples the milliVolts passed by the spline sensor; the values for Base Voltage + Delta Voltage, equal the mV required before the controller detects a given "Kg" of pedal torque.

"Get" just pastes the mV value of the spline sensor, into the "TqVoltate" field. (That TqVoltate field exists purely for calibration purposes; all it does it show you how many mV the spline sensor is passing.)

"Continuous Get" just keeps polling the spline sensor to continuously update the TqVoltate field. This makes it easier to do things like 'watch the TqVoltate value for jitter' or 'put the wheel on a dyno & check crank force at each angle of rotation'.

The only thing "sending" torque data to the controller, is the sensor itself, which is simply a spline-type load cell that increases in resistance when force is applied.

The controller sees a certain "mV", subtracts the Base Voltage to get a 'zero force' baseline, then counts any mV above that baseline, as a quantity of torque equal to whatever is defined in its Delta Voltage fields. (The controller's Base Voltage setting tells it that 752 mV is 'zero pedal force', & the sum of all eight Delta Voltage fields combined tells it that 3240 mV is "60 Kg".)

• Your previous post had me thinking that the Delta Table is instead used to convert the torque sensor output (Tq mV) to a Kg number, and then that Kg number is fed into the Spd Table where it's compared against the Start(Kg) and Full(Kg) parameters to determine which amperage (proportionally between MinCur and Max Cur) to generate.

That's correct.

Could you try to explain it a different way for me? I'm trying to grok the pipeline of data from pedal torque applied to motor current generated.

Pedal » crank » spline sensor (in mV) » controller (mV » "Kg").

With 207 & 415 mV spans:
If mV < BaseVoltage then "Kg" = 0;
If mV > BaseVoltage then "Kg" =
{mV - BaseVoltage} ÷ 41.5

The controller counts that "Kg" toward StartKg, FullKg & ReturnKg requirements for the MinCurrent, MaxCurrent & KeepCurrent of each Spd column.

I'm very surprised that the SpdXX table is based on bike speed and not on pedal cadence. Especially since, as Mike/Frey's article (see first post in this thread for the link) talks about the difficulties human's have pedaling hard at high cadences, it would seem that the Spd table would be helpful to compensate for that (as Mike/Frey says he's doing, but now that's potentially at odds with Spd being bike speed instead).

Indeed, the difficulty of applying high pedal torque at high cadence, is exactly why vehicle speed is referenced when varying the response to pedal torque, rather than referencing cadence.

Cadence is the enemy of pedal torque; there's no good pedal torque to measure when cadence is high.

Since we need much more assist at higher speeds regardless of cadence (& much less assist for low speed control), it is only logical that vehicle speed should be referenced when determining scale of assistance.

Plus, I think it gets complicated that at a moderate bike speed (say 18 MPH), I could be in vastly different gearing and so the pedal cadence/motor rpms would be be vastly different and how much assist we'd want would be different, too.

Exactly. We don't want less assist just because we shifted to a later+faster+harder gear!

When cadence is high we don't need much assist because spinning the pedals is already easy; fortunately there's hardly any pedal force at high cadence anyway.

When cadence is low, we can apply more pedal force to get more assist.

Increasing assist proportional to cadence, would make torque sensing worse, not better. If anything, we'd want more aggressive assist at low cadence & less assist at high cadence, which is the literal opposite of how cadence-sensing assist works.

Cadence sensing is not bad if we never want to pedal hard or cruise easily at high speed or have precise power control during low speed maneuvers. Once pedal torque is being monitored, we need vehicle speed to scale it against.

EggRider returns a "Bafang TorqueSettings write Error - (28)" when I make KeepCur(%) larger than MinCur(%) on the Torque tab and hit Write. So it would appear this is a Bafang controller restriction, not the application itself.

Oof.
I'm not surprised, but that's still disappointing.

Well, I guess we could always hope someone creates a homebrew firmware update for the controller?

But, that brings up another question - the Bafang settings were initially established in the BBSHD days, and included just the Basic, Pedal, and Throttle pages. With the torque-sensor Ultra motor, they added the Torque page, but didn't remove any fields from the other pages.

So, now there are 3 fields on Pedal that conflict/overlap with Torque:

• Pedal's KeepCurrent(%) vs Torque's KeepCur(%) for 6 columns in the Spd table on Torque
• Pedal's CurrentDecay(%) vs CurDecay for 6 columns in the Spd table on Torque
• Pedal's Start Current(%) vs MinCur(%) for 6 columns in the Spd table on Torque

My question is whether the values on the Torque tab completely override the legacy values on Pedal or whether there's some interaction between them. Any thoughts here?

Great question!

I haven't experimented directly with changing the duplicate values on the "Pedal Assist" tab, yet. The changes I made to those were done early on & haven't been touched since tuning the Torque tab settings.

If anyone with a torque sensing m620 Ultra, wants to test changes to the Current settings on the "Pedal Assist" tab, I think it would be very worthwhile for us to find out their remaining effects & whether any other fields override them!

Thanks again - this discussion is much appreciated!

Agreed!

 

[ProphetZarquon]

As for whether the SpdXX ranges are pedal cadences or road speed, Karl says: "SPD0-SPD100: These columns represent the % of the highest RPM ability of the motor that it is currently spinning. Do not think that it has ANYTHING to do with the speed that the wheel is turning because it just doesn’t." Hmm.

I saw that statement, but all I can say is that the UART m620 on the 48V Frey AM1000 v5 which we received, definitely bases "Spd20" on the MPH reported, not the motor RPM.

I don't know where he got the idea that the Spd columns go by RPM, because that literally wouldn't work in any useful way. RPM-based torque sensitivity adjustment simply wouldn't be viable for the fields as shown.

One possibility that has occurred to me, is that perhaps not all m620 are configured in the same way, regarding the method used to determine when "Spd20" etc are reached. Even so, the RPM explanation doesn't add up with observations; but some observations might be skewed by different configs!?

At any rate, the only definitive testing I've seen reported, jives with Spd being speedo-based.

Really, this makes sense.

Spd0\Spd20\etc need to be speed-based.

(It's the inverted KeepCur% limit, & the issue that PAS limits shouldn't move the goalposts on the Torque tab, which present actual problems!)

Anyone claiming "Spd20" is RPM based, had better show me some test procedure & findings that proved it... or I'll have to conclude they're just mistaken!

I'm now thinking of an experiment where I change all the MinCur(%) and MaxCur(%) fields to 1, except for one Spd range at a time, for instance starting with Spd20, which I'll set to MinCur=20 and MaxCur=50. That should be enough for me to detect when power kicks on. Then I'll ride in a very low gear and note the RPM at which power kicks on, then stop. Then in a very high gear do the same thing and note whether power kicks on at the same bike speed or same pedal cadence.

That's essentially what I did, to confirm the weird percentage-times-percentage issues, & to confirm what causes Spd20 to engage.

I strongly recommend this, as it's good to get an idea where/when those Spd ranges engage, prior to fine tuning.

Maybe other settings, or some earlier/later firmware version on the motor-controller, will produce RPM-based Spd ranges, on your m620 unit?

Very interested to hear your findings!

 

[smorgasbord]

Final speed is the biggest single factor to track, when decreasing assist for finer control at very low speeds & increasing assist for easy cruising at higher speeds. Remember that the work required to hold a given MPH, is more directly related to drag & climb height, than to motor RPM.

A single-ratio mid-motor with 18:1 reduction & just the tiniest bit of current, spins 18 times for each crank revolution. Extra current doesn't change the number of motor RPM per crank of the pedals. Applying more assist at higher cadence, wouldn't make the motor spin faster per crank, it would just reduce already scarce pedal force while using more watts & calories than shifting to the next gear would.

Requiring high cadence to get high assist despite tall gearing, would make the rider do inefficient work needlessly & decrease the "push harder get more assist" effect which pedal torque sensing provides.

Varying the pedal torque sensitivity of assist power, based on cadence instead of final speed, would leave the earliest granny & starting gears at max assist (very much not a smooth start) & the final fastest\hardest gears would get less assist than any gears below them that spin faster.

The whole point of the Spd0, Spd20, Spd80 etc settings, is to allow pedal torque sensitivity to scale relative to final speed, because that is essential to low speed controllability & high speed cruising ease.

If we wanted only
{pedal torque + cadence}
as our inputs, we could set all values under Spd0 & Spd 20 etc, to be the same as their neighbors, right across the whole row from Spd0 to 100. That would suck though, because we'd have to use non-optimal gears to get going & to hold top speed.

For this reason, torque sensing ebikes really need to know how fast they're going; the settings under Spd0 & Spd20 are really important to ride feel.

I agree that bicycle speed is a function of power being applied: Here's an interesting article using cycling as the example:

Remember that power is measured by how much force (measured in torque) is being applied to the pedals, multiplied by how rapidly (cadence) that force is being applied. If you're riding at 20 mph, and the only thing that changes is shifting from 80 rpm to 120 rpm, the measured power will remain the same because the torque will be reduced at 120 rpm.

So you're correct that for a given bicycle speed under the same conditions, the power needed is the same regardless of cadence. However, the torque needing to be applied varies greatly with the gearing and since the SpdXX table adjusts motor power by torque we would be getting different results being in different gears.

For instance, my SRAM GX drivetrain has a 10-50 rear cassette. That means that for the same bicycle speed, my cadence is 5X greater when using the bottom gear (50 tooth) than when using the top gear (10 tooth), which also means that the torque needed in the top gear is 5X greater than needed when I'm in the bottom gear. But it also means that for the same cadence and pedal torque, my bicycle will be traveling 5X faster in the top gear than in the bottom gear.

Let's think about that for a moment. Two cases:

1. Bicycle traveling at 6 MPH in the bottom gear. Rider applying X Kg of pedal force, at a cadence of Y rpms.
2. Bicycle traveling at 30 MPH in the top gear. Rider applying X Kg of pedal force, at a cadence of 5*Y rpms.

In this case we have the same increase in cadence as we do in bicycle speed. So it wouldn't matter whether the SpdXX column selection was based on cadence or bicycle speed, we'd be in a different column and thus could specify different Start/Full input to MinCur/MaxCur output ratios.

Let's look at a different second case:

1. Bicycle traveling at 6 MPH in the bottom gear. Rider applying X Kg of pedal force, at a cadence of Y rpms.
2. Bicycle traveling at 30 MPH in the top gear. Rider applying 5*X Kg of pedal force, at a cadence of Y rpms.

You're saying that since the bicycle speed is different, the motor will use a different SpdXX column of parameters. But why? The SpdXX columns are setup to scale motor output proportionally based on pedal force, and then pedal force in one case is higher than the other case. So why introduce a second variable when we've already got a torque->power output ratio variable? My legs don't care what speed my bicycle is traveling at - they only feel pedal force and cadence.

What does matter is that the human body isn't capable of applying as much force on the pedals at high cadences as we can at lower cadences. That's why it makes more sense to have different SpdXX columns for difference pedal cadences, since we can setup Spd80 and Spd100 to provide more assist at lower rider-applied torque at these higher cadences. For a given rider-applied torque and cadence the assistance I want only needs to vary based on how much additional torque the rider applies - not on whether the bike is going faster or slower.

But, as you say, I guess I'll have to try the experiments myself to be convinced. Do you have any advice or caveats as to what I should/should not setup in the Spd Table to confirm? Again, my plan is to basically zero out assist for all but the Spd20 column (by having MinCur and MaxCur in the other columns be 1 and 2 respectively), but keeping a nice boost in the Spd20 column so the feel would be obvious. Anything to watch out for, motor or rider safety wise?


As for the Display calculating the speed for the motor, that's also something that should be pretty easy to check. My plan would be to modify the PAS settings to have less than 100 for the AssistX "Limited Speed(X)" and see if the cut-off point varies with changes to the display's Wheel Size versus the Basic Tab's Wheel Size. I could then combine the two experiments to see if the point at which Spd20 engages varies.

 

[smorgasbord]

These are the Torque settings I used to confirm the Spd tied to road speed vs cadence:

Base Voltage: 753
Delta Voltages: 208 for first 4 and 416 for last 4

Start(Kg): 1 for all 6 Spd's
Return(Kg): 1 for all 6 Spd's
MinCur(%): 1 for all 6 Spd's

Full(Kg): 5 for all 6 Spd's
MaxCur(%): 1 for all except the column I was testing for; that had 100

KeepCur(%): 1 for all 6 Spd's
CurDecay: 3 for all 6 Spd's
StartDegree: 1 for all 6 Spd's

The idea is that only when the MaxCur 100% speed is engaged will I get any significant motor boost. The 5Kg will give me 100% of whatever PAS level I'm in.

 

[smorgasbord]

News Flash: My testing this afternoon, as in several hours of isolating setting changes, indicates that everyone is wrong about what the Bafang SPDXX ranges reference. Since this is such a major surprise, and especially since so many people have been tweaking the Torque Table for years and claiming success based on what I've observed to be faulty assumptions, I'm waiting for some discussion over DM before I post my findings and conclusions. It's just too shocking.

If you want to participate in confirming/denying my conclusions and are willing to use the Torque settings I posted in the message above, DM me to what I did.

If I'm right, you're going to want to look for a new thread I'm going to start on Ultra Programming.

 

[smorgasbord]

BTW, if anyone is in the Carmel, CA area this week and wants to get together to explore Ultra settings, drop me a DM.

 

[ProphetZarquon]

I agree that bicycle speed is a function of power being applied: Here's an interesting article using cycling as the example:

So you're correct that for a given bicycle speed under the same conditions, the power needed is the same regardless of cadence. However, the torque needing to be applied varies greatly with the gearing and since the SpdXX table adjusts motor power by torque we would be getting different results being in different gears.

For instance, my SRAM GX drivetrain has a 10-50 rear cassette. That means that for the same bicycle speed, my cadence is 5X greater when using the bottom gear (50 tooth) than when using the top gear (10 tooth), which also means that the torque needed in the top gear is 5X greater than needed when I'm in the bottom gear. But it also means that for the same cadence and pedal torque, my bicycle will be traveling 5X faster in the top gear than in the bottom gear.

Let's think about that for a moment. Two cases:

1. Bicycle traveling at 6 MPH in the bottom gear. Rider applying X Kg of pedal force, at a cadence of Y rpms.
2. Bicycle traveling at 30 MPH in the top gear. Rider applying X Kg of pedal force, at a cadence of 5*Y rpms.

In this case we have the same increase in cadence as we do in bicycle speed. So it wouldn't matter whether the SpdXX column selection was based on cadence or bicycle speed, we'd be in a different column and thus could specify different Start/Full input to MinCur/MaxCur output ratios.

Let's look at a different second case:

1. Bicycle traveling at 6 MPH in the bottom gear. Rider applying X Kg of pedal force, at a cadence of Y rpms.
2. Bicycle traveling at 30 MPH in the top gear. Rider applying 5*X Kg of pedal force, at a cadence of Y rpms.

You're saying that since the bicycle speed is different, the motor will use a different SpdXX column of parameters. But why? The SpdXX columns are setup to scale motor output proportionally based on pedal force, and then pedal force in one case is higher than the other case. So why introduce a second variable when we've already got a torque->power output ratio variable? My legs don't care what speed my bicycle is traveling at - they only feel pedal force and cadence.

Because we still need to shift.

If we were talking about a single-speed rear-end, it's true that cadence alone could achieve most of the assist scaling we'd need relative to final speed (though speed data would still be very useful); once cadence got high, there'd be nothing to do but try to spin even higher. Higher cadence, higher assist; simple.

However, with multiple gears we can shift gears to maintain leg power beyond any speeds we could reach with a single cadence-to-wheel ratio.

So, when we reach that point during acceleration where our leg power output would wane as we approach our highest cadence, we can shift instead. This brings the cadence back into a range where our pedal effort can make noticeable torque again.

Since we have multiple gears, cadence is no longer fixed to speed & therefore not the primary relevant factor in how much assist is needed.

Of course cadence\RPM are still relevant; but increasing power with cadence\RPM would mean that (for instance) upon shifting to a second or third gear, reduced cadence would get us less assist after the gear shift, forcing us to do less efficient work to reach the optimal RPM for each gear.

When shifting to last gear, this effect could be crippling: Pedaling at an unmanageably high & otherwise totally ineffective cadence in second-to-last gear would produce more motor output than pedaling slower (& more efficiently) in the last gear.

Downshifting to climb in a middle gear, would produce rubber-band effects, where we'd get a burst of power at higher cadence but find ourselves unable to push back up to that higher gear because the drop in cadence would leave us with less assist.

We've got torque sensing & multiple gears; cadence is still a factor & it is still considered in motor output, but scaling torque response to final speed is just top priority.

What does matter is that the human body isn't capable of applying as much force on the pedals at high cadences as we can at lower cadences. That's why it makes more sense to have different SpdXX columns for difference pedal cadences, since we can setup Spd80 and Spd100 to provide more assist at lower rider-applied torque at these higher cadences. For a given rider-applied torque and cadence the assistance I want only needs to vary based on how much additional torque the rider applies - not on whether the bike is going faster or slower.

Please see my explanation above, for why that alone wouldn't work with multiple rear-end ratios; final speed must be taken into consideration else the cadence requirement would work against us. Basing some things off cadence would be fine but we have to have speed data, too.

Hence the addition of the Spd0\Spd20\etc section, rather than going by only the ratio between pedal-torque & cadence (which all on its own, would kinda suck).

But, as you say, I guess I'll have to try the experiments myself to be convinced. Do you have any advice or caveats as to what I should/should not setup in the Spd Table to confirm? Again, my plan is to basically zero out assist for all but the Spd20 column (by having MinCur and MaxCur in the other columns be 1 and 2 respectively), but keeping a nice boost in the Spd20 column so the feel would be obvious. Anything to watch out for, motor or rider safety wise?

Don't run at super-low RPM too long. It can be easy to forget to downshift for lower speeds, because the motor is so powerful:

All but the last little pinion gears intended for top speed, tend to feel like there's no need to downshift with all that power; but it's hugely important to do so, not only for control but for wear reasons.

REMEMBER TO SHIFT & NEVER SHIFT UNDER LOAD.

Yet again, shifting is just a huge issue with these things: You're going to want to find out what settings make the most sense for your gear ratios+rider, but be extremely wary of settings that might apply more power at low speeds or produce a runaway effect.

(For instance wrong mV settings combined with StartKg=1; or simply setting the decays so long that only the brake\shifter cutoffs can save you from surging onward long after the pedals stop.)

There's no hub shifter yet that's rated to take the full force (in Nm) of an m620 plus a rider's effort. Even with shifters that say you can shift under a load, it's probably just not a good idea.

On the upside, once the torque sensing is set up just right, each gear feels usable at both lower speeds and higher speeds, than usual. (Indeed, I now fantasize about a 51-tooth-to-11-tooth seven-speed cassette.)

I find even 10% (of 100%) power quite noticeable, at speeds below 10 MPH. I would definitely avoid any MinCur setting above 30% at <1 MPH, for safety & rear-end damage reasons.

As for the Display calculating the speed for the motor, that's also something that should be pretty easy to check. My plan would be to modify the PAS settings to have less than 100 for the AssistX "Limited Speed(X)" and see if the cut-off point varies with changes to the display's Wheel Size versus the Basic Tab's Wheel Size. I could then combine the two experiments to see if the point at which Spd20 engages varies.

Definitely interested to hear your results!

Any speed limit other than "By Display's Command", on the "Speed Limited" setting, ought to make the controller's WheelSize setting applicable to its speed measurements... but I've never confirmed that so it'd be great to know.

For a first test to confirm that Spd20 is vehicle speed based & not strictly RPM\cadence based, you could simply set your Base Voltage then leave all other Torque tab settings as-is, & change only your max MPH/KPH setting.

Another kinda fun experiment is to set two PAS levels with the same LimitCurrent% but different LimitSpeed%.

Make sure to save your default config before you start, then save your calibrated config under a different file name, & finally save any experimentation under yet a third set of file names. This way you can undo a bad config without undergoing a test of your personal memory!

 

[ProphetZarquon]

News Flash: My testing this afternoon, as in several hours of isolating setting changes, indicates that everyone is wrong about what the Bafang SPDXX ranges reference. Since this is such a major surprise, and especially since so many people have been tweaking the Torque Table for years and claiming success based on what I've observed to be faulty assumptions, I'm waiting for some discussion over DM before I post my findings and conclusions. It's just too shocking.

If you want to participate in confirming/denying my conclusions and are willing to use the Torque settings I posted in the message above, DM me to what I did.

If I'm right, you're going to want to look for a new thread I'm going to start on Ultra Programming.

I mean, if you're getting different results please post them here as it's critically relevant to this thread; but I can only suspect there might be different UART controller firmware setups out there, if lowering your Display's speed limit lowers the MPH at which assist ends yet doesn't lower the MPH at which Spd20 takes effect... because it certainly does so on ours.

Extremely curious about your findings; please post some details here so we can compare notes!

I'm back in town this week so I should have some chance to try the test config you tried. (Please note that other tabs can be relevant too, so we should try to compare all settings and which gear ratios \ wheel types we're using, to be sure we're not overlooking a critical difference!)

 

[smorgasbord]

I just posted a step-by-step on how to setup your Delta Voltage table properly, with either a straight-forward linear mapping or a progressive non-linear mapping, here: https://electricbikereview.com/foru...tage-section-of-torque-tab.52341/#post-593674

 

[smorgasbord]

BTW, I'm still looking for someone to confirm/deny my Spd table findings with another bike. All you need to do is change your Spd Settings temporarily such that MaxCur(%) is the same as MinCur(%) for all but the Spd40 column, then ride. Then you can put MaxCur(%) back. DM me for details if you're interested in helping the Ultra community out.

 

[Nvreloader]

Smorg and Prophet Zarquon
Thank you guys for pushing the Ultra Tuning process,
and I can see a great advancement for the Ultra tuning etc.

If I can ask some questions for both of you,
1. What is the spec's on your bike?
ie; gearing, tire size, battery size, bike type etc.

2. What is your riding style/and the way you like to ride?
ie; road & paved paths, cross country/off road trail riding, down hill single tracks etc.

3. In your opinions, would the types of riding styles change this programing?

4. Can you please post the 4 sections of tuning information for your riding spec's?

Here are the spec's for my bike and riding style,
Wart Hog MD 750, dual battery's 30a total, 1500 Peak Output, 160NM Torque,
26 x 4.5" tires (Fat), Sram X-5 9 spd, DNP 13t - 34T to 44T, 170mm crank arms,
3 ride mode choices pedal-pedal assist- throttle. (ride 95% pedal assist, Eco 1 step)
Bike weight 95 #'s plus rider = 300#'s total.
My riding style/type is off road, sandy creek bottoms, cross county Cow/Wild horse trails up/down Mtns' with 2000' to 5000' elevations changes, quite common per ride.

Your thoughts and suggestions.............
Thank You,
Don

 

[smorgasbord]

If I can ask some questions for both of you,
1. What is the spec's on your bike?
ie; gearing, tire size, battery size, bike type etc.

Luna Apollo: Carbon Fiber full suspension, about 68 lbs I think.
52V, 1.1kWh battery
SRAM GX with 10-50 rear cassette, Wolftooth 48T NarrowWide front chainring, X01 Chain
Tires currently Johnny Watts 27.5" x 2.8"

2. What is your riding style/and the way you like to ride?
ie; road & paved paths, cross country/off road trail riding, down hill single tracks etc.

Until recently a mix of trail riding and pavement, but now pretty much all pavement (long story).

3. In your opinions, would the types of riding styles change this programing?

Yes.

4. Can you please post the 4 sections of tuning information for your riding spec's?

I'm still tuning.
So far, I've posted my Basic tab setting here.
And my Torque tab's Delta Voltage setting here.

Here are the spec's for my bike and riding style,
Wart Hog MD 750, dual battery's 30a total, 1500 Peak Output, 160NM Torque,
26 x 4.5" tires (Fat), Sram X-5 9 spd, DNP 13t - 34T to 44T, 170mm crank arms,

Nice bike! Do you have the older UART version of the Ultra or the new CANBus version? If the newer CANBus version then there's not much you can do programming-wise.

If you have the UART version and a Programming cable or EggRider, please DM me so you can do a quick test on the Spd table to confirm my observations, which, if correct, will totally up-end what everyone has been doing programming Ultras. I'm sure of what I've seen, but I want to be sure what I'm seeing isn't the result of some unique Luna controller/firmware.

My riding style/type is off road, sandy creek bottoms, cross county Cow/Wild horse trails up/down Mtns' with 2000' to 5000' elevations changes, quite common per ride.
Your thoughts and suggestions.............

I think you're going to care more about low-end and middle-range torque than high speed, so that's going to affect your Torque Tab settings quite a bit. I'd be hesitant to adopt the Smooth settings, which reduce low-end torque for the sake of "smoothness," and provide high assist at high speeds (although Mike/Frey thinks it's high cadence, he's wrong), which may not be want you want. You may also want different Return/Keep settings since you probably value responsiveness over lack of jerkiness when starting to pedal while already moving.

 

[Nvreloader]

Nice bike! Do you have the older UART version of the Ultra or the new CANBus version? If the newer CANBus version then there's not much you can do programming-wise.

If you have the UART version and a Programming cable or EggRider, please DM me so you can do a quick test on the Spd table to confirm my observations, which, if correct, will totally up-end what everyone has been doing programming Ultras. I'm sure of what I've seen, but I want to be sure what I'm seeing isn't the result of some unique Luna controller/firmware.

Smorg
Thank you for the info,
my WH bike is canbus now, the tuning is rude, crude and sociably unacceptable ..............YUK.
BUT, I have a brand new Uart motor and parts sitting here to go into the frame, when I pull the Canbus motor out, which sounds like a coffee grinder, when running.

So, I'll have all the info ready to install for the tuning in the new motor, for this years riding, my average speed is 10-15 mph when pedaling, Eco 1 and 95% pedaling,
with very little throttle use.

I think you're going to care more about low-end and middle-range torque than high speed, so that's going to affect your Torque Tab settings quite a bit. I'd be hesitant to adopt the Smooth settings, which reduce low-end torque for the sake of "smoothness," and provide high assist at high speeds (although Mike/Frey thinks it's high cadence, he's wrong), which may not be want you want. You may also want different Return/Keep settings since you probably value responsiveness over lack of jerkiness when starting to pedal while already moving.

I use this bike as I stated and it also my hunting bike with a trailer to haul game etc,
so I am very interested on the slow end of tuning, at75yrs old I don't need to go fast,
life already is too fast for me I think, I am an OLD ODD Phart............LOL

I am hoping that we can get some riders that do almost the same thing/type of riding..........
so I'll be following along.

Thank you for your time and trouble in these tuning post, I can understand some of it.
Don

 

[AHicks]

Smorg
Thank you for the info,
my WH bike is canbus now, the tuning is rude, crude and sociably unacceptable ..............YUK.
BUT, I have a brand new Uart motor and parts sitting here to go into the frame, when I pull the Canbus motor out, which sounds like a coffee grinder, when running.

So, I'll have all the info ready to install for the tuning in the new motor, for this years riding, my average speed is 10-15 mph when pedaling, Eco 1 and 95% pedaling,
with very little throttle use.

I use this bike as I stated and it also my hunting bike with a trailer to haul game etc,
so I am very interested on the slow end of tuning, at75yrs old I don't need to go fast,
life already is too fast for me I think, I am an OLD ODD Phart............LOL

I am hoping that we can get some riders that do almost the same thing/type of riding..........
so I'll be following along.

Thank you for your time and trouble in these tuning post, I can understand some of it.
Don

On the bold, my belief is that this point often doesn't get the attention it deserves. Rider preferences/riding style need to be kept in focus. This became very clear when all the early favorite/best BBSHD tunes started coming out - with no clear idea of why the author beleived his tune/changes might be considered"better"!!

The beauty of the UART motors is that the tuning can be changed, any or all of it, to match a rider's 'druthers. Clearly, to me anyway, those 'druthers are going to be different when comparing an off road only bike, to a commuter, or to one ridden for the hell of it in a semi urban scenario like mine. My thought anyway, FWIW. -Al

 

[smorgasbord]

The beauty of the UART motors is that the tuning can be changed, any or all of it, to match a rider's 'druthers.

Well, I wouldn't go quite that far, as even with all the settings we do have, Bafang hasn't provided us with all the settings we need. The Bosch/Yamaha/Shimano/Brose motors look at bike speed, pedal cadence and pedal force to determine how much assist to provide. The Bafang Ultra only looks at two of those, not all three: We're handicapped from the get-go. And to be fair, even the Bosch motors have Eco, Tour, Sport, and Turbo levels (although the newest model auto-switches between Tour and Turbo).

At a human perception and deception level, what's interesting to me is that for years people all over the internet (Karl, Mike@Frey, Roshan@Biktrix, EveryAmp, & eBikeaholic to name some of the more prominent) have promoted settings they've made without a true understanding of what the Bafang settings actually control! From what I've read, only our own @ProphetZarquon has a good understanding of what's really going on - and he and I are in discussions over some recent findings.

It's actually pretty astounding to me. I had just assumed that these people, especially people working at eBike OEMs, would either have true insider information or have conducted actual reverse engineering or confirmation tests. Turns out neither is true for all of them. I'm a retired engineer/engineering manager, and while I wasn't in the reverse engineering realm, I do understand it. You come up with a theory of operation, then devise a test of that theory that reduces as many variables as possible to constants. You run the test, analyze the data, then devise a variation of that test or add new tests. The goal is find correlation so strong that there's really only one logical conclusion as to how the system works and what the parameters actually measure and control.

Has anyone except @ProphetZarquon and I done even rudimentary confirmation tests? It does not seem so. For instance, the EveryAmp guy posts a DeltaVoltage table that maxes out the pedal force range at just over 45Kg, yet he continues to specify values for pressures above that as if they matter. Or the original Ultra tuner, Karl Gesslein, insisting that the SPD columns mean a certain thing when the first test I ran confirmed he was wrong and that @ProphetZarquon was onto something. Or that Michael at Frey promotes Spd settings when he is also wrong about the columns are referencing.

Don't get me wrong - all of these people have contributed useful information and are right about some or even most things. But, you can't take everything they say as being true and that has resulted in many of us adjusting things that turn out to not be what we thought.

Back at the human perception/deception thing, it's interesting that this has gone on for years. I suppose at the end of the day we as physical beings are adaptable. I've ridden cadence-sensing, rear-hub motored eBikes and, you know what? They work. As a rider, you end up choosing a PAS level and gearing ratio that provides a comfortable pedaling experience. If you find yourself pressing too hard on the pedals because the system isn't torque-sensing, you naturally reach for the "+" PAS button and/or downshift. It's a natural thing. And since the Ultra is torque-sensing, it's already better, even if we're not tuning it as we think we are, or if that tuning just happens to work for the specific situations in which we're riding and we shrug it off when the hill is steeper or the terrain is different, or we're distracted by the tree roots and mud on our single-tracks.

I'll start a new thread "Ultra Tuning: Decoding the Spd Table of the Torque Tab" when I've got independent confirmation of my reverse engineering tests. I'm trying to not make the mistakes others have made.