On Going Deals on Batteries.

No, they're crammed and tiny.  Probably much easier to put a temperature sensor on the heatsink, and have the Pi pop the fan on if the heatsink gets hot.  Or have the Pi read the strings and pop the fan on if any of them indicate "active."

While I applaud you guys for finding ways to improve things, I'm a big fan of keeping it simple.  It seems to me Sid has the balancers working very well, while still keeping them simple and basic (ie, not much to fail so not as likely to fail).

I hope if an improved version that takes significantly more computing power for a significant increase in data output is offered for sale, that the current lcd screen simple version is still an available option.  I see that initially after installation,  a lot of stuff will be happening that will be nice to have data on, but after some settling-in time the balancers should be doing very little.  The data output at that point on should be pretty boring.

I guess I'm more interested in results than documentation of progress.  I'm probably in the minority on this but I usually find myself in that position so nothing new....

As far as controlling fans, a temp sensor on the balancer heatsink connected to a cheap 12v ebay temp/fan controller is my plan.  And no need to complicate (or compromise) the balancer circuit.  Link below is one I currently use;

https://www.ebay.com/itm/DC12V-LED-Display-Digital-Thermostat-Controller-Temperature-Control-Relay-Switch/262326258155?hash=item3d13dd09eb:g:H8EAAOSw1DtXHeKV

It displays the current temp as well as the fan kick in and shut off temps at a glance.

Exactly...for LFP batteries anyway.  Seems Li-Ion never really fully balance...

But for those that want to see cell voltage readouts, this is an easy thing to provide without adding a Chinese "BMS" to the battery.  Also worth noting that if a cell string starts to fail, it's pretty easy to catch with battery info.

So the "LCD" version is the one I'm working on right now.  It's possible I might be able to have a "disable serial" function to reduce the quiescent current to just the ~500uA required to run the LCD...but for those that want a smidge more info, it can be enabled.  Will have to look into that...

Yep, I have some of those as well, just never used them yet.  

On 4/3/2021 at 9:22 PM, Sid Genetry Solar said:

Didn't think of that...but it would definitely make a huge increase in the data transmission.

Each balancer will have the following info available:

• firmware version
• ID number (1 = top of string)
• battery voltage
• shunt state
  • on
  • off
  • MAYBE a crude "throttle"
  • balancer fail?
• thermal protection state (good/trip)
• local temp (MAYBE)

If you stringify all of that with JSON, I'll casually estimate over 100 bytes of data per balancer (as a result of adding all the JSON support stuff).  If we support up to 200 cells in series, that becomes 20,000 bytes of data to transmit...and if we're doing a 5 second "update" interval, that requires a MINIMUM baud rate of 57,600. 

Possible?  Well, the little PICs would have to bump out of 32KHz power save mode to 8MHz to meet the UART requirements--bumping static current consumption from <0.5mA to ~5mA each.

Worth it?  I wonder...'cause parsing a bazillion bytes with a casual Arduino project turns into quite the challenge.  Now, if it's connected to a Raspberry Pi (or other embedded processor) with 512MB of RAM and a 1GHz processor, JSON is child's play.

 

If it's transmitted in direct byte format, we save a considerable amount of data:

1. "header" byte (0xFF)? --might be able to indicate firmware version on low nibble?
2. cell ID byte (1 = positive end of the string)
3. battery voltage HI [may be able to pack a couple of bitflags on the MSB here]
4. battery voltage LO
5. shunt state bits (7: "fail", 6-0: "throttle" [if possible])
6. local temperature (MAYBE...definitely low resolution at best)
7. status bitflags (incl. thermal protection state)
8. checksum

8 bytes * 200 balancers = 1,600 bytes / 5 second update interval = 320 bytes/second = 4,800 baud is more than adequate.  9,600 is very common, and can easily be handled with the processors running at 0.5MHz internal oscillator.

Thoughts?

There is a cost for sure. I think there are some merits, however.

There are different JSON Schemas one can use to reduce the amount of data being sent. One packet per balancer can be expensive. I don't see a super need for a checksum bit given that the packet parses, that's up to you really.

// Every balancer
{
    "fwv" : 1,
    "cid" : 1,
    "bvh" : 4.1,
    "bvl" : 3.3,
    "shs" : 0,
    "lot" : 70,
    "sta" : 0,
    "chk" : 9
}
// Condensed (71-73 characters per balancer):
{"fwv":1,"cid":1,"bvh":4.1,"bvl":3.3,"shs":0,"lot":70,"sta":0,"chk":9}

// Bulk (all balancers in one packet):
{
    "fwv" : [1,1,1,1],
    "bvh" : [4.11,4.12,4.11,4.13],
    "bvl" : [3.3,3.2,3.3,3.3],
    "shs" : [0,0,0,0],
    "lot" : [70,71,73,63],
    "sta" : [0,0,0,0],
    "chk" : [9,9,9,9]
}

// Bulk condensed (138 characters for four balancers, 35 characters each on avg)
{"fwv":[1,1,1,1],"bvh":[4.11,4.12,4.11,4.13],"bvl":[3.3,3.2,3.3,3.3],"shs":[0,0,0,0],"lot":[70,71,73,63],"sta":[0,0,0,0],"chk":[9,9,9,9]}

Examples 1 and 3 are "prettified" versions of the condensed, you'd be sending the condensed. You could even further condense this in some ways... make all field names single character, etc. 

If you can get data from all balancers and aggregate them when sent over serial, the bulk saves lots of space as you can see. You don't need a "cid" (cell index/cell id), the position in the array is the cell index.

One of the main advantages to this approach is that it makes it dead simple for any Python/Java/JavaScript developer to talk to your device, and it allows you to add/remove fields, or change field order without breaking their software. Arduino can parse JSON using libraries, I use this currently to do my bus appliance automation. I talk to the Arduino using JSON packets that constitute read/write commands, and the Arduino sends back only the updated states of all relevant pins. I frequently finding myself adding fields to the JSON on either the Java or Arduino side of the equation- and both ends still work even if I only update one or the other (and I'm good about falling back on behavior if fields are missing/unavailable).

One could simply read a line off the serial port and puke it out over HTTP and have a REST-like interface for consumers to work with, be it web frontends or web interface consumer scripts.

Reporting your firmware version is a good way to signal how to parse the packet in your binary schema. I'm thinking like a systems integrator... to me, the 200 cell use case in my view is an extreme outlier, I think the top end average right now will be 16S-32S. Its good to consider the extremes for sure, and you raise some valid concerns. Depends on where your values are imo.

If you go with binary I will be happy to write a library in 3 or 4 languages for folks here to use. 😃

"Bulk condensed" is definitely an impossibility.  The balancers are based on little MCUs that only have 256 bytes of RAM each--yes, two hundred BYTES (not kilobytes) that must be shared with ALL the other functions.  There simply isn't enough memory to store any length of data string, much less process it.  They also have just 7.1KB of program memory altogether--less, I'm sure, than 99% of the "JSON implementation libraries" out there.  (Which I wouldn't use regardless.)

Each balancer unit has to "pass through" and then append its data to the data string--if the serial is sending back-to-back (which it will), there is no time to add an extra 5 bytes here or there for JSON formatting--otherwise data has to get stored somewhere.

Modern programming has gotten so bloated and wasteful of resources that we have forgotten how little processing power most tasks really need to take.

Most any other programmer looking at the GS inverter CPU wouldn't be able to get half of the functionality out of it--simply due to extravagantly wasteful coding.  "We need a 32-bit processor running 120MIPS."  (GS main "CPU" is an 8-bit processor running at 16MIPS.)

I use the 200-cell example simply because it's a flexibility that no other BMS system (that I'm aware of) can readily offer.  (That's 800v on Li-Ion, so definitely not a very common demand.)

Checksum would only be needed for a binary output; if it's JSON, no checksum is needed--as it'll be pretty easy to detect a mangled string 😉.  It is worth keeping in mind, however, that the concept I have in mind is one of the world's longest games of "telephone", so...well...!

Wait,t he GS uses a 8bit cpu?  So I can play my NES game sand Doom on it?  Sweet. will defently install doom on the gs and have it play while makeing power, and every time it kills a monster, it sends out a pulse of lightning bolts out of a rod that I will place on the side to act as the power switch with warning labels all over it about high voltage. . .

I did put a Blade Runner splash screen on the WiFi boards way back just to tease Sean at one point...

Takes me back to the 80s doing assembler and direct machine coding on Z80s with no RAM at all.  The Z80 had several general  purpose registers and a whole alternate set of them and the index registers.  I think it gave around 112bits (bits!) of storage to play with and you could do quite a lot with that.  The 68xx and 65xx CPUs, possibly the 2650 too (can't remember) all had essentially no general purpose registers so it was a requirement to have at least a few bytes of RAM to be able to anything but blinken lights with them.

IIRC Mike of MikesElectronicStuff on youtube fame wrote a Z80 based parallel printer buffer back then that worked under similar principles.  The RAM that was present was not usable for normal storage, it could be 1, 2, 4, 8 bits wide depending on the buffer size purchased.

Hey fellas don't mean to but in but I think I got a pretty good deal today if I don't have any more problems with my credit card.i think I ordered for a price I'm sure of from a double AA rated company on alibaba and money&info goes thru trade assurance 16 new grade A 3.2v 200ah lofpo4 cells for 1,096.64 including shipping to my house+insurance

@timLet us know how they turn out.

27 minutes ago, Tim said:

Hey fellas don't mean to but in but I think I got a pretty good deal today if I don't have any more problems with my credit card.i think I ordered for a price I'm sure of from a double AA rated company on alibaba and money&info goes thru trade assurance 16 new grade A 3.2v 200ah lofpo4 cells for 1,096.64 including shipping to my house+insurance

Uhm, that is a steal, I could get that same order and have 400ah more of power.  won't have that kind of money for another three weeks, but I might snag that up as well if it real.  got a link to the thing?.

I am waiting on a shipment of the smaller 100ah cells.  Figured I would give these smaller ones a try since I can stack 16 on my rack in place of one of my Cell Tower AGM batteries.  Should save me a bunch of weight the AGM batteries are 128 pounds a piece.  This is the link to the ones I am waiting on.  They are about $178 lot/4 and free shipping.  Saw some reviews and they are good so went for it at least to test them out.

Link

Battery hook up has these for $250 

!

I just bought 4 sets, so will have a 24v 250 bank 😛  saw it hop on it. thats $60 per KW 😛

Battery hook up has these for sale

2x BYD 250ah prismatic cells 

Glad I figured out how to edit out the last post, geesh.