Battery Monitors

[Biggles]

This may open up a can of worms.

 

I'm just coming to the end of the design and debugging of a rather complex battery monitor (however not the sort that is applicable to the average boat owner as it's really far too complex and expensive plus it requires the use of further external devices - for instance it doesn't even have a display) that incorporates more or less every possible feature that man could devise.

 

We've been discussing transferring parts of that design to a new standalone battery monitor and my experience is that actually asking the sorts of people who would be using it, "what do you want?", usually scores dividends and often a few surprises. Many manufacturers seem to miss this stage with the result that they simply produce yet another version of something that has been available for 25 years (the same device with a light in a different place).

 

Some of you use amp hour counters, some of you use SmartGauges, some use voltmeters, some use ammeters, some use a combination, some use nothing. Some are happy with what they have, others less so, some have tried one, not liked it and moved onto something else. None of them are perfect (battery monitoring is not, depsite its apparent simplicity, an exact science) but different ones suit different people. Much of it comes down to the owner's knowledge and experience in what they can actually make work for them.

 

Given a blank sheet, what would you want of a battery monitor? What features would you demand? What would you wish for? What would be a "like" but not a demand? What would be an "absolute must"?

 

Are you currently using something that's almost right for you but you wish it also had such and such a feature?

 

Is there something in particular that stopped a certain device from working for you?

 

Remember that every additional feature will cost money and some people even squeal at the cost of a voltmeter let alone something costing hundreds of pounds. However this device is, at present, aiming to be the Rolls Royce of battery monitors. The budget market is already pretty well covered. Whilst some people avoid expensive equipment, there are just as many who love it.

 

As a boater, and having designed several in the past, I think I have some idea of the overall ideal device but input will be gratefully received and noted even if I disagree with it. The device wont be for me therefore my opinion is worthless.

 

The design process on this sort of device is very long so it will be some time before it sees the light of day but if anyone (or more than one) came up with a brilliant idea I'm sure I could pull some strings and get you allocated as a "beta tester" (which means you'd get one for free ).

 

PS. I have just spoken to "management" and this product has now been given the green light. I start the design when the current two are finished which should be about the end of January.

 

 

I have jumped straight in here. I have not read any other posts so if my comments are duplicated so be it.

 

I have an NB with 440aH of battery charged by a 70A alternator. When we use the boat its for at least 5 hours running at a time with the 240v fridge running from the inverter only when the engine is running.

 

We are not live aboard so our requirements are different to others.

 

So here's my experience..... I have no battery monitoring what so ever. However I know when its time to go to bed at night when:-

 

1. I am on a promise

2. The 240v TV (inverter shuts down)

3. The 12v lights get so dim I can't read.

 

HOWEVER............

 

On the new boat I am building I want everything including a down-loadable memory log to my PC of all thats going on with my batteries. I also want this remotely sent to me when I'm not on the boat either on demand or as an alert. I want it to decide when and how long to turn the generator on for even if I'm not there to keep things like security and battery condition in running order. I want it to alert me to a situation that needs a real person to attend, I want it to be easily upgradeable by either software or reasonably priced hardware. And of course I want it for free, or as close to as possible.

 

Biggles

Edited November 28, 2010 by Biggles

[Gibbo]

Thanks everyone for all the input.

 

Many of the suggestions are already in the design and settled upon.

 

Some we hadn't thought of and will now consider (I love MP's idea of a separate module and display - this has many advanatages).

 

Some we'd already thought of and dismissed as either not possible at the target price or simply not practical because too few people would actually want the feature and therefore the other people who don't want it would not be prepared to pay for it.

 

If nothing else, this thread has shown just how utterly impossible it is to please everyone!

 

For those still following, the absolute settled parts (this development is already completed, debugged and up and running in the other monitor) are, for each battery channel:-

 

Voltage

Amps (max +/- 500A)

Amp hours (maximum battery bank size of 2000 Ahrs) - both straight amp hours and Peukert corrected amp hours

SoC

Calculated battery capacity

Battery capacity state of health

Battery temperature

Any combination of 12/24 volt battery banks

Indication of whether the amp hour counter is in sync with the batteries

User programmable alarms settable to operate on various conditions such as low voltage, low state of charge, low state of health etc

On screen graphing and data logging with a PC and, again with the PC, output from the PC software to spreadsheet compatible files

Continued support for the existing SmartBanks

 

There are some other features to be included that I'm not allowed to discuss. Some of them have been touched on in this thread.

 

There are several tricks included to overcome the usual problems with amp.hour counters such as two independent SoC's are internally tracked (one SmartGauge based, the other amp hour based). The user has the option of locking the displayed SoC to either or allowing the device to automatically select which to display in which case it displays the SoC calculated from the amp hour counter when it knows it is in sync with the batteries but falls back to the SmartGauge based SoC if there is a risk that the amp hour counter may be out of sync (because the SG based one cannot run out of sync).

 

Using a combination of the SmartGauge SoC along with the amp.hour counter it calculates the actual battery capacity and uses that for its internal calculations. This removes one of the biggest problems with normal amp.hour counters in that they can't track the SoC as the batteries lose capacity due to normal ageing.

 

From the calculated battery capacity and the user entered battery capacity (ie that written on the side of the batteries) it calculates the capacity based state of health.

 

Things we haven't decided on are:-

 

Number of battery channels

What will it look like?

Type of display

Type of user interface

Type of connectors

What future expansion will be possible

Whether to include 48 volt operation ( the cost is high and depsite what those involved in it believe, the market is absolutely miniscule - in fact it's close to non existent in comparison to other markets)

Whether to release the information on the output data format so people can write their own apps (people want it, but they also expect the supplier to do all the work for them with piles of technical queries - it can be economic suicide. PC software is already included)

 

If you read through the thread you'll see that these are the most difficult decisions because not a single one of you agreed on any of these points!

 

Again, thanks very much for all the input and ideas.

Edited November 28, 2010 by Gibbo

[Timleech]

Much has already been covered, but following from Biggles' remote download idea....

This could be tied in with, eg, bilge monitors or bilge pump monitoring (already included in some battery monitors). Great for people who may be leaving their boats hundreds of miles away for maybe a whole winter.

As for not being 'over-complex', modern electronics can be very complex on the surface but with a simple set of basic commands. I'm thinking of cameras and phones, which tend to have hundreds of features and options which many of us will never use, but with the better designed stuff you don't notice they are there until you dig deeper. That way they keep the geeks and the casual user happy.

For my own installation which I have planned for next year - basic Smartgauge stuff, plus Amps and Ah, including solar panel monitoring. 'Time to charge' and 'time before charging' would be handy, but not sure how workable in the real world? A display with enough detail/space not to have to be cycling through menus for the different bits of basic info.

 

Yes I'd love to be able to have a chance to beta test, but it would need to be 24V, & I haven't any killer ideas to earn it!

 

Tim

[Justme]

 

On screen graphing and data logging with a PC and, again with the PC, output from the PC software to spreadsheet compatible files

 

 

That sounds like the PC has to be connected to capture the data & then the pc can convert to spreadsheet files. That would ruin a good idea.

 

 

Better would be for the unit to make the files for later down load. Or people will need to leave a power leach (PC) connected 24/7 to collect the data.

[MoominPapa]

Some we hadn't thought of and will now consider (I love MP's idea of a separate module and display - this has many advanatages).

Grins.

 

Whether to release the information on the output data format so people can write their own apps (people want it, but they also expect the supplier to do all the work for them with piles of technical queries - it can be economic suicide. PC software is already included)

 

I disagree. If you do it right you can leverage the free/open source software world to get applications you never dreamed of (and the sales that go with them.) As a good engineer you will, of course, document the API/protocol, and that's all you need. Provide your community with a mailing list and wiki and they'll do their own support.

 

You won't get complaints about lack of Linux support, you'll get Linux applications. You might get Mac support too. All the geeks will buy the open hardware in preference to the bonnet-welded-shut competition, and geeks drive product acceptance in these markets, as you've discovered on CWDF with Smartguage.

 

MP.

[Gibbo]

That sounds like the PC has to be connected to capture the data & then the pc can convert to spreadsheet files. That would ruin a good idea.

 

 

Better would be for the unit to make the files for later down load. Or people will need to leave a power leach (PC) connected 24/7 to collect the data.

 

I agree that's better but the problem is the cost. It would add a lot to the RRP. I also don't believe many people would use it.

 

I disagree. If you do it right you can leverage the free/open source software world to get applications you never dreamed of (and the sales that go with them.) As a good engineer you will, of course, document the API/protocol, and that's all you need. Provide your community with a mailing list and wiki and they'll do their own support.

 

You won't get complaints about lack of Linux support, you'll get Linux applications. You might get Mac support too. All the geeks will buy the open hardware in preference to the bonnet-welded-shut competition, and geeks drive product acceptance in these markets, as you've discovered on CWDF with Smartguage.

 

I can see your point and will, of course, put it forward at the next meeting.

 

I've thought a bit more about this. I'm coming round to the idea that the way forward would be a "ready to go" install package of the complete Windows software which includes everything for those who just want to use the device. Then also release the full data protocol along with source code for some very simple "start packages" of comms software that just reads the data and displays it as text so people have a starting point on which to expand. Probably in a couple of the most popular programming languages, maybe visual basic and C.

 

What we absolutely have to avoid is being expected to answer any questions about it.

[Chalky]

I agree that's better but the problem is the cost. It would add a lot to the RRP. I also don't believe many people would use it.

 

 

 

I can see your point and will, of course, put it forward at the next meeting.

 

I've thought a bit more about this. I'm coming round to the idea that the way forward would be a "ready to go" install package of the complete Windows software which includes everything for those who just want to use the device. Then also release the full data protocol along with source code for some very simple "start packages" of comms software that just reads the data and displays it as text so people have a starting point on which to expand. Probably in a couple of the most popular programming languages, maybe visual basic and C.

 

What we absolutely have to avoid is being expected to answer any questions about it.

A simple serial interface similar to RS232 would be nice as well. Could transmit regular data packets although for a deluxe version something like ISO14229 diagnostics would be great (although expensive to implement). Would make interfacing to a PIC easier.

[Gibbo]

A simple serial interface similar to RS232 would be nice as well. Could transmit regular data packets although for a deluxe version something like ISO14229 diagnostics would be great (although expensive to implement). Would make interfacing to a PIC easier.

 

For legacy reasons (the main users need to interface them to various other devices) the existing one uses RS232 and RS422. This new one, aimed more at end users, will almost certainly use USB but possibly with an option to revert to a normal or perhaps a TTL level serial/RS232. I think ISO14229 is wholly inappropriate for such a device.

[John R]

I have read most of the posts and can see where everybody is coming from. There is one piece of data / measurement that would really change any battery monitor algorithm if you can measure it - acid specific gravity - you really would be able to tell SOC.

 

Digital instruments do exist but would be challenging to fit to typical boat systems but really would make a difference to the knowledge of what is going on.

 

Get your thinking cap on - yours is the best system so if anybody could do it !!!

[Justme]

I agree that's better but the problem is the cost. It would add a lot to the RRP. I also don't believe many people would use it.

 

 

 

The actual cost to add it is not directly linked to the RRP (everyone knows that the cost of making of most things is tiny compared to its final sale price). The extra cost to build it in should be very small. The type that will want it wont want to have a pc on 24 7 either. You should get out more (on other forums I mean) they are full of people data logging stuff just like this (in fact exactly like this) & making low power recorders because makers are not adding them.

 

 

There is one piece of data / measurement that would really change any battery monitor algorithm if you can measure it - acid specific gravity - you really would be able to tell SOC.

 

 

 

To be of real value you would need one in every cell. Thats not to bad on a 12v system made up of 6 x 2v cells but on a 12v system made up of 3 or 4 12v bats it would be far to costly.

[Chalky]

There's a lot of work being done by the semiconductor makers in this area. Hybrid and electric vehicles have meant that battery monitors and management have gone from being an interesting side line to main stream engineering research for many big players. Unfortunately it's not for lead acid chemistry. There are however lots of new devices being developed...

[Gibbo]

The actual cost to add it is not directly linked to the RRP (everyone knows that the cost of making of most things is tiny compared to its final sale price). The extra cost to build it in should be very small. The type that will want it wont want to have a pc on 24 7 either. You should get out more (on other forums I mean)

 

I think the very fact that people are making them at home is pretty good evidence that it isn't commercially viable to produce them. Otherwise companies would be producing them and people wouldn't have to make them at home.

 

I would love to include that feature and I will certainly look into it in further detail.

 

90% of the cost of these devices is time in developing them. It's almost nothing to do with the cost of the components.

 

they are full of people data logging stuff just like this (in fact exactly like this) & making low power recorders because makers are not adding them.

 

Well not really, they're logging a few voltages and currents, not 3Mb per minute of calculation results. There's a bit of a difference

 

There's a lot of work being done by the semiconductor makers in this area. Hybrid and electric vehicles have meant that battery monitors and management have gone from being an interesting side line to main stream engineering research for many big players. Unfortunately it's not for lead acid chemistry. There are however lots of new devices being developed...

 

There are indeed. Unfortunately none of them really lend themselves to the device in question. They are always too specific in their functions. The usual limitation is the limited dynamic range of discharge rates. I receive an almost endless stream of samples and there is always some major issue with them for this purpose. On top of which, most of them are just catching up with what I was doing 10 years ago

[Chalky]

 

90% of the cost of these devices is time in developing them. It's almost nothing to do with the cost of the components.

 

How true, just not realised by the public in general. Also add - protecting the IPR.

[Gibbo]

How true, just not realised by the public in general. Also add - protecting the IPR.

 

And putting it through "approved testing houses" to get approvals for the barrage of standards everything has to comply with (which are really just a money making scam). The costs are really quite scarey but many simply don't see it.

[Chalky]

I designed & built an LED lamp a few years ago using the "new" 4W seoul leds. Performance was astounding and there was nothing on the market to touch it. Looked at going into production, but the certification costs, BS,CE,ECE etc meant that there was no margin in it.

[Gibbo]

Right, back on the subject of data logging and the device storing it internally (so it can log without a PC).

 

How would you expect to get the data out?

 

Plug a PC into it and upload it to the PC?

Pull a memory device of some sort out of the battery monitor and plug into a PC?

 

Would the pulloutable memory stick (or whatever) be more convenient? Would you be prepared to pay more for that (because it would cost more to implement it) than uploading the data into a PC?

 

How long would you expect it to be able to log for? And at what time intervals?

[MoominPapa]

 

I've thought a bit more about this. I'm coming round to the idea that the way forward would be a "ready to go" install package of the complete Windows software which includes everything for those who just want to use the device. Then also release the full data protocol along with source code for some very simple "start packages" of comms software that just reads the data and displays it as text so people have a starting point on which to expand. Probably in a couple of the most popular programming languages, maybe visual basic and C.

 

Sounds fine.

 

MP.

 

 

Would the pulloutable memory stick (or whatever) be more convenient? Would you be prepared to pay more for that (because it would cost more to implement it) than uploading the data into a PC?

 

Sounds like a very useful feature though. Would it cost more to implement? A USB port for a memory stick is the same as a USB port for PC connectivity. I suppose VFAT licenses from Microsoft don't come cheap?

 

MP.

Edited November 29, 2010 by MoominPapa

[Chris Pink]

Right, back on the subject of data logging and the device storing it internally (so it can log without a PC).

 

How would you expect to get the data out?

 

Plug a PC into it and upload it to the PC?

Pull a memory device of some sort out of the battery monitor and plug into a PC?

 

Would the pulloutable memory stick (or whatever) be more convenient? Would you be prepared to pay more for that (because it would cost more to implement it) than uploading the data into a PC?

 

How long would you expect it to be able to log for? And at what time intervals?

 

It strikes me that the data logging would be a niche requirement. To keep the cost down it should be a optional model, and assuming you will need some onboard memory then straight to PC seems logical. A lot would depend on the requirement for a wireless remote. If no wireless then the downside of plugging the PC has to be weighed against the cost of removable storage. If an optional module then that cost becomes less significant.

 

Seems like there's a series of options emerging, basic module, wireless remote and data-logging module.

 

As for logging and logging intervals, hourly for a month (2 weeks if memory an issue) would show the most useful graph of usage.

 

Trouble is that once the techno-curious have found out the pattern of their usage in numbers, the need for logging becomes fairly trivial only really kicking in when something major changes (new equipment for example, cruising rather than moored) and I can see only a very few people keeping up with it. When I had my Belkin UPS, I ran the software a few times until I got the gist of what was going on and then didn't bother again. (I'm thinking aloud) so maybe the plug the computer in option would be sufficient.

[Albion]

Right, back on the subject of data logging and the device storing it internally (so it can log without a PC).

snipped

 

Just a quick question here from a practical point of view. Other than satisfying the geek's interest and the ultimate professional's diagnostic abilities what actually will all this data logging achieve? For the ordinary user I doubt it will be used at all and so Chris has to balance cost against complexity and ultimately market share. I wonder if all this effort will move the end product out of the market to which, I thought, it was originally aimed. If the complexity can be built in to the product with negligible affect on the selling price then I suppose there is no harm in providing it but, to the ordinary user, wouldn't something like the alarm codes displayed on the existing SG be adequate?

Roger

Edited November 29, 2010 by Albion

[Evo]

Whilst I accept the threads purpose is to thrash ideas around and pass on desirable features, I think things are getting out of control when you start taking about memory sticks/sd cards, wireless remotes, and PC interfaces/software.

 

I thought we were talking battery monitor here..?? (for a narrowboat, not a spacestation).

[Gibbo]

A USB port for a memory stick is the same as a USB port for PC connectivity.

 

If only...

 

A USB memory stick is a USB slave device. It is thick and does what it is told by the USB host (the PC where the real USB work goes on). A USB port to connect the battery monitor to a PC is a USB slave device.

 

It takes a lot of processing to be a USB host and not much to be a USB slave. In order for the battery monitor to be a USB host (so it can use a USB memory stick) would mean a quantum leap in processor family and a huge amount of software with a resultant huge jump in price. This was the bit that was putting me off internal data logging storage.

 

However, to put the required memory inside the battery monitor and have the PC upload it directly from the device is no real issue. The only extra cost is a little bit of relatively simple software, a few tiny bits of related hardware and the cost of the actual memory itself (the biggest part). But this is actually do-able at reasonable cost.

[Sir Nibble]

Lots of ideas here, and it's interesting to see the broad range of information required by the technically savvy. This has the thing verging upon computer based diagnostics rather than function monitoring.

In my view the less savvy prospective purchaser has two questions they want answered.

1/ Is there anything I need to do?

2/ What?

So I would want a simple list of things to do like "Charge" or "Replace batteries" with priorities upon them like , Desirable, Important, or Urgent. This way the bloke who paid for his boat by building houses and knows buggerall about electrics has an on board expert giving him a heads up on what he should be doing without assuming he is an expert.

[Gibbo]

It strikes me that the data logging would be a niche requirement.

 

Absolutely agreed.

 

Whilst this thread is turning out to be very usefull for kicking ideas around, I've been doing this game long enough to know that man A who wants function B absolutely refuses to accept that the other 700,000 people involved have no use for it whatsoever and certainly won't want to pay for it

 

What I'm now leaning to for data logging is putting in the software and hardware to allow it to use an internal SD/MMC card (as an optional extra). These are available everywhwere for next to nothing and give a huge amount of memory. The extra cost to include the ability to use this is minimal so it won't really impact the cost of the device for those that don't want it.

 

The users of the current device only use the data logging when they have a problem. Under those circumstances they're quite happy to plug a PC into it to see what's going on. The requirement for internal logging has never even been mentioned.

 

I personally think wireless connectivity is nothing more than a fashion statement. I can't actually see any real use for it for a device that's going to be part of a fixed installation. It seems pointless to me. Radar also makes a bit of a mess of it.

 

Likewise connectivity to a phone or iPod or whatever. Nothing more than a fashion statement. And seeing as each person has his own different device (and Apple do nasty tricks to make sure they get their cut unless the device is jailbroken) it's basically non starter. Unless someone can convince me otherwise.

 

If there was one standard for mobile devices then it might be workable. But there fact is, there isn't. There are about 30 "standards"

 

I thought we were talking battery monitor here..?? (for a narrowboat, not a spacestation).

 

Obviously the discussion here is relating to narrowboats. But no sane person is going to design an electronic device just for narrowboats. The market is far too small.

Edited November 29, 2010 by Gibbo

[MoominPapa]

What I'm now leaning to for data logging is putting in the software and hardware to allow it to use an internal SD/MMC card (as an optional extra). These are available everywhwere for next to nothing and give a huge amount of memory. The extra cost to include the ability to use this is minimal so it won't really impact the cost of the device for those that don't want it.

Point taken about USB bus masters vs slaves. The above sounds like an excellent compromise. Will you have enough smarts available to be able to write a proper filesystem on the card so that is can be removed and plugged into a PC, or will it be internal-use only with access via the USB port? The former is more flexible, but requires more software and therefore more ROM space (and maybe a VFAT license).

 

MP.

[Chalky]

A USB port for a memory stick is the same as a USB port for PC connectivity. I suppose VFAT licenses from Microsoft don't come cheap?

 

MP.

USB memory sticks are a complete nightmare when it comes to drivers. Not all manufacturers follow the specifications to the letter or certify them. There's a lot of issues with compatability if you're writing a protocol stack. A microsoft volume license for their drivers doesn't come cheap. You're better off using an SD card - cheap and reliable.