[TriEmbed] TriEmbed Digest, Vol 16, Issue 18 - Power regulator questions

Fri Sep 19 07:48:48 CDT 2014

Glen and Rodney, yes the tradeoffs part is typically how things work - but not today. 

I am not sure exactly what RTFM stands for but I have received this friendly advice in the past.  Well, when I looked at my FONA board’s instruction set, it turns out there is a function in Adafruit’s library to get the battery voltage.  So, looks like I am getting this functionality for “free”.

Once I saw this, I implemented the situation I described in yesterday’s post.  My trail counter now sends the current battery voltage when it reports the trail counts.  Event better, Ubidots (will do a writeup on them for the blog) will send me an email or text message when the battery voltage drops below a certain level.  While I am in the learning phase, I think this will be very helpful.

Here is what it looks like: 

My next step is to add one more “widget” to send the signal strength (more discovery in the Adafruit library) at the beginning like I do with the GPS data.

Of course, the FONA board is not cheap - $39 - so I know I am paying for this functionality.  

Chip

On Sep 18, 2014, at 3:13 PM, Glen Smith <mrglenasmith at gmail.com> wrote:

> Charles,
> 
> As you said in a previous email, "As with all things electronic, there is a trade off."
> 
> How much is it going to add to your BOM cost is the bottom line. Once the part is on board, measuring and transmitting the data is virtually free, and for your prototypes, can provide useful information. Bench testing batteries and extrapolating their lifetimes gets you close to an answer, but ambient conditions on your bench are a far cry from real world. Getting the metadata and watching it graph would be interesting to ME. But now we start down a slippery slope again - how does temperature affect that battery life? Let's add a temp sensor to your system... (Do I remember that there is a temperature sensor in the 328? Google says yes:
> http://playground.arduino.cc/Main/InternalTemperatureSensor ). So assuming that the 328 is sleeping most of the time, the die should be pretty close to the ambient temp inside your enclosure. Temperature might very well affect trail usage - so reporting that regularly might be useful for the primary function as well.
> 
> Collecting a graph of battery voltage and temp vs time may be of value for other projects that you come up with in the future. It may not be of much interest to Parks & Rec - except to know when a sensor may need maintenance. It might be nice if a sensor went unexpectedly off line to be able to look at the last reported voltage. If it is close to nominal, chances are something else happened. Close to the built in cut off voltage of the battery would lead me to suspect things are still intact, but have no juice.
> 
> Personally, I think I would add a spot for the component on the board, with a jumper setting or code support to know if it is populated. Early deployed units would be populated and the data watched. If I discovered that the data was boring, future units would lack the sensor.
> 
> Glen
> 
> On Thu, Sep 18, 2014 at 2:27 PM, Charles McClelland <chip at mcclellands.org> wrote:
> Rodney, 
> 
> Agreed, it is overkill for my current non-connected sensor for exactly the reasons you state below.  I should have mentioned that this is for the GPRS based connected sensor which has much higher and more variable power demands.  
> 
> I was reading this article from the TI power folks who - unsurprisingly - thought that fuel gauges should be included in all battery designs.  I started thinking about how emotional this engineer was getting with words like “baffled”, “excited” and “flustered”.  I figured there must be something here.  Full disclosure - TI also sent me a sample of their BQ27410-G1 Gas Gauge chip
> 
> I am planning on putting a connected sensor in the local Ulmstead park to measure vehicle traffic.  I was thinking about the “metadata” I could send with each transmission and I realized that including the battery voltage might be a good thing.  I could watch the battery levels and know when I needed to swing by the park to change the battery.  I am using the Sparkfun one you pointed out below so, it is not about under voltage but about remote monitoring.  Over time, I will probably get a sense of how long a battery lasts so perhaps this is just for the learning phase.  According to the RC blogs, cold weather can affect LiPO performance so, the battery life could change significantly as we go from Fall to Winter.
> 
> Does this make sense or am I making this more complicated than it needs to be?
> 
> Thanks,
> 
> Chip
> 
> On Sep 18, 2014, at 2:09 PM, Rodney Radford <ncgadgetry at gmail.com> wrote:
> 
>> The subject of Lipo batteries and battery fuel guage were discussed at a previous TriEmbed meeting.  For your application, I think it is overkill as what you are doing is constant - wake up, take a measurement, log it, and go back to sleep - so you should be able to determine the length of time a charge will last without it.
>> 
>> The issue with Lipos is that you should not overuse them so they go undervoltage, but why not go with one with builtin overcharge, overcurrent and undervoltage circuitry built in, like this one from Sparfun:
>> 
>> https://www.sparkfun.com/products/341
>> 
>> They have a variety of sizes from from 40mah to several thousand mah, so you could first test your circuit with the smaller unit, determine how long it will last, and be able to better extrapolate out how big of a battery you would need to last for the amount of time you would need between charges.
>> 
>> 
>> On Thu, Sep 18, 2014 at 1:11 PM, Charles McClelland <chip at mcclellands.org> wrote:
>> Michael, 
>> 
>> Thanks for taking a look at the power supply thread,  as my projects run on batteries, I have put some time into this.
>> 
>> Here are a few thoughts:
>> 	- Like you, my circuits draw a relatively small amount of current.  I developed these tests at a higher current so they would not take a month to run
>> 	- your current regulator (MCP1700-3302E) is Linear so it will dissipate - read waste - power equal to the product of the difference between Vin and Vout time current (Eqn 6-1 in data sheet)
>> 	- This is where I started but I decided to move to a switched power supply for three reasons:
>> 		- They are battery omnivores - since the TPS63031 is both boost and buck and is over 90% efficient over a large range (1.8-5.5Vin) - I can throw all sorts of batteries at it
>> 		- As they are more efficient, they should throw off less heat - potentially a big deal since I put them in a box and bury them
>> 		- This supply can handle from very small 25uA to 800mA currents
>> 
>> As with all things in Engineering, there are some trade-offs I had to accept:
>> 	- more expensive
>> 	- QFN packaging - ugh
>> 	- weird and exotic new component required - an inductor - no really!  There are a bewildering number of choices here!
>> 
>> Some suggestions:
>> 	- I would be happy to loan you my test rig which you could use to test your current power supply and compare it to the three I made.  
>> 	- I added the Excel spreadsheet with the full set of tests and results to the posting on the Triembed.org site
>> 	- I could give you a TPS63031 breakout board so you could test the supply in your circuit without the pain of soldering - I have some extras
>> 	- You could look at commercial options such as the little breakout boards from Pololu - I have one of these you could borrow if you like
>> 
>> Hope this helps.  
>> 
>> BTW, my next step in my power supply obsession is to add a battery fuel gauge to the circuit so my Arduino can check it and so I could use LiPO batteries with more confidence.
>> 
>> 
>> Chip
>> 
>> 
>> 
>> On Sep 16, 2014, at 5:00 PM, triembed-request at triembed.org wrote:
>> 
>>> MCP1700-3302E
>> 
>> 
>> _______________________________________________
>> Triangle, NC Embedded Computing mailing list
>> TriEmbed at triembed.org
>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>> TriEmbed web site: http://TriEmbed.org
>> 
>> 
> 
> 
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
> TriEmbed at triembed.org
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> TriEmbed web site: http://TriEmbed.org
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20140919/cc8b1769/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-09-19 at 8.39.27 AM.png
Type: image/png
Size: 128165 bytes
Desc: not available
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20140919/cc8b1769/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-09-19 at 8.46.52 AM.png
Type: image/png
Size: 36527 bytes
Desc: not available
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20140919/cc8b1769/attachment-0001.png>