Some of these questions are already answered in the user guide that I've already posted, but I'll answer them here for completeness:Paul.Allen wrote:First off Mark, I want to say your Firmware is really Awesome! I love how it really does handle the batteries independently. To test it I decided to put in 2 cells that I knew were not the same amount discharged. The file is big so I will email it to you and let you post it if you want. The following are some questions, thoughts and suggestions. Some of them I already know the answer but might as well have it documented.
Not really. There are some delay() calls in the code - the main one being when reading from the ADC and I'd say that the controller spends most of its time on that delay. The byte code program has delays but they're not implemented by calling the delay() function.Question:
*Is your code timer driven?
I take readings both whilst it's charging and also when it's all quiet. The voltage readings whilst charging are only logged to the file and not actually used for determining whether the cell is full (except for a maximum voltage check)*Do you take any readings during charging, or only when all is quiet?
10 bits. With a 7.8kHz frequency.*How many bit resolution are you running the PWM in this version (508)?
Yep! Generally because the cell has determined a high internal resistance. The actual reason is logged in the data file along with the measured resistance.*Is purple for bad battery?
Most of the time, I'm running it at 18 bits for voltage and 16 bits for current, but I'm running a lower resolution when doing the internal resistance check. The byte code program can adjust the resolution by modifying the relevant register.*What resolution are you running the ADC at?
I don't think that there should be any problems with running one on discharge whilst the other is charging - I haven't noticed any problems with charging causing noise on the discharge measurements.Thoughts:
*Could there be any adverse side effects of having one cell discharge while the other is charging or vice versa? My thought would be reading values under the noise of charging, which if you don’t read them while current is flowing, then this wouldn't be an issues.
Measuring temperature whilst charging could potentially be a problem on revision 6 & 7 depending on how the temperature sensor is setup - voltage fluctuations caused by the charging circuit could potentially cause noise for temperature sensor reading. With a previous log file that you sent through, there were some strange things going on with the temperature sensor, but I don't think that it was caused by the charging circuitry unless you're also running into a similar problem with running 2 chargers at the same time off a single USB hub as I posted about here:Temperature, anything else?
It's good to think about these sorts of things!Over all I don’t think it is bad, I think it is great, but just trying to think about it.
I think it's easier for processing the data file in Excel and it also reduces the size of the file quite a bit. I've got it outputting a header line so it should be reasonably easy to see what's what when you load it into Excel.Suggestions:
*Is it possible to add text to the values printed out like I did in mine? Or is there a reason you would like to leave the text out, like for greater ease of reading it into a future plot program or maybe even when we have the LCD?
Yep - already on my TODO list - I forgot to add that change in earlier!*For Rev 6-7 and on, let’s make the switch positions as I have printed on there, Charge, Discharge and Analyze.
I'll have a think about this. I don't think it's really necessary - even if batteries are left on the charger for 24 hours, that's still only 50 mAh. Would be nice to eliminate it altogether if possible, but it's not the end of the world if we can't.When set to charge, I was thinking we could have it hit the batteries with a jolt of current every few minutes or so if they are left in the charger, to counter act the 2mA drain on them (which I still haven’t figured out the exact source but am narrowing it down). Of course the LED’s wouldn't indicate this is happening, it would just take place in the background.
I've got some ideas for trying to track down where the current is going myself, but I haven't had time to try it yet
Yep - already on the TODO list as well. I've got an idea for how to make it work in a flexible manner - stay tuned!*Add the button start for Rev 6-7, not super critical yet but would be nice.
That's actually not too easy to do with the way that I've got the code working at the moment, but I'll try to work out a way to do it. There's actually 2 different flashes that occur depending on whether the currently charging cell is running in fast mode or medium/slow mode. Changing the flash for medium/slow mode will be quite easy. The other one not so much. I could quite easily make the flashing for when one is fast charging appear less bright (it already is, but it's not that noticeable) How does that sound?*Also, IMO, I think the Red LED when flashing during charging should be on for a shorter amount of time, like maybe 10ms or so. The time between flashes is fine.
Thanks for the feedback and suggestions!Really great Mark!!