connecting batteries in parallel or series, myth and theory

[krw]

HAH!

I have NEVER seen Rev 1.0 firmware in a production device. More
typically it is 3 or above with a page ot two of change history at the
start of the source code.

I have, but everyone knows that programmers count from zero. ;-)

 

[[email protected]]

|
| [email protected] wrote:
|>
|> |
|> | [email protected] wrote:
|> |>
|> |> | On Wed, 10 Sep 2008 12:58:16 -0400, "TWayne" <[email protected]>
|> |> | wrote:
|> |> |
|> |> |>> krw wrote:
|> |> |>>>
|> |> |>>> In article <[email protected]>, [email protected]
|> |> |>>> says...
|> |> |>>>>> In article <[email protected]>, phil-news-
|> |> |>>>>> [email protected] says...
|> |> |>>>>>>> In article <[email protected]>,
|> |> |>>>>>>> [email protected] says...
|> |> |>>>>>>>> In alt.engineering.electrical Ken Maltby
|> |> |>>>>>>>>
|> |> |>...
|> |> |>>... You don't
|> |> |>> 'improve' firmware for modern electronics. It has to be written
|> |> |>> exactly one way, to perform the job at hand.
|> |> |>
|> |> |>Wow; all that experience and you can still say that. Woof! How many
|> |> |>times have you seen the same hardware with different functions and uses?
|> |> |>All you change to get from one to another is ... wait for it ... the
|> |> |>firmware! Careful; if you say never, you're either blind &
|> |> |>inexperienced or lying.
|> |> |>
|> |> |
|> |> |
|> |> | I'd say that krw, despite the fact that he and I do not get along,
|> |> | knows far more than you do about it.
|> |>
|> |> He does seem smart. Too bad he doesn't apply himself well.
|> |
|> |
|> | He is designing electronics for a living, while you just complain.
|>
|> I am designing software and firmware for a living, while you just make
|> personal attacks on people you disagree with.
|
|
| Then show us some software for the Haris/Intersil FIR filters I
| posted.

The software I develop that is not proprietary is released under BSD, LGPL,
or GPL licensing in the usual places. Sorry, no DSP software in there.

 

[[email protected]]

|
| [email protected] wrote:
|>
|> |
|> | Then show us some software for the Haris/Intersil FIR filters I
|> | posted.
|>
|> The software I develop that is not proprietary is released under BSD, LGPL,
|> or GPL licensing in the usual places. Sorry, no DSP software in there.
|
|
| I didn't think you could handle it.

I already did handle it.


| As far a writing firmware, I have written disassemblers for older
| microprocessors, extracted the data form the masked ROM, disassembled it
| and modified it. I reverse engineered the circuit with data from
| printed databooks, and hand drew schematics to identify all the
| addresses, then commented the disassembled code.

Fine.


| On project was for a intelligent disk drive, so I wrote the
| disassembled file to the disk in the drive I was disassembling the
| firmware. I have used a sector editor to write and modify progams in
| machine language, as well. Not assmbler, or a HLL.

Fine.


| That was shared, long before BSD, LGPL, or GPL licensing. It was so
| long ago that the disks are no longer readble.

So no one can read it. How sad.

 

[[email protected]]

| Wow; all that experience and you can still say that. Woof! How many
| times have you seen the same hardware with different functions and uses?
| All you change to get from one to another is ... wait for it ... the
| firmware! Careful; if you say never, you're either blind &
| inexperienced or lying.

He can't possibly grok that concept.

 

[[email protected]]

|
| |>> krw wrote:
|>>>
|>>> In article <[email protected]>, [email protected]
|>>> says...
|>>>>> In article <[email protected]>, phil-news-
|>>>>> [email protected] says...
|>>>>>>> In article <[email protected]>,
|>>>>>>> [email protected] says...
|>>>>>>>> In alt.engineering.electrical Ken Maltby
|>>>>>>>>
|> ...
|>>... You don't
|>> 'improve' firmware for modern electronics. It has to be written
|>> exactly one way, to perform the job at hand.
|>
|> Wow; all that experience and you can still say that. Woof! How many
|> times have you seen the same hardware with different functions and uses?
|> All you change to get from one to another is ... wait for it ... the
|> firmware! Careful; if you say never, you're either blind & inexperienced
|> or lying.
|
| It was not I who "wrote" the tiny part of "Michael A. Terrell"'s post
| that you quoted. Nor did any of the others your posting software
| listed.

It looks like he got the header quoting wrong. It should at the end have
stated that Michael A. Terrell (M.A.T.) wrote that. I double checked and
saw MAT's post to see that it appears he really did (though I did not trace
the posting path to be sure it wasn't forged by someone trying to make him
look bad).


| There are some things that can lend themselves to "modding"
| via a modified firmware, but it is highly unlikely that "phil-news-
| nospam" has gone from clueless about battery maintenance, at
| the beginning of this thread - to being able to "improve" the basic
| charging algorithms and sophisticated monitoring routines
| imbedded in today's charge controllers. Even modding the
| firmware of a DVD drive to be region free and changing speeds
| in the media tables, requires a detailed understanding of how the
| processing is implemented, not just the spec sheet data for the
| ICs involved.

Remember, I'm the one that ASKED about battery maintenance. Only a few people
offered genuine clues. The rest, like MAT and KRW, offered nothing or wasted
time making personal attacks.

Once I do understand exactly what is involved in battery maintenance, then
I will be able to program firmware or hostware to manage it. It sure seems
to be that _this_ place is not a place to learn anything.


| This is a guy who wouldn't have the slightest idea how to set
| the options of a modern charge controller, to match a particular
| battery setup. He had no understanding of the impacts of the
| physical construction, chemistry, operational environment, or
| any other pertinent factor, and yet he now claims to be ready
| to improve on the firmware developed by the makers of the
| devices.

Once I do know the battery related issues, then yes, I will be able to apply
that to fireware because I already have the programming and system hardware
knowledge to do that. It's the battery maintenance physics I'm still trying
to learn.


| You will run into this kind of egotist, all the time in Internet
| postings, it is foolish to play their games, after they have
| exposed their true nature.

You have some difficulty in understanding programming, it seems. One does NOT
need to learn the science of what is to be controlled before learning to do the
programming to control it. I already have the programming skills. This, like
any other project, involves combining the ALREADY EXISTING PROGRAMMING SKILLS
with the science of the application (in this case, batteries) and then it can
be done. So I am _ready_ as soon as I know the battery science. And based on
what information is available now, it sure appears that a lot of that is going
to have to be acquired through scientific experimentation. There seems to be
very very few people here who really know the subject.

I never assumed anyone here would teach it all. What I was hoping for was a
civil discussion. But until idiots like MAT and KRW leave and stay away, it
looks like such things cannot happen.

 

[[email protected]]

|
| [email protected] wrote:
|>
|> |
|> | [email protected] wrote:
|> |>
|> |> |
|> |> | Then show us some software for the Haris/Intersil FIR filters I
|> |> | posted.
|> |>
|> |> The software I develop that is not proprietary is released under BSD, LGPL,
|> |> or GPL licensing in the usual places. Sorry, no DSP software in there.
|> |
|> |
|> | I didn't think you could handle it.
|>
|> I already did handle it.
|>
|> | As far a writing firmware, I have written disassemblers for older
|> | microprocessors, extracted the data form the masked ROM, disassembled it
|> | and modified it. I reverse engineered the circuit with data from
|> | printed databooks, and hand drew schematics to identify all the
|> | addresses, then commented the disassembled code.
|>
|> Fine.
|>
|> | On project was for a intelligent disk drive, so I wrote the
|> | disassembled file to the disk in the drive I was disassembling the
|> | firmware. I have used a sector editor to write and modify progams in
|> | machine language, as well. Not assmbler, or a HLL.
|>
|> Fine.
|>
|> | That was shared, long before BSD, LGPL, or GPL licensing. It was so
|> | long ago that the disks are no longer readble.
|>
|> So no one can read it. How sad.
|
|
| Why? It was passed on to others, and who knows where it ended up?
| My copies are gone, since I never needed them again. At least I know
| how to reverse engineer a device, when needed. I also know when a
| device is hard coded inside a single IC and can not be modified. That
| is when you design something to do the job you want from scratch,
| instead of whining about being denied source code, and schematics.

Well at least I know not to demand you prove programming skills by posting the
source code of projects owned by someone else, or even projects you own that
you may prefer to keep proprietary so you can profit financially from them.
If you do decide to post anything publically under a free license, and it is
well designed and works, then the world will gain from it and you get thanks.

Having source code simplifies things. It avoids the reverse engineering.
If because of all your experience in reverse engineering hundreds or thousands
of devices, it is trivially easy for you to do, then fine. You're lucky and
and skip the effort to get source code. I'll still prefer to get source code
because it can expedite any reverse engineering that might become necessary.

 

[[email protected]]

| I have worked on everything from early tube equipment to state of the
| art DSP based telemetry equipment. I know that firmware changes how a
| device works, but you can't program in features the hardware doesn't
| support. Firmware in consumer devices is usually hard coded into ICs
| that require that you sign an NDA, and that forbids any modifications.
| The only thing you can do is design a new product or board with the
| features you want.

Whether the firmware can be reloaded or not, and whether an NDA is required
or not, depends on the manufacturer. Most do require the NDA or have other
limitations, such as no way to reload firmware. This is common for devices
so specialized they build the board, possibly even the CPU itself, and do
all the firmware development strictly for one product.

By contrast, a product I did some development for involves an ARM based
board that includes flash memory for the firmware. It can be reloaded
fairly easily, and intentionally so. The board has a JTAG port, 2 USB
ports, and even a serial port. It also has 3 POTS ports, and component
HD video ports (driven by a Phillips video chip I didn't work with).
It is intended for cable STBs in China. I built the Linux OS for it.
I did not work on the user interface. I don't read Chinese. Some of
the people I communicated with on the project did not speak English
very well. I wished I could have kept the test boards I used.


| Either put up, or shut up. If you can't find the datasheet of an IC
| online it is either obsolete, or proprietary. Track it down and see if
| it even has anything more than a few simple gates. you will find most
| of these battery related ICs to be ASIC, or Application Specific
| Integrated Circuit. That means there is nothing you can do to make
| changes, unless you steal the masks, change the layout and have new
| chips made. There are a couple IC designers on
| who do this work every day. One of them may
| be the designer of the chip in question, and would have a good laugh
| that you are going to modify their firmware.

Chances are, if I saw the specs for this IC, at least in terms of how much
RAM and ROM was on the chip, I'd be the one having a good laugh. You can
be sure I'm not going to run a power system from one IC. I'm going to do
it from a full computer which allows it to keep and analyze a large amount
of data. So I have no interest in some puny little IC.

 

[[email protected]]

| [email protected] wrote:
|>
|> | Either put up, or shut up. If you can't find the datasheet of an IC
|> | online it is either obsolete, or proprietary. Track it down and see if
|> | it even has anything more than a few simple gates. you will find most
|> | of these battery related ICs to be ASIC, or Application Specific
|> | Integrated Circuit. That means there is nothing you can do to make
|> | changes, unless you steal the masks, change the layout and have new
|> | chips made.
|>
|> Chances are, if I saw the specs for this IC, at least in terms of how much
|> RAM and ROM was on the chip, I'd be the one having a good laugh. You can
|> be sure I'm not going to run a power system from one IC. I'm going to do
|> it from a full computer which allows it to keep and analyze a large amount
|> of data. So I have no interest in some puny little IC.
|
| You might want to take a look at some of Dallas Semiconductor's
| products, some of which do provide options for dynamic reconfiguration.
| IIRC, their product line includes devices for monitoring batteries.

I'm not sure what all I would be interested in, just yet. I need to get a
better idea of what all I need to measure, and what devices are available
to do the measurements.

For example, how does one set up a computer system to measure specific gravity?
That probably requires a special battery. One way I could envision doing this
(requires being part of the battery design) is for Gray coded float device in a
narrow tube opened to the electrolyte of each cell, behind a few window. An LED
would scan the code bars of the device horizontally and the code received would
indicate the position.

There are other ways this could be done, but I would favor an optical one where
I don't need to penetrate the cell to do this. The measurement device would
have to be in place permanently, and the cell needs to remain as sealed as it
would be in normal operation. I just don't know how this can be done with any
existing batteries. I've always know specific gravity measurements to be done
manually by opening the cell cap, and closing it again when done. But this is
not something I want to implement under computer control.

What I want for any measurement device in general is just a way to feed data
to my computer system. I also want control over contacts to open and close
circuits under automated control.


| If you'd like a small footprint for your full computer, follow the link
| below for a few more ideas (block diagram, photos, descriptions).

The size of a PC is a suitable footprint. It will have its own power system.

 

[krw]

You might want to take a look at some of Dallas Semiconductor's
products, some of which do provide options for dynamic reconfiguration.
IIRC, their product line includes devices for monitoring batteries.

If you can actually buy them. Dallas and Maxim are the absolute
*pits* as suppliers. I won't even look at their products anymore.