connecting batteries in parallel or series, myth and theory

[[email protected]]

In alt.engineering.electrical [email protected] wrote:
| On Aug 22, 12:37 pm, [email protected] wrote:
|>
|> ||>
|> |> ||> |> |>
|> |> |> | Looking at the stated purpose of the paper and the "test setup" drawn
|> |> in
|> |> |> the
|> |> |> | paper it would seem that the test conditions do not match the
|> |> purpose.
|> |> |> As I
|> |> |> | understand it, in a VRLA cell the electrolyte has only limited
|> |> contact
|> |> |> with
|> |> |> | the plates. Determined by capillary action in the separator material,
|> |> |>
|> |> |> Are you confusing VRLA with AGM?
|> |> |>
|> |> |
|> |> | If I am it is due to reading this paper:
|> |> |
|> |> |http://www.battcon.com/PapersFinal2006/LandwehrlePaper2006.pdf
|> |> |
|> |> | I'll look up AGM in a minute.
|> |>
|> |> What kind of capillary action exists in VRLA?
|> |>
|> |
|> | Did you read the cite? AGM, from what I read is a Gell Cell. VR (Valve
|> | Regulated) LA is made with an absorbent plate separator, under some pressure
|> | between plate/separator/plate, and a limited amount of electrolyte.
|> | Separator materials vary. Now. I am familiar with flooded cell and gell
|> | cell, having worked with both for many years, and I have seen the insides of
|> | what I now know to have been a VRLA cell as well as Silver Zinc flooded
|> | cells in the military ( the battery shop guy was a friend of mine and showed
|> | me how to inspect, test, and repair the AgZn cells ) but my responses in
|> | this thread are extracts from certain cited sites alongside already
|> | accumulated experience. If you must question something it would help if you
|> | actually read the cited paper before asking the question. That way you might
|> | not need to ask.
|>
|> AGM is absorbent glass mat, not gel cell.
|>
|> VRLA is a class of batteries (includes AGM and gel cell) that includes a
|> regulated valve to control the gas release at a certain pressure.
|
| Yes, and if they do gas off, the lost material is no longer there to
| recombine and the batteries capacity is diminished.

Yes, that is a problem. Replenishment is needed. Hopefully there is no lead
in that gas. Loss of hydrogen, oxygen, and sulfer can be dealt with in a
flooded cell. Both gel cell and AGM make this replenishment impossible.
I guess that is an acceptable tradeoff for the benefits they provide for
certain usages.

 

[Me]

So. What kind of capillary action exists in a VRLA? HeH.

BTW, I am seing in literature the term Gell Cell and AGM being used
interchangeably. I will grant that the specific technology is quite
different, but ----.

-

Don, your conversing with real Lame'rs here, on this subject.
Not professionals by any stretch of the imagination, and
[email protected] is the worst of them all.

Me

 

[krw]

Yes. There is also an alt.engineering.explosives. This thread has gone to
the electrical engineering group forever it seems. I am not a usenet newby,
I always read the crossposting list. The poster Me, and the Bruce I am
refering to, are retired powdermen as well as other engineering
accomplishments. I don't see anything unusual in engineers having multiple
talents. Every Engineer I know is an engineer first with some specialty
field of interest second. We all took the same basic Engineering courses in
whatever schools we went to. How 'bout you? Did you take all the required
basic courses before you broke out in your junior or senior year into the
Electrical specialty? Did your school have an "EPICS" sequence? "Engineering
Practices Introductory Course Sequence" consisting of multiple seminar and
public as well as recorded speaking on your research projects as well as
other "confidence building" and practical subjects such as FORTRAN for
Engineers etc? But then maybe I am insane and don't realize it. Maybe I
dreamed all this and have been deluding myself for the past 40 years.

Certainly all engineering colleges are not the same. We didn't have
any required inter-diciplinary courses. Only the math, physics, and
chemistry was common to all engineers. That changed from a heavy
cross-pollination a few years earlier, mainly to reduce the
graduation from five years (fewer then 10% made it through in four
years) to four (normal 120 semester hours). They couldn't eliminate
the social science or humanities requirements and it didn't make
sense to offer an EE degree with no EE courses, so the only thing
left was TAM, statics/dynamics, etc.

 

[Me]

HeH. Good to see you here. I "am" being nice about it here. Quite unlike I
treat the kewel dewdz on our "now pretty quiet due to national security
concerns" group. A little stimulation of the mind comes in handy to us old
folks though.

I'm wondering if the Bruce in Alaska here is the same one that posted now
and again on a.e.e as well.

Looks to "Me" that it is the same guy. We have chat'ed, in the past,
about energetics and Remote Living.

Me

 

[[email protected]]

In alt.energy.homepower [email protected] wrote:
|> In article <[email protected]>,
|>
|> > So. What kind of capillary action exists in a VRLA? HeH.
|>
|> > BTW, I am seing in literature the term Gell Cell and AGM being used
|> > interchangeably. I will grant that the specific technology is quite
|> > different, but ----.
|>
|> > -
|>
|> Don, your conversing with real Lame'rs here, on this subject.
|> Not professionals by any stretch of the imagination, and
|> [email protected] is the worst of them all.
|>
|> Me
|
| Yeah, but I'm still right.

Heads or tails? You can be right half the time. Means nothing about an
ability to know the future.

You might be right that the best installation of batteries will not have
any batteries in parallel. But you really only know that by chance. You
don't know any of the science behind why (you only know reasons).

This "best" is only in terms of the ultimate technical installation in the
ideal circumstance (such as no limit on space or finances). You do not
have the knowledge to select a "best fit" system in circumstances that would
dictate something different.

You have stated more than once you believe I have asked about this in search
of someone to justify a desire you _think_ I have to wire up batteries in
parallel. The truth is I was looking for technical/scientific documentation
to justify _any_ way to wire up batteries. What I found is that there is no
one simple answer.

All that you have posted basically summarizes into one simple point: You
vote for avoiding parallel batteries. There's no other useful information
in your posts. A count of how many people would avoid parallel batteries
is above 1 (so you are not the only one). But that is not scientific info.
It serves nothing more than to be a suggestion to consider some other scheme
besides parallel. But that was the point of why I asked about this in the
first place (e.g. the count was already above 1 before I ever heard of you).

 

[[email protected]]

In alt.energy.homepower [email protected] wrote:

| God, you're funny. The only reason you asked is in the hope that
| someone will hold your hand and tell you it's ok to use parallel
| batteries so you can feel good about making a choice that is stupid.

People might believe you if you were in a position to know. You aren't.
So they know you just make stuff up.


| Remember this:
|
| "This is not a problem for occasional discharges, or for more frequent
| discharges that are taken to completion. It can become an issue,
| however for a system that is designed for long discharges, but is
| subjected to frequent shallow discharges. In this case, the high rate
| battery will receive the brunt of the cycling duty, and may age
| prematurely as a result."
|
| This is the kind of system used in home power situations.

But you still fail to describe the science behind this. Of course, I'm not
in a real position to know if you understand the science or not. If you do,
then you must have some reason for not saying it.

 

[[email protected]]

In alt.engineering.electrical [email protected] wrote:
| On Aug 25, 4:22 pm, [email protected] wrote:
|> In alt.energy.homepower [email protected] wrote:
|>
|> | God, you're funny. The only reason you asked is in the hope that
|> | someone will hold your hand and tell you it's ok to use parallel
|> | batteries so you can feel good about making a choice that is stupid.
|>
|> People might believe you if you were in a position to know. You aren't.
|> So they know you just make stuff up.
|
| I most certainly did not make up
|
| www.battcon.com/PapersFinal2002/McDowallPaper2002.pdf

No, but you do not grok the science behind it. You, instead, look for the
conclusions and then assume it applies to every case.


| This paper makes it quite clear that parallel batteries for a home
| power system is not suitable.

Only for home systems where the paralleling is done the way they described.


| So unless you intend to run a float system for home power (the gods
| know you sound stupid enough to try) the paragraph below describes
| what you will be building.

Since you don't grok the science, you wouldn't grok the alternatives.
You'll have to wait for the PDF paper to come out.


|> | Remember this:
|> |
|> | "This is not a problem for occasional discharges, or for more frequent
|> | discharges that are taken to completion. It can become an issue,
|> | however for a system that is designed for long discharges, but is
|> | subjected to frequent shallow discharges. In this case, the high rate
|> | battery will receive the brunt of the cycling duty, and may age
|> | prematurely as a result."
|> |
|> | This is the kind of system used in home power situations.
|>
|> But you still fail to describe the science behind this. Of course, I'm not
|> in a real position to know if you understand the science or not. If you do,
|> then you must have some reason for not saying it.
|
| The reason for not saying it is that you will call me a liar and deny
| that the reasons are valid.

You are a liar and your reasons are not valid!

There. Over and done with. So there's nothing new to fear. Now go ahead
and post the science you think you know.


| The article at
|
| www.battcon.com/PapersFinal2002/McDowallPaper2002.pdf
|
| says it all.

It might be all there is in your small world.

And, BTW, where in the paper does the author mention home power systems?
Search for "home".


| If you don't like the paper or its conclusions about parallel
| batteries in a system that is designed for long discharges, but is
| subjected to frequent shallow discharges, I suggest that you take it
| up with the author, Jim McDowall, and tell him he as a fool.

The fool is the one who misapplies what this paper says. For example, it
discusses the discharge of one string into another. But this is clearly a
case of the strings simply being hot wired to each other as the means to
parallel them. He didn't cover the case of strings wires in parallel with
isolation rectifiers.


| I did not write the paper. But I did tell you the same thing.

No, you only told me what the paper concluded, while thinking it applied to
all of the designs I'm considering (it only applies to _some_ of them).

 

[Johnny B Good]

In alt.engineering.electrical Eric <[email protected]> wrote:

| I seem to recall a problem with batteries on submarines if they come in
| contact with sea water there can be H2S produced, bad news in a sub.

Not H2S but chlorine gas due to the reaction of sulphuric acid with the
salt in sea water.

 

[Archimedes' Lever]

So, the Schottky diodes in your computer's power supply are signal
diodes?

They are very fast and are used in small signal applications quite
often.

 

[[email protected]]

| In article <[email protected]>, [email protected]
| says...
|>
|> | The design of sophisticated micro-processor controlled
|> | charge controllers/chargers is a little beyond my pay
|> | grade. Before attempting to create your own you might
|> | thoroughly research what is available, there may be one that
|> | is already operating in a similar manner. (If not you can
|> | risk your own battery bank for a year or two testing that
|> | idea out, then post here with your results. )
|>
|> Unfortunately, when it comes to the firmware controls, it's hard to get real
|> information to make judgements. Most people don't know programming and so
|> much accept whatever the manufacturer decides to put in there. That means
|> for people like me, the information I want (the source code of the firmware)
|> isn't going to be available.
|>
| Do you demand circuit diagrams for every IC you use too? GL1?
| Doping profiles? In this case there is very little difference
| between "hardware" and "firmware".

I certainly at least need the pinouts and what the IC does. Circuit diagrams
are a common way to explain this succinctly.

Firmware, in particular, is highly subject to "bugs" and frequently needs to
be upgraded. The reason I want access at this level is because I believe I
may be able to make things smarter and function better in a much wider range
of conditions, including an understanding of conditions not directly measurable
that would only be know by the record of past measurements. Very little
firmware programming in any industry gets this sophisticated.

 

[krw]

| In article <[email protected]>, [email protected]
| says...
|>
|> | The design of sophisticated micro-processor controlled
|> | charge controllers/chargers is a little beyond my pay
|> | grade. Before attempting to create your own you might
|> | thoroughly research what is available, there may be one that
|> | is already operating in a similar manner. (If not you can
|> | risk your own battery bank for a year or two testing that
|> | idea out, then post here with your results. )
|>
|> Unfortunately, when it comes to the firmware controls, it's hard to get real
|> information to make judgements. Most people don't know programming and so
|> much accept whatever the manufacturer decides to put in there. That means
|> for people like me, the information I want (the source code of the firmware)
|> isn't going to be available.
|>
| Do you demand circuit diagrams for every IC you use too? GL1?
| Doping profiles? In this case there is very little difference
| between "hardware" and "firmware".

I certainly at least need the pinouts and what the IC does. Circuit diagrams
are a common way to explain this succinctly.

Do you demand circuit diagrams for your televisions too? Radios?
What do you do if there is an ASIC in there? This is a silly demand.

Firmware, in particular, is highly subject to "bugs" and frequently needs to
be upgraded. The reason I want access at this level is because I believe I
may be able to make things smarter and function better in a much wider range
of conditions, including an understanding of conditions not directly measurable
that would only be know by the record of past measurements. Very little
firmware programming in any industry gets this sophisticated.

Hardware and firmware are no different, other than firmware can (not
necessarily may) be updated. Other than that, there is no
difference. he device manufacturer may have damned good reasons to
NOT let you play and is certainly under no obligation to do so (I
wouldn't).

 

[[email protected]]

| In article <[email protected]>, phil-news-
| [email protected] says...
|> | In article <[email protected]>, [email protected]
|> | says...
|> |>
|> |> | The design of sophisticated micro-processor controlled
|> |> | charge controllers/chargers is a little beyond my pay
|> |> | grade. Before attempting to create your own you might
|> |> | thoroughly research what is available, there may be one that
|> |> | is already operating in a similar manner. (If not you can
|> |> | risk your own battery bank for a year or two testing that
|> |> | idea out, then post here with your results. )
|> |>
|> |> Unfortunately, when it comes to the firmware controls, it's hard to get real
|> |> information to make judgements. Most people don't know programming and so
|> |> much accept whatever the manufacturer decides to put in there. That means
|> |> for people like me, the information I want (the source code of the firmware)
|> |> isn't going to be available.
|> |>
|> | Do you demand circuit diagrams for every IC you use too? GL1?
|> | Doping profiles? In this case there is very little difference
|> | between "hardware" and "firmware".
|>
|> I certainly at least need the pinouts and what the IC does. Circuit diagrams
|> are a common way to explain this succinctly.
|
| Do you demand circuit diagrams for your televisions too? Radios?
| What do you do if there is an ASIC in there? This is a silly demand.

Your reading comprehension skills seem to be lacking. You skills in coming
up with analogies are also rather poor. If you read more carefully and do
some thinking as you read, you can see I say that it is the pinouts that are
what is needed. The circuit diagram happens to be a common way to explain
the pinouts of ICs, and that's what people often work with. If you had ever
built an IC based project, you'd know this, and would have been able to
compensate for your poor reading skills.

The TV equivalent to "pinouts of an IC" are the video/audio input/output
jacks. And it is the pinouts that I need.

If you knew anything about electrical engineering, you'd understand this.

If you could read better, you'd have know I never asked for circuit diagrams
and only referenced them as a way that is done ... for ICs ... I never said
this for TVs.


|> Firmware, in particular, is highly subject to "bugs" and frequently needs to
|> be upgraded. The reason I want access at this level is because I believe I
|> may be able to make things smarter and function better in a much wider range
|> of conditions, including an understanding of conditions not directly measurable
|> that would only be know by the record of past measurements. Very little
|> firmware programming in any industry gets this sophisticated.
|
| Hardware and firmware are no different, other than firmware can (not
| necessarily may) be updated. Other than that, there is no
| difference. he device manufacturer may have damned good reasons to
| NOT let you play and is certainly under no obligation to do so (I
| wouldn't).

You wouldn't (let people modify firmware) just because you have a major
attitude problem. Ironically, firmware you might develop is what would
most likely need to be modified ... a lot ... or replaced entirely.

Companies that put a lot of effort into making firmware that works really
well don't want to let their competition see how they do that. If they
really do make good firmware, then there's no issue. Unfortunately, a lot
of companies are as full of themselves as you are and _think_ their firmware
is really hot stuff when in reality it is just crap. People who know how
to develop firmware know they can do better. They just need the hardware
interface details to do it. And they need the firmware code itself if they
intent to replace only the parts that are broken and keep the parts that
work OK (for firmware that isn't really total crap, but can use a little
improvement).

 

[krw]

| In article <[email protected]>, phil-news-
| [email protected] says...
|> | In article <[email protected]>, [email protected]
|> | says...
|> |>
|> |> | The design of sophisticated micro-processor controlled
|> |> | charge controllers/chargers is a little beyond my pay
|> |> | grade. Before attempting to create your own you might
|> |> | thoroughly research what is available, there may be one that
|> |> | is already operating in a similar manner. (If not you can
|> |> | risk your own battery bank for a year or two testing that
|> |> | idea out, then post here with your results. )
|> |>
|> |> Unfortunately, when it comes to the firmware controls, it's hard to get real
|> |> information to make judgements. Most people don't know programming and so
|> |> much accept whatever the manufacturer decides to put in there. That means
|> |> for people like me, the information I want (the source code of the firmware)
|> |> isn't going to be available.
|> |>
|> | Do you demand circuit diagrams for every IC you use too? GL1?
|> | Doping profiles? In this case there is very little difference
|> | between "hardware" and "firmware".
|>
|> I certainly at least need the pinouts and what the IC does. Circuit diagrams
|> are a common way to explain this succinctly.
|
| Do you demand circuit diagrams for your televisions too? Radios?
| What do you do if there is an ASIC in there? This is a silly demand.

Your reading comprehension skills seem to be lacking. You skills in coming
up with analogies are also rather poor. If you read more carefully and do
some thinking as you read, you can see I say that it is the pinouts that are
what is needed.

NO, your cognitive skills are nonexistent. Pinouts do no good if
you have no idea what's inside the black box and cannot buy a new
one (i.e. an ASIC). Much of the world is like that, you know.

The circuit diagram happens to be a common way to explain
the pinouts of ICs, and that's what people often work with.

....and in most cases it would do you no good if you had it. You
have no idea what's in the black box and can't buy another black
box, if you did.

If you had ever
built an IC based project, you'd know this, and would have been able to
compensate for your poor reading skills.

You are clueless. We left the 74xx world decades ago.

The TV equivalent to "pinouts of an IC" are the video/audio input/output
jacks. And it is the pinouts that I need.

You have no idea what's inside the box and couldn't do anything with
it if you had it.

If you knew anything about electrical engineering, you'd understand this.

My pinky knows more about this subject than you ever will, dumbshit.
I design the stuff for a living (and have for the past 35 years).

If you could read better, you'd have know I never asked for circuit diagrams
and only referenced them as a way that is done ... for ICs ... I never said
this for TVs.

I used TVs as a *simple* example, dumbshit. Circuit diagrams will
do no good if you have no clue what the black box is. If *you* knew
anything about the subject you wouldn't be making such a fool of
yourself. Yes, a schematic will help *me* as the designer. It
wouldn't to shit for me as a user. "No user serviceable parts
inside."

|> Firmware, in particular, is highly subject to "bugs" and frequently needs to
|> be upgraded. The reason I want access at this level is because I believe I
|> may be able to make things smarter and function better in a much wider range
|> of conditions, including an understanding of conditions not directly measurable
|> that would only be know by the record of past measurements. Very little
|> firmware programming in any industry gets this sophisticated.
|
| Hardware and firmware are no different, other than firmware can (not
| necessarily may) be updated. Other than that, there is no
| difference. he device manufacturer may have damned good reasons to
| NOT let you play and is certainly under no obligation to do so (I
| wouldn't).

You wouldn't (let people modify firmware) just because you have a major
attitude problem. Ironically, firmware you might develop is what would
most likely need to be modified ... a lot ... or replaced entirely.

No, I wouldn't let you modify the firmware because I'm smart enough
to avoid additional work (read costs) for my legal and
service/waranty departments. There is no advantage to giving users
this information and a *lot* of pitfalls. You really are stupid.

Companies that put a lot of effort into making firmware that works really
well don't want to let their competition see how they do that. If they
really do make good firmware, then there's no issue. Unfortunately, a lot
of companies are as full of themselves as you are and _think_ their firmware
is really hot stuff when in reality it is just crap. People who know how
to develop firmware know they can do better. They just need the hardware
interface details to do it. And they need the firmware code itself if they
intent to replace only the parts that are broken and keep the parts that
work OK (for firmware that isn't really total crap, but can use a little
improvement).

You really don't have a clue.

 

[[email protected]]

| In article <[email protected]>, [email protected]
| says...
|> | In article <[email protected]>, phil-news-
|> | [email protected] says...
|> |> | In article <[email protected]>, [email protected]
|> |> | says...
|> |> |>
|> |> |> | The design of sophisticated micro-processor controlled
|> |> |> | charge controllers/chargers is a little beyond my pay
|> |> |> | grade. Before attempting to create your own you might
|> |> |> | thoroughly research what is available, there may be one that
|> |> |> | is already operating in a similar manner. (If not you can
|> |> |> | risk your own battery bank for a year or two testing that
|> |> |> | idea out, then post here with your results. )
|> |> |>
|> |> |> Unfortunately, when it comes to the firmware controls, it's hard to get real
|> |> |> information to make judgements. Most people don't know programming and so
|> |> |> much accept whatever the manufacturer decides to put in there. That means
|> |> |> for people like me, the information I want (the source code of the firmware)
|> |> |> isn't going to be available.
|> |> |>
|> |> | Do you demand circuit diagrams for every IC you use too? GL1?
|> |> | Doping profiles? In this case there is very little difference
|> |> | between "hardware" and "firmware".
|> |>
|> |> I certainly at least need the pinouts and what the IC does. Circuit diagrams
|> |> are a common way to explain this succinctly.
|> |
|> | Do you demand circuit diagrams for your televisions too? Radios?
|> | What do you do if there is an ASIC in there? This is a silly demand.
|>
|> Your reading comprehension skills seem to be lacking. You skills in coming
|> up with analogies are also rather poor. If you read more carefully and do
|> some thinking as you read, you can see I say that it is the pinouts that are
|> what is needed.
|
| NO, your cognitive skills are nonexistent. Pinouts do no good if
| you have no idea what's inside the black box and cannot buy a new
| one (i.e. an ASIC). Much of the world is like that, you know.

That is NOT universally true. In many cases it makes sense, such as if the
IC is an array of gates. In other cases, the internal details to not need
to be know, such as a CPU. If the pinouts are properly and completely
described, the internals don't need to be known. I'm sure even YOU do not
insist on the internals of a CPU, which often does include microcode style
firmware as well (usually not re-programmable).

Remember, it was YOU who said it was silly to ask for details, and now you
reverse course and insist that the details are necessary. The truth is
that "it depends" (I'd love to trademark that term).


|> The circuit diagram happens to be a common way to explain
|> the pinouts of ICs, and that's what people often work with.
|
| ...and in most cases it would do you no good if you had it. You
| have no idea what's in the black box and can't buy another black
| box, if you did.

Again, you are showing your ignorance. The fact is that the pinouts of many
ICs are _simply_ shown via a circuit diagram that has pin numbers. That is
for many ICs a succinct, yet complete, description of what it does.


|> If you had ever
|> built an IC based project, you'd know this, and would have been able to
|> compensate for your poor reading skills.
|
| You are clueless. We left the 74xx world decades ago.

I was there, then. You obviously blinked and missed it.


|> The TV equivalent to "pinouts of an IC" are the video/audio input/output
|> jacks. And it is the pinouts that I need.
|
| You have no idea what's inside the box and couldn't do anything with
| it if you had it.

One does not need to know what is in the box if its function is clearly
described, and the semantics of the connections are also clearly described.
It doesn't take much description for obvious devices like a TV. And yet
you seem to think that can't be done?


|> If you knew anything about electrical engineering, you'd understand this.
|
| My pinky knows more about this subject than you ever will, dumbshit.
| I design the stuff for a living (and have for the past 35 years).

And yet you never saw an IC described by its circuit diagram labeled with
pin numbers?


|> If you could read better, you'd have know I never asked for circuit diagrams
|> and only referenced them as a way that is done ... for ICs ... I never said
|> this for TVs.
|
| I used TVs as a *simple* example, dumbshit. Circuit diagrams will
| do no good if you have no clue what the black box is. If *you* knew
| anything about the subject you wouldn't be making such a fool of
| yourself. Yes, a schematic will help *me* as the designer. It
| wouldn't to shit for me as a user. "No user serviceable parts
| inside."

Well, you got something right: a TV _is_ a simple example. Too bad it is
not an applicable example when compared to certain types of IC.

In terms of the complexity of what is inside a TV, even a TV of 20, 30, or
even 40 years ago, without having to consider today's CPU driven TVs, there
is a LOT in there. Yet the connections are simple, basic, and well defined:

1. Antenna in (sometimes more than one)
2. Audio/Video in (sometimes in various forms: composite, component, HDMI)
3. Audio/Video out (exists on premium/prosumer/pro models)
4. Headphone jack (did you know it usually cuts off speakers when plugged in)

One does not need to know the circitry inside to understand what all these
connections do. Even YOU can understand this. You just need to apply this
in your discussions and upgrade your analogies.

A CPU is another example that is more complex on the connections. This will
also depend on how much of a computer system is integrated, such as an "SoC"
(System on a Chip). The classic connections include bus cycle timings, strobes
for various data lines, as well as memory address lines and data in/out which
are sometimes combined (and almost always buffered in this case) or are kept
separate (for faster unbuffered).


|> |> Firmware, in particular, is highly subject to "bugs" and frequently needs to
|> |> be upgraded. The reason I want access at this level is because I believe I
|> |> may be able to make things smarter and function better in a much wider range
|> |> of conditions, including an understanding of conditions not directly measurable
|> |> that would only be know by the record of past measurements. Very little
|> |> firmware programming in any industry gets this sophisticated.
|> |
|> | Hardware and firmware are no different, other than firmware can (not
|> | necessarily may) be updated. Other than that, there is no
|> | difference. he device manufacturer may have damned good reasons to
|> | NOT let you play and is certainly under no obligation to do so (I
|> | wouldn't).
|>
|> You wouldn't (let people modify firmware) just because you have a major
|> attitude problem. Ironically, firmware you might develop is what would
|> most likely need to be modified ... a lot ... or replaced entirely.
|
| No, I wouldn't let you modify the firmware because I'm smart enough
| to avoid additional work (read costs) for my legal and
| service/waranty departments. There is no advantage to giving users
| this information and a *lot* of pitfalls. You really are stupid.

My firmware would have far fewer bugs than your firmware. THIS is the kind
of thing that helps _avoid_ tech support costs and even legal issues.


|> Companies that put a lot of effort into making firmware that works really
|> well don't want to let their competition see how they do that. If they
|> really do make good firmware, then there's no issue. Unfortunately, a lot
|> of companies are as full of themselves as you are and _think_ their firmware
|> is really hot stuff when in reality it is just crap. People who know how
|> to develop firmware know they can do better. They just need the hardware
|> interface details to do it. And they need the firmware code itself if they
|> intent to replace only the parts that are broken and keep the parts that
|> work OK (for firmware that isn't really total crap, but can use a little
|> improvement).
|
| You really don't have a clue.

I have far more clues about firmware and programming than you have. I have
never designed a circuit that interfaces to a CPU chip. But I have done
sub-instruction-set microcode programming, which does involve knowing how
the hardware is organized ... before there were ever such things as FPGAs.

 

[[email protected]]

| Wouldn't you love to see Phil try to learn how a DSP or FIR filter
| works? I had the full schematics of the Microdyne RCB-2000 on my bench
| All 38 size 'D' drawings. A lot of the testing was done with a Fireberd
| BER test set. That is something you won't find in a ham's shack. I had
| over a half million dollars worth of test equipment on my bench, and the
| product line had about 5 million dollars worth of test equipment.

Try to learn? I've done it in software/firmware before. So what if I have
never designed a DSP chip.


| Large sections were a half dozen or more blocks of programmable logic
| connected together. It required multiple programming interfaces and
| programs. The computer on my bench had three parallel ports, and I
| could have used a half dozen more, on top of that. I had a Needham's
| EMP-20 to program the CPU for the front panel interface, and a
| connection to the engineering server to download all the versions of
| firmware written for different customers. and rev levels.

Did you write actual assembly language code, or just push a few drag and
drop blocks across the screen.


| Phil is a hopeless idiot. He has no clue what damage his 'custom
| firmware' could do to a piece of modern electronics. You don't
| 'improve' firmware for modern electronics. It has to be written exactly
| one way, to perform the job at hand.

Look who's talking.

And clueless about firmware, at that. It is NOT true at all that there is
only one way to do things. Of course, there are WRONG ways to do things
that can do damage in many cases (for example voltage control). If you
think I don't know that, you aren't thinking (but I've known this for quite
a while, as it showed in some of your earliests posts).

But it is absolutely true that there _is_ more than one way to do things.
And this is _especially_ true for some of the crapware programmed into many
consumer electronics these days (like in most TVs, cable STBs, etc).

 

[krw]

| In article <[email protected]>, [email protected]
| says...
|> | In article <[email protected]>, phil-news-
|> | [email protected] says...
|> |> | In article <[email protected]>, [email protected]
|> |> | says...
|> |> |>
|> |> |> | The design of sophisticated micro-processor controlled
|> |> |> | charge controllers/chargers is a little beyond my pay
|> |> |> | grade. Before attempting to create your own you might
|> |> |> | thoroughly research what is available, there may be one that
|> |> |> | is already operating in a similar manner. (If not you can
|> |> |> | risk your own battery bank for a year or two testing that
|> |> |> | idea out, then post here with your results. )
|> |> |>
|> |> |> Unfortunately, when it comes to the firmware controls, it's hard to get real
|> |> |> information to make judgements. Most people don't know programming and so
|> |> |> much accept whatever the manufacturer decides to put in there. That means
|> |> |> for people like me, the information I want (the source code of the firmware)
|> |> |> isn't going to be available.
|> |> |>
|> |> | Do you demand circuit diagrams for every IC you use too? GL1?
|> |> | Doping profiles? In this case there is very little difference
|> |> | between "hardware" and "firmware".
|> |>
|> |> I certainly at least need the pinouts and what the IC does. Circuit diagrams
|> |> are a common way to explain this succinctly.
|> |
|> | Do you demand circuit diagrams for your televisions too? Radios?
|> | What do you do if there is an ASIC in there? This is a silly demand.
|>
|> Your reading comprehension skills seem to be lacking. You skills in coming
|> up with analogies are also rather poor. If you read more carefully and do
|> some thinking as you read, you can see I say that it is the pinouts that are
|> what is needed.
|
| NO, your cognitive skills are nonexistent. Pinouts do no good if
| you have no idea what's inside the black box and cannot buy a new
| one (i.e. an ASIC). Much of the world is like that, you know.

That is NOT universally true. In many cases it makes sense, such as if the
IC is an array of gates. In other cases, the internal details to not need
to be know, such as a CPU. If the pinouts are properly and completely
described, the internals don't need to be known. I'm sure even YOU do not
insist on the internals of a CPU, which often does include microcode style
firmware as well (usually not re-programmable).

I had the internals of the CPU. I was on the design team. ;-)

Remember, it was YOU who said it was silly to ask for details, and now you
reverse course and insist that the details are necessary. The truth is
that "it depends" (I'd love to trademark that term).

The details of the circuit are needed by the designer of the widget,
yes. They are *NOT* needed by the user of the widget and are not
generally available (anyone making this level of detail available to
users is an idiot).

|> The circuit diagram happens to be a common way to explain
|> the pinouts of ICs, and that's what people often work with.
|
| ...and in most cases it would do you no good if you had it. You
| have no idea what's in the black box and can't buy another black
| box, if you did.

Again, you are showing your ignorance. The fact is that the pinouts of many
ICs are _simply_ shown via a circuit diagram that has pin numbers. That is
for many ICs a succinct, yet complete, description of what it does.

Wrong. The pin number is *never* sufficient. You'e stuck in the
7400 days.

|> If you had ever
|> built an IC based project, you'd know this, and would have been able to
|> compensate for your poor reading skills.
|
| You are clueless. We left the 74xx world decades ago.

I was there, then. You obviously blinked and missed it.

Your cognitive disorder is showing showing again. The rest of the
world (we) left that era decades back. You're still stuck in it.

|> The TV equivalent to "pinouts of an IC" are the video/audio input/output
|> jacks. And it is the pinouts that I need.
|
| You have no idea what's inside the box and couldn't do anything with
| it if you had it.

One does not need to know what is in the box if its function is clearly
described, and the semantics of the connections are also clearly described.
It doesn't take much description for obvious devices like a TV. And yet
you seem to think that can't be done?

It can't. By you. You don' thave the tools, knowledge, or
information. There is no reason for the manufacturer to give you
the latter, even if you had the first two, and *many* reasons to not
publish that information.

|> If you knew anything about electrical engineering, you'd understand this.
|
| My pinky knows more about this subject than you ever will, dumbshit.
| I design the stuff for a living (and have for the past 35 years).

And yet you never saw an IC described by its circuit diagram labeled with
pin numbers?

Try reading for once, Phil.

|> If you could read better, you'd have know I never asked for circuit diagrams
|> and only referenced them as a way that is done ... for ICs ... I never said
|> this for TVs.
|
| I used TVs as a *simple* example, dumbshit. Circuit diagrams will
| do no good if you have no clue what the black box is. If *you* knew
| anything about the subject you wouldn't be making such a fool of
| yourself. Yes, a schematic will help *me* as the designer. It
| wouldn't to shit for me as a user. "No user serviceable parts
| inside."

Well, you got something right: a TV _is_ a simple example. Too bad it is
not an applicable example when compared to certain types of IC.

Try comprehending what you read, Phil.

In terms of the complexity of what is inside a TV, even a TV of 20, 30, or
even 40 years ago, without having to consider today's CPU driven TVs, there
is a LOT in there. Yet the connections are simple, basic, and well defined:

1. Antenna in (sometimes more than one)
2. Audio/Video in (sometimes in various forms: composite, component, HDMI)
3. Audio/Video out (exists on premium/prosumer/pro models)
4. Headphone jack (did you know it usually cuts off speakers when plugged in)

Ok, you have four pin numbers. That's all you need right?

One does not need to know the circitry inside to understand what all these
connections do. Even YOU can understand this. You just need to apply this
in your discussions and upgrade your analogies.

You are a brainless twit.

A CPU is another example that is more complex on the connections. This will
also depend on how much of a computer system is integrated, such as an "SoC"
(System on a Chip). The classic connections include bus cycle timings, strobes
for various data lines, as well as memory address lines and data in/out which
are sometimes combined (and almost always buffered in this case) or are kept
separate (for faster unbuffered).

yadda, yadda, yadda...

|> |> Firmware, in particular, is highly subject to "bugs" and frequently needs to
|> |> be upgraded. The reason I want access at this level is because I believe I
|> |> may be able to make things smarter and function better in a much wider range
|> |> of conditions, including an understanding of conditions not directly measurable
|> |> that would only be know by the record of past measurements. Very little
|> |> firmware programming in any industry gets this sophisticated.
|> |
|> | Hardware and firmware are no different, other than firmware can (not
|> | necessarily may) be updated. Other than that, there is no
|> | difference. he device manufacturer may have damned good reasons to
|> | NOT let you play and is certainly under no obligation to do so (I
|> | wouldn't).
|>
|> You wouldn't (let people modify firmware) just because you have a major
|> attitude problem. Ironically, firmware you might develop is what would
|> most likely need to be modified ... a lot ... or replaced entirely.
|
| No, I wouldn't let you modify the firmware because I'm smart enough
| to avoid additional work (read costs) for my legal and
| service/waranty departments. There is no advantage to giving users
| this information and a *lot* of pitfalls. You really are stupid.

My firmware would have far fewer bugs than your firmware. THIS is the kind
of thing that helps _avoid_ tech support costs and even legal issues.

You're a clueless idiot. Users cause more problems than they can
possibly solve.

|> Companies that put a lot of effort into making firmware that works really
|> well don't want to let their competition see how they do that. If they
|> really do make good firmware, then there's no issue. Unfortunately, a lot
|> of companies are as full of themselves as you are and _think_ their firmware
|> is really hot stuff when in reality it is just crap. People who know how
|> to develop firmware know they can do better. They just need the hardware
|> interface details to do it. And they need the firmware code itself if they
|> intent to replace only the parts that are broken and keep the parts that
|> work OK (for firmware that isn't really total crap, but can use a little
|> improvement).
|
| You really don't have a clue.

I have far more clues about firmware and programming than you have.

You're obviously a liar too. Ever been on a high performance
microprocessor development team?

I have
never designed a circuit that interfaces to a CPU chip.

Quite obviously.

But I have done
sub-instruction-set microcode programming, which does involve knowing how
the hardware is organized
Whoopie!

... before there were ever such things as FPGAs.

....and you presume to know how this stuff works?

 

[TWayne]

....
... 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.

 

[UltimatePatriot]

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.

 

[[email protected]]

| 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.

 

[[email protected]]

|
| [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.