View Single Post
Old 04-06-2011, 07:05 PM   #4605 (permalink)
DJBecker
EcoModding Apprentice
 
Join Date: Nov 2010
Location: Annapolis
Posts: 159
Thanks: 0
Thanked 32 Times in 27 Posts
Quote:
Originally Posted by jackbauer View Post
So by way of safety the controller should also monitor battery current? And see that they maintain an expected relationship.
Yes. That would avoid this specific type of failure from becoming worse and allow detecting a few more fault types.

An interesting question is the benefit if you are using IGBTs with driver modules. (You are using them instead of MOSFETs, right?) The modules can shutdown on some types of short circuit faults (desaturation "desat" protection). It may be that instead of removing the need for battery current monitoring, it makes it more important. Instead of immediately burning out the "push" side devices, it allows them to keep pushing power into the shorted diodes. Something will eventually melt, and it may not be something safe.

An issue with adding this to the AVR-based Cougar controller design is the A/D converter. Not only is the current chip out of input pins, but the A/D converter is pretty slow. It's already only sampling the motor current every 4th cycle.

That could be addressed by running the A/D converter at a faster clock. The next step up is doubling the converter clock. That would put it only slightly over the rating to get full accuracy. So the LSB would be a little noisier. But given that the controller already has a high level of electrical and magnetic noise, I doubt that it would be significant.

Control theory tells us that doubling the sample rate allows us to accept about double the noise for the same results. (A zillion caveats omitted, the most important of which is a non-correlated noise distribution.) Since we aren't going to be doubling the noise, we should end up with better control plus more available conversions for the battery current monitoring.

But this might not actually work for us. I don't believe that a 16MHz AVR has enough compute cycles to run the existing feedback loop twice as often. I'm sure it could be done, but it would require some really careful code tuning and worst-case analysis.
  Reply With Quote