Still need to add numerous sanity checks to prevent over-discharging, but the happy path works. I'll probably have this pulled into main branch tonight or tomorrow afternoon.
Right now it only works when the grid charger is plugged in. It will probably stay that way for a while.
I've also figured out how to turn LiBCM on when the IMA switch is first turned on... that's a hardware change, though, so the beta PCBs won't ever get that feature. The nuance here is that LiBCM needs to be able to turn itself off - and stay completely off - so that the pack isn't over-discharged if the car sits at an airport for six months.
A few days ago I made a comment about how LiBCM was pulling more power than I had previously measured. Now I know why:
When I characterized LiBCM, I didn't have the grid charger plugged in. It turns out the grid charger consumes 252 mW whenever HVDC is connected to its output terminals. This is 10.5x more power than LiBCM itself pulls after it has turned itself off.
So RevC hardware will get... a switch that disconnects grid charger's DCDC output whenever it's not actively charging. This will probably be an opto-isolated high side FET, but TBD... it's possible I can drive the FET directly using the mains input, in which case no isolation is required... however that opens another can of worms. We'll see what happens when I get around to RevC schematic. Update: ...[will get] an inline blocking diode... because that's exactly what diodes do. Man, sometimes I surprise myself with how complicated I make things.
Fixing this issue will increase LiBCM's keyOff standby time (i.e. sitting in an airport parking lot) from 100 days to 35 months.
...and now I've convinced myself to design out the LTC6820 IC, which handles the SPI to proprietary isoSPI link. I don't want to do this, but given that these chips are impossible to find right now, I've decided it will be a fun distraction from the main project. Honestly it's not that complicated... just need two window comparators to decode the differential response, two half bridge drivers to create pulses, and a super small microcontroller acting as an SPI slave to glue it all together. How hard can it be? (Famous last words).
I'm going to spend a few hours designing a circuit, and then if I can get pulses shaped like what isoSPI expects, I'll commit to it. If wave-shaping proves difficult, it's possible I can add an additional LTC6804 to the PCB and only use the SPI<->isoSPI functionality, but that'll add $20/PCB. Plus, I'm not certain the LTC6804 will work without powering its cell inputs (TBD).
Alright, well got it all drawn out on paper... replacing the LTC6820 requires the following parts:
-Attiny404 (or similar 12-pin uC with SPI)
-two window comparators (to detect positive and negative pulses)
-a current-starved current source (e.g. wilson mirror or similar), which requires QTY4 FETs
-QTY4 FETs configured as two half bridges
-opamp to generate bias voltage
-QTY1 FET to enable bias circuitry
Not the hardest project, but it would still take a couple weeks to design and verify... and with all those parts it's going to cost more than just using the LTC6804.
But then I found that Mouser expects to get QTY412 LTC6820 units in stock on 2021OCT25 (probably from a customer return). I tried to buy them all, but Mouser is limiting me to QTY50 per month... that's right, we've entered the rationing state!**
So I bought QTY50 (total price: $294.75). And if you want to buy QTY50 too, I'll happily buy them from you. Send me a PM with your paypal address and I'll send you the money... Mouser accepts paypal, so you won't be out any money (I'll send you the money first). Update: I got creative and ordered a couple hundred more, sending them to various different addresses, and paying with various different paypal accounts I may or may not have for precisely things like this. Buying them QTY50 at a time is annoying, but that's a small inconvenience versus having none to buy.
**Years from now my non-existent grandchildren are going to snicker about how "grandpa Mudder hoards semiconductors... he has them stashed all over his house."
I've got mine back in and working using the firmware from the Linsight web page.
Note it does not like first startup after flashing.
It took a lot of fiddling around booting, rebooting, powering up/down etc.
Finally with the LCD on the shorter cable etc after programming I got the code running.
I am running VPIN via the LiBCM.
I note the spoofed (detected) voltage at tickover Bvo is only 144V?
Does that cause a problem with auto stop I wonder or IMA start?
Test drive shortly....
Seems OK getting about 20kw on kickdown with my CVT battery at about 3.75V/Cell.
Can you reliably reproduce the "first start" issue you describe? If so, can you remove the middle mat and take a video that shows the LEDs blinking? I'd like to see the process you're going through that results in a failure to start on first keyOn.
I assume you're getting P1648 on first boot?
Note that if LiBCM can't establish communication with the LCD screen on powerup, it will hang forever. Note that this hang only occurs on first powerup; after LiBCM is running, the LCD screen can be unplugged, data/clock can be shorted, floating, noisy, whatever... and LiBCM shouldn't hang.
If you continue having first boot issues, try commenting out this line in the config.h file:
#define LCD_4X20_CONNECTED //Comment to disable all 4x20 LCD commands
That will completely disable the I2C connection to the LCD screen. If the first boot issue persists with that line commented out, then it's not an LCD issue.
It shouldn't be a pain to get running, and I can't fix the problem if I don't know what it is. I don't have any issue starting my car, so maybe there's something different in our process? I'll shoot a video tomorrow showing my first boot process, just to make sure we're on the same page.
When you get to a place where you aren't 'stuck' if it won't start, I'd love to better understand the problem you're having.
Re adding a series diode to prevent the grid charger backfeeding. Good idea..
I think a lot of these LED power supplies/psu's absorb some power from a permanently connected battery.
It also makes the charger connector a tiny bit safer as HV won't be present when it's off.
I've spent the last day getting LiBCM to turn on faster. Specifically, I'm looking at the time it takes:
-from the moment the 12 volt power supply in the IMA bay clicks on ("keyON").
-to the moment LiBCM finishes executing the main firmware loop for the first time.
In the graphs below, these are shown as:
YEL: 12 volt power applied to IMA bay. Essentially 'keyON' signal
PNK: LiBCM's 5 volt rail
BLU: toggles at the END of LiBCM's main loop.
The OEM Arduino behavior is quite slow:
It takes 920 ms from keyON (yellow) to finishing the first loop. Note that this delay is ONLY the FIRST TIME LiBCM powers up. At present, after LiBCM turns on, it never turns off (unless the battery gets too low).
The primary reason for this delay is the MEGA2560's bootloader, which allows us to reprogram LiBCM over USB. The bootloader runs prior to the main LiBCM firmware. Each time the Arduino comes out of reset (e.g. is powered on), the bootloader waits for reprogramming instructions from the host computer. If no instructions are received after 1 second, then the bootloader 'exits' and the main program begins. Without this delay, there wouldn't be enough time for the host computer to send valid instructions... the delay is necessary if we want to update LiBCM firmware over USB.
However, the MCM requires LiBCM to start sending the BATTSCI signal within ~60 ms after keyON. If the BATTSCI bus isn't running after 60 ms, then P1648 CEL occurs.
These two paragraphs are at odds with each other.
The solution wasn't immediately obvious to me, but is simple in hindsight:
When the bootloader starts, it checks keyON... if the key is on, the bootloader exits immediately. Super simple concept, but my goodness was the actual implementation difficult! Specifically, I had to setup the build environment, decipher the cryptic 512B bootloader, write some assembly, and also dig through the mega2560 datasheet... this took about a day to figure out!
Here's the result:
Note: The timescale (X axis) has changed
Now it takes just 78.4 ms from keyON to finishing the first loop. That's 12x faster! ...but still not fast enough.
The primary culprit for the remaining delay is the mega2560's ~67 ms clock stabilization delay. Fortunately, this is programmable all the way down to 0 ms (which is a bad idea). The manual suggests that if the MEGA2560's power supply rise is monotonic (it is), then the clock stabilization delay can be equal to the supply's rise time.
So I reprogrammed the MEGA2560's clock startup stabilization fuses to 4 ms:
Note: The timescale (X axis) has changed
Now it takes just 16.1 ms from keyON to finishing the first loop. That's 57x faster! And now we're well below our 60 ms BATTSCI timing requirement (to prevent P1648).
Q: So what does all this mean?
A: LiBCM now boots fast enough that P1648 will no longer occur (from a cold boot).
A: LiBCM can now turn itself off whenever it wants, which saves battery life. I'm thinking LiBCM will turn itself off an hour after the keyOFF event. Notes:
-You'll need to plug the charger in within an hour of turning the car off.
-If LiBCM is off when the grid charger is plugged in, the grid charger will not charge.
-LiBCM will never turn off when the grid charger is plugged in
A: You can leave a fully charged LiBCM G1 "at the airport" for more than three years (before LiBCM will have consumed the nominal lithium pack energy). Note that in practice the lithium self-discharge rate will reduce the standby time... my goal is for LiBCM itself to not over-discharge your pack.
A: You can leave a nearly empty LiBCM G1 (e.g. with just 20% SoC remaining) "at the airport" for at least six months.
Unfortunately for our beta testers, these firmware changes aren't USB-updatable. I'll need to send them new ISP-programmed MEGA2560 PCBs. I'll probably do that at the same time I send out the RevC PCB; I'll start working on that design tomorrow.
Forward-looking LiBCM hardware timeline:
SEP19: Place RevC LiBCM PCB order
OCT03: RevC LiBCM PCB should arrive
OCT04: Build QTY1 PCB (program P&P, etc)
OCT05: Bringup QTY1 RevC PCB on my bench
OCT07: Build QTY5 PCBs for beta testers
OCT11: USA beta testers receive RevC hardware
OCT21: Peter receives RevC hardware
NOV10: Start shipping "early adopter" LiBCM units?
This is an aggressive timeline, and I probably won't hit that target.
All bets are off if anything goes wrong (which is bound to happen).
The MVP firmware is nearly complete.** There will be features missing in the MVP code, but it will be good enough that a customer could safely use it without ever updating the firmware again. I'm considering shipping the first production units unprogrammed, to force LiBCM's early adopters to learn how to upload the firmware... that will drastically increase the chances that the MVP firmware gets updated as new firmware versions are released.
**Remaining MVP firmware features to code:
-state of charge (coulomb counter)
-better SoC granularity to MCM
-generic "something is wrong" P-code
Features absent from (user-upgradable) MVP firmware:
-LiDisplay firmware. Early adopters will need to keep using existing 4x20 screen, which is buggy in some cars.
-Variable fan speed control... MVP will only turn fans on/off at specific setpoints.
-Finely tuned voltage spoofing algorithm... existing implementation is "good enough"
-Runtime-configurable settings... you'll need to choose all settings when you load the firmware on LiBCM
-any other features I eventually come up with.
For several reasons, I'm on the fence about selling unassembled LiBCM kits to the general public:
1: The electrocution risk is very high if you do something wrong.
2: Improper installation can result in thermal events (i.e. 'fires'). We had one thermal event in our beta testing, due to a bent pin on the OEM BMS connectors, which it turns out require exacting co-linearity whilst plugging them in. These aren't consumer-grade connectors, as they don't allow for off-axis insertions. The connector is fine once it's plugged in. Note that this is the OEM connector that comes on the lithium pack... "changing it" would require manually rewiring every single lithium module, which would take a LONG time.
3: While pre-assembled LiBCM packs are nearly "drop-in" replacements to an OEM NiMH pack, the actual LiBCM mechanical pack conversion process is extensive. Our beta testers had lots of feedback to improve the process, but it'll never get a good score from ifixit.
4: I don't want the increased support burden.
For the above-listed reasons, I primarily intend to ship kits to a select few "Certified LiBCM Converters" ("CLCs"), who will perform the pack conversion process, and then either install the pack in your car, or ship you a completely assembled pack (which you can then install nearly identically to an existing NiMH pack). Note that installing an LiBCM-converted pack into the IMA bay is fairly straightforward... it's the actual pack conversion that is difficult.
I suspect the primary CLC supplier will be BumbleBee batteries, given my estimate that Eli owns more than 90% of the lithium modules LiBCM is specifically designed for (I believe he has enough modules to convert around QTY350 cars). Other CLCs include all of LiBCM's beta testers, and also Eric Powers, given his extensive history with the G1 IMA system. If you are interested in becoming a CLC, keep in mind that each CLC I bring into the fold will require several hours of effort on my part in support (see item 4).
I recognize that not everyone will want to pay the price premium for a Certified LiBCM Conversion. Specifically, many individuals have already purchased lithium modules to perform the conversion process themselves. To those individuals, my overwhelming recommendation is to find a nearby CLC. I'm sure LiBCM's beta testers will agree that this is the correct answer in most cases.
However, I will sell Linsight conversion kits (i.e. everything but the batteries) to any individual that agrees to the following terms:
A: You must sign a liability waiver that absolves me from injuries/death resulting from the conversion process
B1: To ensure you're up for the task, you must agree to watch the LiBCM conversion kit assembly videos PRIOR to ordering the LiBCM kit. These videos will be posted at linsight.org (the existing videos that are there now will change, based on feedback from our beta testers).
B2: You will need to correctly answer several installation-related quiz questions, which I will provide via PM.
C1: I will not provide private technical support to non-CLC individuals. I simply don't want to devote the time and effort to support each DIY customer. If you have questions, you will need to post them publicly; I will then link you to the linsight.org page containing the answer (which I might have just written if your question is new). This is a superior format to insightcentral's thread-based sprawl.
C2: If you insist on private technical support, I will charge my "pro bono" rate, which is presently $100/hour. I won't hesitate to raise this rate as required to keep people from overusing it. I absolutely do not want LiBCM to be my primary focus six months from now... I'll keep making them as needed, but I don't want to keep supporting them (besides on a public forum, such as ic.net & linsight.org).
D: LiBCM kits installed by non-CLC individuals will not have any specified warranty period. I will 100% test each kit prior to shipment. If LiBCM arrives damaged, I will replace it at a fair cost (which could be $0 if I determine that the issue was on my end).
E: If you are unable to complete the LiBCM conversion process, I will accept returns for a nominal restocking fee.
F: I (mudder) will not, under any circumstances, perform the LiBCM conversion process for you. My primary focus will be to create the LiBCM kit, which by itself is a huge undertaking.
G: I will not provide any specific support for any other lithium battery besides the specific G3 Honda Insight lithium modules that LiBCM is designed for. I will provide a general guidance page (on linsight.org) for those seeking to use LiBCM with different lithium modules. However, my support will end at the BMS ribbon cable ends, which you must then connect to every single cell in your pack. If you connect your end of the ribbon cable up incorrectly, it will destroy the LiBCM PCB, the ribbon cable, possibly your pack, and could cause a thermal event. You will need to be 100% certain you've connected each sense lead up correctly prior to plugging it into the LiBCM PCB.
I'm one of the people who have purchased QTY 4 18S modules. While I believe that I can probably safely do this conversion, I also know that I will plan to watch the video(s) first, before even making the decision regarding whether to attempt it.