• Howdy! we're looking for donations to finish custom knowledgebase software for this forum. Please see our Funding drive thread

I want your opinions: Brushless controller features

ZapPat said:
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 said:
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.
Was your zappy a brushed controller by any chance?

fechter said:
The Allegro sensor should be fast enough.
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.
I know didn't specify it here, but with the SVM method I plan to use, the current loop needs to be very fast for the controller to be able to follow the phase wire's current draw during each PWM cycle. This permits the controller to output a current-controlled waveforms that match the ones produced by the motor, thus the reduced torque ripple. In other words, no more just setting a fixed duty cycle to be used during the whole commutation time and to be updated only once per commutation. So the control loop frequency is now the PWM frequency instead of the commutation frequency... a big difference!
 
ZapPat said:
fechter said:
Toorbough ULL-Zeveigh said:
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.

Can you guys help me out here? I think I might be missing something ... In 2005 IR came out with a new line of HEXFETs with integrated body diodes to which was meant to reduce part counts on controller boards. The HEXFETs were designed specifically for synchronous rectification. Included in this lineup are the 4110, and 4310. Since most designs seem to be incorporating the 4110, does the synchronous rectification discussion become a moot point (of course still worth noting).
Is there something I'm not getting?
 
smithinparis said:
Can you guys help me out here? I think I might be missing something ... In 2005 IR came out with a new line of HEXFETs with integrated body diodes to which was meant to reduce part counts on controller boards. The HEXFETs were designed specifically for synchronous rectification. Included in this lineup are the 4110, and 4310. Since most designs seem to be incorporating the 4110, does the synchronous rectification discussion become a moot point (of course still worth noting).
Is there something I'm not getting?
All FETs have internal body diodes... but just not very good ones in general. IR's improved HEXFETs just have better internal diodes, having less recovery charge and thus faster possible switching times (meaning less switching losses). The reduced parts counts argument stems from the fact that extra seperate diodes in designs are not so important as the FET's own diodes get better.

As for the usefullness of synchronous rectification, just compare the power dissipation of the FET's diode conducting 50A or so of current, vs that same FET conducting that same 50A. You get about 1V drop for the diode alone, vs about 0.25V when the FET is conducting. So with synchronous rectification you save 75% of the dissipation linked to diode conduction time. With lower Rds FETs or paralleled devices, this bonus gets even better.
 
ZapPat said:
smithinparis said:
Can you guys help me out here? I think I might be missing something ... In 2005 IR came out with a new line of HEXFETs with integrated body diodes to which was meant to reduce part counts on controller boards. The HEXFETs were designed specifically for synchronous rectification. Included in this lineup are the 4110, and 4310. Since most designs seem to be incorporating the 4110, does the synchronous rectification discussion become a moot point (of course still worth noting).
Is there something I'm not getting?
All FETs have internal body diodes... but just not very good ones in general. IR's improved HEXFETs just have better internal diodes, having less recovery charge and thus faster possible switching times (meaning less switching losses). The reduced parts counts argument stems from the fact that extra seperate diodes in designs are not so important as the FET's own diodes get better.

As for the usefullness of synchronous rectification, just compare the power dissipation of the FET's diode conducting 50A or so of current, vs that same FET conducting that same 50A. You get about 1V drop for the diode alone, vs about 0.25V when the FET is conducting. So with synchronous rectification you save 75% of the dissipation linked to diode conduction time. With lower Rds FETs or paralleled devices, this bonus gets even better.

Thanks for that. It turns out I just wasn't clear on what synchronous rectification was ... or basically that it distinguishes between active and passive freewheeling. Anyone looking for a primer on synchronous rectification, take a look at this great overview:

http://www.infineon.com/cms/en/product/search.html?q=AP08078
 
ZapPat said:
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. :eek:
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.

Another reverse voltage protection system is to use a fuse inline with the battery input and a "crowbar" diode that will blow the fuse if polarity is reversed. (the drive FET body diodes may be sufficient for this). A similar system uses a normally open relay bridged by a "large" resistor. The coil of the relay is then driven off of the controller's power buss. Normally the resistor precharges the controller's capacitors and trips the input relay once the power buss gets to a high enough voltage. When voltage is reversed the drive FETs bypass all the resistor's current and the power buss never gets to a voltage high enough to trip the relay.

Marty
 
lawsonuw said:
Another reverse voltage protection system is to use a fuse inline with the battery input and a "crowbar" diode that will blow the fuse if polarity is reversed. (the drive FET body diodes may be sufficient for this). A similar system uses a normally open relay bridged by a "large" resistor. The coil of the relay is then driven off of the controller's power buss. Normally the resistor precharges the controller's capacitors and trips the input relay once the power buss gets to a high enough voltage. When voltage is reversed the drive FETs bypass all the resistor's current and the power buss never gets to a voltage high enough to trip the relay.
Marty
The simple fuse idea sounds good, but I wonder if smallish, cheap 50A - 100A fuses exist to integrate inside the controller housing? The contactor + pre-charge resistor idea might be good for a larger EV, but I wouldn't want one on my bike. Unless maybe I could find a small, high power , cheap relay - which I doubt would be cheaper than extra upside down FETs and assotiated gate drive components. So unless I can source small, cheap and high powered fuses, Wayne is probably right about the cost issue for reverse voltage protection.
 
perbear said:
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
Hi Per, and thanks for the interesting link. I would of course agree with you about variable speed transmission being one possible solution for making regen more efficient. But I also like keeping things physically simple, and the Nohassel setup seems a tad complex (although very interesting nonetheless). I like direct drive hub motors for their simplicity and efficiency, but realise that they lack the advantages that gears have to offer. What I plan on doing is to obtain a 4 gear like setup without using actual mecanical gears.

It 's pretty simple actually, except that it needs a controller with the firmware and two outputs to work. I want to use relays to switch the battery pack between series and parallel, giving two ratios. Then use relays in the motor to shift the motor between Wye and Delta configurations, giving two other ratios. So combined you get 4 speed ratios, and the controller would have to "shift" these two outputs as to always be in the highest efficiency ratio at all times (one of four). I realise this would require a bit of work to make the firmware react in the right way while shifting, but I do like a challenge so will try it for sure! Doing this will help quite a lot for better regen efficiency at lower speeds too.

I think Docbass is doing this manually already, but I haven't heard a report about it yet.

Thanks for posting!
Pat
 
wrobinson0413 said:
For short circuit, I was thinking of the protection for all cases not just phase to phase. After thinking about it, I think that phase to phase is the minimum that you would need since most problems occur with phase wires shorting during spin outs. The other two areas where you could have potential failures are phase to rail shorts, but since the bus power is on a separate set of connectors, there is very little possibility of those cases occuring during run time. If someone wires up the battery input to a phase input accidentally, your startup diagnostics should see that condition and not enable the bridge.
If they put the battery input on one of the phase wires, then the controller will detect an under-voltage condition and not activate the FETs. As for the phase-to phase protection, I am already using phase current sense, so all that is needed is a very fast response time. I am not quite sure how fast this reaction time would need to be. Anyways, the main positive fuse would blow in such an event and provide backup protection if the current limit doesn't kick in.


Reverse voltage protection is done using mosfets on the negative return to the battery. A diode is not practical because the power dissipation is too high for large battery currents. If you wanted to make a bullet proof design, you would want out of saturation detectors on each mosfet bank as well as the reverse voltage protection. Too bad the IR2125 is so much money.
What would pull the FETs out of saturation?

As for the reverse battery protection, a fuse would be enough to provide simple protection, don't you think?


Waterproofing is a very tricky problem. No case will remain waterproof indefinitely when you need to have connector openings or cabling exits. Soft potting is one of the more secure ways of doing it. When I mean soft, it is like cured silicone but easier to remove. If the box is not hermetically sealed, then you will have condensation forming inside over time, which will eventually lead to a failure.
Any links or names of easily available good soft potting stuff? This will be a very important aspect for me, specially because of the particular FET mounting I have.


Datalogging is not as difficult as you might think. The idea is to have a sample window allocated in ram that you fill on a trigger, then blast the data back to your GUI. National instruments has very nice sope tools that allow you to display your data in a nice format. The only issue with that method is that you need to have a laptop connected during your testing phase. For longer time period datalogging of slow signals, you could add a large serial EEPROM to store items like RPM, voltage, current, etc, locally.
I don't see the first type of datalogging you describe (using the PC user interface) as complex as the long-term storage solution using EEPROM or SD cards. I've never used external EEPROMs before, but I'll have to learn. And if I find that the SD card solution would be easy enough to use, imagine how much we could log with 1 gig of flash?


Some of the BMS features are nice to add to your controller, but they add cost. The basic stuff that is free like LVC and OVC shutdown limits is easy to add to your diagnostics. The rest of the BMS functionality is more difficult to add in a cost effective way. One key functionality of a BMS for LiFePO4 would be the individual cell LVC shutdown command. If you had that local to the battery, then the rest of the run-time functionality could be incorporated in your controller. I think all you would need is a reliable measurement of the battery current to complete the protection of the battery. You would still need a ballancing method for charging your battery pack. If you were using SLA, then all the battery management could live on your controller.
What I meant when I was talking about linking the BMS to the controller, was more like just taking an existing BMS design like the one made by the guys here on ES, and just mod it's assembly to suit the special controller. The simplist thing to do, and most important is just sending the BMS's cell-level Over Voltage Cutoff signal to the controller. This combined with the controller's current limiting behavior would make regen always a safe experience for the battery. If the Under Voltage Cutoff signal would also be routed to the controller, then the BMS's discharge cutoff FETs become useless, and could be possibly removed to reduce system cost and losses.


Have you started to tally up your cost on the material for your controller yet? I imagine that you may get a bit of a surprise when you finish your tally. I have gone through a small costing exercise myself, and I wondered at just how much money the chinese actually make per unit on their higher end controllers.
I have checked individual prices out quite a bit when comparing different possible parts to be used, but I've only counted up the whole total as an estimate. As for the cheap chinese offerings issue, I guess I'm hoping to start off by offering something quite different, mostly for the higher-end savvy ebikers such as we find here on ES. I am hoping also to do a bit like Justin does with his Cycle Analist and build the controller here in North America, altough I know that avoiding using cheap labour makes costs go up. Anyways, there are still too many unknowns for me to have a good idea of total costs just yet. To name them: PCB costs, assembly costs, case, connectors, waterproofing and finishing. I'm thinking something like a bit under 100$/unit probably in low quantities, and I hope less with higher volume and more optimized assembly methods later on.

Thanks again for your thoughts, Wayne!
Pat
 
ZapPat said:
It 's pretty simple actually, except that it needs a controller with the firmware and two outputs to work. I want to use relays to switch the battery pack between series and parallel, giving two ratios. Then use relays in the motor to shift the motor between Wye and Delta configurations, giving two other ratios. So combined you get 4 speed ratios, and the controller would have to "shift" these two outputs as to always be in the highest efficiency ratio at all times (one of four). I realise this would require a bit of work to make the firmware react in the right way while shifting, but I do like a challenge so will try it for sure! Doing this will help quite a lot for better regen efficiency at lower speeds too.

I think Docbass is doing this manually already, but I haven't heard a report about it yet.

Thanks for posting!
Pat

Coil switching solutions required complex wiring and many high current switches. Similar principles has been used with success on old tram/streetcars having the same challenges as e-bikes with regards to torque vs speed. I suspect that efficiency is not very good since the motor can not be optimized for a certain RPM band. On a tram efficiency is not important since it runs on "wire" and not a battery.

Using the ESC for such switching will of course save some of the additional cost, but you would probably have to add a lot of relays or double the number of transistors? Anyway, I wish you good luck with this effort, if it works well, it might be a better solution than using two motors as in the Nohassel. That certainly requires twice as many transistors as a regular ESC!

Also for those who is not convinced that regen is important: Sanyo has just released a new family of hybrid e-bikes: http://www.eneloop.info/fileadmin/EDITORS/Portal/PRESS_RELEASES/1201_SANYO_eneloop_bikeNR.pdf

While mentioning Sanyo, they are probably owned by Panasonic any time now:
http://www.bike-eu.com/news/3187/acquisition-leads-to-mega-e-bike-component-maker.html

Perbear
 
lawsonuw said:
I've seen older RC controllers use "solder drop" fuses. Where a drop of solder was used to bridge two posts, and acted as a fuse. Not particularly precise, but simple. A properly sized jumper could also be used as a fuse.
My two bits,
Marty
"anything can be a fuse"
I will definitely look into this type of protection, but likely as a last resort protection method. From what Wayne says (wrobinson), fuses are slow reacting devices, and that FETs will likely blow before a fuse does. Something else to read up on... or maybe just doing some potentially destructive testing will give me an idea of how fast fuses are!

Thanks for the advice Marty!
 
perbear said:
ZapPat said:
It 's pretty simple actually, except that it needs a controller with the firmware and two outputs to work. I want to use relays to switch the battery pack between series and parallel, giving two ratios. Then use relays in the motor to shift the motor between Wye and Delta configurations, giving two other ratios. So combined you get 4 speed ratios, and the controller would have to "shift" these two outputs as to always be in the highest efficiency ratio at all times (one of four). I realise this would require a bit of work to make the firmware react in the right way while shifting, but I do like a challenge so will try it for sure! Doing this will help quite a lot for better regen efficiency at lower speeds too.

I think Docbass is doing this manually already, but I haven't heard a report about it yet.

Thanks for posting!
Pat

Coil switching solutions required complex wiring and many high current switches. Similar principles has been used with success on old tram/streetcars having the same challenges as e-bikes with regards to torque vs speed. I suspect that efficiency is not very good since the motor can not be optimized for a certain RPM band. On a tram efficiency is not important since it runs on "wire" and not a battery.

Using the ESC for such switching will of course save some of the additional cost, but you would probably have to add a lot of relays or double the number of transistors? Anyway, I wish you good luck with this effort, if it works well, it might be a better solution than using two motors as in the Nohassel. That certainly requires twice as many transistors as a regular ESC!

Also for those who is not convinced that regen is important: Sanyo has just released a new family of hybrid e-bikes: http://www.eneloop.info/fileadmin/EDITORS/Portal/PRESS_RELEASES/1201_SANYO_eneloop_bikeNR.pdf

While mentioning Sanyo, they are probably owned by Panasonic any time now:
http://www.bike-eu.com/news/3187/acquisition-leads-to-mega-e-bike-component-maker.html

Perbear
Docbass already has a series/parallel contactor on his bike's battery pack, and he is about to get a custom delta/wye motor from Xtalite. Both options use three relays (if using SPDT for the motor, and SPST for the battery pack), but of course multi-contact relays could also be used to cut down parts count. Not really anything complex, exept for the controller's programming if the "shifting" is to be controlled automatically by it. With some optimizing and experimenting, the "shifting" should be able to be done in an almost transparent way to the user (Docbass in this case!).

So I guess we should know by next summer how usefull such a setup is, and if it is a cool feature then I might think about replacing [some of?] those mecanical relays with semiconductors. Hey, it might not be worth it, but I do love trying things out! I would love to have someone do the math to compare this electrical shifting solution to a four speed macanical gear solution?...

So I now have one beta controller tester on my list (I'm writing you a PM, Doc)... I hope to get a couple other experienced ebike users to add to this list when the first small test run of units happens.
 
wrobinson0413 said:
Hi Pat
Here is the datasheet of the potting material that I mentioned earlier. The stuff we are using is Dow Corning Sylgard 170 A&B which is a dark gray, and is very flexible and easy to remove if you need to repair your board.
Wayne
Cool! Thanks for that info, Wayne. I'll check out that datasheet soon. Do you have any idea how well it ages?
 
- User-configurable via simple computer interface window (Max current, LVC, HVC, + all other optional parameters)

better yet have the user programmability done by a usb flash drive so mac users can get in on the game by saving a text file to a fat 32 formatted usb stick and plug it into the controller.

or even better have web interface like a router has so connect the controller to any computer mac,pc will not matter then connect to an ip like 192.168.1.x.

or make a wireless connection using bluetooth or wifi so it can even be done from web able phones like the apple iphone and make the signal very weak so it only has a range of a few inches (so no security issues regarding hackers).


- Regen on demand (with some automatic current adjustment done by the controller to optimize efficiency)
- Adjustable max regen current (*)

have the regen come on slowly maybe from 0 to full over a second time so there is not the sudden torque issues that supposedly can shatter or snap axels on the phoenix brute

and if you are also designing a hub motor too you may want to think about using genuine american steel for the axel and the motor core that the axel goes through (not cheap chinese steel) so the axel will not get broken by the torque.

- Adjustable LVC (*)

so that it can be used with all battery types including nicd and nimh ( so the cheap tool packs can be used.


- Adjustable speed limit (for legal purposes, or safety for some)

nice feature but i never heard of anyone getting a speeding ticket on a bike (maybe in a residential zone like a trailer park or if a playground is split by a road or alley where there is a 5 or 10 speed limit also i am not sure if a bike has a large enough profile to be picked up by radar anyways.


- Diagnostic LED(s) and/or use PC interface software for problem solving and error reporting

have the led(s) externally viewable unlike the crystalyte controllers where you have to open up the controller to see the indicator.

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

have the user be able to upgrade the firmware because not all manufacturers stay in business for ever or products are forced discontinued by c&d notices over copyright/patents or trademarks.

if the reason for having the maker do the upgrade is because of warranty issues or the potential of botching up the upgrade and paperweighting the unit then http://images.google.com/images?um=1&hl=en&q=sandisk+card&btnG=Search+Images should solve that problem make it have a flash card slot where the firmware lives on a fat 32 formatted camera flash card that can be connected to any computer and the firmware file is copied to the card and the card is then put in the controller.

thereby the only way to botch up a firmware update is to disconnect,corrupt or crash the computer during a copy.

if the reason for having the maker do the upgrade is because of copyrights then open source the firmware or even release under the creative commons .




selectable sensor/sensorless modes so user can select because under demanding loads like going up a hill or pulling a trailer (somewhere i read that rc controllers would work but would have very weak acceleration so sensorless may be only good for cruising).
 
fechter said:
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.


another way would be magnetic isolation (if you ever have taken apart a tv or computer monitor there is a small audio transformer between the horizontal driver and the horizontal output transistor.
 
Re: sealing the controller
Here is alternative to sealing controller with sticky mess. Simply provide for a 2nd box cover, like wires exiting a box through baffles. Then if needed to disassemble or repair, easy and clean. No airtight controller means ventilation and no splash via baffle, or 2nd cover to prevent water intrusion due to normal use conditions.
 
Hello. Interesting thread you have here.

I'm also thinking of building my own BLDC controller (150A, 60V maybe) one day and here is one of my thoughts:
These motor drive/regen controllers use PWM (better ones - SVM) for voltage leveling that is running at ~10kHz (just a wild guess, don't know exact frequency). Correct me if I'm wrong, but BLDC motor core is made of isolated electrotechnic steel plates, that are about 0.25mm in thickness. This is a type of plates that is used in low frequency (50/60Hz) transformers. Problem here is that high frequency pulses induct parasitic currents in these plates and a part of energy is wasted to heat.
I'm considering possibility to mount powerful LC filters for pulse filtering. Caps would be connected with motor's unused center of windings (in "star" interconnection types) or they could be unused at all. Inductors should be made of thick wire wound around ferrite core.
I currently own Cyclone 500W kit and now Crystalyte 5403 is already on the way. So I do not have a motor and controller to do some experimenting. My guess, if it would improve performance, it should be noticeable by measuring current at full speed with no load.

Any thoughts on that?
 
Is this project still going? I am VERY interested in this as well. I hope there is still some interest. I think I may give it a try as well, but I am thinking about using an AVR chip instead... I have some experience with the PICs but the AVRs just give you more MIPS and then some. Any thoughts on using AVRs?

Also on the point of speed sensing for using 2 wheel drive: I don't think you might need a bunch more datapoints for the hall affect aka: an ABS ring in order to get an accurate enough speed in order to change the speed. I love the idea of this for snow riding to insure both wheels are moving simultaneously reminiscent of ROKON http://www.rokon.com/ :-D

Alot of great ideas and apparently some pretty good EEs:-D
 
wrobinson0413 said:
Just thought I would bump this to see if you have made any progress yet Pat

Well progress is slower than I would like, Wayne, but it's at least still moving along. It's funny that you posted yesterday, since I was also wondering yesterday what you were up to these days, and how your own controller project was doing?

I have been neglecting this thread I must admit - There are soooo many things I have to think about already, so I figured I would get my latest PCB revision finished up before doing an update here and answering posts. It turns out that there are many challenges to bringing an ebike controller to market, and I'm not just talking technical challenges! Just juggling time around with my limited ressources is a headache, since I cannot even think of hiring or contracting out certain tasks yet. I have tried to get some financial assitance from different governemental entities, but it seems like I am in a business situation where NO goverment programs apply. Being a new start-up AND working in a technical R&D field are not well looked at it seems. You either have to be selling something already and they will give you extra money for R&D, or come up with some conventionnal non-innovative business proposal and you can also get assitance for starting up. It gets me a quite peeved sometimes when I see so many brainless and almost pointless projects around here get HUGE subsidies, and I've done math on a few of these and I can assure you they often make no economic sense whatsover! Also, having no track record also makes any helpfull associations with other existing companies/individuals difficult. To make things worse, I live in a "techinicaly challenged" area, where the only projects that are encouraged are tourism, wood loging, fishing, agriculture and gigantic wind turbine farms. So locally there are practically no companies that could be potential associates as they don't understand what I'm working on. So I'll have to be very patient it seems, and spend much more of my own time doing the non-technical things I would rather have someone else do to help make this creation eventually ready for production. Well, that's enough non-tech talk, but I had to spout some of my frustration about this boring yet important aspect of this project! :?

I am really looking forward to trying my design out on the road, since so far I've only had it running in my lab. My last PCB design had a couple errors to fix and a number of things to change, so when the new revision is done I'll be able to finalise my firmware and go for a run at ~50V and ~100A... hopefully in a month or two max. I now have some great LiPos for high powered testing, and will have two NC hubs (front+back) to play with, so my bike will be ready for some kick-ass testing when the time comes. I'll post my initial controller feature set in before I hit the road with it, but only after I've sent my last PCB off for etching. I'll answer all the old posts here I've been neglecting... sorry guys! I haven't managed to clone myself yet... :)

Ciao!
Pat
 
Back
Top