connecting batteries in parallel or series, myth and theory

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.

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

In alt.engineering.electrical krw wrote: | In article , phil-news- | snipped-for-privacy@ipal.net says... |> In alt.engineering.electrical krw wrote: |> | In article , snipped-for-privacy@ipal.net |> | says... |> |> In alt.engineering.electrical Ken Maltby wrote: |> |> |> |> | 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).

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.

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

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

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

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

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

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.

You really don't have a clue.

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.

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.

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.

In alt.engineering.electrical krw wrote: | In article , snipped-for-privacy@ipal.net | says... |> In alt.engineering.electrical krw wrote: |> | In article , phil-news- |> | snipped-for-privacy@ipal.net says... |> |> In alt.engineering.electrical krw wrote: |> |> | In article , snipped-for-privacy@ipal.net |> |> | says... |> |> |> In alt.engineering.electrical Ken Maltby wrote: |> |> |> |> |> |> | 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.

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

Sigh so much arrogance and ignorrance in one post. Any change in the DSP or logic array prigramming affects the timing. Of course, you have no idea, since you've never done anything with either. The schematic is nothing but data bus, control buss adress bus and power rails. Changing the DSP or FIR firmware affects how the digital signal is processed, and the recoverd signal. There was over three years of work on the design and testing of that prodcuct, with a minumum of six engineers at any time. You are nt going to do better in your home shop. All you would do is destroy the hardware by randomly uploading crap to the IC registers as you attempt to change things. Study the data sheets for some DSP or FIR ICs:

You have proven time after time that your reach exceeds your grasp.

We used several Harris devices, which are now Intersil.

If you're so damn smart, why aren't you working for one of the companies, or even better, design and manufacture your own products. Oh, that's right. You're just another blowhard with a callsign. 10-4 good buddy! I'll bet you're out of those 807s!

ote:

i haven't read this whole mess so I may repeat someone.

The battery charger and controller IC manufacturers provide applications boards with generic battery constants and enough instructions to modify them to the proper values the cell manufacturer recommends. You have to understand the basics and the data sheets but you don't have to be able to design the charging system from scratch.

If you want to, however, a constant voltage / constant current output (like a of a lab supply) will charge most types of batteries pretty well if not very fast. You could add a temperature sensor to detect and adjust the endpoint, and a discharge load to condition the cells. A current sense resistor and low ON resistance FET in series with the output would give you emergency shutdown.

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

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

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

7400 days.

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

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.

Try reading for once, Phil.

Try comprehending what you read, Phil.

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

You are a brainless twit.

yadda, yadda, yadda...

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

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

Quite obviously.

Whoopie!

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

...

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.

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.

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.

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.

Luck; Ken

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 then our products were not rushed into production.

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

--=20 Keith

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

|>>> In article , snipped-for-privacy@ipal.net |>>> says... |>>>> In alt.engineering.electrical krw wrote: |>>>>> In article , phil-news- |>>>>> snipped-for-privacy@ipal.net says... |>>>>>> In alt.engineering.electrical krw wrote: |>>>>>>> In article , |>>>>>>> snipped-for-privacy@ipal.net says... |>>>>>>>> In alt.engineering.electrical Ken Maltby |>>>>>>>> wrote: |>>>>>>>>

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

Quite often, when it designed to be programed. A lot of our products were designed that way, while others were mask programmed MPUs. You are talking peanuts and watermelons. the peanuts are the tiny number of products you can modify, and the watermelons are the hard coded devices.

I have been legally blind all my life. Do you want to make something of it? I can't see worth a dam without thick glasses, but I worked over

40 years in electronics, including reverse engineering products. I really don't give a damn what you think, since you are a nobody to me. 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.

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 news:sci.electronics.design 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.

| 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 | news:sci.electronics.design 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.

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'd like a small footprint for your full computer, follow the link below for a few more ideas (block diagram, photos, descriptions).