I want your opinions: Brushless controller features

[ZapPat]

Hi all fellow ES members!

I have been working on my own ebike brushless controller prototype, and would greatly appreciate some idea input from my fellow ES members. Specially from you guys who have lots of practical EV experience, I would be most pleased if you could share your aquired wisdom with me. Even though I've been playing with brushless controller design for some years part-time on my workbench, I am quite new to actually applying it to real-world EV applications. BTW, I will not be able to implement all this right away of course, but I like to have many ideas at once to play with - Mainly so I can make the hardware ready to support future firmware changes. So...

"What features would the ideal ebike controller have?"
There might be a couple diverging views, but post any and all ideas please!

To start you off, I've come up with this possibly desirable feature list (feel free to pick apart, criticise and commend on at will!)
- Small (something like castle creations offerings)
- Efficient (mostly usefull because of the smaller heat sink requirements)
- User-configurable via simple computer interface window (Max current, LVC, HVC, + all other optional parameters)
- Regen on demand (with some automatic current adjustment done by the controller to optimize efficiency)
- Adjustable max regen current (*)
- ABS-type reaction (to avoid possible lock-ups, specially when using large motors like X5's - Note that this may just be equivalent to seting a max regen current...)
- Maybe use brake switch input to enable regen mode, and/or... Use "snap" the throttle off to coast or "roll" the throttle off to engine brake ---> Method's suggestion here!
- Adjustable high-voltage cutoff, for regen use (*) ---> Eventually a direct signal from the BMS would be much better, to cutoff/reduce regen current when first cell hits Vmax.
- High-voltage cutoff user warning, and/or automatic redirection of regen current to optional load resistor, or it might be possible to implement an engine break using the FETs
- Adjustable max current (*)
- Adjustable LVC (*)
- (*) = Optional connection to moded BMS (for LVC, HVC) --> this would reduce the BMS's cost (eliminating the need for the BMS FETs and shunt), augment system efficiency and provide regen overcharge protection on a per cell basis
- Optional cruise control (for relaxing that tired wrist)
- Optional dual driving modes (power mode, economy mode,...); Maybe could use some sort of automatic switching between modes, or use a button, or selectable via PC
- Adjustable speed limit (for legal purposes, or safety for some)
- Throttle input calibration (for a more linear throttle control response)
- Selectable throttle control modes: Classic (PWM duty cycle) control mode, Current control mode
- Cycle analyst connection (maybe eventually integrate an LCD with CA functions right into the controller?)
- Diagnostic LED(s) and/or use PC interface software for problem solving and error reporting
- Upgradable firmware (maybe by end user, but likely available only by sending the unit back to builder)
- Reduced torque ripple (less of a cogging "square" feel, specially when accelerating hard at low speeds and while doing strong regen)
- Sensorless operation eventually
- For hard-core tweakers: Optional ICD interface to use the controller's hardware with custom user-made firmware
- WHAT ELSE??

Thanks for your input!
Patrick

 

[Microbatman]

No hall sensors. Even if it means making a new matching hub motor. Lose the hall sensors. The RC crowd has been running BLDC motors for years without hall sensors. I still can't figure out why we need hall sensors for e bikes with todays modern software/firmware technology.

Hall sensors seem to be the weak link in the power drive chain and quite the pain to replace.

Programable low voltage cutoff

120 volt max 50amps

Downloadable data via USB to track current

 

[Miles]

Hi Patrick,

Pulse charge regeneration?

Sine wave rather than block commutation?

 

[smithinparis]

Hey Patrick,
I too am working on a brushless controller design. I fried my Crystalyte V1 36V 20A Start Immediate controller in some light flurries, and rather than fix it up, I decided to build a new, custom controller. I could fix the Crystalyte, I know I blew 2 FETs and one of the gate driving resistors, but rather than make an order from Digikey for those three parts, and risk blowing them again because of another fault further up the chain - I figured I'd build the controller that I actually want.
I've gotten all my parts from Digikey already, and I'm laying out the power section (I don't want to build the power section on a breadboard), and when that's done, I'll be building the actual control bit.
When the ball starts rolling, I'll get a thread going because I really want to get some opinions from the fine folks here as well.
Here is what I'm after:
1) Capable of 36 V to 72 V 35 A - for this I've choosen the IRF4310 FETs (6 for now)
2) Microprocessor controlled for easy upgrading and adding new features later on down the road - I'm basing it on a PIC 16F871. An absolutely massive PIC chip.
3) Regen capable
4) Ebrake connection (of course)
5) Current limiting
6) Thermistor heat monitoring that will throttle the controller down to limit the heating, rather than shutting down
7) Serial data out to plug into a Palm Pilot or PC, and a little serial LCD that will be located on the handle bars.
8 ) A 12V DC/DC converter and 5 V regulator combination to power the low power stuff
9) Sensored operation to start with, and will add an optional Sensorless option later
10) Completely @#$%@!@ing waterproof (sorry, I'm still a little bitter)
11) A connection to the front wheel speedometer pickup to implement a watchdog type function that will match the speed of the wheels (like antilock brakes) in the event of slippage on ice or a tumble off the bike (I've taken the spring out of my throttle, so it doesn't shut off on its own)
12) Voltage and current monitoring
13) Serial data in to allow for tweeking of some nitty gritty parameters (throttle calibration, PWM changes, current limiting changes ...)
I've already purchased all the bits and pieces to implement most of the stuff above. My goal was to keep the price under the cost of a new Crystalyte 36V 20A Start immediate controller (~$125), and I actually managed to keep it just under $100, which I'm pretty happy about.

 

[ZapPat]

Hey Patrick,
I too am working on a brushless controller design. I fried my Crystalyte V1 36V 20A Start Immediate controller in some light flurries, and rather than fix it up, I decided to build a new, custom controller. I could fix the Crystalyte, I know I blew 2 FETs and one of the gate driving resistors, but rather than make an order from Digikey for those three parts, and risk blowing them again because of another fault further up the chain - I figured I'd build the controller that I actually want.
I've gotten all my parts from Digikey already, and I'm laying out the power section (I don't want to build the power section on a breadboard), and when that's done, I'll be building the actual control bit.

Sounds very wise of you not trying the power layout on your BB If you like it at all!

When the ball starts rolling, I'll get a thread going because I really want to get some opinions from the fine folks here as well.
Here is what I'm after:
1) Capable of 36 V to 72 V 35 A - for this I've choosen the IRF4310 FETs (6 for now)
2) Microprocessor controlled for easy upgrading and adding new features later on down the road - I'm basing it on a PIC 16F871. An absolutely massive PIC chip.

Do some reading on the PIC18F2331-2431-4331-4431 micro, you might like these better because of the 6-8 pin power PWM output peripheral and faster ADC.

3) Regen capable

Remember OVP to go with that!

4) Ebrake connection (of course)

An obvious one I forgot to add, and which I'll have to think about in case I also decide to use the break switch for regen.

5) Current limiting

I'm using an Allegro hall sensor so far, but am not sure it's fast enough for what I need. It's also much more costly than shunts, but then again would let me make controllers up to 200A with no heat. And I am also experimenting with using FET resistance as a current sensing device, but would not count on it for current logging no matter how much thermal compensation I apply. At least that's how I feel now, with only preliminary tests done using this technique.

6) Thermistor heat monitoring that will throttle the controller down to limit the heating, rather than shutting down

Oh, a good one that I forgot to write in my list! I use a microchip TC1047A temp sensong chip for now, but might change for a potentialy cheaper thermistor for economics. The microchip sensor is easy to use in software, having a constant slope. And I got them free as samples I must admit...

7) Serial data out to plug into a Palm Pilot or PC, and a little serial LCD that will be located on the handle bars.

The serial port is really great as a debugging aid too. I use it to output Throttle, duty cycle, current, voltage and RPM to my PC through hyperterminal. When need be, you can output any variable temporarily also for debugging when you don't want to use the PIC and ICD in debug mode. I'll have to add your data streaming idea to my list, for sure though! (maybe as an option though since I wanted to make a basic controller with as low a cost as possible).

8 ) A 12V DC/DC converter and 5 V regulator combination to power the low power stuff

So far I am using a transistor/diode as first stage, with a 7805 for logic. I can't see myself using a switcher because of the cost, but might have to anyways at higher voltages.

9) Sensored operation to start with, and will add an optional Sensorless option later

Same here! Pedal first would be easy, else we need very good startup code, or again just use halls for startup if available...?

10) Completely @#$%@!@ing waterproof (sorry, I'm still a little bitter)

This would be doubly important for me, because of my very particular assembly. I am still wondering were to source nice cheap aluminum cases?

11) A connection to the front wheel speedometer pickup to implement a watchdog type function that will match the speed of the wheels (like antilock brakes) in the event of slippage on ice or a tumble off the bike (I've taken the spring out of my throttle, so it doesn't shut off on its own)

Sounds cool! I am actually thinking of eventualy making a dual motor controller that would do just this, but even in a more active way!

12) Voltage and current monitoring

Into some kind of flash or only out through serial coms?... I once thought that using cheap SD flashcards would be very neat for the sheer quantity of available logging memory! Read/wrtie libraries for this is pretty easy to find.

13) Serial data in to allow for tweeking of some nitty gritty parameters (throttle calibration, PWM changes, current limiting changes ...)

I currently use serials also for changing dead time and such during tests - it's great having bi-directionnal serials for debugging!

I've already purchased all the bits and pieces to implement most of the stuff above. My goal was to keep the price under the cost of a new Crystalyte 36V 20A Start immediate controller (~$125), and I actually managed to keep it just under $100, which I'm pretty happy about.

I guess my project would be around this amount right now, but in just a little higher quantity the costs could be lowered. Call me crazy, I've been toying with the idea of possibly setting up shop to make these if all tests go well. There are a couple guys here on ES who seemed interested in maybe being involved with something along these lines... I haven't forgoten you, guys, I'm just puttering along slowly and doing much testing and thinking! :wink:

Thanks for your great input, Smith, and good luck with your own build!
Pat

 

[smithinparis]

Patrick,
Thanks for the feedback...

Do some reading on the PIC18F2331-2431-4331-4431 micro, you might like these better because of the 6-8 pin power PWM output peripheral and faster ADC.

I'm actually limited by my programmer - I does a huge number of 16Fxxx's, but only a few 18Fxxxx's. They'll make do for now. I actually picture this thing in the end having a couple of dedicated PICs for different purposes to free up space and cycle times.

I'm using an Allegro hall sensor so far...

For the current sensing, I ordered the Allegro ACS756. I have to admit I don't have any experience with that IC, so I don't know all of it's limitations. I choose it however because of the current handling, and because it should interface really well to the PIC.

So far I am using a transistor/diode as first stage, with a 7805 for logic. I can't see myself using a switcher because of the cost, but might have to anyways at higher voltages.

Much like your "economical" temperature sensors, I managed to get some samples of DC/DC converters through Maxim - the MAX5035.

This would be doubly important for me, because of my very particular assembly. I am still wondering were to source nice cheap aluminum cases?

I'm still looking for some good ideas on this front - if anyone has a good, well priced (read cheap) source please chime in!

Into some kind of flash or only out through serial coms?... I once thought that using cheap SD flashcards would be very neat for the sheer quantity of available logging memory! Read/wrtie libraries for this is pretty easy to find.

It will be though the serial port. It will be way too slow to give really detailed measurements. I've thought about adding in some memory (like an SD card or a USB stick) but that will come later.

Anyway, it sounds like we've got pretty similar goals! Good luck with your build, and I will be posting my trials and tribulations shortly (probably after the mad Christmas rush is over!).

 

[fechter]

A wide input range switching voltage regulator would be nice.

There should be temperature inputs for both the controller and the motor. Either one should start reducing the current limit when they approach the cutoff temperature.

Some kind of dynamic timing advance would be good for high rpm motors (useless on direct drive hub motors).

Optical isolation between the power stage and the control logic. When FETs blow, let's not take out any more parts than necessary. Optical isolation would make it easy to adapt different power stages.

 

[Toorbough ULL-Zeveigh]

I'll see Miles's's's sinusoidal commutation & raise him space-vector modulation.
remember, you did axe 4 ideal.

if yer gonna go to the trouble of building something form scratch you may as well make it, well, not exactly state-of-the-art but at least with technology dating from this century.
http://www2.electronicproducts.com/...idal_commutation-article-JUNCOP1-JUN2002.aspx
http://www.elec.canterbury.ac.nz/research/powerelectronics/documents/AUPEC2001_DTC.pdf

 

[ZapPat]

A wide input range switching voltage regulator would be nice.

Cost is an issue here, but if there would be a low-cost, high frequency and fairly cheap switching solution then this would be better for sure. I'll have to compare the linear transistor drop loses vs the controller's power losses and circuit power requirements to see relatively how much this contributes to heat generation. Some quick math tells me that the linear regulator losses would be around 5W with an 80V battery, so maybe I should think more about a switcher?

There should be temperature inputs for both the controller and the motor. Either one should start reducing the current limit when they approach the cutoff temperature.

I had the FET temp sensor covered (forgot to note it), but yes a motor one would definetely be nice too, it's just not very widespread a practice to have temp sensors in your motor. I put one in mine the third or so time I took it apart, and I think link and docbass have ones too. Maybe just having it available might make it more common. It would make the system much more bulletproof for sure though... no more meltdowns causing shorted windings, dead FETs, and dead halls!
And linear cutback for sure for both sensors. I'm planning on using the FET's inherent resistance vs temperature dependance to help me do temperature rollback in the FETs.

Some kind of dynamic timing advance would be good for high rpm motors (useless on direct drive hub motors).

Timing advance... do you mean something like a commutation angle compensation to account for reletively slow hall sensors? For me, timing advance makes me think increased motor torque at high speeds, when back EMF gets close to batt voltage.

Optical isolation between the power stage and the control logic. When FETs blow, let's not take out any more parts than necessary. Optical isolation would make it easy to adapt different power stages.

I did this in my first two BLDC controller prototypes, but this time I'm relying on good layout to avoid problems and to avoid too many parts. Plus, don't you think the damage would stop at the FET driver anyways, and not go all the way to the micro? So far I've blown 2 phases worth of FETs during tests, once because the logic board disconnected from the power section while running, and another time because I was testing motor sequencing code in the micro, but was using my ecycle motor to do this...duh! Big current spikes insued and only one FET per phase leg to take it... Poof! Point was, nothing else blew either time, not even the drivers.

Thanks for your input, Richard!

 

[ZapPat]

No hall sensors. Even if it means making a new matching hub motor. Lose the hall sensors. The RC crowd has been running BLDC motors for years without hall sensors. I still can't figure out why we need hall sensors for e bikes with todays modern software/firmware technology.
Hall sensors seem to be the weak link in the power drive chain and quite the pain to replace.

Definetely will be done, but I want to implement some of the other more critical features first. And even with good startup techniques, halls are hard to beat for zero speed takeoff. Pedal-first would be easier, so I might start with this once I get into the sensorless part.

Programable low voltage cutoff

Already noted above and it is of course considered essential. The hardware is already there (simple ADC with divider). Both LCV and OVC will be easily changed via user-friendly software. Also see the interesting BMS function sharing idea that applies to LVC, OVC and current limiting. I wonder what it would take for the great BMS available here on ES to become compatible for use with such a controller?

120 volt max 50amps

I'm starting with a 75V FET model that will be able to operate at 67-69V max. As for current, I have started with a 6 FET model and have yet to see what I can push through it continously. So far It's pumped out up to 50A for a few of seconds without problem, but my load resistors and inductor started smelling like that familliar burnt electronics scent many of us have come to know so well... I have no real heat sink on my setup for now, only copper bars with it's massive heat absorbing capacity so I'm limited for now.
I will definitely plan to have a 100V+ flavor model latter on, and also a 12 FET model for the more adventurous ebikers among us!

Downloadable data via USB to track current

For now I'm going to stick with the USART (RS-232) to avoid having to add another chip and get into learning to use it. It would be good for a future version for sure, but for now almost all computers still have regular serial ports. Serials comms will be used both for the controller settings interface and for an eventual data display module (graphing, save to file, etc). The data logging interface is lower priority for now.

I think I'll have to edit my first post and add priorities for each feature.

Thanks for posting, microbatman!

 

[billvon]

No hall sensors.

Why not do both? If all three sensors are working, then it uses them. If one or two are working, it uses them as indexers and ignores the others. (Helps start from a dead stop.) If none are working, it becomes a sensorless controller. Justin did that in his controller.

 

[billvon]

I'm actually limited by my programmer - I does a huge number of 16Fxxx's, but only a few 18Fxxxx's.

The ICD2 supports pretty much everything Microchip makes and is pretty cheap (<$160.)

 

[billvon]

- Small (something like castle creations offerings)

If you make it small, put a flange on it so you can bolt it to the frame and dissipate more heat! Heat is the big problem with small.

- ABS-type reaction (to avoid possible lock-ups, specially when using large motors like X5's - Note that this may just be equivalent to seting a max regen current...)

Maybe do this like the Tidalforce did it. When you hit the brake, it ramps up regen slowly, over about a second. That lets you modulate regen by pumping the brakes, like a manual PWM. (Note that regen will never lock up a wheel, since if the wheel slows down the braking force is reduced as well.)

- High-voltage cutoff user warning, and/or automatic redirection of regen current to optional load resistor, or it might be possible to implement an engine break using the FETs.

By turning both halves of the bridge on? Yikes! Maybe a very simple power zener (i.e. zener+PNP) to do an emergency limit. You'd be limited by heat dissipated though.

- Selectable throttle control modes: Classic (PWM duty cycle) control mode, Current control mode

This would be very nice. PWM would allow you to (roughly) set speed with the throttle, current mode would set torque.

- Cycle analyst connection (maybe eventually integrate an LCD with CA functions right into the controller?)

Yes, you could just add an off the shelf LCD (like one of the Orbital Matrix serial LCD/button interfaces) and you'd have a remote monitor.

- Upgradable firmware (maybe by end user, but likely available only by sending the unit back to builder)

Just include whatever ICP connector your chosen uP uses, and you'll cover that base for most experimenters. (And make it easier to reprogram at the factory.)

- Reduced torque ripple (less of a cogging "square" feel, specially when accelerating hard at low speeds and while doing strong regen)

You can do this via flux vector control, but that's a LOT of math for a little uP to handle. You'd probably be looking at something in the dsPIC30F series.

- Sensorless operation eventually

Do both!

 

[smithinparis]

I'm actually limited by my programmer - I does a huge number of 16Fxxx's, but only a few 18Fxxxx's.

The ICD2 supports pretty much everything Microchip makes and is pretty cheap (<$160.)

When I was just getting into PIC programming years ago, I had searched for programmers and came up with the K150 which programs a very large number of PICs - over 100 types (including some of the 18F's) and it only cost between $50 and $60 (it was many years ago). For anyone interested in getting into programming micros for cheap, I'd really recommend it. But, you are right, not all are supported, so you do run into problems every now and again...

 

[wrobinson0413]

.

 

[ZapPat]

Hi Patrick,
Pulse charge regeneration?

Any documents or links about this? From a quick google search, seems like this is mostly just using pulses to charge the batteries, with maybe some small negative pulses thrown in too. I've heard of something similar before, but I haven't seen anything to prove what benefits doing this would bring. On top of this, a controller doing regen pulses the battery anyways, it's the nature of steping regulators.

Sine wave rather than block commutation?

I'll see Miles's's's sinusoidal commutation & raise him space-vector modulation.
remember, you did axe 4 ideal.

That's what my "Reduced torque ripple" was describing actually! And it's the space-vector variant that I would be using for sure, since I don't want to lose the 15% or so extra drive voltage which happens when going from regular trapezoidal commutation to regular sine PWM. Many funny words, but the principals are quite simple really. Of course the necessary math power needed to do this will force me to upgrade to a DSP in the future, something like a dsPIC most likely since I know PICs already.

BTW Toorbough ULL-Zeveigh, do you know of even more "state-of the art" techniques that would apply to an EV controller? I would like to know of them, if only for personnal education!


Thanks for the feedback, guys!

 

[Miles]

Hi Patrick,
Pulse charge regeneration?

Any documents or links about this? From a quick google search, seems like this is mostly just using pulses to charge the batteries, with maybe some small negative pulses thrown in too. I've heard of something similar before, but I haven't seen anything to prove what benefits doing this would bring. On top of this, a controller doing regen pulses the battery anyways, it's the nature of steping regulators.

Anything useful here: http://techno-fandom.org/~hobbit/cars/boost-hack/ ?

 

[Icewrench]

I like cruise control. Don`t know how to build it, but I like to use it.

 

[ZapPat]

Hi Patrick,
Pulse charge regeneration?

Any documents or links about this? From a quick google search, seems like this is mostly just using pulses to charge the batteries, with maybe some small negative pulses thrown in too. I've heard of something similar before, but I haven't seen anything to prove what benefits doing this would bring. On top of this, a controller doing regen pulses the battery anyways, it's the nature of steping regulators.

Anything useful here: http://techno-fandom.org/~hobbit/cars/boost-hack/ ?

It's a nice view into how and why regen works. Very good for regen newbies for sure!

 

[ZapPat]

If you make it small, put a flange on it so you can bolt it to the frame and dissipate more heat! Heat is the big problem with small.

To have a good contact surface between controller and frame I would need to have an aluminum tube to flat surface adapter. As for heat generation, I might have to go with a switcher circuit for the controller's own power source instead of a linear regulator. Also, I use fast FET switching speeds that lower my power switching losses. Conduction losses will then be the main heat generation source I'll have to deal with.

Maybe do this like the Tidalforce did it. When you hit the brake, it ramps up regen slowly, over about a second. That lets you modulate regen by pumping the brakes, like a manual PWM. (Note that regen will never lock up a wheel, since if the wheel slows down the braking force is reduced as well.)

Tidalforce regen control method noted - thanks Bill Von! And a note about the regen lock-up thing: There might be a lock-up effect when you are on snow/ice or dirt, but yes in general it's true that reduced back EMF at low speeds effectively prevents a complete lock-up. That being said, try turning by hand a large hub with all three leads shorted and note the huge resistance even at very low speeds!

- High-voltage cutoff user warning, and/or automatic redirection of regen current to optional load resistor, or it might be possible to implement an engine break using the FETs.

By turning both halves of the bridge on? Yikes! Maybe a very simple power zener (i.e. zener+PNP) to do an emergency limit. You'd be limited by heat dissipated though.

I haven't though about these solutions much yet, but considering that very strong regen is just equivalent to shorting the motor windings I figured this might be possible. I am well aware that destructive voltage spikes might be produced, and this might ultimatly make any such idea impossible to do. Tests to be done here...

Just include whatever ICP connector your chosen uP uses, and you'll cover that base for most experimenters. (And make it easier to reprogram at the factory.)

Will do, but it will likely be in the form of a simplified header to save space, to be used with a simple adapter dongle for those wishing to reprogram the MCU.

- Reduced torque ripple (less of a cogging "square" feel, specially when accelerating hard at low speeds and while doing strong regen)

You can do this via flux vector control, but that's a LOT of math for a little uP to handle. You'd probably be looking at something in the dsPIC30F series.

That's right, no choice but to go with a DSP when I get into this territory.

- Sensorless operation eventually

Do both!

I'll try to keep both options to combine each of their advantages.


Thanks Bill Von!

 

[fechter]

I'll see Miles's's's sinusoidal commutation & raise him space-vector modulation.

And don't forget synchronous rectification. Most of the 'cheap' controllers do not have this.

 

[perbear]

I agree that a DSP and syncronous rectifier is required for optimal regen, but I believe Miles is right in that you also need variable transmission.

Have a look at the FAQ for the Nohassel propulsion system. It looks very much like what you are describing as it is designed to solve the same:

http://groups.google.no/group/nohassel/web/nohassel-faq-frequently-asked-questions?hl=no

Kind regards,

Per

 

[ZapPat]

I'll see Miles's's's sinusoidal commutation & raise him space-vector modulation.

And don't forget synchronous rectification. Most of the 'cheap' controllers do not have this.

Don't worry Fechter, I've been using this technique on my half bridge test circuits from a couple years ago, and of course also on my last three-phase prototype too.

Has anyone ever looked at how the cheaper bike controllers implement their regen? If they don't use synchronous rectification they would be in for a big performance hit particularly during regen at low speeds. I guess the only way I'll know is to test my setup and compare with other's numbers here. Justin just gave us some very sweet practical info about regen, so this will help me!

The only hick with synchronous rectification is that in itself it doesn't permit freewheeling, so the controller either needs to disable outputs when freewheeling is desired and/or have it actively track current cycle-by-cycle to give a net zero current flow even if actively switching all the time. For now my phase current sensing method still needs perfecting, since my present allegro hall sensor on the battery bus is inadequate for this type of fast loop response.

 

[fechter]

The only hick with synchronous rectification is that in itself it doesn't permit freewheeling, so the controller either needs to disable outputs when freewheeling is desired and/or have it actively track current cycle-by-cycle to give a net zero current flow even if actively switching all the time. For now my phase current sensing method still needs perfecting, since my present allegro hall sensor on the battery bus is inadequate for this type of fast loop response.

The Allegro sensor should be fast enough.
On my old Zappy controller (which used synchronous switching and had regen), if I dialed the regen current limit down to zero, the motor would freewheel very nicely. In fact, it seemed to freewheel better than it did by disconnecting it from the controller. Only hitch is you need power to the controller to keep it freewheeling, but the current draw under this condition is very low. For emergencies, you can unplug the motor.

The loop response of my regen current limiter was heavily filtered but the change in load on a vehicle motor is very slow compared to a switching cycle. There may have been a tiny bit of overshoot, but it was not noticeable. If the space vector averages zero, some small variations won't bother it.

 

[ZapPat]

I'm happy you posted, Wayne!

One is to have a good intuitive GUI that allows you to easily configure your controller to be what you want and do what you want through a generic serial port. The second suggestion would be to have datalogging capability which can be accessed through your GUI. Having a view into what is happening in your controller makes for less frustration during debugging. Have many times have you heard "I think I blew my hall sensor, how can I check it?". That is something that can easily be checked through software by showing those states in a GUI. When I look at the Chinese controllers, I find that is one thing that is lacking on them. The only GUI that I have seen for the ebikes was for the infineon controller that Knuckles was selling, and that was very primitive. I haven't looked at what the Kelly controller GUI looks like. Just imagine the diagnostic capabilities that you could have if you structured your code correctly and had visibility into all the system parameters like throttle, current, voltage, temperature, brake, halls signals, etc.

Your suggestion that the GUI is so important has stimulated me into installing MS visual studio. I'll start to move my present one line hyperterminal display over to a better GUI, as I really think you're right that it will help with debugging quite a lot. Plus it'll give me a head start on the user configuration software that will go with the controller. As you say, a good user interface is one thing that is lacking in most all Chinese offerings.

As for datalogging I will do this, but later only. The prob is storage space mostly, which limits recorder resolution and recording time. I like the SD cards for sheer size, and maybe just soldering one onto the controller board would be simpler than adding a reading slot. I think I saw libraries for PICs that permit easy read/writes to SD cards. When it does happen, I'll add data viewing to the UI maybe using a tab or something like that. One tab for settings, another for diagnostics and another for logged data viewing. I'll be using VB for the UI, BTW.

I posed a similar question about what people would like to see in a controller back when I joined this forum, and the tweakability factor was high on people's list, along with reverse voltage protection and short circuit protection. It is too bad that the cost associated with the last two items is high.

Isn't reverse voltage protection just a series diode?... a big and inefficient one though, I agree. humm... 0.3V * 40A = 12W of dissipation... kinda terrible, and makes my idea of a heat sink about twice as big. Else use extra FETs instead to reduce conduction losses - expensive once again! I guess you're right after all.
As for short circuit protection, you mean just for shorted phases, right? I guess real fast current sensing would be needed when there's no motor inductance and resistance to slow the current increase rate. I guess one day I'll have to test this out to see what would be needed in terms of reaction speed of the current limiting loop.
As for tweakability, I'm a bit undecided here since I would kinda like to make a living doing this kind of thing someday, but also really like the idea of open source too. I'm thinking for the moment that I could provide (or user could make) the ICD dongle for reprogramming the PIC and use the hardware the way they want. I would also provide basic functional starting code (uncompiled) with lots of comments to build on for power users. This would also mean though that they would abandon the factory-provided code when they choose to go with their own code, and of course this would also void warranty because of the possibility of code-related destruction of the FETs. Humm...

One other thing is the waterproofing. I think that will pose more of challenge for your design if you also try to keep it so that the controller is tweakable. I know that you can get soft potting that will make your controller more or less waterproof, yet still allow you to peel it off to tweak.

Sounds like neat stuff that peelable goo, but I actually haven't thought much about waterproofing yet. One thing is for sure, I'm aiming to be able to change FETs easily in the final assembly. Is relying on the case and it's gaskets to be waterproof such a bad idea?


Your BMS build looks pretty neat, BTW. I have been thinking about the integration of BMS functions into the controller. This would eliminate the BMS's power FETs and more importantly give much needed complete battery regen protection (cell level OVP namely). Regular charging could be routed through one of the bottom side FETs since this is where I am doing current sensing already (charger positive would be connected to the battery positive). I'll have to think this through more sometime to see if there are obvious problems with this idea?

I appreciate your input!
Pat