Self-learning controllers

Joined
Nov 25, 2009
Messages
14
Location
cantabrigivm, massachvsetts
Hi all,

Frequent reader but rather infrequent poster here; I operate primarily in the e-scooter and go-kart (and other weird rideables) domain, not so much e-bikes.

I come to you with a request for feedback on Chinese ESCs which have a 'self-learn' mode where they can automatically recognize Hall sensor configurations for any given motor. Many Chinese e-bike ESCs advertise this nowadays and I want to hear if people have had good experiences with them or not. The forum search did not lead me to much insight on how much penetration these controllers have into the e-bike maker market.

Basically what I did was catalog several different Chinese e-bike controllers from various eBay sellers and recorded a few different aspects of their functionality such as sensorless start and run, method of using Self-learn, etc. I've made a summary post on my website: http://www.etotheipiplusone.net/?p=2387 regarding the matter and pitched together an Excel spreadsheet that summarizes the findings.

My questions include:

1. What other makes/models of controllers have this feature that ES readers frequently use? I'm always out to expand the catalog, so sources of where to get these would be good.
2. Is this really useful for e-bikes with hub motors? Or can you assume that since it's a bike, you're basically going to be moving before hitting the throttle? The hub motors e-bikes I've ridden seemed to have no trouble starting themselves sensorlessly, I supposed because of how many poles/slots they have.
3. Since my 'research' was appending sensor PCBs to a typical R/C outrunner for propulsion applications, do you guys think there's a market for R/C type conversions with these controllers? I'm not out to sell anything so far, but I'm genuinely curious as to how many R/C conversion projects have been stymied because of the difficulty of arranging sensors. As my site shows, I've been developing a standardized set of sensor PCB mounts and plastic mounting rings.

Otherwise, feedback, comments, and questions are welcome. I ideally don't want to replicate work that already has been done on this forum...
 
I believe the majority of ebike controllers can automatically detect and work with 60 deg or 120 deg Hall sensors now, and some can also automatically switch between Hall sensor operation and sensorless operation. Certainly the auto detection of 60 deg or 120 deg Halls has been commonplace on ebike controllers like the Xiechang over at least the last three model iterations that I know of, even the original XC846 models had this capability several years ago.
 
I read through your results with the controllers that you have tested, there is a lot of very usefully info in there. Thanks for taking the time to do this, and it has answered one of the niggles that I had with a cheapo controller that I was playing around with once ( about the reversing of the wheel ) .

Sorry I have no additional information for you as regards the self learn function on these controllers. I think most people with hub motors would be happy with the max eRPM that these controllers can do and the function of sensor/sensorless operation are able to deliver but for people wishing to use sensored rc motors these limited eRPM's are a big issue, I run my rc motors at around 9k rpm (63000 eRPM) and so far have only found that the keywin/crazyman controllers are able to do this reliable ( I have tried may others that are much cheaper than the keywin/crazyman controllers but no joy as yet ).

I see from your spreadsheet that the vitualvillage controller looks like if it would be a good candidate to test for my purpose but it also looks like if vitualvillage are no longer trading on e-bay :( ( they have nothing listed anymore ). The keywin/crazyman are the most popular controllers on this forum ( I think ) and people modify to there own spec . Never assume you are already going to be moving before you hit the throttle even with a e-bike :D so good startup torque is a must. Myself and many others run RC motors fitted with hall sensors ( not just ) on e-bikes.
 
Sorry, I didn't read your website round up before. It's useful, but I can probably shed a bit of light on some of the issues you observed.

All ebike controllers of this type and price range are primarily designed to drive hub motors, so have an inherent built in phase current estimation algorithm that assumes a typical hub motor LR value, which will be quite high. Hook them to a motor with a notably lower L or R than they are expecting and they will struggle. None of them sense phase current directly, the universal practice for budget controllers is to only measure battery current, often with two separate and independent circuits, and then derive the maximum allowable phase current from the assumed LR of the motor and the programmed value set (if the controller is user/dealer programmable, which many are). The second current sense circuit is usually the cause for shut downs when trying to drive low L or R motors, like RC-type outrunners. Often it's just a fast comparator that detects an over current spike on the shunt and triggers an interupt to shut the controller down. The idea is that this will give a modicum of protection from a wiring or motor fault, but in practice it isn't usually enough to save the FETs from death under extreme conditions.

What helps is to dig around and find the source of these controllers. There a quite a few controller manufacturers in China, but only a handful of different manufacturers products seems to make it to the export market. The two most commonly seen seem to be the Xiechang and the Wuxi Technology controllers.

The Xiechang's are sold by quite a few internet/ebay vendors (e-crazyman, Lyen, Emissions Free, Crystalyte etc), and come in a variety of models from a low power 6 FET version right up to a 36 FET monster. All are programmable by the user and all use the same microcontroller core. This core used to be an Infineon XC846 dedicated motor control 8 bit MCU (8081 based, believe it or not!), but for the past couple of years these controllers have used a home-grown controller, labelled XCKJ8B116A. This seems to be a close copy of the Infineon motor control MCUs, with very similar functionality. The programming software for these is readily available here and so these controllers are fairly popular, as they can be easily reconfigured.

The Wuxi Technology controllers are again widely sold on the internet/ebay etc, under the Hua Tong, KU, Greentime or other names. These are also programmable and come in a fairly wide range of configurations, up to 24 FET models (AFAIK). Unfortunately the programming software hasn't escaped from China, making these controllers much less useful from the perspective of tinkerers who want to change current and voltage settings. Hacking these ends up being crude bodges to shunts etc, with the commensurate degradation in some of the other controller functionality.

The sensored/sensorless switching on those controllers that have this capability isn't intelligent on any that I've seen. It's simply a set of zero crossing detectors added to the board (usually using one or two quad comparator packages, often LM339s) to generate a set of "Hall" signals from the phase connections and feed these back to the MCU as an OR'd connection with the Hall signals. The MCU will trigger on whichever edge it sees first, either the Hall signal or the zero crossing signal, meaning that the controller carries on working even if a Hall fails.
 
Jeremy Harris said:
Sorry, I didn't read your website round up before. It's useful, but I can probably shed a bit of light on some of the issues you observed.

All ebike controllers of this type and price range are primarily designed to drive hub motors, so have an inherent built in phase current estimation algorithm that assumes a typical hub motor LR value, which will be quite high. Hook them to a motor with a notably lower L or R than they are expecting and they will struggle. None of them sense phase current directly, the universal practice for budget controllers is to only measure battery current, often with two separate and independent circuits, and then derive the maximum allowable phase current from the assumed LR of the motor and the programmed value set (if the controller is user/dealer programmable, which many are). The second current sense circuit is usually the cause for shut downs when trying to drive low L or R motors, like RC-type outrunners. Often it's just a fast comparator that detects an over current spike on the shunt and triggers an interupt to shut the controller down. The idea is that this will give a modicum of protection from a wiring or motor fault, but in practice it isn't usually enough to save the FETs from death under extreme conditions.

I found that nearly all the 'OTHER' controllers ( must have tested 6 more more ) would not shut down, but once the rc motor get to around 4k rpm they would just start mis-firing and drawing huge amounts of current so this would indicate to me that they may not even have any type of phase current limiting :? .

Edit:
But this could be that the the controllers need to be forced into working with sensors, because without halls connected they basically do the exact same thing. You only know that the halls are working initially because of the increased starting torque ( this was not the case with all the controllers I tested )
 
gwhy! said:
I found that nearly all the 'OTHER' controllers ( must have tested 6 more more ) would not shut down, but once the rc motor get to around 4k rpm they would just start mis-firing and drawing huge amounts of current so this would indicate to me that they may not even have any type of phase current limiting :? .

Edit:
But this could be that the the controllers need to be forced into working with sensors, because without halls connected they basically do the exact same thing. You only know that the halls are working initially because of the increased starting torque ( this was not the case with all the controllers I tested )

I've seen the same thing, and interestingly it's pretty much how my simple DIY controller behaves when asked to deliver a high phase current. I think that "shut down" may have been the wrong word, in that I didn't mean shut right down, just momentarily shut the output stages off when an excessively high peak was detected. The Xiechang's remain shut down until the throttle is closed and opened again, but I've got an unknown cheapie here that just shuts down when the current peaks and then tries to restart, usually with another shut down a fraction of a second later.
 
Jeremy,

Sounds pretty much like what I've discovered through messing with these things over the past year or so. I most like the self-training Halls feature and wish it can become prevalent on more legitimate controllers like Kelly... or someone design some real hardware around the processors. What dies the most for me with those cheap controllers is the discrete gate drive circuit made of tiny BJTs. Guess GDICs are just too upmarket for them.

Part of the decision process when I tell people of their sensored vs. sensorless options is always playing sensor order roulette - and with R/C type motors that you have to append sensors to, also timing roulette. I'm so far still the biggest fan of the controllers sold by bobzhangxu because they automatically switch out of halls as soon as the motor hits a certain eRPM. I'm not enamored by the timing lag introduced by Hall sensors at high speeds, and this is the region of operation where your torque and speed transients are likely to be the smallest (having mass and all), so the "innate" sensorless functions are great there.

And yes, it looks like the seller virtualvillage has disappeared. I'm scouring eBay listings now trying to see if the Yiyun controllers are still available elsewhere.
 
The "automatic switch" from sensored to sensorless with these controllers isn't usually by design, it's just an accident of crudely OR'ing the zero crossing detector outputs with the Hall sensor outputs. The Halls are often located with slightly retarded timing for good starting torque, so as the motor speeds up the zero crossing detector starts to trigger before the Halls, so ensuring that the motor runs neutrally timed. Many motors, especially high pole pair count hub motor, can have quite substantial timing errors from the way the Hall sensors are fitted, too. The greater the pole pair count the more accurate the Hall positioning requirement gets, and it's not at all uncommon for sensors to be out by quite a few degrees (electrical).

The FET drivers are deliberately weak, I believe, to keep FET switching speeds slow. This means they can get away without needing to do much in the way of EMI control and simplifies the commutation capacitor choice and board layout. Typically the gate drive current will be around 130mA peak, so FET switching times are often considerably greater than 1µS. This does increase FET switching loss a bit, but that's another compromise they make to keep them cheap and simple. As I (and others here) have found, when you up the gate drive to levels that give sub 500nS switching times the potential for noise and ringing increases and the demand on the commutation capacitors becomes such that more expensive low ESR types are required, with better layout of the power tracks.

For me, the programmable controllers always seem to be a better choice, simply because being able to adjust phase current, battery current, cruise control settings, speed switch settings etc in a few seconds via a serial cable to a PC is invaluable. For example, I had a very twitchy throttle on my latest build, but turning the phase current down, whilst keeping the same battery current limit, has improved the feel of the throttle at low speed a lot. It's a pity that the Xiechang is the only controller series where we have access to the programming software. It's clear that a lot of other controllers have programming ports on the board, but we've not been able to get a copy of the software to make use of it.
 
Hi Jeremy,

Thanks for the insight. Do you happen to have a link to anyone who has reverse-engineered an example schematic for the setup you describe? I know there's this: http://www.avdweb.nl/solar-bike/electronics/ku63-motor-controller.html but I don't think it's the exact controller I have. It does show both Halls and ZCD outputs feeding into the micro, so the OR'ing could be done internally in software.

I'm fairly certain the type I mentioned explicitly switches by design, because I tried starting with the Halls in many displaced positions that were clearly "off-timing" in either direction. However I'm now curious what the exact relation is and will go back and double check.
 
I've collected bits and pieces of some parts of some of the circuits of some controllers over the years, but never got around to taking the time to draw them up. The Wuxi Technology controller circuit diagram you referred to (the avdweb link) is a good source and somewhere on here there is a copy of the Xiechang circuit diagram (I have a copy on my other PC somewhere, I'll try and dig it out later). Both are very similar (near identical, in fact, except for using different MCUs) as are many others I've looked at. I think that there's been a process of just copying what works from one manufacturer to another, given the close similarity in the internal circuitry.

All the MCU based controllers I've looked at have used low speed, pretty simple, 8 bit MCUs, with limited processing speed and hence capability to do anything other than basic motor control. The give away that they are slow and internally quite limited is that they almost always have to use an external fast current protection loop, using something other that MCU processing to shut things down under fault conditions. If they had enough processor speed to do taught control, like cycle-by-cycle current limiting, then they wouldn't need the extra external circuitry.

This low processor speed capability is one of the reasons that some are quite noticeably e rpm limited, I believe. It's also what makes me believe that there cannot be much in the way of added intelligence to auto detect things like Hall sequence errors, as the majority of these things just don't seem to have the additional processing capability that would be needed to get something like this to work. There may be some newer controllers around with better MCUs, but so far they don't seem to be that commonplace in the budget ebike parts market.

It would also make sense for a controller that has a better and faster MCU to stop using 6 step trapezoidal drive and switch to something like FOC, as it's really just the limited capability of the current range of processors that keep them stuck with this fairly crude (and noisy) drive methodology. Pretty much the same external circuitry could be used as used on current cheap controllers, the main difference would be in the code in the more capable MCU. The advantages in terms of being able to drive motors more smoothly, the use of current mode throttle control and the higher inherent level of protection from faults from using fast phase current sensing would make such a scheme attractive, I would have thought, yet currently we only see this on high-end controllers.

My guess is that the ability for a controller to autodetect a Hall sequence is a fairly limited attraction. Sure it makes it simpler when initially wiring up a motor and controller, but I don't think I've ever spent more than two or three minutes working out the correct Hall sequence anyway. An ebike manufacturer would have no need of this at all, as they are going to use wiring looms that are specific to the bike, motor and controller, and therefore won't need the controller to sort out the order of the wires for them. The only use for such a feature is the DIY ebike conversion market, and then only those building from scratch, rather than using a kit. That's a pretty small market, well catered for here on ES. Sure people occasionally have minor issues where they get the Hall sequence wrong initially, but it's not an issue that comes up very often, it's very easily sorted and many motor/controller wire colour combinations are documented here to give people a good chance of getting it right first time. It strikes me that an auto learn feature like this may really just be a solution looking for a problem, rather than something that gives a real performance benefit.
 
I was playing with one of the KU63 controllers from BMSBattery that have the automatic self-learning function. Previous versions had non-automatic self-learning, where you have to connect a couple of wires and do a self learning procedure.

I was testing with a new Bafang CST motor. The controller figured it out first time and it gave 25.9 mph. Without switching off, I pulled the hall plug. The motor still worked but had intermittent pick-up from start. I disconnected the battery and re-connected it, whereupon the pickup became normal, but top speed was only 22.5mph.
 
Back
Top