Another Engine Control and Regulator project - DC Alternator

[mike90045]

I'll vote for a 48V capable version.

[thomasonw]

I have been spending some time over the past few days trying to come up with a design that will work not only supporting a 48v alternator (and potential 48v field), but ALSO support a full 48v system.  And by 'system' I mean:

• 48v Starter
• 48v Fuel Pump
• 48v Glow Plug
• 48v Throttle Controller Motor.

It is the H-Bridge for the Throttle Controller Motor I have having difficulty solving.  To date all the integrated H-bridges I can find are limed to 35v or so max with the step into industrial controlling (which will support 60-70v+) being just too much.   A pieces-part H-bridge driver is a possibility, though am starting to run into extra costs associated with all the components and that many of the 'driver' chips will not work outside a duty cycle of 10-90%, unless one adds even more parts.  And adding in a break function just makes this worst.

So, before I go on much more I really need input from folks who have  a 48v (or 36v  ) DC Generator:   Is your starter 48v?  Would you use a 48v throttle control unit?  Is the Glow Plug 48v?    OR - is it more likely that the alternator/Field is 48v, but the rest of the 'system' is 12v (or maybe 24v).

As I have not found a readily identifiable solution for a true 48v system I really want to ask:  Is this truly a need?

And again - to be clear - this is NOT talking about the alternator / field.  48v there is done.   This is talking about 'the rest of the story'.


And on other news:  The other day I conformal coated my board.  Next week will install / wire it in a neat way back near the generator.  The Firmware is working well enough at this point that I am ready to start giving it 'real life' field runs over the summer.

-al-

[BruceM]

Yep, a discrete H-bridge is a pain because of the delay logic and "glue" (resistors, capacitors) to prevent "shoot through". (Brief shorting during switching.)

I think it's more practical to require all these accessories be 12V. 

Great project, I hope the sea trials will be fun and uneventful!

Best Wishes,
Bruce

[mike90045]

There are FEW 48v accessory components.

There are soon going to be a lot of 24V & 36V gear, as auto makers start abandoning the 12V standard much as 6V fell long ago.

[thomasonw]

All,

This morning I posted a revised copy of the controller design:  http://smartdcgenerator.blogspot.com/2013/02/version-021-schematics-posted.html

This is intended to easy assemble (ala, using through hole diodes instead of the SMT ones, and allowing for optional daughter cards on the INA-220's), support a wider range of alternator Fields (High or Low drive, 12v to 48v) and simplicity configuration for 48v battery support by providing dedicated PCB stuffing options as opposed to the current "Replace Cx with a new resister, and run a jumper wire from xx to yy" approach :-)





A summary:

• 12-48v High or Low field drive options
• Added off-board protection to OneWire bus
• Added RC time-delay to crowbar, to reduce false triggering from noisy raw battery voltage.
• Added NTC sensor for the field FETs - though expect only 2-3w worst case power displacement through them.
• Added capability to install a local buzzer - Am woried about remote or auto starting in case one is around the machine at the time
• Hardware support for RTC - to allow to times starting, and/or quite periods for auto-starting (Firmware not modified yet)
• Corrected PCB issues:  Physical interference of one resistor, added selected thermal-reliefs to enhance solderability, added in daughter board option for INA-220's

A couple of specific points that have been talked about here (BTW, thank you all so much for the input!)

FET Drivers for High Drive:  Aside from the 12v deployment, which uses an integrated drive ship, I moved to a NPN/pull up resistor driver.  My reason for this was mainly around Vdd max of the direct driver chips, which limited them 24v and under deployments (and even then would need some help around Vgs max of the FETs- thank you SPSinc).  There are a wide range of 'boot strap' driver chips which would have been nice - and allowed use of N-FETs, however they all depend on a non-zero PWM duty cycle or the addition of extra components.  Other approaches (e.g. optic coupling, transformers, etc) seemed to each have their own limitations / issues.  After looking at what was needed to deploy a modified boot-strap design I stepped back a bit - the PWM frequency being used is only 490hz, and though there is switching loss using a NPN/pull-up I calculated it at being 2-3w worst case.  Given the low cost of the NPN/pull-up, the ability to fully support duty cycles from 0 to100%, and the resulting low heat being generated, I settled on this.   But please - is my thinking reasonable, or am I missing something big.....

System voltage above 24v.  Here again I have been looking at how to address this.  Bottom line is:  the Throttle motor H-bridge selected (which is design and marketed into the Auto industry for throttle motor controlling) will not support Vdds above 40v - limiting to 24v systems.  I was unable to locate an integrated H-bridge which would support higher voltages, and a discreet approach again started to run into high parts count / costs, and reduced functionality.  Though it may change in the future, today I believe that most all starters, fuel pumps, and even throttle control motors are actually 12v - perhaps some 24v.  When (if?) the auto industry moves to 48v deployment, and things like starters, throttle motors, etc, become common in 48v I am sure there will be an integrated 48v capable throttle motor control chip - and I would say at that time the design can be revised.  But until then, 24v is the system cap.  (and do remember, this is independent of the alternator.  The design fully supports 48v alternator, even in a 12v 'system').

OK, comments please.  I am in no rush to completing this v0.2.x series of revisions, as there is little to no functional difference between the 0.1.x boards I now have built. (I am a 12v across the board deployment).   As such I am thinking this design will be 'revisable' into the summer.   But if someone needs support for field voltages other then 12v HIGH-drive I can move forward quicker.

Again, thank you to all who have given prior comments and reviews.  This project would not have happened without that.

The .pdf files are located here:

  Controller: https://docs.google.com/file/d/0B5GiaoeXCQ3vMlBGU3Y4NkExQ28/edit?usp=sharing
  Remote: https://docs.google.com/file/d/0B5GiaoeXCQ3vcG81clVPLTF5cjA/edit?usp=sharing
 
And this documents the configuration / stuffing options:
        https://docs.google.com/file/d/0B5GiaoeXCQ3vUTV3UUwzZllLVUE/edit?usp=sharing



And the link at the top of this posting has more details, including a cool 3D image!  (So easy to impress this light-box / Mylar & Tape guy).


And on a status update:  The last week has been spent with the Flu...  Now that that is over, I am going to work on doing a neat install of the controller on our existing Kubota DC generator, route the CAT-5 cable forward (perhaps the biggest challenge) and mount the remote.  Due to some extra travel needs this year we have delayed our winter port departure, now looks like sometime in mid to end of March.  At that time will start 'real world' trials!

-al-

[thomasonw]

This morning I posted v0.2.2 of the Controller and the Remote.    Schematics, PCB PDFs and Gbr files.  A couple of us are working towards doing a PCB fab soon - driven largely by assembly improvements in the v0.2.x design (Using through hole Diodes, and option for INA-220 daughter cards).

Note also that the Remote board has been changed to use another Amtel CPU instead of a 3rd party backpack.  This will not only reduce costs a little, but allows for a much neater physical assemble.  Plus it does not lock one into a single source for the LCD.

Schematics should be here: https://docs.google.com/folder/d/0B5GiaoeXCQ3vdm5ydEJFR0dzVkE/edit?pli=1

And the PCBs layouts here:  https://docs.google.com/folder/d/0B5GiaoeXCQ3vb2FJQm05Qy1jeWs/edit



Looking to go to FAB in a week or so, if anyone is either interested in one of these boards, or has a chance to look things over, speak up!

[thomasonw]

Files for schematic, PCB layout, Config options, and BOM are posted in files section of blog.

http://smartdcgenerator.blogspot.com/


-al-

[thomasonw]

Am getting closer to having this installed and ready to use.  Here is a mock-up of the 'Control Panel' am looking to get built:




I use a company called Front Panel Express (www.frontpanelexpress.com/) to make up small panels like this.  They have a downloadable CAD tool that is simple to use.  Then just upload it and a week or so later you get your panel! Can even print out a sample in 1-1 scale (that is what you see above).   So Nice.

The only down side is their prices have gone up a LOT over the past few years.  This panel comes in at around $90 - - -  But I already have several others of like look, so need to keep the trend going.

[BruceM]

Wow, those are nice front panels.  Is you panel black anodized aluminum with white or no infill?  Are the powder coated or acrylic panels any cheaper?
I'm very impressed with your work!

Best Wishes,
Bruce

[thomasonw]

Wow, those are nice front panels.  Is you panel black anodized aluminum with white or no infill?  Are the powder coated or acrylic panels any cheaper?
I'm very impressed with your work!

Best Wishes,
Bruce

Thanks.  The panels I get are black anodized aluminum with white infill.  I have used a mixture of White and Red with other panels for 'backup' selections (like 'Air' in Whilte, and 'Backup Air' in Red for the two air horn air compresses)

The company offers a wide range of finishing options, anodized, power coated, blank.  All your choice.  Plus a range of panel materials and thicknesses.  It really is a slick operation.

-al-

[thomasonw]

Well,  been busy with many thing over the past few weeks.  Including this controller project!

A FAB run of the revised PCBs are in shipping and should be here Monday, they mainly feature assembly improvements (changing SMD Diodes to through-holes / placing INA-220's on optional daughter cards), support for LOW and HIGH drive fields. And support for alternator field and battery voltages from 12v to 48v. 

Have been fine tuning the firmware, focusing largely on smooth starts and stops  (Warmup and cool-down periods for the Engine).  Gave  up on trying to get a stable RPM measurement via the stator during start-up and very early in the warm-up cycle.  Just was not able to get a level of consistency.  But the cool-down works great, and it even self-adjust how hard to drive the field by monitoring ramp-up and noting at what point the alternator starts producing amps, then uses a little lower field drive during cool down.  Will see how this works over time, worry that a very warm alternator will behave differently then a cold one in terms of min field drive to produce amps.

Also have played some with the Bluetooth - what a PITA.  Part of the challenge is that bring forward RTS is patent protected and only one company offers Bluetooth with that feature!!!  Wow, what a New, Creative idea that is so Non-Obvious:  When simulating RS-232, carry forward the RTS signal!  (Yes, I believe the Patent Office has been like a dunking sailor for the past 10 or so years...)    But do have it to where I can monitor the debug serial output.   Figure this will allow me to capture live-run data just by having the laptop in the aft stateroom, as opposed to needing to pull the hatch covers and plug in the Service USB device.  In two weeks we will be leaving port for the summer and will be nice to be able to capture more live-run data.

And I have some questions on what to expect for EGT engine temp during normal operating conditions.  But  I posted those over in a new thread in the "Perkins/Cat/Kubota/Yanmar/Isuzu " forum as it seemed a bit more inline there.

-al-

[thomasonw]

Today I did a 30 minute run using the latest firmware and am rather happy with it.  So much so that I 'clipped' the local jumper on the controller that allowed it to power-on w/o the remote attached.  Next week the custom remote panel will arrive and I plan to install the remote and start using this thing!  (We leave dock in two weeks and likely will need the generator for a couple of months until the Solar start to kick in)

And here is a graph from today's run:





Note that VBat values are plotted against the left scale and are shown 10x their true reading.   (Battery voltage ranged from 13.5v to 15v, not 135 to 150v!)

You can see a full start, ramp, bulk, acceptance phase charge cycle here.  I manually stopped the generator while still in Acceptance, as I typically do not let it run after getting down to 40A or so.  No reason to listen to the noise for only 40A's...

A few things to point out:

• You can see early on the starter engaging:  VBat dipped, and Amps went negative.
• What you can not see is the RPMs slowly increasing during warm-up period.
• The management of Volts and Amps worked great during Bulk charge mode. 
• Around the 9.3 minute time I turned off a large load that had been on the inverters (750w space heater).  You can see the resulting voltage rise and the controller nicely handling the situation.
• At about 17.7 the battery voltage has climbed to its temperature compensated charging point, and the controller enters Acceptance phase - here the voltage is held constant and the Amps decline as a result of the battery's ability to accept a charge.
• Also at this time throttle control kicks-in; the engine is slowed down in response to the lower loads.
• And here there is still a bit of hunting as shown by the squiggly lines. It looks to be an interaction between the throttle control and alternator regulation.  Will continue to work on this.
• And you can almost see the cool-down period where the RPMs drop slowly, until 1100RPMs (configurable) are reached when the engine is stops.

I am very pleased with this run, it is doing all I wanted and more.  Over the next couple of months we will be using the generator a lot and I will be able to continue my monitoring.  I am also looking forward to getting the EGT installed and looking at the relationship between EGT and Load.  It is my intention to use EGT to finally decide appropriate loads on the engine (as opposed to looking for black exhaust as an indication of overloading).

On those squiggly lines, I will continue to work and see if I can desensitize the system some more to reduce hunting.  But I am also thinking over the summer I will work to upgrade the controller firmware to a proper PID algorithm.   (See http://en.wikipedia.org/wiki/PID_controller).  And with that will  move from High School Algebra into Freshman Calculus.   See, my Math Teachers were right:  I will find a use for this stuff in the real world!

But for now, things look good.  Am going to post the Firmware after I review the detail data from today's run.  And start getting ready for a summer of cursing.

[BruceM]

Looking good!

It will take some experimenting to get proper dampening. 

Before looking at your algorithm, it might be wise to put an oscilloscope on the analog inputs and make sure that the PWM circuitry isn't glitching your inputs and thus causing the instability.

There is some inductive lag in the alternator response, and your sample/control interval is quite slow.  A calculated rate of change of voltage (velocity) and perhaps an acceleration term can be used to dampen (opposite direction) the calculated correction.  If you continue to have trouble send me this small bit of code and I'll write a suggestion.  I've written a couple aircraft autopilot programs, and did the same in analog circuitry for a massively filtered alternator output as well.  If your debugger allows you to adjust the scalars for your dampening terms, you can dial it in experimentally and get some lovely smooth results.  This is vastly easier with floating point arithmetic,  but I noted that you were using that ready.

[thomasonw]

Looking good!

It will take some experimenting to get proper dampening. 

Before looking at your algorithm, it might be wise to put an oscilloscope on the analog inputs and make sure that the PWM circuitry isn't glitching your inputs and thus causing the instability.

There is some inductive lag in the alternator response, and your sample/control interval is quite slow.  A calculated rate of change of voltage (velocity) and perhaps an acceleration term can be used to dampen (opposite direction) the calculated correction.  If you continue to have trouble send me this small bit of code and I'll write a suggestion.  I've written a couple aircraft autopilot programs, and did the same in analog circuitry for a massively filtered alternator output as well.  If your debugger allows you to adjust the scalars for your dampening terms, you can dial it in experimentally and get some lovely smooth results.  This is vastly easier with floating point arithmetic,  but I noted that you were using that ready.

Thanks Bruce, I have looked at the VBat for noise, and yes there is a noticeable amount of noise in the line - PWM switching in causes a notable amount during its transition, but it is not the only source of noise.  My DSO is rated at 10Mhz, and I would say I am able to see lots of sum 1uS noise spikes all the time - both from PWM changes, and other changes on the boat..  (Ah, but DC is DC - Right???    ).   Fortunately the pre-conditioning snubbers (R/C) before the INA-220's take ou a lot of that, and the internal smoothing function of the INA-220's handles anything that might be left.  (Gotta love the function of those INA-220s!).  And the debug data shows no indactin of 'Wild Voltages' throwing things into a tail-spin.   I do not believe it is a VBat sensing issue.


Today I spent some time looking at a short time frame of the debug data, snips below.  Before getting into it some background:

VBat is sampled every 100mS, and the PWM is adjusted at each sample.
"Debug" data was captured every 10th 'Sample', so we are seeing data about every 1 second.
Temperature compensated target voltage was 14.802v until time stamp 1,372,860mS when the target decreases to 14.785v due to battery temperate change.

There are two configuration variables which can be adjusted for VBat / PWM calculations:
    PWM_CHANGE_RATE = 100mS        (Look to change PWM value 10 time a second)
    PWM_V_SENSITIVITY = 75mV         (For every 75mV we are off, adjust the PWM 1)


OK,  here is an expanded graph segment showing the hunting:




And here is the detailed data behind it:




The columns are:

   mS         = Timestamp of when data was sampled. (in mS)
  Alt-State  =  12 means we are in Acceptance Mode.
  PWM       = Current PWM value being sent to Alternator Field
  VBat       =  Latest measured battery voltage from INA-220's
  Amps      =  Latest measured Alternator current from INA-220's
  Watts     =  Product of Volts * Amps - Used to decide RPMs needed.
  Ve:         = Internal calcuation of Voltage Error while looking to adjust PWM
  Ae          = Internal calcuation of Amps Error while looking to adjust PWM

The "= " column is the resulting PWM adjustment value for THAT cycle.  Remember, I only captured data every 10 cycles, so adjustments in the other 9 cycles can only be seen by looking at the current absolute PWM value.  Notes of " >>i = " is where the system decided to adjust the throttle, and the goal RPM follows.  Anytime the system decides to adjust the RPMS, a ">>i= " is displayed.

And here is a code snippet:







//------------------------------------------------------------------------------------------------------
//
//  Manage the Alternator. 
//      This function will check and change the Alternator state as well as make adjustments to the PWM Field Value
//      -- Consider Ramping
//      -- Consider how far from target we are, further away = hit change it harder.
//      --  And if overvoltage, drop it down even faster!
//
//
//------------------------------------------------------------------------------------------------------



void manage_ALT()  {

    int   PWMErrorV;            // Volts delta (Battery limited):   +  --> Drive the PWM harder    -  --> Back off the PWM some.

                            <<  SNIP    Values for Amps, Watts, etc.. >>
                  

    int   PWMError;               // Holds final PWM modification value.


   

    if (!ian220AMPWaiting || !ian220EGTWaiting ||                     // If Volts/Amps measurements are not ready,   -- OR --
       ((long)millis() - (long)(lastPWMChanged + PWM_CHANGE_RATE) <= 0L))            //   it is too soon to make a change
               return;                                    //      just skip doing anything this time around.

                  


   
   PWMErrorV  = ((targetBatVolts   - measuredBatVolts) / PWM_V_SENSITIVITY);   

      
                           <<  SNIP  >>





                                       //  If someone wants to pull things down, let them have 1st say!
                                       //  If someone critial is spot on, don't let anyone else talk him into 'just a little more?'
   PWMError = 0;                                 //  Note this is in priority order, with overvolts having 1st spot.
   if      (PWMErrorV  <= PWMError)  PWMError = PWMErrorV;                  // Over Volts, adjust down due to overvoltage.


                            <<  SNIP   - Amps, Watts, Temps, etc come next in line.  >>


   else      PWMError = PWMErrorV+PWMErrorW+PWMErrorA;                  // Else, we are Under Voltage, AMPs, Watts and temps. . . 
                                       //    . . so we can adjust up base on Volts.
                                       //    And add in the Watts and Amps delta as well!

   

                          <<  SNIP    Code that deals with mode transitions, throttling,  and bounds checking . >>>>
      




           //-----   And put out the adjusted PWM value to the Field control.
   fieldPWMvalue += PWMError;                                     
   analogWrite(FIELD_PWM_PORT,fieldPWMvalue);                  
   lastPWMChanged = millis();                           
      
}




The full code can be found at:  https://docs.google.com/folder/d/0B5GiaoeXCQ3vQU5ncXhETjQ3OGM/edit  Look for the  " void manage_ALT()" function.


In looking at the data, I am hoping making adjustments to the two variables above will help.  Looking over the detailed data, it seem MY system gives around a 20-40mV change for each 1 PWM change.  I can also see a rate of change in the 20mV/second range when presented small (1-2x) changes in the PWM value.  And as much as -80mV/sec when decreasing PWM values.  (Some of that might be external load influences, during this trial run I had shore power disabled - so refrigeration coming on could cause a load change.)

Curious Bruce, if your auto-pilot algorithm only included at-the-moment-of-time error calculations, or if you included any rate-of-change and/or direction-of-change compensation.  The more I look at this, I am thinking I need to include some type of rate-of-change awareness into the calculations, else we will just keep driving the PWM in a given direction until the Voltage FINALLY gets on target.  But by that time we likely have built up a lot of momentum and will overshoot (Just as I am seeing).  Am thinking if I increase the time from 100mS to perhaps 250mS or even 300mS, it would allow more settling time for the Alternator to respond to changes.  (There is an independent fault checking section that is NOT time based and will trap out any massive overvoltage situations - ala Load Dumps....)  Will also configure things to capture Debug information  every cycle, not every 10th.

Open to any ideas and suggestions on perhaps configuration values to try to use as well as coding hints

-al-

[BruceM]

Autopilots  have dampening terms based on velocity, acceleration and jerk.   The error in lets say altitude demands a positive elevator change, but this is dampened by subtracting the velocity in that direction times some scaling factor, as well as subtracting acceleration times a factor, etc.  This prevents the aircraft from overshooting and wildly oscillating around the desired altitude.  Consider the desired elevator change as the aircraft is "nose up" and almost at the desired altitude. There is still a small positive error, but the elevator must go down to slow the rate of climb or an overshoot will soon result. The dampening term in this case is larger than the error term, so the elevator will go negative.  Same approach for real time control of anything with a lag in response.

The correction MUST take into consideration the current rate of change of voltage (1st derivative) and likely the acceleration ( second derivative).  In your case the rate of change (voltage velocity) is calculated by the difference between the present voltage and the last voltage.  The second derivative is the difference between the newly calculated velocity and the last calculated voltage velocity.  

After reviewing your code and data, it looks to me that you need to add dampening to the PWM error calculation. You presently seem to have none, and thus the oscillation shown is to be expected.  Sorry, I don't do 'C'.  This pseudocode assumes a fixed rate of calculations.  (every 100ms  is fine, slower is OK but it must be fixed or velocity and acceleration calculation must be adjusted for the varying time base)

'calculate battery voltage velocity and accelleration
vbattvelocity= batteryvolts-lastbatteryvolts
lastbatteryvolts=batteryvolts
vbattaccel=vbattvelocity-lastvbattvelocity
lastvbattvelocity=vbattvelocity

'calculate dampening term with scaling variables to be set by debugger- start with zero scalar2
damp= vbattvelocity*scalar1+ vbattaccel*scalar2

PWMerrorV=PWMerrorV-damp

The velocity term will limit the rate of change of voltage, the acceleration term will limit the suddeness of changes.
I don't know if you'll need acceleration at all.  When acceleration and velocity damping terms are tuned right, you get nice quick corrections with no overshoot.

I hope this helps.  Send me a PM you'd like to discuss this further.