Sunday, October 27, 2013

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!









Saturday, October 26, 2013

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.




Thursday, October 24, 2013

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.