I look forward to helping recoup some of this cost when it's out of beta!
|old code (LTC demo code)||new code|
|number of c files||1||4|
(239, 154, 95, 31)
|wild use of magic numbers?||yes||minimal... to be designed out|
|enigmatic variable names?||yes:|
cfg, adcv, ADCV, rdcv, RDCV, wakeup_sleep,
len, data, r_config, cmd, cmd_len, rdcv_reg,
parsed_cell, adax, md_bits, dcp, ch, chg,
|enigmatic function names?||init_cfg (no initiation actually occurs)|
set_adc (doesn't actually set adc)
adcv (same name as variable)
adax (on surface looks like it gets called... never does)
rdcv (same name as variable)
OMG that is awesome and should be its own project. I use that library for my NiMH conditioner/tester and only use it for reading voltages because I never had the bandwidth to figure out the balancing code (and I had an alternative). If you can break that out as a separate project, you are going to be a hero to many people.Holy smokes... I somehow convinced myself to rewrite LTC's LTC6804 library from scratch.
Maybe later. Not my top priority right now, particularly since the full feature set isn't implemented yet.OMG that is awesome and should be its own project.
I haven't implemented cell balancing into a snazzy "dischargeCell(cellNumber)" function yet, but I just happened to have outlined exactly how to do that here (search "control cell discharge FET"). You basically set whichever DCC[n] bits you want to enable cell discharge on, and then you send the six CFGR bytes to the IC.I use that library for my NiMH conditioner/tester and only use it for reading voltages because I never had the bandwidth to figure out the balancing code (and I had an alternative). If you can break that out as a separate project, you are going to be a hero to many people.
My goal is to finalize that soon... I keep running into roadblocks that prevent it from working, and then end up spending hours rewriting entire sections of code. This should settle down now that the architecture is siloing itself into neat little piles.I'm hanging on for the variable VPIN hardware mod to be finalised before I reinstall my pack in the car..
lcd_refresh(); LTC68042cell_nextVoltages; key_update(); gridCharger_update(); adc_update(); battsci_update(); metsci_update(); vPackSpoof_update();
Should be really easy to swap the pin if you just add a jumper on the back of the Arduino from the current pin to the new one. Just leave the current pin as an input (high-impedance) and enable the new one.So obviously on the next revision I'll swap to a different PWM pin, and then run at 62 kHz... which will resolve the issue entirely. But for now we'll either need to change the firmware (annoying, as described above), swap the pin manually (hard), or just stuff more capacitance onto C13 (see above).
technically correct, the best kind of correctDidn't work too much on VPIN spoofing today...
...LiBCM was running so fast that it was making decisions prior to reading back all cell voltages from the LTC ADCs. Specifically, the loop now runs 7x faster than LiBCM can read all QTY48 cell voltages. Note that each loop now reads QTY3 cell voltages, whereas the old, slower version read all QTY48 cells each loop.
The primary issue this 'causes'* occurs when the key first turns on:
The "actual pack voltage" the MCM expects to see on connector E - which LiBCM man-in-the-middles - isn't constant.
As LiBCM reads each QTY3 cell voltages back, the pack voltage LiBCM 'sees' increases by ~10.5 volts. Since LiBCM must know the correct pack voltage in order to correctly spoof the voltage seen on MCM'E', this causes the MCM to panic.
*Note: Speeding up the loop didn't 'cause' this issue, but rather it just made it present itself. The underlying issues always existed... LiBCM was previously just too slow for it to matter.
To fix this, I've added a flip-flop frame buffer:
-One frame always contains the latest complete set of cell voltage measurements retrieved from the LTC ADCs.
-The other frame is a "work in progress", while each cell voltage is read back and stored from the LTC ADCs.
-As soon as all cells are read and stored in the "WIP" frame, it becomes the "complete" frame.
-Simultaneously, the previously "complete" frame becomes the new "WIP" frame, and the cycle continues forever.
When the key first turns on, LiBCM immediately starts reading each cell voltage, storage each result in the "WIP" frame. During this time, each cell in the "complete" frame remains "0.0000" volts. But the MCM doesn't care about that... it's really only the linear rise that upsets the MCM. Then when all QTY48 cell voltages in the the first "WIP" frame are stored, it becomes the "complete" frame and so the pack voltage immediately jumps from "0 volts" to "170 volts" (for example). The MCM likes this.
Other positive results:
Since we only ever compare voltages on the "complete" frame, we know for certain that all ADC cell voltage conversions happened at approximately the same time. Whereas the initial implementation could have allowed voltage comparisons using ADC data taken at vastly different times (i.e. when the oldest cell voltage ADC conversion was compared to the newest). That could be up to QTY16 runs through the superloop (48 cells / 3 cells per loop = 16 loops to retrieve all cell voltages).
This issue could certainly have been resolved by initializing with dummy voltage data, and adding a delay to the code... but that's sloppy and would likely cause problems later. The flip-flop frame buffer is the technically correct solution, and it's completely transparent to anything outside the file it lives in (i.e. LTC68042.c).
This is the ideal solution... however I'm using every pin I routed out, except for the uncommitted "GPIO" pin... which isn't connected to a timer. Therefore, I'd first need to move another timer-pin's signal (e.g. TEMP_SENSOR_EN) to that GPIO pin, and then I could move VPIN_OUT to that TEMP_SENSOR_EN pin. If it's required, it's probably going to require a wire cut somewhere on the PCB, and then two soldered wires across four Arduino thru hole pins.Should be really easy to swap the pin if you just add a jumper on the back of the Arduino from the current pin to the new one. Just leave the current pin as an input (high-impedance) and enable the new one.
I've run into the timer problem before, it's why I don't like to use Arduino on big projects. I tried to use all the timers and was unable since one of them is tied so deeply into the Arduino code.
Ha, youtubez is still processing the 4k .I didn't know it was still possible to film a 360p video in 2021.
Thanks! Take a peak at the firmware architecture... much improved. Honestly I think it's taken its final form; I no longer see any reason to add a cooperative scheduler. So now it's time to add all the bells and whistles.Great work!
R.I.P. CVT splinesDaydreams in broken cv shafts
That's nice to know.I no longer see any reason to add a cooperative scheduler.
I put 7600 miles on my HCH last month which included Death Valley, Baker (100+ degrees), Vegas, Utah with several climbs past 10,000 ft and many past 5000 ft, on hot days. Even saw a couple of camouflaged unreleased Kias going up the passes out of Death Valley, one towing a trailer. Would the IMA motor withstand being hot-soaked in Death Valley or Baker and then being asked to deliver 200-250% climbing up the steep passes leading out of them (perhaps trying to maintain speed if someone is behind them?)Based on what I know about the MCM, that'll limit maximum assist to 124 A (with +40%).
No idea, not a priority. I do know the following:Would the IMA motor withstand being hot-soaked in Death Valley or Baker and then being asked to deliver 200-250% climbing up the steep passes leading out of them?
See above.The car may back off what it thinks is 100% - 10 kW - after a few seconds. But 5 kW still could work out to more than twice that actually. Can the car handle it in such conditions?
I agree, but it'll be a long time before that makes my list of "exciting things to do today". I doubt the MCM's OEM drive signal will overheat the motor, but I agree someone should test it. @Bull Dog knows much more about the OEM BLAC motor's thermal capacity than I do.I think that is something that needs to be characterized to see if there is a risk of motor failure, or a temporary thermal shutdown of the iGBT (thinking Insights with no AC).