Honda Insight Forum banner

401 - 420 of 456 Posts

·
Registered
Joined
·
1,036 Posts
I won't have time to look at code until this weekend. But I did notice a couple of things (yes, I saw the MVP caveat, and no, I am not current in this space, so this all comes with a grain of salt.)

First, a nit, is that digitalRead returns an int (ugh). You have it going into 8 bits. I am pretty sure the compiler handles the narrowing properly, but may be issuing a warning. Arduino has warnings mostly off by default. Turning them on can help catch issues. Perhaps use the data type returned by digitalRead (ugh) or explicitly cast the return of digitalRead to uint8_t (ugh ugh).

Second, another nit:

delay(220); //forcing buffers to overqueue

I abhor all use of delay(); because everything blocks. I do use it but usually only in setup(). For periodic stuff I use a small library that lets me specify when a function should run later, and in loop I look at a list of those functions and their future run time to see which should be run next. The "scheduling" call in my library is simply runLater(someFunction, 500). someFunction is the name of the function to be run later; for simplicity it returns nothing and takes no parameters. runLater is basically accepting a function pointer. 500 is how much later in milliseconds. runLater simply calculates the future run time (millis() + 500 in this case) and stores this with the function pointer in a list in order of expiration. Then once per loop, another function called from loop simply looks at the top of the list to see if it is time to call the function there, so there is very little overhead when something is queued to run later. When it's time, it simply calls the function.

Using this I have abolished delays from my code. It is definitely "cooperative" in that if a function does not return promptly things stall. Data corruption when one thread writes into a variable that another cannot read atomically is not an issue because no interrupts are used; every function is simply called from loop() and must return before another can be called. No timers are used except what millis() already uses. Arguably each "runLater" is a scheduling of a "thread", but this is the complicated way of looking at it. Really, it's just a way to have something happen after an interval without blocking the system. It's just wrapping a time check to see it if is time to do something in a couple of functions.

(I had written this originally to replace delay and call code after a timeout and thought of it only as a way to get a delay without blocking all execution. It took someone else to tell me it was a cooperative multitasker. I briefly poked around some of the multitaskers for Arduino and decided to stick with this simple approach.)

You mentioned you were planning to use a cooperative multitasker. If you really don't need all the baggage and handling timeouts and periodic events is all you need, consider this approach.

There are some great answers on stack overflow about unit testing and things like inversion of control. I mention this here because I'm also a fan of Serial.print debugging, but am ready to refactor my NiMH conditioner and coming up with a methodology for unit testing before doing that seems like a good idea, given the number of frustrating issues I found in rev A that would have been caught if run first in a test framework.
 

·
Linsight Designer
Joined
·
2,371 Posts
Discussion Starter · #402 · (Edited)
digitalRead is slow, but it does type cast correctly when stored in a uint8_t... in other words, there's no need to specifically cast myvariable = (uint8_t)(digitalRead(pin)). Compiler handles that. Of course you are correct that digitalRead is (ugh), but for an MVP it's sufficient.

delay(220) isn't permanent... as the comment suggests, I'm intentionally forcing the buffers to overflow, to verify LiBCM correctly discards old, stale data. Specifically because of this delay(220), LiBCM ends up throwout out about 25% of the data without processing it, because it "runs out of time" (i.e. it's intentionally stuck in a while loop (inside delay()).

Rest assured there are MANY more examples of poor embedded programming practice in the MVP code... and they will remain there through the beta phase... once I ship the beta testers hardware, then I'll have time to get rid of the superloop and build an actual multitasking architecture... you can look through my commends for many instances of "//when multitasked, this needs to be done differently by doing ___".

Right now I'm going to spend a little more time tidying up the code as it exists now, such that it's good enough to drive 1000 miles to Austin, which I'll be doing as soon as the PCBs arrive.

I'm not convinced reviewing the code as it exists today is worth your time and effort. I'd save that for later on in the beta phase.
 

·
Linsight Designer
Joined
·
2,371 Posts
Discussion Starter · #405 · (Edited)
"Minimum Viable Product"
It's basically what a company shows off before the product is actually ready for primetime... the engineers are biting their fingernails off behind the scenes, since anything beyond the "happy path" will cause the wheels to fall off.

MVP is the next step after POC ("Proof of Concept").

...

Unrelated: I really enjoyed reading Paul Graham's latest essay. His previous essay also resonated with me (in a self help/improvement sort of way).
 

·
Administrator
Joined
·
12,892 Posts
Nice video. (y)

In all my BCM Fooler resistor matrix systems the MCM E Input always saw the same voltage as was across the BCM taps 10 x 10k resistor matrix.

When I wanted to lower the voltage the BCM and MCM E saw I just inserted resistors into the + feed.
So we had say 10 x 10k for the BCM taps (100k) then perhaps with another 10k resistor in + feed.

In effect a 100k/10k potential divider

I never had a problem with the sampling issue/capacitor in the MCM you mention.
But the impedance of my matrix + pre resistor across the HV was 110K.

So about 1.5ma drain across the divider.
Let's call that 270mw dissipation across the 11 x 10k resistors.

I also used a tiny HV opto so the divider was only powered when the ign was on to avoid any battery killing long term parasitic drain when the ign was off.

The MCM VPIN input has an internal 100k pull down, so inserting the same value pre resistor (10k) in that line reduced that voltage by the same amount as the BCM/MCME.
Everything matched. ;)

Sounds like you just need to adjust the impedance of your MCM E input.
 

·
Linsight Designer
Joined
·
2,371 Posts
Discussion Starter · #407 · (Edited)
Thanks for the MCM'E' info. I'll use that info to figure out the best solution... I agree with you that it's likely sinking more current across the voltage divider.

...

I'm looking over the data I gathered in the video above:
Peak assist was 71 amps at 158 volts, which is 11.2 kW assist.
The local minimum around that event was 10 amps at 162 volts, which is just a 4 volt drop across a 61 amp delta. This works out to a pack ESR around 65 mOhm, which is about what we estimated it to be... certainly very good.

Starting pack voltage: 179 volts

Final pack voltage: 174 volts

minimum pack voltage: 157 @ 44 amps assist, just before getting to the top of Lookout Mountain

maximum pack voltage: 180 @ 33 amps regen, just before getting to the bottom of Lookout Mountain

Note that MCM is entirely stock at present.

...

I'm not sure what conditions are required to 'unlock' 100 A from the MCM. Any guidance? My understanding is I need to be in 2nd gear... do I also need to be redlining the car? I've never really paid attention to the amount of assist the MCM is providing.

I must say driving up Lookout Mountain in 4th gear is a first.
 

·
Administrator
Joined
·
12,892 Posts
In my recent CR-Z Nimh work I have been using two set voltages for the IMA system.

Voltage A which is a normal sort of average voltage, lets call it 160-165V for the G1..

With that sort of fixed voltage the BCM/MCM/ECM will not try and start voltage related charging or restrict regen.
The SOC can be completely independent of this fixed fake voltage. You can control that with QBATT etc.

Voltage B which is the maximum power point (MPP) voltage, and the voltage at which the MCM will deliver the most current.

This is ~120V (1V per cell in the standard Insight) Anything below that and assist starts to throttle back dramatically.
Higher voltages than that also proportionally reduce MCM current as it is trying to maintain a set Kw output.

So I have two modes.

Normal driving which was my fixed 160V or so. (You can have variable/natural voltage)

WOT which fixes the voltage at ~120V for maximum IMA current while the pedal was to the metal.

The difference in IMA power/current between a fixed 160V and 120V can be in the order of a few kw so it is worth doing. The higher your actual battery voltage the greater the gain!!!!

Even if you allow a variable voltage for normal use, the fixed 120V for WOT is very useful.... ;)

If your reported/actual voltage is say 165V the car (MCM) might only allow 70A of current but if it thinks it is only 120V it might command 90A+
(These figures are of course without the current hack or IMAC&C)

That extra 20A of current at an actual 165V = 3.3kw. :p

The stock ECM only commands certain assist levels at certain times and in certain gears and cuts back quickly of its own accord. It's a law unto itself.

To unlock the full motor melting power potential from the MCM you need manual IMA control as well as the current hack and voltage stuff I have mentioned above.
 

·
Linsight Designer
Joined
·
2,371 Posts
Discussion Starter · #411 ·
@Mario
It turns out the SBH11-PBPC-D10-ST-BK ribbon header I'm using has latching lugs built into it. You could therefore use a mating, latching connector. I've already purchased QTY200 of the non-latching connectors, but if you want latching support, it's available by swapping the connector. Certainly for the beta units I'll be using non-latching connectors. I'm still not personally concerned that the ribbons will come loose (famous last words). Rest assured I'll be testing this during my road trip to Austin next week.

@retepnikrep
Thanks for all the advice, Peter! You've got years more experience working with the OEM MCM than I do... as you know, my initial goal back in 2016 was to remove the MCM entirely. Therefore, I only took the time to figure out the signals the MCM was controlling... I didn't take the time to learn all its oddities and quirks.

Using the information you provided in your previous two posts, I've determined:
-The (lower) voltage the MCM reads is expected, precise, and uncharging. As you proposed, the voltage difference is almost entirely due to the 100 kOhm pulldown inside the MCM. I have a 10 kOhm resistor in series with both the MCM_E_HVDC+ & MCM_E_HVDC-. For the record, this isn't the first time you've specifically reminded me that the 100 kOhm resistor exists... maybe one day I'll learn.

-Given the above paragraph, the "100%" MCM_E voltage will always be 91% of the actual pack voltage. Then, since LiBCM can vary the MCM_E voltage from 100% to 87%, it would appear that we can spoof the MCM_E voltage from 79% to 91% of the actual pack voltage.

-Therefore, we should expect to be able to spoof the nominal lithium pack voltage as follows:
Actual pack voltage range: 156 to 192 volts.
Spoofed 'full' (4.00 V/cell) pack voltage range: 152 to 175 volts
Spoofed 'nominal' (3.6 V/cell) pack voltage range: 137 to 157 volts
Spoofed 'low' (3.3 V/cell) pack voltage range: 125 to 144 volts

-Thanks for the missing information on how to get to 100 A... it absolutely makes sense that the MCM has some ultimate power limit setting... I was just thinking current, but obviously the voltage matters, too. Derp!

-Given the above, it makes sense to increase the 'spoofing adjustment' range, which means decreasing the resistance value on the voltage adjustment circuit. This will of course increase the power sunk across those two components, but I'll see what I can do without spinning the RevB PCB... higher power resistors are available on the footprint... they just cost more.

It also makes sense that during WOT, LiBCM should spoof the pack voltage to ~120 volts. That's going to be fun!

I've filed CAR025 (otherwise known as 'bugs' or 'issues') to track this issue, and will play around with this more tomorrow. As it stands right now, my tired mind doesn't fully understand why the MCM's measured voltage is even lower than what I'm seeing. I'll spare the details, pending further thought tomorrow.

Note that the statement you made:
"I never had a problem with the sampling issue/capacitor in the MCM you mention"
...would have required you to actually probe the MCM_E connector inputs with a differential probe, as I did this afternoon. However, given your explanation above, while this signal oddity certainly exists, it likely isn't the actual cause of the voltage droop (as discussed above).
 

·
Linsight Designer
Joined
·
2,371 Posts
Discussion Starter · #412 · (Edited)
RevB PCB just shipped. My supplier always sends a tantalizing picture of the PCB tag:
90860


FYI: That's the top left corner, near the bay3 BMS circuitry... the bay3 fan is the large hole at the bottom with "DESICANT SILICA GEL" packet stashed within.

FedEx doesn't yet have a delivery date, but based on my experience it'll be here ~JUN15. That's a bit later than I had expected, but such is the supply chain circa now. I'm ready whenever they arrive.

Slightly related: The USPS guy dropped off a dozen small packages today... all LiBCM parts sporadically ordered over the past week. I've quarantined our guest bedroom as storage space for this project. Most of that inventory will travel with me down to Austin next week.

...

I just sat down and starting playing with the pack connectors. I'm certainly regretting not buying the connector-specific pin removal tool... I've already got a small pile of connectors with unremovable pins (until I get the tool). I'm just going to set them aside for now, and then when I place the next order I'll make certain to add that tool to the order.

Nothing major to report yet, except that there's certainly at least one way they'll fit inside the case.
 

·
Registered
Joined
·
11 Posts
Awesome first functional drive!

I use a program called Megunolink to quickly debug things when I get to this point in a project.
It makes nice real time graphs almost as easily as using the Arduino serial monitor.
The downside is that it's paid software, definitely worth the money though.
Its great for revealing subtle bugs like a 1000Amp blip or the 50Amps limit you may be experiencing with you recent test.
 

·
Linsight Designer
Joined
·
2,371 Posts
Discussion Starter · #414 · (Edited)
Megunolink looks great! I usually just use LabVIEW to visualize my data. It's a jumbo jet, but I know how to use it. Thanks for the recommendation, though.
FYI: The "1000 amp" blip wasn't real... it's just the OBDII's screen update rate causing old and new data to appear at the same time.

...

Given Peter's latest advice, I've once again modified the MCM'E' Connector circuit. At a very high level:

-The old circuit allowed voltage spoofing from 87% to 100% of the actual value.
For example, if the pack voltage is 180 volts, then LiBCM can spoof any voltage between 157:180 volts.

-The new circuit should allow voltage spoofing from 67% to 100% of the actual value.
For example, if the pack voltage is 180 volts, then LiBCM can spoof any voltage between 121:180 volts.

-The new circuit only requires component changes (i.e. the PCB remains the same).

-The new circuit will work with 54S & 48S (I'm using higher power resistors).

Background:
LiBCM can spoof all three HVDC signals that the MCM sees:
-BATTSCI (digital)
-MCM'E' (as controlled by the circuit mentioned above)
-VPIN (LiBCM man-in-the-middles this analog signal)

Therefore, LiBCM can tell the MCM "battery is at 120 volts" whenever it wants (e.g. when the battery current sensor measures more than 50 amps, which indicates that the pedal is all the way down).

...

As Peter mentioned above, the MCM applies peak current around 120 VDC... as the voltage increases, the MCM dials back the current, so that the power does not exceed a specified limit. Based on my brief testing, I believe the maximum power is limited to around 12.5 kW (e.g. 72 amps @ 172 volts).

Thus, by spoofing the MCM voltage lower, we can increase the actual IMA power delivered. I haven't tested the new circuit yet, but if my math is correct, LiBCM should be able to increase output power by ~6 kW (~8 horsepower)... with zero additional modifications (i.e. the vehicle is stock besides LiBCM).

It gets real fun when you add the "+40% current" PCB inside the MCM, and replace the stock 100 amp fuse with a mechanically identical 175 amp version:
Now we're talking about an additional 14 kW (18+ horsepower) on an otherwise stock car.

Of course none of this is new... Peter figured this all out years ago... but LiBCM is going to make it super easy to add a ton of extra power without a ton of extra kludgery. I'm excited to actually test this out and see what happens... just ordered some 175 amp L50S fuses.

...

The digikey parts order, eBay fuses, and PCBs should all arrive middle of next week.

...

FYI: I'm going to spend much less time on LiBCM over the next few days; we've got guests coming into town on Sunday and I need to tend to several duties I've been putting off for the past several weeks.

I've made a list of things to add to the MVP firmware prior to departing for Austin. Beyond that, I don't intend to do much work on the firmware prior to building the PCBs.
 

·
Linsight Designer
Joined
·
2,371 Posts
Discussion Starter · #416 · (Edited)
The stock 100A fuse and the L50S 175A fuse are not identical in size, you have to hack some plastic about the fuse mount to fit it.
You are absolutely correct. Looks like I mis-read the L50S datasheet last night:
90893


While it is true that fuses from 101 to 200 amps are all the same size... 100 amps is in fact less than 101 amps. Whoops, well no trouble... I have zero qualms about hacking a few mm off the junction board.
 

·
Linsight Designer
Joined
·
2,371 Posts
Discussion Starter · #417 · (Edited)
While updating the MCM'E' schematic just now, I decided to make a couple videos.

Here's a pointless video highlighting all nets on LiBCM RevB:

Here's an excellent LiBCM BOM visualization. You'll need to download the RAW file and then open it in your web browser...
...if you trust me... if not, here's a demo video:
FYI: I used this plugin to create the BOM visualizer.

Looks like RevB ended up having QTY613 components, with QTY56 unique part numbers.

KiCAD really has come a LONG way since I started using it in 2013. Boy I love the Open Source community!
 

·
Registered
Joined
·
1,036 Posts
From one serial printlner to another: It looks like someone has written a source-level debugger for Arduino that works on Mega. It works with gdb or visual studio code. I'm chasing a bug on my Mega-based NiMH cell conditioner and was wondering if someone had come up with one yet. Apparently so, in 2018. It does consume a serial port, though. I'm going to check it out. Creating and Debugging Arduino Programs in Visual Studio Code - Part 2

I still need to work out a unit test framework for this thing. I'm thinking of refactoring the code and that would be a good time to do it.

EDIT:

On the Arduino unit test frameworks, a criticism on Stack Overflow is that unit testing should be done not in the target environment. Seems that unit testing is usually done in a mocked framework. I guess when you assemble all the unit tested code into the actual platform that is integration testing.

I was thinking that if things are so bad that source level debugging is needed in actual hardware, opportunities to catch it beforehand - like running candidate code in a mocked environment or even println debugging in that environment, have been missed.

On other projects I wondered how I would run my Arduino sketch in a mocked environment. It would be a lot of work to build the mock or tweak an existing... simulator?... to behave like the real hardware.

But I'm going down that road, because trying to duplicate the failure on my hardware (which uses a LTC6804) is very time consuming as I have to charge the cells in the test stick to where they were during the failure and altering their voltage to create tests for corner cases is a time consuming non-starter.

I think they solution is to refactor the code into a library, with shim functions that abstract the hardware interfaces (and some library interfaces) in a separate library; one shim couples to the mega and ltc6804 and another shim to the other mocked mega.

Then the Arduino sketch is a smallish program that calls the library, and if I need to test or debug a library function I do that from a different program that runs on the PC.

I am getting ready to refactor my cell conditioner code to output to a database. So I'm going to look into this separation of functionality. It seems that Arduino coding is a thing on Visual Studio Code, and this guy's source level debugger works there. So I'll see if I can get something running there. I intend to run some of the LiBCM code in my own LTO build someday, so wrapping it in a library that I can just as easily debug, regression test (especially after each code change) or drop into a wrapper .ino file to run on actual hardware, that would be really useful.

whether or not this can actually be realized, I hope to know soon. My stick conditioner has a half dozen different charge, discharge, and rest modes, and if it works for that, I will be really pleased.

/EDIT
 

·
Engine-Off-Coast
Joined
·
2,049 Posts
# 100 Amps
I just want to throw in on the 100A discussion above -- it should be possible to get max assist at WOT in 3rd as well as 2nd. You can only get max assist for 4 seconds, starting from when you floor the pedal, and then it lowers the current. But you can get it again by letting up a little bit for half a second and then flooring it again. I've seen 100A in both 3rd and 2nd. (My car has 40% hack, not sure if that's relevant? I'm measuring this via OBDIIC&C, with the correct amp hack value setting.)

# Fuses:
I used 150A L70S fuses on the junction boards for the 3 LTO conversions I did. The L70S series will blow faster in case of a short.


lily-junction-board.jpg


The bolt on the right side of the fuse is an OEM IMA battery case bolt with the 12mm head. They're the perfect length to accommodate the wider cylinder of the bigger fuse, but you'll need spacers of some sort.
 
  • Like
Reactions: mudder

·
Linsight Designer
Joined
·
2,371 Posts
Discussion Starter · #420 ·
FYI: I intend to reply to the above posts later tonight. I'm in the zone on this issue right now.

...

Just wanted to add more troubleshooting on MCM'E' voltage spoofing:

Key points from this video:
MCM'E' voltage is much less important to MCM than either VPIN or BATTSCI(voltage) signals. I can get to about 20 volts difference between MCM'E' and those other signals, whereas VPIN and BATTSCI(voltage) must be within 10 volts of each other.

The "is HVDC+/- shorted to chassis?" test ("HVDC-ST") is performed by the MCM by charge shifting a switched capacitor from either HVDC lead (+/-) to chassis ground... this is the reason why the MCM'E' high voltage circuit isn't galvanically isolated (inside the MCM).

The problem with the HVDC-ST circuit is that when you add 10 kOhm series resistance to the MCM'E' connector (so you can spoof it with a voltage divider), that causes the MCM'E' voltage to droop considerably (e.g. 50 volts) each time the HVDC-ST operation is performed.

Certainly the MCM'E' voltage ADC measurement is synchronized with the HVDC-ST ADC measurements (there are two HVDC-ST measurements per MCM'E' voltage measurement). Specifically, the MCM'E' voltage test occurs ~200 ms after the 2nd HVDC-ST test. In the OEM system, this 200 ms delay gives the MCM's HVDC capacitors time to recharge (through a pair of inline 220 Ohm resistors). Therefore, when the MCM'E' voltage is measured, the capacitor inside the MCM has had time to recharge to the pack voltage.

However, the additional dual 10 kOhm series resistance added by LiBCM increases the recharge time by 50x, hence the MCM'E' voltage takes 50x longer to recover after the 2nd HVDC-ST test.

...

There are several ways to fix this problem:
-decrease the additional series resistance value added by LiBCM... this decreases our voltage spoofing range.
-increase the downstream capacitance (either on LiBCM, inline with the harness, or inside the MCM), so that the voltage drops less when HVDC-ST is active.
-do nothing in hardware, then fully characterize the behavior across multiple MCMs, and then calibrate it out (assuming it's consistent).
 
401 - 420 of 456 Posts
Top