PCB v0.1.1 Errata

I have completed my initial hardware debugging of v0.1.1, as  reminder - key changes were:

• Moved from switching 5V / lin 3.3v regulator to cascaded linear regulators (Zenor pre-regulator, and 3.3 LDO for final stage).
• Update Bluetooth module to FCC certified one.
• Updated FET Driver to allow full support of 48v batteries.  (specifically, equalizing).

In debugging the last version of the hardware, I have found the following errata:

Click image for larger view

 I still have a little more firmware work to clean up, specifically I need to make changes in the Bluetooth code around reassigning the connection name/password, and I also need to look into this whole 3.3v issue with Arduino not supporting the watchdog.

Will be thinking on the next steps, if to render and post a revised PCB set now or hold off until some field testing can be completed...  Any thoughts?

Oh Bother . . . Arduino does not support watchdog in 3.3v boot loader.

I have been using the Arduino programming environment for this project to take advantage of its rather simple and integrated approach.  It also does make code a bit simpler to follow, for example:
 
    pinMode(FIELD_PWM_PORT, OUTPUT);

does tend to read better then:
  
     DDRA = 0b11111111;

However it also comes with downsides.  Such as slightly larger code (example, the DDRA code above sets 8 ports at a time), and other side effects.  One of which I came across today...

Seems the default Arduino boot loader does not always support watchdog timers in the 3.3v version.  (See here for some insight:  http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1123964 )

Bother.

This impacts the current code in two ways:

1. Reliability with availability of Watchdog
2. Us of watchdog function to force a reset of the code (ala, during a recoverable fault)

I will need to research a bit more how to get the watch dog functioning.  Clearly I can modify the boot loader, and that in the end might be what needs to be done.  But bother - kind of gets away from the 'simple integrated programming environment'

Revised Charge Pump

Almost all boot-strap FET drivers rely on a less then 100% duty cycle in order to drive the charge-pump; actually have found only ONE  exception - the LT1910f.  A great part, worked clean and well - but would not support voltages sufficient to deploy in a 48v environment (Specifically to support Equalize mode on a High Drive configured alternator).   So I looked at ways to add an external charge pump to more traditional FET drivers by using an unused pin from the Amtel  CPU as the PWM driver and a voltage doubler.  My original idea was this:

Soft Switching R9/21 was not sufficient for IRS2127 leakage

Kind of a modified voltage doubler, it utilized the soft switches of R9 and R21 to handle the 'boost'.  I had hoped that the modest current demands of driving FETs would allow this simple approach to work.  But it did not, the internal Vb impedance of the IRS2127 was such that too much of the charge was bled off, rendering the soft-switching idea unworkable...

So, I modified it replacing the soft resister switches with a hard FET.  I found an interesting approach of configuring a FET to self-switch, eliminating the need for an inverted PWM driver with all its associated issues of race conditions.  (reference: "A Self-Boost Charge Pump Topology for a Gate Drive High-Side Power Supply" by Park and Jahns.  IEEE March 2005).  Building upon this idea I now have:

Revised hard switching Charge Pump

In operation, when Q5 is enabled C12 will charge to around 11v via D9, R19, and D11.  When Q5 turns off, R9 then starts to bleed some of that 11v back to the net named 'Floor'.  This starts Q6 to turn on as we now have the 11v in C12 applied across Q6's Gate-Source (with D11 now blocking the bead-back)..  As Q6 turns on, it pulls the Floor up to the level of the main FETs Source (Vs on U3), pushing C12 up with it via R19.  Resulting in the 'Pump' net to ultimately be sitting 11v above the floor - transferring this charge pump voltage into C11 via D8.  R19 is in place to limit peak surge current, protecting both the FETs and the Diodes.

There is a bit of inefficiency in this design (ala R19), but as the frequency is very low (455hz) we really do not need to worry about things like switch loss, etc too much.  I have mocked up this modified charge pump and it works great.  Spice modeling shows this will also more then handle 2mA of current demands, more then sufficient for any leakage in U3. 

One side effect of this was needed to create a 12v voltage source.  I did this by raising the intermediary voltage in the power supply from 8V to 12v (simply changing the per-regulator Zener).  A down side of this is the 3.3v regulator now needs to do more work and is starting to get a bit on the edge for heat dissipation.  So one will need to add either a small separate heat sink to it, or drill and mount it to the main heat sink.


Has been fun to come up with this, but will tell you:  Sure wish the LT1910f would had about 10v more headroom in it. . . .

3.3v boot-loader for Arduino

I have not done too much on this Regulator project as of late, as we have been busy with visitors and visiting too many coffee shops.  But I did play around some with solving the 3.3v boot-loader challenge.  Turns out it is really simple, and the Arduino Pro comes in a 3.3v/8Mhz version using the Amtel 328P micro-controller.

I found this Sparks-of-fun forum posting that covered ALMOST all of what was needed:  https://forum.sparkfun.com/viewtopic.php?f=32&t=27960, but there is one detail that bothers me:  5v to 3.3v signal levels...   As written the author is directly driving the poor target (running at 3.3v) from the 5v output pins on the hosting Uno.   I am sure for short bursts it will work OK, but it is stressing things a bit, so here is what I did:

 Just used a couple of resister dividers to bring the 5v down to 3.3v land.  Needed to do this for the MOSI (Master Out Slave In) as well as the SCK pins.   I used 470ohm and 1K ohm resisters, but you can try any 1:2 ratio resister you have around.   Note that the Reset pin does not need this, as the Amtel Reset pin is torrential to voltages 2x of Vcc!  (Which is also why there is no clipping diode on the reset circuits).

Once I had the voltages right, I fired up the Arduino ICE programming environment and:

1. From the Menu bar, select Tools/Board and make sure it says Arduino Uno (or what matches the host board you are using)
2. Press the Open Sketch button, scroll down and find the ArduinoISP.  Select that to upload the ISP firmware into the host board (the Uno in my case).
3. Go back to Tools/Board, and this time select: "Arduino Pro or Pro Mini (3.3v, 8Mhz) w/ATmega 328"
4. Select Tools/Programmer and make sure "Arduino as ISP' is checked
5. Now, do Tools/Burn Bootloader

And that should be it!   From now on you will need to make sure you have the correct board selected (Tools/Board) as you move back and forth between the 3.3v environment use don the regulator and the 5v Uno boards.   But at this point the Arduino boot loader should in the regulators CPU, and you should be able to load sketches.  I of course always try BLINK first (adjust the port number to 8 to match where the LED is on the regulator board).



So, there you have it.  3.3v Arduino bootloader all programmed and ready to go!  I just need to finish soldering up the PCBs, and then start uploading the new firmware and testing things out.  Given we are in port though perhaps the end of February, my 'test bed' is a little unavailable.   But I expect after the 1st of the year I can start make some small runs here at Dock.

And a side note:  When I 1st tried to do the above, it did not work.  Reason being I had already loaded the Amtel CPUs with the normal (5v) bootloader, and the Brown Out fuse prevented the CPU from operating on 3.3v.  My workaround was to power the regulator from 5v vs. 3.3v.  That allowed me to load the bootloader and now all works well as 3.3v    If you are using Fresh CPUs, you you should not have this issue though.

BOM update - V0.1.1 design

This morning I posted up a parts list and Mouser BOM  (See Parts list tab above).   And there is some good news / bad news from a cost standpoint!

Good news is:  Basic component cost for the regulator came down a whopping $13.22 (to $29.72) through a combination of the simplified design and some more careful scrubbing of components selected.  The bad news is changing from the low-cost HC-05 Bluetooth module to the RN-41 eat up all that savings, and the new combined component costs (including optional Bluetooth module) now comes to $54.67, a $6 increase...

So why again did I switch out the Bluetooth module?  Two reasons:   First and foremost is the HC-05 has no FCC certification.  And given it also has no shielding there is a great probability this things is quit noisy from an EMI standpoint.   The RN-41 not only has the FCC cert (plus other countries as well), it also has the needed shielding.  

And there is another significant benefit of the RN-41, range.  The RN-41 is a full-power Bluetooth with a range of several 100 feet, which the HC-05 is a low-power class of Bluetooth modules, with a best range of maybe 100'.   Put it into a shielded engine room and that might get even shorter...  If you do not need the extra range you can swap-out for the RN-42, it too has the FCC cert, is pin and firmware compatible, but as a short-range lower power device is $7 lower in cost...

I have real mixed feeling over the Bluetooth module.  Perhaps once I finalize the design I will make up two PCBs - one for each - modify the firmware with some #defines and let you all decide which way you want to go.  

Off course, a 3rd option is:  Just built the board as it is today, but without the RN bluetooth.  Order the HC-05 from Ebay and use jumper wires to connect it via the service port!

3.3v it is, and ordered new batch of PCBs

I looked at what was needed to move the Arduino 'cpu' from 5v to 3.3v, and it looks doable.  the CPU certainly support 3.3v, a bit at a lower clock frequency, but there are some futzing that is needed in the boot-loader that I still need to research.   In any case - to get things moving along I revised the hardware to a pure 3.3v only design and orders PCBs today.   As soon as the Mouser BOM website starts cooperating,  I will place parts order as well.

There were a few considerations in moving the 3.3v, mainly software.  It seems the Arduino boot-loader enables a 'brownout' detection in the Amtel CPU and sets it trigger for something like 3.8v, that will need to be adjusted.  A bigger change was the need to reduce the CPU clock speed from 16Mhz to 8Mhz. - with the concern being will the firmware still work?   I did some timing tests.  It takes around 1-2mS for the current firmware to complete a 'cycle', and there is about 6mS per cycle of headroom.   Meaning I can add another 6mS of code (which I did via dummy delay(1); called) in the mainloop and things will still work well.   So, with a 6:1 buffer I feel comfortable cutting down to a 3:1 when running at 8Mhz.

While I was at it, I added a proper ISPC connector, in case I need to re-flash the boot-loader after soldering in the CPUs  (or worst case, in case I abandon the Arduino environment all together and go with a native Amtel development environment).  Needed to scrub all the resister dividers, as well as change up the Zeners.

I have already posted v0.1.1. of the schematics and PCB layout (See tabs above).  Will post a BOM in the next day or so, as soon as Mouser starts cooperating.  And I will go back in an update the Hardware Overview to reflect the new 3.3v only system.

Posted V0.1.0 of schematic - and Where should we measure current?

Today I posted a revised version of the regulators schematic, and also completed filling in the Hardware Overview.  Some major changes between v0.0.x and v0.0.1.x of the design:

• Usage of Liner regulators vs. switching regulators for  +5v
• Elimination of the DUAL port
• Update of the FET driver chip

For more complete descsiption of the hardware, see the Hardware Overview tab above (or http://arduinoalternatorregulator.blogspot.com/2010/06/hardware-design-overview.html)

And to download a .pdf of the whole schematic, click on the Schematic tab above. (https://docs.google.com/file/d/0B5GiaoeXCQ3vTWpFQVd5UDExamc/edit?usp=sharing)

Where to Measure Current?

A comment on elimination of the Dual port, as that is not really talked about anywhere else.  A group of users I am looking at for this design is Marine use, where is is common to have two engines with alternators charging a common house battery.  Given a key goal of this project is to better manage the battery's state of charge - deciding when to exit Absorption phase by MEASURING its state of charge (as indicated by its Acceptance Amps) as opposed to GUESSING its state of charge (by using a length of time), there is the need to know how many Amps are actually going into the Battery.  In a dual engine setup the amounts of amps being delivered would be the sum of each engine.   So my thinking was by measuring the Alternator Amps of each alternator, and sharing that information, the correct decisions would be made.

During trial runs it occurred to me there can easily be even more charging sources.  Generators, Solar Panels, etc..  Combine this with some amps being diverted to directly power house loads we get a situation where the Dual port was a kind of partial solution.  The real solution is:  measure battery the amps AT THE BATTERY, not the Alternator...    So I removed the Dual port and will document Best Practice is to measure the Amps via a whole-battery shunt.   

However, IF one still wants to measure Alternator production (just because they are curious, or perhaps they are using the advanced configuration options to limit the Alternator output - say by managing Watts load for a small engine DC generator), then an Acceptable deployment will be to make some guess on other charging sources and typical house loads.  Down the road there is the ability to add external communications into the regulator via either the serial port (ASCII strings), or an I2C adapter board, to receive information from say an external battery monitor, or even add a 2nd Amp Shunt port...    Will think on this problem a bit more, but for now there is sufficient flexibility in the regulator as-is to accommodate any installation approach.

Hardware update

Debugging the hardware I have IDed several areas I am not happy with.  In fact, overall I am not happy with almost the whole design and am l looking to improve each subsection.  Here is a rundown of the changes I am looking at:

Changed  out Zener diodes in overvoltage protection:  The zeners just did not work for any input which has a noticeable impedance, as the Zeners themselves are incredibly leaky and caused massive signal changes – even well before their knee.  This was most noticeable on the NTC problems.  With its  5-10K impedance the Zeners rendered this circuit unusable.  So, I have gone back to the tried-but-true two Diode approach.

Changed from Switching to Liner voltage regulator:  A key challenge in  being able to support the wide range of battery voltage – from 12v to 48v systems – is handling this wide dynamic range without hardware changes.   The expected actually battery voltage can range from 8v to over 68v and with this massive voltage range traditional Liner power supplies can have a large amount of heat disputation (upwards of 3Watts).  So I tried a Switcher – but it just is not working.   It is missing its design specs, frequency of operation, ripple, etc.   The datasheet cautions that ‘fine tuning’ of components is often needed to dial things in..   Well, I just do not have the experience to do that.   And despite the promise of 48v being ‘normal’ in automobiles (and hence there being a wide range of ICs available to support these higher voltages), we are just not there yet.  Hence the picking is slim when it comes to 48v tolerant ICs (All ICs - not just voltage regulators!).   In the end I am going back to the brute-force linear regulator.  I will use a simple zener/emitter-follower transistor for the pre-regulator to handle the bulk of power dissipation in 48v deployments finishing up with a proven reliable LM7805 to polish things off.

Changed FET driver chip:  This support for 12v to 48v systems also has been a challenge in the FET circuit.  Specifically the driver.  I found the LT1910 chip which solved a TON of issues (chiefly being able to self-generator boost voltage during 100% duty cycle) and it has worked very very well.  However, it will not withstand voltages that might occur on 48v systems.  Specifically while equalizing, and more so, specifically while equalizing in a cold temperatures where the battery voltage needs to be higher…  I wrestled with this one for a long time, as the LT1910 is such a nice solution, and it worked for all but a small corner case…  And in fact, it might have been just fine, only overrating above its max rated voltage by say 5-7v or so…    But. . . . .  it bothered me . . . .  so I have changed this design.  I could not find another fully integrated FET driver like the LT1910, and instead selected a common high voltage driver chip (IRS2127 in this case, good for up to 500v - should be sufficient!).  That left me with the challenge of how to support boost voltage generation with high duty cycle, specially:  How to keep the FETs on while at 100% / full field…   I thought about just limit field drive to say a 98% max, and that might have worked.  But in the end I added an external voltage doubler to provide boost voltage.  There are app notes about doing this using 555’s for this, with extra costs.  In the end I thing I will be able to use a 2^nd PWM pin from the Amtel CPU to drive the voltage doubler.  Will see how this all works out….

Bluetooth module supplier changed:  The low cost HC-05 Bluetooth module I have been using to provide simple wireless connection has been working well, and at $5 how can one beat it!   Well, in fact I am a bit concerned that it does not carry an FCC certification.  And in looking at Bluetooth devices that do I can clearly see extra shielding.  Perhaps it is not an issue, perhaps one does not worry about FCC cert.  But, I am changing the module to one that provides the same Serial emulation functionality (SPP), has the extra shielding, and carries an FCC cert (along with other countries as well) the Roving Networks RN-41.  It is available at Mouser, but sadly costs $25. . . .  This one I am a bit troubled by, because I think there is no really engineering risk here – it is a ‘government’ thing.   IF by chance I make up a few of these to offer to others, in kit, or even some level of assembled, I worry about the FCC thing..   So – Costs Up $20 for that one.  There is one advantage though, the RN-41 is higher power and likely will keep a stable connection for over 50’ or so, while the HC-05 was a lower-power Bluetooth device designed for a few feet.   AND if one wants to lower costs, the same low-power level device is available from Roving networks as the RN-42, it is pin and software compatible, and its costs is around $15.  So only $10 up..

Upgrading the Voltage sensor chip:   Again, driven by the wide range needed to cover and the desire to not have any assembly (ala, part value selection) options to cover that.  I tried a switchable pre-scaling voltage divider in front of the INA220, but that proved to be problematic – again, and impedance thing.  In order to keep the power dissipation reasonable in the resister divider in a 48v system I needed to use somewhat high resister values, but that combined with the input impedance of the INA220 did not produce a stable design.   TI offers an upgraded part, the INA226 which not only has improved input impedance, but also a wider voltage tolerance (it can handle 24v systems directly), AND greater resolution!   So, I am going to upgrade to that part, and place a fixed voltage diver on the input to cover the range needed for 48v systems.  No more switching in/out, it will just always be there.  I will lose some precision with the pre-scaling, but will pick it back up with the improved resolution of the INA-226.  And it looks like the expected impedance input range of the INA-226 will keep total calibration errors under 0.5%.  I feel this whole thing is a bit of a compromise between precision and flexibility to cover the wide deployment range w/o hardware changes.  I looked into other approaches, ala a simple Op-amp to buffer the input impedance, but again picking are slim to cover the wide range needed (actually, I did find a jus the part I needed – the LM143.   But that simple, low cost device was taken off the market in the late 90’s.   Sigh..).  Did find native 48v sample chips, but they had too low of resolution, and insufficient speed to meet the 100mS cycle time goals.

Current Measurement:  Another benefit of upgrading the sensor chip to the INA-226 is its ability to handle voltages sufficient to allow the Current Shunt to be placed either High or Low on 12v AND 24v systems.   Giving greater deployment flexibility to those systems.  36v and 48v systems will still need to place the shunt low (in the ground) to prevent exceeding (and damaging) the INA-226.  In order to place shunts High on 36/48v systems, a simple external pre-scalar will be needed (ala, and AD8217).  I had thought to imbed the pre-scalar directly into the design, but that has the side effect of locking ALL deployments into high-shunt deployments.   So, for now, am going to simplify things with this slight restriction:  36v/48v systems must use a shunt placed low or use an external pre-scalar on a high-shunt.  As the world progresses, perhaps a new INA-22x will come out that can directly handle 48v voltages. 

Removed the Dual-sync port:  With the insight of where the shunt SHOULD be placed (or, perhaps more polite to say COULD be placed) it became clear that a dial-sync capability was not really needed.  By placing the shunt at the battery that situation is handled, and even more:  Things like a 3^rd charging source (ala Solar panels) and house loads are all covered.   None of that would have been addressed with the simple dual-sync port, but placing the shunt at the battery does.   So:  With a better engineered solution available, still retaining the flexibility to place the shunt on the alternator if one wishes (and perhaps making some educated guesses at other charging sources / house loads) I have removed the dual sync logic and code.  It seemed like a needed feature, but in the end it was an incomplete solution.  There is a better one, and the better one is FREE!

Removed CAT-5 connector block:  And with these  simplifications, I can remove the stacked CAT-5 block; going back to header pins for the Service port and using simple screw connectors for the NTC temperature probes.  It not only lowers costs some, but also greatly increases the flexibility of sourcing temperature probes – several are readily available from EBay, and one could also use ones from Morning Star or even Balmar.  All made up for you!  (Will need to confirm the nominal resistance of these as being 10K, and if not you will need to change the source code #define calibration values).

OK, that is it.  I will be looking to fab up new PCBs this October, and perhaps do some assemble in November when we return to port for the winter.  Until then, I will continue to refine the firmware – currently addressing details around load-dumping, and think I about have it nailed.

Looking at Load Dump

Load Dump is a condition when a large DC load is suddenly removed.  A common example aboard Viking Star is when the Dryer is running, it consumes 1200watts to power the heating element.  This is supplied via the inverter, and it can consume upwards of 90-100Amps to meet the need.  But when all of a sudden the Dryer decides it is at temperature, it will turn off the heating element - with a very very sudden drop in a 90A+ load:   a Load Dump.

While the heating element is operating, the Alternator will work it hardest to meet the needs of the

inverter with the remaining energy being sent to the battery for its recharging needs.  However, once that Inverter load is suddenly removed, the Alternator will take some time to spool down - and there is a risk of overvolting the battery if not done quick enough.   BTW:  In the Automobile world, there are many recognized transient situations.  Most of which are described in the graph to the right.  And yes, I am using Load Dump a little different - removal of  large load, as opposed to disconnecting the battery . . . .

The Source code is configured to update the Alternator field drive every 100mS, or 10 times a second.   And any overvoltage situation takes absolute precedence in reducing the PWM drive.  With the DC generator, and its smallish 135A alternator, the normal PID logic was able to deal with any load-dump situations.  However, with using our Mains alternator (a 270A Leece Neville monster)  I found the PID was not able to respond quickly enough.  Example, on one run I noted a max Overvoltage of 450mV, almost half a volt!

So I added in some Load Dump code:  upon detecting as little as 40mV overvoltage, we now cut down the PWM by 50%. 80mV causes another 50% pull back, and 120mV over target just turns off the Alternator.  a Primary goal is to protect the Battery.  Using this approach I was able to reduce the maximum overvoltage to 80mV.  (As a side:  the regulator normally regulates within a 25mV range around the charge profile target).

After looking at the data dumps from todays trial run, I think I can do better - by looking not only at the absolute voltage to detect a Load Dump, but by also looking at the Rate of Change of voltage.  If I see a massive Rate of Change, and we are close to the target Charge Profile voltage, then we also trigger a Load Dump pull back of 50%.

Continued progress

Over the past several weeks I have continued to test out the Arduino based Alternator Regulator.  It has gotten to the point where I now am using it as the primary regulator and the source code is getting rather stable.  But I continue to find problems with the hardware design, today’s admission is around the high voltage switching regulator - it is just not stable.

It is operating outside its design frequency, has very poor response to transients, and is present as much as a 100mV ripple in the +5!!!   All of this is enough to zero out the Bluetooth, and I am sure lots of other things are impacted.

So, in the redesign I will be going back to a liner regulator.  Either a standard LDO with a pre-scaling transistor, or something like the TL783 form TI.   At issue here is when running with a 48v system, there will be upwards of 3w of heat displaced with a linear regulator!

But, it will be stable....  

And I have been thinking more on application - specifically the placement of the Amp shunt.  IF we are really looking to understand the condition around the battery, then I am thinking it makes more sense to place the Shunt at the BATTERY, as opposed to at the Alternator.   Doing so would allow us to know the true state of the battery, independent (and accounting for) and house loads, and/or other charging sources.  

It would however preclude managing closely the load the Alternator places on the engine.


But I think there is sufficient flexibility in the firmware to allow the user to use it for either application:   Better regulation of large alternators on a house battery, as well as doing things like limiting the load placed on an engine if one wants.

All depends on how it is hooked up and configured.

So, will continue to work through issues with the firmware and ge ready to do a hardware redesign this fall.   One open question I have is:   Should I continue to use as many Through Hole devices as I can, or give in and start moving to SMT for things like blocking Diodes, resisters, etc...

Hum....