Discussion of Mark's firmware

Forum for announcements and discussion of beta firmware.
Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by Mark » Wed Oct 16, 2013 3:45 am

ukoda wrote:I have had the job of estimating battery life of dry cells and selecting batteries for some products we supply. We have done simple discharge tests before but I'm tempted to rework the software for that testing next time it is needed.
With the way that I've written the firmware, you'll be able to load a byte code program onto the SD card to do your own custom testing routines - saves having to reflash the firmware whenever you want to change the way that the charger works.

I'd be curious what you'd like the charger to do for the testing that you're doing?

ukoda
Posts: 22
Joined: Fri Oct 11, 2013 3:28 am

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by ukoda » Wed Oct 16, 2013 6:26 am

Mark wrote: With the way that I've written the firmware, you'll be able to load a byte code program onto the SD card to do your own custom testing routines - saves having to reflash the firmware whenever you want to change the way that the charger works.
That sounds like a good idea.
Mark wrote: I'd be curious what you'd like the charger to do for the testing that you're doing?
We would test our product on a bench supply to find the minimum voltage it will run at and divide that by cells to get a minimum cell voltage. We would then put a load on each sample cell we had and see how long it took to fall to that minimum voltage. From that we would know which is the best cell and make a better estimate of the expected operation life. We are typically asked to make a product that will run for 1 to 3 months but would need to do the test in a day or two so would discharge at a higher rate and scale the results. I realise that their are catches to that approach but it is still much better than working purely from datasheets and spreadsheets.

Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by Mark » Wed Oct 16, 2013 10:22 pm

Are these devices generally low drain constant use or are they intermittent use high drain devices?

Batteries that have high capacity with low drain devices may not work well at high currents and vice versa, so it's difficult to extrapolate from fast rate discharges to low discharges. We could set up some code to do a discharge down to a certain cutoff voltage, rest the cell for a certain amount of time and then repeat to give a better idea of how much capacity would be available to a low current device.

Possibly a better idea would be to do discharges at various rates on each cell to build up a database of discharge curves so that you can then check each graph for the capacity for a given cutoff voltage to determine the capacity at the chosen rate. Biggest problem with this of course is that even with a lot of testers, it would still take a lot of time to build up a decent database.

ukoda
Posts: 22
Joined: Fri Oct 11, 2013 3:28 am

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by ukoda » Thu Oct 17, 2013 2:13 am

It is for shop retail video displays and movie theaters. Did you ever see the cardboard Tron motorcycles with the light up wheels used to promote the film? I did the electronics for wheels on that, the flashing pattern determined battery life and had to be approved by Disney. More recent battery powered work is the Spyro Skylanders displays where the diorama is offered as a battery version (yes, I'm paid to play with toys!). That one has a 7" LCD and media player as well as micro, touch panels, LEDs and RFID power. It uses a PIR to detect people and has a pack of something like 16 D cells. So power consumption is 10's mA when idle and 100's mA when active. The ratio of idle to active is a guessing game. Also our discharge tests have been very primitive.

Your suggestion of how to get accurate discharge curves is sound, but over kill in my case given the variables. Whenever someone talks of battery life I notice the minimum usable voltage is often overlooked. I guess some people have noticed that when brand X camera says a set of batteries are dead you can put them in brand Y camera and it will say they still have a third of their charge. And so it is that you can't just take a batteries rate mAh value and divide it by mA to get operating hours. You need discharge curves and very few battery manufactures provide that data. Given the type of people who have brought an UltraSmartCharger I'm guessing that is not news to people here.

In my case just setting the minimum voltage that marks the end of the test and knowing the current draw and total time would be all the information I needed. It would give me a set of figures a magnitude better than before.

One of the advantages of living in China is you get to see how things are made. I visited a battery factory, it was interesting. The machines they use for testing are pretty cool. Imagine the UltraSmartCharger on a much larger scale i.e a small room and a PC. I though I had photos but I can't find them right now.

BTW that 3000mAh battery yields 2132 mAh on test.

Tcepsa
Posts: 46
Joined: Tue Aug 06, 2013 5:26 pm

Troubles with 0.514

Post by Tcepsa » Thu Oct 17, 2013 3:13 am

Finally getting a chance to try playing around with this version, but I've hit some snags.

I needed to tweak CVM.cpp to change the capitalization of an include: Line 2
from

Code: Select all

#include "EEPROMex.h"
to

Code: Select all

#include "EEPROMEx.h"
I ran into undefined symbols in the Robot_Control library--looks like that's a bug with the Arduino 1.0.5 IDE; removing that library from arduino-1.0.5/libraries appears to have resolved that issue.

But now I'm running into trouble with the SD card code. I'm getting the following errors:

Code: Select all

In file included from UltraSmartCharger.ino:6:
Logging.h:62: error: ‘SdCard’ does not name a type
Logging.h:63: error: ‘Fat16’ does not name a type
UltraSmartCharger.ino: In function ‘unsigned int LoadProgramFromSD(prog_char*)’:
UltraSmartCharger:60: error: ‘DataFile’ was not declared in this scope
UltraSmartCharger:60: error: ‘O_READ’ was not declared in this scope
UltraSmartCharger:63: error: ‘DataFile’ was not declared in this scope
UltraSmartCharger.ino: In function ‘void setup()’:
UltraSmartCharger:172: error: ‘card’ was not declared in this scope
UltraSmartCharger:172: error: ‘Fat16’ has not been declared
Is there a different SD card library that I need to get to support the smaller card memory limit?

Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: Troubles with 0.514

Post by Mark » Thu Oct 17, 2013 12:35 pm

Tcepsa wrote:Finally getting a chance to try playing around with this version, but I've hit some snags.

I needed to tweak CVM.cpp to change the capitalization of an include: Line 2
from

Code: Select all

#include "EEPROMex.h"
to

Code: Select all

#include "EEPROMEx.h"
Thanks for letting me know - I've fixed this for the next version. I thought that we had fixed all of these capitalization problems!
I ran into undefined symbols in the Robot_Control library--looks like that's a bug with the Arduino 1.0.5 IDE; removing that library from arduino-1.0.5/libraries appears to have resolved that issue.
Yep. I have a feeling that this might be related to the missing fat16lib library - see below.
But now I'm running into trouble with the SD card code. I'm getting the following errors:
<snip>
Is there a different SD card library that I need to get to support the smaller card memory limit?
Yes! I've just updated the guide to flashing the firmware to make this a bit more obvious:
viewtopic.php?f=3&t=32

Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by Mark » Thu Oct 17, 2013 12:42 pm

ukoda wrote:In my case just setting the minimum voltage that marks the end of the test and knowing the current draw and total time would be all the information I needed. It would give me a set of figures a magnitude better than before.
No worries then!
BTW that 3000mAh battery yields 2132 mAh on test.
That's not as bad as I was expecting then!

BTW, I didn't see any of those displays - I rarely go to the movies these days - sorry! Those displays may not have made it to Australia anyway...

ukoda
Posts: 22
Joined: Fri Oct 11, 2013 3:28 am

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by ukoda » Thu Oct 17, 2013 11:26 pm

Mark wrote: BTW, I didn't see any of those displays - I rarely go to the movies these days - sorry! Those displays may not have made it to Australia anyway...
An Aussie aye? Don't worry I won't you against you, Brisbane makes a great holiday spot. The Tron displays did get to Australia, one even reached my old home town of Auckland. Recently I had to check the language files for our Skylanders display, they did an Aussie version with a voice actor with such a strong stereotypical accent that it brought a smile to my face.

Tcepsa
Posts: 46
Joined: Tue Aug 06, 2013 5:26 pm

Re: Discussion of Mark's firmware

Post by Tcepsa » Sat Oct 19, 2013 1:53 am

Looks like that was the last of the capitalization problems, and adding the FAT16 library did fix my compilation issues. Also I made the change you mentioned earlier with the PWMRange setting and it does appear to have resolved the high frequency noise as anticipated. Hooray!

I have not yet tried actually saving data to the 4GB memory card that I've been using, so I'll probably have to reformat it, but for now I'm just capturing the output over the serial line. Will report back once I've tried the data card and let you know how it goes (I have a 1GB card that I can use, but I haven't checked the filesystem type on it yet).

Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: Discussion of Mark's firmware

Post by Mark » Mon Oct 21, 2013 6:18 am

Tcepsa wrote:I have not yet tried actually saving data to the 4GB memory card that I've been using, so I'll probably have to reformat it, but for now I'm just capturing the output over the serial line.
I just tried reformatting a 4GB card to Fat 16 but it didn't work. (I wasn't expecting it to work, but it was worth a try to save others from having to try it)

Post Reply