Saturday, April 27, 2013

Adding a little Persistance . . .

After posting v0.0.9 of the code, I expanded the slow throttle control code to a more general 'persistent' Amps and Watts variables    These two use the same approach of factoring in the current measured Amps and Watts into a running total - with the idea of smoothing over short-term changes.

These two new variables are used to decide how to adjust the Throttle, and also when to transition alternator charging modes (e.g., from Acceptance to Float, and Float to Shut-down).

A prime example is when the battery is in its late Acceptance state drawing perhaps 40A and we are running the dryer at the same time with its heating element turning on and off every 20-30 seconds or so.  Without a level of persistence  the throttle control logic would go nuts "Hey, we are just charging the battery, can slow the engine down. . .   Oh Dang, now someone is taking LOTS of watts (dryer kicked in), need to speed the engine up. . .  Well, now the watts are low. . .   Wow - make up your mind".    But by adding persistence  the engine will speed quickly, and be a bit slower to react when slowing down.  Likewise I use a persistence variable for Amps when deciding to change charging states.  In the above example, once the Amps got below my configured 40A mark the generator would shut down - even if the Dryer was still running.   I noticed this when coming back to the boat and seeing the generator had completed its charge cycle and shut down, but we were down -229Ah on the Link-10 meter.

Using persistence  for the Watts and Amps fixed both these.  The averaging periods are configurable using two #defines.

   #define WATTS_PERSISTENCE_FACTOR  64L
#define AMPS_PERSISTENCE_FACTOR  4096L


And you can disable these features by setting them = 1L



As indicated before, I am really in the short strokes for this project.  I am going to hold on to the latest (persistence) edits and maybe make some other small changes to the source - looking to improve its readability   Will also look at the configuration #defienes, words and ordering.  And pull them into an #include file.  Once I get all that done, and solved any other small issues that come up, I will post v0.1.0 of the code.  If someone wants the code before that, let me know and I will post an inbetween copy.  (or just send it to you).  But this morning I made some readability changes (ala changes a string of If / Else's into a switch/case statement ) and I want to at least load it into the generator and make sure I have not broken anything before posting the next edits!


Going forward?  Some ideas:

  • Stripped down version - regulator only, dropping all the engine control, but keep Volts, Amps(?), and temp comp.
  • Add a 'setup' mode in the new remote display?  Seems a waste to have all that CPU power just sitting there doing simple translations.  Maybe I can add a screen to the display where major items can be configured.  Then save them into the Atmel EEPROM....   Currently all the Users Interface (U.I) is via #defines in the source.   Doing something basic in the remote would perhaps allow someone to use this project w/o knowing the Arduino programming environment...
  • Flush out the RTC - adding in block-out periods for autostart
  • Add alternative starting modes?  Ala, let the user be able to select 'Low Noise' mode when starting the generator???  (Again, a U.I thing)
  • Someone suggested a split-bulk mode, allowing much higher amps in the initial charge state, then tapering back.  This is something not seen on any regulators out there, but I do understand Lead Acid batteries can safely take a massive amount of current during initial charging.
  • Add some type of runtime status, ala Hours ran, Ahs (Watts) produced, etc...
  • EEPROM dump during a fault, allows for later downloading.
  • Something to drop us back into Bulk phase from Float mode?  In the case a large draw appears to have been placed on the system during Float?
  • A configuration to allow C or F to be used and/or displayed?  (Currently, everything is in F)

I also have not done any trials with co-generating while the watermaker is running.  I am sure once we need that capability (later this summer?) I will find some other issues.


But until then, I continue to be very happy with this project.  It is doing all I wanted.



No comments:

Post a Comment