Torque vs cadence based PAS riding experience

AHicks said:
Regarding controlling your power/speed with the cadence sensor. I don't see how that will work either and for the same reason mentioned just above. There's no way to factor changes in load. With power increasing as cadence is increased,
WIth the CA, you can make the power *decrease* then, if you wish (some of the settings can be made negative for this purpose). I don't know if any built-in controller settings can be changed like this, but the CA can be used between your control system and your controller to do a lot of things that controllers can't do on their own (it's one reason it exists).


what happens when a hill is encountered? I don't know about others, but I can say that MY cadence is going to slow considerably (no doubt). If we are using cadence to control power, when cadence slows due to an increase in load, power is decreased. When faced with an increased load/hill, decreased power is the LAST thing I would want to see in this situation!
That depends on how the specific controlling device works, and the settings chosen in it. In the Cycle Analyst, there are ways to compensate for this, to varying degrees depending on the motor system, situation, and bike gearing, etc.

Additionally, if you are riding uphill, etc., you would normally shift down to keep your cadence as close to the same as possible, just like when you ride more slowly, and when riding faster you would shift up to do the same thing. (this is how a regular pedal-only bicycle would be used, too, for those that have never used them). If you don't have continously variable gearing like a Nuvinci, then it's not always exactly the same cadence, but if you have the right gearing setup on the bike it wil be close most of the time. If your gearing range is not wide enough for all the situations you use the bike in, then there will be situations where you can't do this, but if it is correclty geared then you can do so. Many people choose to never shift gears, even when they dont' have motor assist, so they don't realize they can do this, and have to work harder when it's not necessary. ;)


I would love to see the level of control the CA gives you over all of the PAS modes (and throttle modes!) implemented directly in controllers; I don't know of any that do, yet (even the OSFW stuff).

I'd personally like to see it done in a simpler, more user-friendly way, that doesn't require intimate understanding of the interactions between each of the menus and settings, and something that is more graphical in nature, but even if it was done in the exact same way it would still be better than what is presently available in the controllers themselves. ;)


The way I would like to see it done (based on just a minute's pondering) might include something that looks a bit like a graph for the various settings, vaguely like the way the Grin Motor Simulator looks. Set scales for vertical/horizontal view of each of the settings that is proportional to your system's capabilities and the terrain/speeds/etc you have to deal with. Draw (or drag handles on) a line for each of the parameters to set them to how they react for each intersection of these things. If something is out of bounds it just won't let you change it to that, and will alert you (perhaps flashing the line at you from the out of bounds point on, flattening it, etc). If a curve you make for one setting will affect other things, you can see that directly on screen as it changes them, literally as you drag the points of the curve. If you don't like the change, just Undo (infinite levels!) and go back to what you had before you touched it. ;) Save as many presets of these curve sets (or individual curves!) as you like, so you don't have to redraw them for other things, or other setups.

Would be nice if these could be onscreen for the controller itself, but even if they have to be in a setup program on a computer, or tablet/phone app, it would still be a great improvement over what controllers have available now (and even over the CA's present menu system, which could be left intact for those that need access to that).

I'd have to ponder it more to come up with a good GUI for setting this kind of thing up in a way most people could just look at and figure out.
 
Thanks Al for the quick reply.

AHicks said:
OK from a stop, this old man uses a touch of throttle to get the bike moving while I collect my balance. Not much ... From there, how quickly the bike accelerates will be based on the PAS level
:
Because you are using power based PAS, the amount of power (from a practical standpoint) remains the same within each PAS level.
:
amount of power will remain about the same regardless of speed, as long as the pedals are turning.

Okay, so seems if starting on a steep uphill, best course would be to set at PAS5, start the vehicle via throttle & once it starts moving, keep pedalling at whatever cadence once can.

The control scheme here probably is Basic PAS, constant power.
 
afzal said:
Thanks Al for the quick reply.

AHicks said:
OK from a stop, this old man uses a touch of throttle to get the bike moving while I collect my balance. Not much ... From there, how quickly the bike accelerates will be based on the PAS level
:
Because you are using power based PAS, the amount of power (from a practical standpoint) remains the same within each PAS level.
:
amount of power will remain about the same regardless of speed, as long as the pedals are turning.

Okay, so seems if starting on a steep uphill, best course would be to set at PAS5, start the vehicle via throttle & once it starts moving, keep pedalling at whatever cadence once can.

The control scheme here probably is Basic PAS, constant power.

Re:starting on a steep hill scenario. Actually it's pretty easy. You just use the throttle in any amount required. This gives you a chance to get your gear and PAS level coordinated and in use.

As I ride for pleasure only, I only RARELY use PAS 4 or 5 (it's been months!). Just not in that big a hurry! PAS 1 generally (or maybe 2 if going into the wind) for cruise (9-14mph or thereabouts), Pas 3 for occasional big hills. 4 and 5 are there when/if needed. Yes been riding daily for a while, but at 70 years old and 6'2"/315lbs, I'm no picture of fitness.... Decent bike with good tires that are properly inflated doesn't need a lot of power to maintain lower cruise speeds. As mentioned, somewhere between 75 and 150 watts is all you need. Makes no difference if the motor is 500w or 1000w, that's all they need!

That's generally the issue with the junk controllers. They're supplying twice the power needed when in PAS1! The most common complaint is they're too fast with no way to slow them!
 
Definitely you should have the option of throttle from the stop, then take up with cadence controlled. That class of e bikes that cannot have a throttle is stupid.

Definitely you should have the option of user adjustment of the PAS settings, so you don't get the settings most retailers set.

One reason I really hated PAS was the settings they used. Whether it was a half rotation of the pedals, or 10, when it kicked in it was wham, full throttle. Especially uncomfortable if the bike was front hub. I rode a bunch of them like this at interbike, rear hub, front hub, mid drive. The demo bikes were set up to show off their power. Amost all rode like crap, unless they had a throttle you could use to get going.

Thank God cheap ass displays, and controllers are history now, unless you use scooter stuff.
 
I take it that a torque sensor fed torque controlled system (well tuned) is far better than any type of basic or Cadence PAS controlled system. Upon analyzing, I had arrived at the same conclusion, but wanted to hear other people's opinion, especially one's who have used those.

My goal is to develop a controller that would provide ride experience similar to a well tuned torque sensor based system, but using only Basic PAS. Here a software algorithm will take the place of torque sensor.
 
amberwolf said:
I would love to see the level of control the CA gives you over all of the PAS modes (and throttle modes!) implemented directly in controllers; I don't know of any that do, yet (even the OSFW stuff).

I'd personally like to see it done in a simpler, more user-friendly way, that doesn't require intimate understanding of the interactions between each of the menus and settings, and something that is more graphical in nature, but even if it was done in the exact same way it would still be better than what is presently available in the controllers themselves. ;)


The way I would like to see it done (based on just a minute's pondering) might include something that looks a bit like a graph for the various settings, vaguely like the way the Grin Motor Simulator looks. Set scales for vertical/horizontal view of each of the settings that is proportional to your system's capabilities and the terrain/speeds/etc you have to deal with. Draw (or drag handles on) a line for each of the parameters to set them to how they react for each intersection of these things. If something is out of bounds it just won't let you change it to that, and will alert you (perhaps flashing the line at you from the out of bounds point on, flattening it, etc). If a curve you make for one setting will affect other things, you can see that directly on screen as it changes them, literally as you drag the points of the curve. If you don't like the change, just Undo (infinite levels!) and go back to what you had before you touched it. ;) Save as many presets of these curve sets (or individual curves!) as you like, so you don't have to redraw them for other things, or other setups.

Would be nice if these could be onscreen for the controller itself, but even if they have to be in a setup program on a computer, or tablet/phone app, it would still be a great improvement over what controllers have available now (and even over the CA's present menu system, which could be left intact for those that need access to that).

I'd have to ponder it more to come up with a good GUI for setting this kind of thing up in a way most people could just look at and figure out.

After developing the controller, a good GUI display development is in the plan (unless things go south)
 
afzal said:
I take it that a torque sensor fed torque controlled system (well tuned) is far better than any type of basic or Cadence PAS controlled system. Upon analyzing, I had arrived at the same conclusion, but wanted to hear other people's opinion, especially one's who have used those.

My goal is to develop a controller that would provide ride experience similar to a well tuned torque sensor based system, but using only Basic PAS. Here a software algorithm will take the place of torque sensor.

I think it can be done, or maybe even exceed. Some algorithms of course, but with plenty of user definable parameters being very important as well. I think trying to come up with some sort of generic, 1 set of parameters fits all program will never work out well. There are just too many riding styles! You can't expect an elderly newby to have the same priorities as a younger, possibly more experienced and fit rider. Nor can you expect the needs of somebody riding around on subdivision streets to have the same priorities as somebody riding on a beach, off road, hilly areas vs. flat, and on and on. TOO MANY VARIABLES for one set of parameters and algorithims. GOOD firmware will take as much of that into account as possible.

I would note that a well tuned Bafang BBSxx mid drive does not have torque sensing, yet is VERY pleasant to ride. Sure, the very similarly designed/programmed Ultra motor does have torque sensing, but it doesn't have this huge insurmountable advantage over it's non torque converter siblings. -Al
 
AHicks said:
I would note that a well tuned Bafang BBSxx mid drive does not have torque sensing, yet is VERY pleasant to ride. Sure, the very similarly designed/programmed Ultra motor does have torque sensing, but it doesn't have this huge insurmountable advantage over it's non torque converter siblings. -Al
Bafang BBSxx behavior is a good data point, let me search ES on it, if there is anything more to add w.r.t Bafang BBSxx riding experience, please do so.

I think geared mid-drive per se has an advantage w.r.t user experience, was your KT controller on a geared mid-drive system ?
 
afzal said:
I think geared mid-drive per se has an advantage w.r.t user experience, was your KT controller on a geared mid-drive system ?

No. The Bafang BBSxx and Ultra mid drives both use an internal controller by Bafang. I think you'll discover that the OEM controller programming is pretty easy to improve on. The controller is CAPABLE of being programmed to perform really well (which is my point, this is not a hardware issue, it's a programming issue). You're going to get into a can of worms here though, in the UART vs. Canbus controller types. I'm speaking of the UART based controllers. They are easily programmed by anyone that wants to. CANbus, the newer interface, is locked down by Bafang, and as of yet, not able to be changed. Same terrible OEM programming.

I think that one of the reasons the UART based Bafang programming can be improved on so easily (as compared to anything else I'm familiar with), goes back to a point made earlier. Within the Bafang controller programming, there are literally dozens of parameters an end user can change according to their own priorities. Additionally, it's possible to load up a single file to change everything all at once - laying the groundwork for custom packages that set ALL parameters with a certain set of priorities in mind....

My KT experience has all been on geared hub motors from 500 to 1000 watts as well as direct drive hubs from 1000 to 1500w.
-Al
 
Yes HillCruiser, please continue on the new thread once created.

I have a proof-of-concept with the initial software iteration, behavior doesn't look bad. An intermittent assist could be felt at low speed on flats, some of the ES threads mention a similar behavior with the torque sensor, and that similarity (though has to be fixed) is encouraging (for me).

Though I can think of how a torque sensor assist would behave, having never rode a torque sensor assisted one, I will be purchasing a torque sensor to experience it. Probably will go ahead with Erider BB so that the signal can be used directly (thanks amberwolf for this subtle detail!)
 
afzal said:
Yes HillCruiser, please continue on the new thread once created.
Terrain Control alternate to PAS/Torque control
https://endless-sphere.com/forums/viewtopic.php?f=3&t=114781
 
A belated update:

After further software iterations, the proof-of-concept virtual torque pedelec controller (provide assist in proportion to the effort put by the rider without using torque sensor) has been validated to work satisfactorily on gearless hub motor as well as geared hub motor. VESC hardware was used and software was written as necessary.

Next step is to design controller hardware for the minimum viable product. I am confident of taking care of the software, but electronics, though not alien to me, I might outsource or hire someone. Anyway the initial product is going to be a low power one, PCB layout is not that critical. So I have started doing the design myself as well to get a grip on the things. To avoid licensing issues, it was decided to design hardware internally, more below.

---

For the initial product to get test feedback, I had thought of using bluepill plus power board, the same idea was put forth by casainho and there was an anticipatory bail from me on that thread. And then later I thought, perhaps I can simply use the hardware they are developing along with my software (I do plan to make it public after a period of 5 years, but if I make it open source now, I will be digging my own grave). But then I looked into the licensing, they have used software license (GPL) for hardware design. I don't know what to make out of that, to put it bluntly, a software license on a hardware design does not make sense. But I cannot blame the developers as it is their discretion, moreover the developer's intention was to make it as open as possible. As a hobby developer, they might do, but as my intention is to develop product for sales, I can't proceed with an ambiguous license.

On the non-technical side, some unexpected things happened. The virtual torque pedelec controller development got selected for startup incubation in one of the best electronics park around here. Advantage is that it has many facilities like PCB fabrication & assembly (though not to the required extent), quality instrumentation equipments etc. Further they can provide some market visibility. And to get there, had to invest some time to overcome multiple hurdles. Once selected, there was further requirements of company incorporation, which in turn had other dependent requirements eating my time. But I hope the time lost here can be recouped later because of the facilities they offer. And now I am positive, covid ;)

---

Since non-technical work in parallel was not allowing me to concentrate properly on technical stuff, started doing wheel lacing on hub motor, spending a little time every day for a few days, it was a good experience. I couldn't get proper length spoke locally. And in the absence of spoke cutter & threader, I had to rely on the groove in the plier to cut (after getting a spoke with 3mm more than required) & spoke wrench as spoke threader (tightening the nipple on bare spoke after the end of the thread to make more threads, though it was a crude spoke threading technique, it was not utterly bad, though was painful & time consuming). Spoke calculation was done using Grin's calculator & truing (poor man's truing machine - bicycle turned upside down) was also done based on Grin's video. Result - operation successful, patient died. Though wheel was reasonably true, few spoke(s) punched hole on the tube. The patient had to be resuscitated. Wheel had to be false'd ;) to prevent further tube puncture. There was another reason that exacerbated the issue - rim was bent while removing the existing tyre that was too difficult to take out. Though not trued properly, it was okay to ride & test what was needed of that setup.
 
An update:

First iteration of the hardware is ready, sanity test okay. Firmware development is under progress. Expecting the controller to be ready for beta testing in around 9 months.
 
Last edited:
First iteration of the hardware is ready,
What is the motivation for your work?! There are several cheap and reliable torque sensors available, so why not just use them, for a natural bicycle feeling on an E-Bike....

regards
stancecoke
 
Last edited:
Do you know the "affe" automatic, offered by an Austrian engineer? He tried the same as you. But his homepage doesn't exist any more...
Guten Tag, my German is only kindergarten level. From a quick look of the translated discussion on pedelec.de forum, what I could make out is that it is specifically for geared cycles & upon detecting lower gear, it provides more power. I will convert the pdf once at my laptop & go through it.

Mine has been validated only on a mechanically gearless ecycle, yet to test on a geared one.

Don't get me wrong, thanks for the link & on the dangers involved
 
Back
Top