[Openec] RFC: One-Wire-Filesystem (owfs) for charging battery on XO and openec, (long)

[Frieder Ferlemann]

Hi all,

this is a proposal to use the One-Wire-Filesystem for charging the
battery on the XO and openec.

Please read this as a medium timescale proposal and not as something
to be done right now. When coming up with a new scheme one had better
present some arguments so this proposal is structured as follows:


1) what is OWFS
2) how it could be used within XO
3) why having charging algorithms within the EC itself might
   not be the best approach
4) how it could be used within a gang (multi battery) charger
5) what does it empower people to do





1) what is OWFS?
================
The One-Wire-Filesystem allows to access data on 1-wire devices
as if they were a file within a directory.

http://sf.net/projects/owfs

The ds2756 is already listed here, so parts are already in place:
http://www.owfs.org/index.php?page=standard-devices

Temperature, Current, accumulated Current, EEPROM data, etc.
could be accessed by reading/writing text files
http://owfs.sourceforge.net/shell_hints.html


2) how would it be used within XO
=================================
A task in linux user space would periodically (and/or on
notification) read the data from the appropriate files
and based on that give directions to the EC.
These directions would tell the EC what to do now and
what to do next.

The charging algorithms will basically react on entities like:
(t, I, V, R, T, I*t, dV/dt, dT/dt).
So if one of these entities leaves a specified intervall the
EC would "know" what to do next (without having to know a
bigger view) and then notify the host that it needs
updated directions.

By checking f.e. entity t (time) the EC would react
as a dumb timebased charger, monitoring dV/dt would allow
for a charge end due to voltage drop (not that this is intended),
T or dT/dt would allow for charge end due to temperature
or temperature rise (not that this is intended),
V would allow for charge end due to end voltage reached...

Note the above mentioned modes are not meant to be the
charging modes, just the direction given to the EC
so it can react autonomously for the next few seconds
or tens of seconds.

There should be no hard real time requirements on the
linux user space code.


3) why having charging algorithms within the EC itself might
   not be the best approach
============================================================
The resources within the EC are pretty low (RAM is 128 byte
idata memory, 2kByte xdata memory).
While one can it is not really a good idea to have floating
point operations on the EC. (Linux kernel does not either)
The 2kByte do not allow an elaborated charging algorithm
to use a longer history.

If charging algorithms change/improve or as new batteries
or new battery types are used this would mean updating the
EC code. (Of course updating can be done but the scheme
proposed under 2) would not need this)

There might be patent implications with the proprietary
charging algorithm (Goldpeak seems to want to patent it
but who knows whether the algorithm itself is not covered
by another patent). If the charging algorithm resides
in linux user space it can be exchanged quickly.
It would f.e. be no fun to change an algorithm on the EC
that has been converted from floating point to integer
arithmetic for another algorithm. Linux user space code
on the other hand could be a "quickly moving target".


4) how it could be used within a gang (multi battery) charger
=============================================================
If the battery data (and the charger) is accessed/controled
via OWFS then the _same_ algorithms could be used both
on the XOs and on the gang charger!
The gang charger will need to know about more batteries but
basicalle the software for the gang charger could be built
from the _same_ source as (linux user space) charging code
on the EC!)

So if the charging data would f.e. be fed into a database
on the school server there are inherently have no problems
with having to keep around two different interfaces.


5) what does it empower people to do
====================================
Well you could run the charging code on _any_ linux system which
there is one-wire-filesystem support for.

The adapter can be as simple as an RS232 connector and a
few diodes/resistors or be an off-the-shelf USB to One-Wire adapter.

One example: If you to develop/evaluate a charging algorithm
and want to do so in a larger scale, you could implement the
algorithm on a linux PC, connect a few resistors/transistors
controlling charge/discharge current to the parallel port
of the PC and give it a go.
You can evaluate on _several_ cells (and eventually several
algorithms, or different load profiles) at a time.
(This could be a nice subject for several diploma theses).

Each cell would have its own ds2576 connected to it so you
would need _much_ less XO battery packs:)


Another example: Also (probably not a good idea) of course
the XO or the school-server itself could be controlling
the gang charger as well...


Greetings,

Frieder