[mudder]

FYI: I

Mudder, as I ponder what I want to do regarding faster charging and the final revision PCB, I dug up this post where you mention what grid chargers you would offer.

Are the above times for charging from 0%-100% or for some other range?

Whenever I quote charging time, I'm using 10% to 85% SoC, since that's the range LiBCM uses. Since the EHW5 modules are nominally 5 Ah, I'm quoting the time to charge 3.75 Ah (i.e. 75% SoC, which is 85% - 10%).

Also, in your above post you mention that if we limited ourselves to a 1 Ah grid charger, we could probably stick to the current revision board. If we were able to locate such a grid charger, what would its charge times be?

The grid charger included with Open Beta LiBCM Kits is 450 mAh/h, and so takes around 8 hours to charge the battery (if the firmware version is older than v0.7.3, it takes around 12 hours).

A 1.0 Ah/h grid charger will take under 4 hours to charge the battery.
A 2.1 Ah/h grid charger will take under 2 hours to charge the battery.
A 4.2 Ah/h grid charger will take under 1 hour to charge the battery.

 

[mudder]

Update: LiBCM Open Beta Kits are sold out.
I'm still accepting orders, but kits won't ship until early June (at the earliest).

 

[Wipeout]

Update: LiBCM Open Beta Kits are sold out.
I'm still accepting orders, but kits won't ship until early June (at the earliest).

I think I've decided to wait for v1.0 of LiBCM as I want a turn-key upgrade for my dying-IMA Insight, but I'm excited to see how much this has progressed! Sometimes my Insight doesn't get driven for weeks at a time, and it's not always able to be plugged in. With the future Revision D battery drain, will it kill the HV pack in under a month, and is there a way to have it automatically go into sleep mode?

Cheers!
Adam

 

[mmdepace]

I didn't keep up with the thread. After upgrading beyond 0.7.3, I have likely left the grid charger plugged in every night a bit longer than necessary, possibly by 50% longer. Want to report that charge termination has worked perfectly every time. In other words, it never charged beyond where it was supposed to terminate.

Side note - had planned to turn of the HV battery switch before 10 days of airport parking (currently in progress). No big deal though as the system already accounts for this. Another nice test in progress, I suppose. Parked somewhere around 50% SOC. Figure I'll be no lower than about 35 upon return.

 

[Balto]

Update: LiBCM Open Beta Kits are sold out.
I'm still accepting orders, but kits won't ship until early June (at the earliest).

Whoops. Didn't think you would run out tbh. Was meaning to order another Incase my citrus needs a pack, or Mario and I want to do more testing on the big batteries. Ah well.

 

[mudder]

I think I've decided to wait for v1.0 of LiBCM as I want a turn-key upgrade for my dying-IMA Insight, but I'm excited to see how much this has progressed!

No problem. I suspect quite a few people are waiting for 1.0. Hopefully it's ready by June, but I have no idea for sure. Note that the production hardware will ship in the order received... so you could buy it now and be first in line... or just wait until it is officially released. In other words, the only remaining changes for v1.0.0 are in firmware.

Sometimes my Insight doesn't get driven for weeks at a time, and it's not always able to be plugged in. With the future Revision D battery drain, will it kill the HV pack in under a month, and is there a way to have it automatically go into sleep mode?

Once I get all the firmware power saving features implemented:
The RevD LiBCM unit will drain a fully charged pack down to 20% in about 18 months. Once the battery state gets too low, LiBCM will turn itself off until the next key-on event. When LiBCM is off, it will consume 20% SoC after around 5 years. If you plan to store the car for longer than 6 years, you should either turn the IMA switch off or leave the grid charger plugged in.

During the Open Beta period:
There probably isn't going to be a discernible difference between RevD & RevC power draw (maybe 1.3% SoC/day, versus 1.0% SoC/day).
As mentioned previously, LiBCM will automatically turn itself off if SoC drops below 10%, so there's no reason to worry that the battery will over-discharge just because it's sitting... that would take years.

 

[mudder]

I didn't keep up with the thread. After upgrading beyond 0.7.3, I have likely left the grid charger plugged in every night a bit longer than necessary, possibly by 50% longer. Want to report that charge termination has worked perfectly every time. In other words, it never charged beyond where it was supposed to terminate.

As you probably know, leaving LiBCM plugged in "for too long" isn't an issue. At this point I always leave my LiBCM plugged in whenever I'm not driving it.

FYI: For safety reasons, I only edit the gridCharging.c file when absolutely needed... later on it will be the first code section I write unit tests for.

Side note - had planned to turn off the HV battery switch before 10 days of airport parking (currently in progress). No big deal though as the system already accounts for this. Another nice test in progress, I suppose. Parked somewhere around 50% SOC. Figure I'll be no lower than about 35 upon return.

After ten days you should probably be closer to 40% SoC, but yeah please let me know the actual result. Note that with the latest firmware, LiBCM will turn off if the SoC falls below 10%. I'll eventually increase this to 20% SoC (it's a user-configurable parameter in config.h).

 

[rustedcaddy]

Forgive me if I'm in the wrong thread, new to the forum and couldn't find another similar.
Just got my LiBCM the other week, thank you mudder! Excellent craftsmanship.
I haven't procured my battery yet but glad I got the LiBCM before open beta closed.
I was comparing EHW5 packs and briefly looking at the FoMoCo packs mentioned and tested on here. Has anyone experimented with Tesla modules? I'm very comfortable building packs with my spot welder so was thinking at $600ish shipped it would be a better option to get up to 5.2kWh (if all cells fit). From what I read here, any Li packs will work with LiBCM. Am I crazy or overlooking something obvious here? - if not I'd be happy to be a guinea pig for the cause!
Thanks,
Rusted

 

[mudder]

Hey Rusted, you're in the right place!
The LiBCM hardware supports all known lithium chemistries. However, the firmware presently works with cells that work between 3.1 and 4.2 volts. Fortunately, this includes the cells used in Teslas, so yes, Tesla modules would work. However, given how small each tesla cell is, it's probably cost-prohibitive to use them with LiBCM.

If you want to make a Tesla pack for your LiBCM unit, the hardest part will be figuring out the mechanicals. I can send you ribbon cables as long as you want, which will plug into LiBCM's 0.1" headers. I'll certainly help you out with the firmware, too.

 

[Buckley]

I have been without boost since the software canceled. 3 days now.
It is almost impossible to accelerate onto the highways' entrance ramps in Atlanta with the prevalence of aggressive drivers without risking a life terminating event.
I am excited for all of the Betas who are enjoying their boosts, but I am not computer literate and cannot figure out the final steps for updating.
In trying to take responsibility for fixing my own problem, I read all of the linsight FAQs but only made it through the first 8 of 24 pages of this thread. Could not understand the posts in any way. Seriously, John, you need to keep this technical thread but please start a "users-nontechnical empirical language" thread. Or I might, but I would need the community support.
Here is my latest update-blocking problem:
I plug in the USB from behind the passenger seat and my Microsoft surface Pro 2 laptop gives a chime of recognition but nowhere can I find the LiCBM represented on my File Explorer:

So I try the upload anyway, but it does not work:

For really computer-illiterate owners, two things make for more difficulty:

1. Using an apple laptop in the video when I have a PC laptop.
2. Supplying a USB cable that is too short. Your port is on the right but my only port is on the left. I have to try an upload the software hunched over in the cargo compartment.
A second problem with the operation will be brought up after this problem is ironed out.
Please help.

 

[mudder]

1: The Arduino environment is nearly identical in Mac OS, Windows, and Linux. If you're having problems uploading the firmware, it's probably not OS related. Please record a video of the process and post it on youtube. FYI: The firmware update experience will be much simpler once LiBCM exits Open Beta.

2: If your computer only has USB ports on the left, I recommend sitting in the passenger seat. If installed correctly, the cable should be long enough. Regardless, another option is to purchase a USB extension cable.

 

[Buckley]

Thank you for your reply. The problem is not uploading firmware. From the screenshots it can be seen that I have uploaded everything to get me to the Arduino program opening MVP.ino .

The problem is you show how to make sure your laptop is communicating with the LiBCM on your Mac but not on windows. My windows 10 MS Surface pro, while it acknowledges the USB connection with a chime, does not show me any communication with the LiBCM on the two screenshots that I included. I have no example to point me in the right direction.
How do I direct the USB port to the LiBCM? What does the error message on the Arduino program mean and what is the way to correct it?

 

[Mario]

Just from the screenshot, I would assume the correct board type has not been selected in the Arduino IDE under Tools->Board. Possibly you have also not selected the serial port under Tools->Port. This is explained at 1:50 in the step 17 video:

Did you make sure you did that? These steps are the same for Windows and Mac.

Opening Arduino isn't "uploading everything". You have the firmware source code (MVP.ino and all other files), you have the program that will compile that into the firmware and upload it (the Arduino IDE), and now you need to actually run the process that will put the firmware on the board.

 

[Buckley]

You know, Mario, that probably is it. I think my eyes glazed over about a minute into the vid. There is so much stuff to absorb; I think i blinked. I will edit this post once I follow your suggestions.

Spot on, Mario. Thank you. I just needed a little prompting my first time into the universe of Beta. I have boost.

 

[geocougar]

2. Supplying a USB cable that is too short.

Would suggest you use a USB extension cable.

Edit: I see this was already suggested.

 

[tervic]

Hi Mudder,

Sorry for kind of dropping off on the whole back up starter deal. I have uploaded 7.5 firmware to the problem child. I was able to capture a back up start last night. Info is attached.. I kind of think I may not have captured everything you need for diagnosis, if not please let me know what is needed.

 

[Balto]

Tervic. I'm not sure if this has been covered, but have you tried replacing the starter relay? It could be getting stuck and forcing a 12v start I believe...

 

[tervic]

No, I haven't heard about that...
However, this not an all the time thing. Happens intermittently at inconsistent intervals. Also never happened prior to the new lithium pack (other than the normal super cold temperature start).

I'm not sure how a sticking starter relay would cause this. Wouldn't such a scenario present as a starter that begins cranking as soon as the car is energized when key on happens?

 

[Balto]

No, I haven't heard about that...
However, this not an all the time thing. Happens intermittently at inconsistent intervals. Also never happened prior to the new lithium pack (other than the normal super cold temperature start).

I'm not sure how a sticking starter relay would cause this. Wouldn't such a scenario present as a starter that begins cranking as soon as the car is energized when key on happens?

No, the starter relay is something I mod on bypassed cars. It allows instant start from the starter rather than waiting 5 seconds with the key held forward. It could just be coincidence that it failed at the same time as lithium went in. Stranger things have happened. 🤷‍♂️🤷‍♂️

 

[mudder]

The easiest way to test for that is to remove the backup starter relay:

...

FYI: The commands below only work with the latest (pre-release) firmware.

...

The next thing you should do is plug LiBCM's USB cable into a laptop, open up the Arduino Serial Monitor, then type $DEBUG. This should return the following:

Debug data persists in EEPROM until cleared ('$DEBUG=CLR' to clear)
-Has LiBCM limited assist since last cleared?: NO
-Has LiBCM limited regen since last cleared?: NO
-loopPeriod exceeded since last cleared?: YES

If you're getting different results:
-Let me know what you get.
-Type $DEBUG=CLR to clear those (persistent) values.
-The goal here is to see if LiBCM is limiting assist for some reason. Obviously this will occur whenever the battery gets full... so for this testing, you should either prevent the battery from getting full (e.g. Calpod), or you should clear the settings ($DEBUG=CLR) each time after the battery gets full.

Edit: After reviewing your log, I see you're getting the expected results (above). This means LiBCM isn't intentionally preventing IMA start. You should still perform the test below.
...

Next, let's see if we can increase the frequency that your car uses the backup starter... that will let us know if this is an LiBCM-related keyON timing issue.
I've added the command $KEYms specifically to troubleshoot this issue. Here's how to use it:
-Type $KEYms=100. This will add a 100 ms delay from when LiBCM detects that the key has turned on, to when LiBCM starts sending data to the MCM.
-Start the car ten times. After each start, log whether the IMA or backup starter was used. Then turn the key off and wait for LiBCM's 4x20 display to turn off, then restart again.
-If the backup starter only happens once or twice, increase the keyON delay more (e.g. $KEYms=150).
-If the backup starter happens all the time at any particular value, decrease the keyON delay (e.g. $KEYms=50).
-The goal is to figure out whether or not LiBCM is booting up fast enough.
-Ideally you can respond with something like: "the backup starter always occurs when $KEYms exceeds 100 ms, and rarely occurs when $KEYms is less than 25 ms."
-When you're done testing, make sure to reset the delay to 0 ms ($KEYms=0).
-Note that the maximum value for $KEYms is 254 ms.

...

Further thoughts on the data you collected:
It appears the IMA system did in fact attempt to start the car... so if the backup starter was engaged, too, then that's really odd. I base this on the following code:

Key:ON
Charger: OFF
0,0,A, 182,149,V, 3.811,3.810,V, 3250,mAh, 0.0,kW, 13,C *
-1,0,A, 182,150,V, 3.811,3.810,V, 3250,mAh, -0.2,kW, 13,C 
-1,0,A, 182,150,V, 3.811,3.810,V, 3250,mAh, -0.2,kW, 13,C 
-1,0,A, 182,150,V, 3.811,3.810,V, 3250,mAh, -0.2,kW, 13,C 
-1,0,A, 182,150,V, 3.811,3.810,V, 3250,mAh, -0.2,kW, 13,C 
-1,0,A, 182,150,V, 3.811,3.810,V, 3250,mAh, -0.2,kW, 13,C 
0,0,A, 182,149,V, 3.811,3.810,V, 3250,mAh, 0.0,kW, 13,C 
36,25,A, 182,143,V, 3.809,3.808,V, 3250,mAh, 6.6,kW, 13,C
5,3,A, 180,147,V, 3.775,3.761,V, 3248,mAh, 0.9,kW, 13,C 
1,0,A, 182,149,V, 3.801,3.799,V, 3248,mAh, 0.2,kW, 13,C 
1,0,A, 182,149,V, 3.804,3.803,V, 3248,mAh, 0.2,kW, 13,C 
-1,0,A, 182,150,V, 3.803,3.801,V, 3247,mAh, -0.2,kW, 13,C 
-2,-1,A, 182,150,V, 3.807,3.806,V, 3247,mAh, -0.4,kW, 13,C

That looks like an IMA start to me. Specifically, the IMA start occurred ~2 seconds after keyON. Thoughts?