Not having to plug in at all would be really impressive.  But it sounds like a helluva stretch goal – on a par with getting it all into a bracelet!

I'm pondering strategy.  I took a helluva long time to get all parts of the hardware working with TS05.  Just getting drivers for the various chips to work took me an embarrassingly long time, and this all has to work before the higher levels of software can be started.  Getting all that goinf for TS05 before I started on the analysis stuff was an error.   I'd like to avoid developing code for all the secondary sensors until we know: 
  1. how many ranging ops we need to do in one day in realistic conditions, 
  2. how much that sucks out the battery,
  3. how repeatable the ranging values we get are.  

For that we need a wearable unit, and some anchors, and the software needs to be getting 

<timestamp><anchor number><range>
records somewhere where we can read them. Almost nothing else matters until that simple pipeline is working and we can see it is going to come in under power budget.  From there on in everything else is just optimization – making Dewbly range more intelligently, report more useful things, and use less power to do it is optional firmware work, and the cloud-based analysis software can proceed independently.
Developing ARM code to get ranges from the DecaWave is going to take me a while.  I've not done drivers for an ARM, and I'm sure there are lots of gotchas.  
But before that even, there's a lot of core (OS) code that has to work before I even get to the ranging stuff. For example I have to get timestamps working, and find a way to initialize the TOD clock with the correct time-of-day for example. 
I'd really like to start with the simplest hand-built OS so the code is small, leaving the possibility of flash space left over to store range data on the ARM itself.  Then I don't have to get the separate flash memory drivers working.
But I do have to figure out how to get the data up to the cloud, or PC.   Maybe it comes over a serial line to start with? I suppose if I have the DecaWave interface working, then I could send all the data over that wireless channel  initially, and if that didn't sink the power budget then hey – we are to first base with the data pipeline, and from there on everything is just 'optimization'.  It's just that the optimization is going to be the bulk of the firmware I expect.
I'm telling you all this because it may have some bearing on your hardware strategy if you know that I'm unlikely to get around to much other than the DW chip for quite a while.  Maybe it buys you some time to figure out some of the more esoteric details of charging, or enclosure?  

//Mik
On Tue, Aug 12, 2014 at 11:50 PM, David Carkeek <dcarkeek@gmail.com> wrote:

It was I who made the mistake in units. 

The Li-Po battery has a lot more usuable energy in it. If we manage energy usage correctly I think we can have a very long battery life. If the solar charging works it may never need to be plugged in.
Which reminds me again that I need to be sure there is a PV cell we will be able to use on the Minitec enclosure.
On Tue, Aug 12, 2014 at 8:31 PM, Mik Lamming <mik@lamming.com> wrote:

Ah.  That showed my complete ignorance didn't it 😀

I always had the model that physical volume was a good estimate of battery capacity, and I was excited to see that my model was violated, but it seems I misunderstood.  Oh well, at least my model is intact.  I wonder when we will get 1000x extractable energy in the same volume.  The harder the challenge the more the triumph.


//Mik

On Tue, Aug 12, 2014 at 11:26 AM, David Carkeek <dcarkeek@gmail.com> wrote:

It's close to the same amount of energy in a CR2032 and fully charged small lithium-polymer pouch battery. I put the CR2032 in W-h but labeled it in mW-h.

CR2032: 0.675 W-h
3mm x 20mm x 30mm: 0.666 W-h
5mm x 30mm x 20mm: 0.888 W-h
4.7mm x 22mm x 29mm: 1.11 W-h

But the advantage of the li-po battery is that large current can be drawn from it without trashing the energy capacity. If button cell is pulsed at high current (high being just a few mA) the energy capacity is much less. I am optimistic that the battery capacity will be adequate.  Making a ring is another matter.

On Tue, Aug 12, 2014 at 9:47 AM, Mik Lamming <mik@lamming.com> wrote:

So a 1000x to 1600x a CR2032.  That a significant difference.  If 1600x lasted one day, then 1000x would be a bit naff.  On the other hand if a 1000x lasted a week, then 1600x is not a significant consideration.

In general, if the difference between one battery and another was the difference between running less-than-a-day and running more-than-a-day then I'd go for more-than-a-day at almost all costs.  If the difference was on a week boundary then I'd go for small.  But since I don't have much clue what our burn rate will be, it's a bit academic.  
At this stage I think I'd maximize your convenience because getting stuff to work ASAP is the priority.  Next we should have a bunch of anchors and a wearable each.  
The first goal is to get daily activity data out of Dewbly onto the screen and into an Excel spreadsheet so we can look at it. It doesn't matter if the devices are big, or small initially.  If we can't recognize patterns in the data, then it will be bloody hard to get software to see them, and we will be done!  
The second goal is to make it easy to gather and upload data every day.  I think the hardware department should take responsibility for making it convenient and reliable for us to gather data day after day, and conveniently recharge with minimal hiccup.   For that reason I think we should try very hard to build two sets of hardware so we can both see the fruits of our labors, and maximize usability – perhaps I mean minimize PITA issues.  
Even if the data presentation software is very primitive, I think it would be very good for you to be able to see what we get.  You'll have different insights and good ideas for how to make things better, or do more interesting things.  I also think it would be good to be able to show early results to potential collaborators if we have any promising results.  Maybe there are retired data analysts, or firmware people who might get excited by good results.
I reckon it will be quite some months before we have anything working well enough to have any insights about battery life.  But firmware work can try and get the burn rate down while hardware can look for ways to get more power into the budget, and recharging schemes.


//Mik

On Tue, Aug 12, 2014 at 7:58 AM, David Carkeek <dcarkeek@gmail.com> wrote:

I have received four of the battery samples I ordered from Ali Express. It looks like a 180mAh battery (3mm x 20mm x 30mm) fits between the PC board posts and leaves enough height for everything else. 3.6V * 0.18Ah = 666 mWh. Recall that a CR2032 button cell is 225 mAH * 3V = 0.675 mWh.

Another larger battery might be made to fit. 4.7mm x 22mm x 29mm, 300mAh * 3.7V = 1110 mWh. One of the posts would have to be cut.
One more sample needs to arrive. It might be the best one if thickness isn't an issue because it will fit between the posts. 240 mAh * 3.7V = 888mWh.

Leave a Reply