SR Internships 2014 - Battery Fuel Gauge

[Giorgos Karatziolas]

Hi all, 

As part of this project, I've got to collect the discharge curves for a set of SR batteries. To do this I have designed a constant current load (with help from Tyler, Rich and Rob).

I've now got a complete schematic (attached below) for the constant current load, and I'm looking to get it prototyped. 
In order to do so, I'll need to buy a set of components (outlined in track ticket 2504). 

I've not written a trac ticket, let alone a purchasing one before, so let me know if I've missed anything out. 

As well as this, a data acquisition device is going to be required in order to collect data about the battery voltages while they're discharging. This will be the subject of another track ticket. Currently I'm waiting on a reply from the supplier regarding the delivery time. The DAQ in question can be found here [0]. It's not too late to post alternative models if anyone knows of anything cheap and reliable. 

Thanks, 

Giorgos

[0] http://www.open-daq.com/productos/opendaq-s

[Giorgos Karatziolas]

Hi again, 

I thought I'd post an update regarding my internship. I've been working for just over 2 weeks now (I lost a few days to a chaotic house move). The first prototype of the constant current sink has arrived, but some of its behaviour is unusual. When used to load power supplies, the device works nicely. When used to sink LiPos, fuses blow. All I can imagine is that when the battery is connected, the circuit undergoes some transience before reaching its steady state of drawing a constant current. During this transient stage, it is possible that the LiPo is being connected to a ~240mOhm load. This would draw a current of ~50A and so blow a 15A automotive fuse in about 10ms. I'm off to the UG electronics labs to test this idea out. On the bright side, this was a good safety test. I now have faith that the fuse will blow long before the wires incinerate or the LiPo explodes!

The openDAQ has also been a source of trouble. I've got it working, and 6 of the 8 analogue channels work as expected. Unfortunately, channel A1 doesn't log any data, and channel A4 is shorted to ground (which lead to some sparks being made). OpenDAQ have said that I can send the product back and receive a new one at no cost, but I'm not sure what would be the best plan of action. If my circuit is going to take a long time to debug, then I may as well send off the openDAQ, otherwise I'll just work with the 6 channels for as long as I can. 

Thanks,

Giorgos

[Giorgos Karatziolas]

Hi everyone, 

I'm beginning to worry about the lack of progress that I'm making with my project, so I'm going to outline why I'm having trouble, while also posting some ideas about what might allow me to still produce some useful contribution to SR.

The first problem is that the openDAQ that I've received in faulty. OpenDAQ have stated that I can send it back for a replacement, but this might not be good enough as it could be another week before I get my hands on the fully working one.
This is not a massive problem as 6 of the 8 channels work fine (meaning that I could ask for a replacement to be sent out in before I send mine back). The other possibility is that should the project change, I'd have good ground to ask for a refund.

The next (and biggest) problem is that I don't have faith in the load that I have built. I've done a pretty wide range of tests on it, and the behaviour of the device is unpredictable. Sometimes it works very well, safely discharging LiPos at a constant rate. This has been seen to work at the target of 5C (11A), but it has not yet been seen to do that for the full 15 minutes taken to discharge a LiPo at that rate. 
My problems with it are as follows:

a) Very frequently, the device will provide a very low resistance path for the LiPo. This can blow the fuse within milliseconds of the battery being connected. What is very unusual is that this has happened both when the discharge circuit has been powered and unpowered. One possibility is that the MOSFETs are holding some gate charge and so being switched on. I don't believe that this can be the case as there is a pull-down resistor connected to the gates of the MOSFETs. Another possible cause is that during the transient stage of the discharge, right after the LiPo is connected, a huge current might be being draw. Having looked at this with an oscilloscope yesterday, I've fount that this isn't the case, the system responds to a step input (LiPo being connected) with a critically damped current draw. So the current peak doesn't seem to be being caused by this.
b) The device is hard to set for a specific current. Either a power supply capable of sourcing 11A needs to be connected as a fake battery while the current drawn is tuned, or the tuning needs to be done while the battery is connected. As a result, the initial data is lost.
c) The battery voltage threshold at which the load automatically stops discharging the battery is dependant upon the supply voltage of the rest of the circuit. This means that an precise threshold is very difficult to set up.

d) I'm not certain how safe the device is. This is a big source of concern as the idea of starting a LiPo fire terrifies me!

In doing what I've done so far, I feel like I've learnt a lot. For example, I've learnt that modular design is very important. I should have tested the modules of my design individually under realistic test conditions as opposed to trying to test the entire design at once. This would make the design's imperfections easier to detect. I've also learnt some electronics theory by having my initial designs altered by Rich and Rob as well as learning some things about practical electronics and circuit assembly. 

I think that it is very important that I ask what the main goal of this project is. If the goal is to collect the battery discharge data set, I think that I may be going about it the wrong way. The data that I collect will most probably only be approximate (since testing, I've lost a lot of faith in the performance of the constant current sink). As well as that, the data will take a huge amount of time to collect. If this is the goal, I first need to ask why, and then I would say that using the Turnigy Accucell-8150 to do the discharge and data-logging will probably be far more accurate than anything I can make. The data that I've collected with it so far seems more than accurate enough to create a simply battery fuel gauge (if that is the ideal end use of the data collected).
Should the end goal be to create a battery fuel gauge, then I think it would be a good idea for me to use the Turnigy discharger to collect small samples of data and use it to create a simply model of a discharging LiPo, and then collect more data when the old model proves to be limited. This approach would probably be good enough to create a simple 3-bar fuel gauge (similar to that seen in a digital camera) fairly quickly.

All thoughts on the above are welcome. The main point is that I feel very worried about how limited my progress has been, and a change in direction may help me produce something useful.

Thanks, 

Giorgos 

[Giorgos Karatziolas]

Hi all, 

I've just spoken to Tyler and Alyster. They were wondering whether it would be worth me moving to a different task to work on for the rest of my internship.
The major idea was to create an automated motor board tester. As far as we could tell, a complete test script doesn't yet exist for the motor boards. This could be written by me with help from whoever wanted to be involved. 
The goal would then be for me to create a device which the motor boards could be plugged into and when a button is pressed, a full test report is produced. This could also have tie-ins to the inventory. The motor board could have it's status updated to working or faulty. 

Alyster and Tyler have talked me through some of the practical details of interfacing with the motor board and I think I'd be  comfortable creating the required software and hardware. 

While I'm working on this I can still collect some battery data.

How do people feel about this?

Thanks,

Giorgos

[Sophia Maria]

Hi Giorgos,

rich has some good existing thoughts on it, some tickets are around with the basic ideas from severl months ago.

At least from my perspective this seems like a very useful thing that we can really use.

cheers

lilafisch

--
You received this message because you are subscribed to the Google Groups "Student Robotics Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to srobo-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Giorgos Karatziolas]

Hi Lilafisch,

Like you said, I had a look on trac and found some useful stuff. 
First of all, it looks as though Rich has already created some testing kit #1768.
As far as Tyler and I could tell, this was only for use by the manufacturer of the motor board.

As a result, it could be useful for what I'm doing, but it doesn't mean that it's already been done.

Something very useful was a full specification of what the motor board should be able to do [0] 
As long as everyone agrees that this is worth doing, I can base the testing procedure on this document. 

Thanks, 

Giorgos

[0] https://www.studentrobotics.org/trac/wiki/Motor%20Controller%204/Requirements%20Specification

[Rob Spanton]

Hi Giorgos,

On Wed, 2014-07-09 at 02:51 -0700, Giorgos Karatziolas wrote:
> I'm beginning to worry about the lack of progress that I'm making with my
> project, so I'm going to outline why I'm having trouble, while also posting
> some ideas about what might allow me to still produce some useful
> contribution to SR.

On Wed, 2014-07-09 at 09:07 -0700, Giorgos Karatziolas wrote:
> I've just spoken to Tyler and Alyster. They were wondering whether it would
> be worth me moving to a different task to work on for the rest of my
> internship.

As you know, you're doing a 6 week internship, and you are now in week
4. When you started the internship, Rich and I both stressed that this
was an extremely short period of time for getting anything useful done.
This is why we stripped down the project that we had initially planned
for you.

You are currently somewhere around halfway through that project, and
there is still time within which you can achieve something useful with
that. Let's not abandon it. Yes, you are experiencing some technical
difficulties, but this is to be expected: this is reality! Moving to a
new project for 2.5 weeks is not going to result in something that is
more complete.

Cheers,

Rob

[Giorgos Karatziolas]

Hi Rob,

If I do continue with the battery project, I need to ask what outcome is more important.
Do you want a model of a battery which can be used to create a fuel gauge which can identify 5 or so charge states, or do you want a huge data set which could hypothetically be used to create a higher precision battery fuel gauge?

Giorgos

[Rob Spanton]

Hi Giorgos,

> Do you want a model of a battery which can be used to create a fuel gauge
> which can identify 5 or so charge states, or do you want a huge data set
> which could hypothetically be used to create a higher precision battery
> fuel gauge?

(As previously discussed) Your project is to create the dataset. The
way of ascertaining whether a fuel gauge (whether it reports 500 or 5
different states) actually works is with that dataset.

Cheers,

Rob

[Rob Spanton]

On Wed, 2014-07-09 at 02:51 -0700, Giorgos Karatziolas wrote:

> The first problem is that the openDAQ that I've received in faulty. OpenDAQ
> have stated that I can send it back for a replacement, but this might not
> be good enough as it could be another week before I get my hands on the
> fully working one.

I think you should find out how long it would actually take them to
replace it.

> My problems with it are as follows:
> a) Very frequently, the device will provide a very low resistance path for
> the LiPo. This can blow the fuse within milliseconds of the battery being
> connected. What is very unusual is that this has happened both when the
> discharge circuit has been powered and unpowered.

If it's happening in the unpowered state, then it is likely that your
circuit is being powered from the battery through some clamping diodes
on an IC's inputs. Have a look at the rails on a scope whilst a bench
supply is connected to where the battery would be. They'll most likely
be non-zero.

> One possibility is that
> the MOSFETs are holding some gate charge and so being switched on. I don't
> believe that this can be the case as there is a pull-down resistor
> connected to the gates of the MOSFETs.

If there's a pull-down that's of a sensible value, then no, this won't
be happening.

> Another possible cause is that during the transient stage of the discharge,

> after the LiPo is connected, a huge current might be being draw. Having looked
> at this with an oscilloscope yesterday, I've fount that this isn't the case, the system
> responds to a step input (LiPo being connected) with a critically damped
> current draw. So the current peak doesn't seem to be being caused by this.

To me, it seems like the most likely situation is that the feedback loop
isn't stable. I know that you've stated previously that it was made
stable by adding a pull-down on the gate, but this is not really in line
with my expectations of what you would have to do to make it stable.

My expectation is that to achieve stability you will need to do
something along the lines of what is described under the heading
"Capacitive Load Tolerance" on page 9 of this document:
http://www.ti.com/cn/lit/gpn/lmc662

> b) The device is hard to set for a specific current. Either a power supply
> capable of sourcing 11A needs to be connected as a fake battery while the
> current drawn is tuned, or the tuning needs to be done while the battery is
> connected. As a result, the initial data is lost.

I would be surprised if ECS did not have supplies that could go up to
10A.

> c) The battery voltage threshold at which the load automatically stops
> discharging the battery is dependant upon the supply voltage of the rest of
> the circuit. This means that an precise threshold is very difficult to set
> up.

This is why you're using the voltage reference.

Cheers,

Rob

[Rob Spanton]

Hi,

Just in case anyone thought that there were some problems that were not
soluble here: with a small amount of investigation, at least 2 problems
with the current hardware assembly have been found -- this means
progress is being made, as now they can be fixed.

Rob

[Giorgos Karatziolas]

Hi all,

I've been debugging my circuit, and I've found that the reason that the sink was shorting out everything that was attached to it was because one of the power MOSFETs had failed closed. I'm not sure what caused this, but I'm going to be investigating that now to make sure that it doesn't happen again. 

I've also altered the feedback to lower the potential for the system to oscillate. This hadn't been causing problems with the constant current sink, but it had been causing very significant problems for the low power model of the current sink that I had put together for debugging. So better safe than sorry!

Thanks, 

Giorgos

[Giorgos Karatziolas]

Hi everyone, 

I've been working on fixing my constant current sink. I'm now pretty certain I know what killed it and I've almost finished designing a new version which will be immune to the old problems. 

The old problems were caused by the following:

• The system that was designed to automatically start the discharge when a lipo was connected and automatically stop when the lipo voltage is lower than 9.6V was designed with improper resistor values and so didn't trigger at the correct voltages. This made it impossible to discharge lipos with my test setup as their fully charged voltage was lower than the threshold. 
  
• As a result, I disconnected the automatic cut-off when testing in order to test the rest of the sink.
• This meant that the "SET" value which was used to control how much current was being drawn wasn't being pulled to zero when a lipo wasn't connected. Instead, this value was controlled entirely by the SET potentiometer.
• Even when dialed all the way down, this produced a small voltage at the SET input. When no lipo is connected, no current is draw. This means that the SET input was always higher than the feedback from the sense resistor when no lipo was connected.
• This meant that the power FETs defaulted to the on state as the system was trying to draw more current.
• When a lipo is connected, it is, for an instant connected to a ~200mOhm load.
• This draws about 50A. 
• 50A is greater than the maximum current that the FETs can sink.
• Usually the fuse is the first thing to blow, but I believe that it may be possible that one of the FETs may have sunk more current than the other (they may take different amounts of time to change the resistance of their channel).
• One of the FETs had failed, I believe that this was the cause. 
  
• As soon as the FET failed closed, the fuse would then blow because of the huge resultant current draw. 

To make sure the new version doesn't have this problem, a few things are being done:

• The automatic start/stop system is being redesigned and then simulated to make sure it functions exactly as planned.
• The FET which pulls the SET voltage down will be turned on by default through the use of a pull-up resistor. This will ensure that if the automatic start/stop system fails or is disconnected, the load will default to being switched off. 
• A capacitor and resistor have been added to the feedback loop of the op-amp in the current sink. This increased noise immunity when the SET voltage is very low. This makes it impossible for low level noise to turn the sink FETs on unless they are meant to be. 

I'll be putting together a new schematic soon and posting it here. I'll then order the parts. 

Thanks, 

Giorgos

[Giorgos Karatziolas]

Hi, 

Here's the new design, as long as no one sees any huge problems, I'll order the parts today and issue a trac ticket too.

Thanks, 

Giorgos

--
You received this message because you are subscribed to a topic in the Google Groups "Student Robotics Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/srobo-devel/_GiVdXIvGO4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to srobo-devel...@googlegroups.com.

[Giorgos Karatziolas]

Hi all, 

So I've assembled and tested the new load.
There are some problems though:

• Setting the sink for very low currents (~50mA) can cause the device to sink so current. This is because the opamp that controls the kill switch has a low output of ~700mV. I believe that this is enough to partially turn on the FET that can be used to pull the SET value down to zero.
  This could possibly be solved by getting op amps with better rail to rail performance, or by adding a potential divider that sets the gate voltage.
• A far more major problem is that the heatsink isn't sufficient for cooling the power FETs when the sink is drawing anything close to 10A. I have just been testing with a LiPo after the sink was proven safe up to 2A through use of a bench supply. 
  When a LiPo was connected, the sink was fine up to about 2A. At currents higher than that, the FETs began to smell, After about a minute at 6A, the fuse blew. One of the FETs failed closed. The FETs are bolted to a PC heatsink with a fan. Thermal paste has also been applied, but they can't lose enough heat through the heat sink to operate at high currents. Any ideas?

Thanks, 

Giorgos

[Jeremy Morse]

Hi,

On 19/07/14 12:36, Giorgos Karatziolas wrote:
> * A far more major problem is that the heatsink isn't sufficient for

> cooling the power FETs when the sink is drawing anything close to
> 10A. I have just been testing with a LiPo after the sink was proven
> safe up to 2A through use of a bench supply.
> When a LiPo was connected, the sink was fine up to about 2A. At
> currents higher than that, the FETs began to smell, After about a
> minute at 6A, the fuse blew. One of the FETs failed closed. The FETs
> are bolted to a PC heatsink with a fan. Thermal paste has also been
> applied, but they can't lose enough heat through the heat sink to
> operate at high currents. Any ideas?

What power rating does the heat sink have? (I can't immediately find the
related ticket on trac).

The ambient temperature in B32 is not a good place to be testing these
things of course, but I can't imagine it has a major effect on the
cooling power (PCs still work, etc).

--
Thanks,
Jeremy

[Giorgos Karatziolas]

Hi, 

On Saturday, July 19, 2014 12:48:30 PM UTC+1, jmorse wrote:

What power rating does the heat sink have? (I can't immediately find the
related ticket on trac).

This is the heatsink that I'm using.  

http://www.arctic.ac/eu_en/alpine-64-gt-rev-2.html

It's supposedly only rated to 70W. I didn't know that until now. The website that I got it off of just said what CPUs it was rated for.
At 6A, the FETs and resistor should have been dissipating 72W between them. 

 

The ambient temperature in B32 is not a good place to be testing these
things of course, but I can't imagine it has a major effect on the
cooling power (PCs still work, etc).

They've just started turning the aircon on at weekends, so it's finally nice and cool in here! 

Thanks, 

Giorgos

[Rich Barlow]

On Sat, 2014-07-19 at 04:36 -0700, Giorgos Karatziolas wrote:
> * Setting the sink for very low currents (~50mA) can cause the

> device to sink so current. This is because the opamp that
> controls the kill switch has a low output of ~700mV. I believe
> that this is enough to partially turn on the FET that can be
> used to pull the SET value down to zero.
> This could possibly be solved by getting op amps with better
> rail to rail performance, or by adding a potential divider
> that sets the gate voltage.

Yes, the correct solution to this is to use a better op-amp. Adding a
potential divider to the output will affect the feedback loop and
potentially destabilize it again. (Changing the op-amp could also have
this affect, but probably not).

> * A far more major problem is that the heatsink isn't sufficient

> for cooling the power FETs when the sink is drawing anything
> close to 10A. I have just been testing with a LiPo after the
> sink was proven safe up to 2A through use of a bench supply.
> When a LiPo was connected, the sink was fine up to about 2A.
> At currents higher than that, the FETs began to smell, After
> about a minute at 6A, the fuse blew. One of the FETs failed
> closed. The FETs are bolted to a PC heatsink with a fan.
> Thermal paste has also been applied, but they can't lose
> enough heat through the heat sink to operate at high currents.
> Any ideas?

Does the heatsink get too hot to touch when it's drawing 6A? If not then
I suspect you have a problem with the interface between the FETs and the
heatsink. The constant current sink that I built can easily sink 13A for
about 5 minutes before the heatsink gets too hot to touch. Note that
that's without the fan running. If I have the fan running then it stays
at about 35°C when sinking 13A and can run indefinitely.

Admittedly the heatsink on my current sink is larger than the one you
bought, but it shouldn't make that much difference. Even if you assume
the heatsink I have was designed for a TDP of 140W* you would only
expect yours to have double the temperature rise than mine does. So
maybe a maximum of 45°C at 13A. This all assumes that the FETs are
solidly connected to the heatsink.

Rich

* Note that a heatsink being rated by the amount of power it can
dissipate is bollocks. Without them defining the temperature rise it'll
be at the power it doesn't mean anything. I've made the assumption that
our two heatsinks were designed to keep the CPUs at a similar
temperature.

[Giorgos Karatziolas]

Hi Rich,

On Saturday, July 19, 2014 5:35:18 PM UTC+1, Richard Barlow wrote:

Yes, the correct solution to this is to use a better op-amp. 

I'll do a bit more testing to see how big of an issue this is, it seems to be working fine at the moment.
If there's any more trouble then I'll switch it out for a better opamp.

  

Does the heatsink get too hot to touch when it's drawing 6A? If not then
I suspect you have a problem with the interface between the FETs and the
heatsink.

The heatsink was nowhere near as hot as the FETs when there was the heat trouble.
I'm going to sand the contact on the heatsink to make sure it's nice and flat.

Then I'll give it a thorough cleaning, and then I'll try again.

Thanks, 

Giorgos

[Giorgos Karatziolas]

It works!

It's finally working nicely. The heatsink has been attached properly and the system is running fairly cool. It's unfortunately only got one power FET at the moment as the other three were damaged by me!

I've set it to draw 5A. The system is running at about 50'C and I've been probing some signals and found the to be non-oscillatory.

I'm going to let this LiPo discharge at 5A for a while and check to see that the cut-off works properly.

I know this is very late for part 1 in a 3 part project to start working, but I should be able to collect some data when the openDAQ arrives!

--