mux wrote:In the Leaf, the rapid charger does its own current limiting; all the car does is set a maximum current (120A in the case of Leaf) and a maximum voltage (391V in case of the Leaf). The charger then does constant current-constant voltage (CCCV) charging just like any other battery charger.

The first description/senctence better defines the functionality, since the voltage of the battery increases as it charges. So it's not really a constantvoltage source too during the constant current charging, but limits the max battery voltage as the process completes.

Vehicle asks for specific current and DC charger deploys that. AFAIK 10x per second.It's not CC CV. Vehicle is not limiting according to pack voltage.Vehicle is limiting according to maximum cellpair voltage.

Current from DC station varies up and down. Enabling AC for example. Current risesas peak voltage per cellpair allows more current. And station ramps up.

Alright, holy shit, after a full weekend AND monday of messing up probably everything there is to mess up about this endeavour, I *FINALLY* got my CAN bus bridge to work the way I intended. It now:

- Transparently passes through all CAN messages- Can selectively edit CAN messages ('man in the middle' attack-type stuff)- Outputs every single CAN message as well as possible errors out to a serial port

I have mounted this on my EV-CAN right off the VCM and am currently using it to add the extender pack capacity to the main pack capacity by modifying CAN message 0x5bc (available charge signal). This has the desired effect of increasing the amount of kilometers on the dashboard accordingly.

I'm now going to spend the rest of today making some more logging tools and properly writing firmware for the extender pack. I'll post a video maybe tomorrow (depends, I have a busy week ahead).

I don't think I can convey how big this news is. I'm not the first person to spoof CAN this way, but as far as I know, I'm the first person to do realtime CAN bus manipulation in a working Nissan Leaf, certainly for this purpose. This will allow for unprecedented hacking of these vehicles.

I'm revising the board design and layout, hardening it and selling it soon for $40-50, depending on how expensive the potting is going to be.

And a quick follow-up: I just drove about a kilometer with the module in place, but it did stall once. The firmware clearly still needs some polishing before I can reliably get long-term logs. I hope to have this done by thursday, which is when I need the car for a longish trip. Then I should be able to log all CAN messages during a drive to a computer and I"ll post it here.

And another follow-up: I just finished up the entire thing. I fixed the bug that caused the firmware crash earlier and I got the extender to properly talk to the VCM. The car now correctly displays the remaining range based on the total capacity of all batteries in the car.

Alright, holy shit, after a full weekend AND monday of messing up probably everything there is to mess up about this endeavour, I *FINALLY* got my CAN bus bridge to work the way I intended. It now:

- Transparently passes through all CAN messages- Can selectively edit CAN messages ('man in the middle' attack-type stuff)- Outputs every single CAN message as well as possible errors out to a serial port

I have mounted this on my EV-CAN right off the VCM and am currently using it to add the extender pack capacity to the main pack capacity by modifying CAN message 0x5bc (available charge signal). This has the desired effect of increasing the amount of kilometers on the dashboard accordingly.

I'm now going to spend the rest of today making some more logging tools and properly writing firmware for the extender pack. I'll post a video maybe tomorrow (depends, I have a busy week ahead).

I don't think I can convey how big this news is. I'm not the first person to spoof CAN this way, but as far as I know, I'm the first person to do realtime CAN bus manipulation in a working Nissan Leaf, certainly for this purpose. This will allow for unprecedented hacking of these vehicles.

I'm revising the board design and layout, hardening it and selling it soon for $40-50, depending on how expensive the potting is going to be.

mux, Is there a possibility that this programmable "spoofing" of the CAN can be used to hack a pragmatic solution that allows the bi-directional CHAdeMO protocols to be used to design a charge/discharge controller so that my Leaf can be used as the energy storage for my solar system? Both Pika Energy and SolarEdge use a DC bus design philosophy with their proprietary (expensive) home storage batteries that are essentially functionally the same as my Leaf's battery. Seems it should be a matter (likely NOT simple) of proper battery management based on external operating requirements (charging when excess energy is available (solar or grid) and discharging when externally energy is required - operator demands).

Yes, totally. Note that to implement CHAdeMO, you do need to have direct control over the contactors as well. But yeah, this could very well be a CHAdeMO controller as well. Will require some significant engineering and programming, obviously.

I'm told that 2013 and later model Leafs have bidirectional energy capabilities and can be used with the Setec Power V2H unit and the Nissan V2G units (vapor-units???). Appears this is very worthwhile hack to use with a commercially available (~400 VDC) bus system (Pika Energy in particular). Pika has no interest however as they want to sell their proprietary (yes very expensive) battery. I don't really blame them however as they likely don't want to be involved in the already problematic battery degradation issues of the Leaf.

Since I'm not an electronics designer with any in-depth CAN, microprocessing, circuit board design experience, I'm simply hoping a DIYer or startup company will produce the basic design of the required controller. It seems you have mastered the external battery charge controller functions which would seem to be the critical factors in the design of the solar/grid based charge (discharge) controller. The Bolt purportedly uses PLC protocols over the DC bus to do the controls - that might be simpler? AND having a 60 KWH battery would result (my case at least) in almost total independence from the grid for my house with properly designed solar/backup generator system.

The arguments that such dual functional use of a large EV battery will significantly increase degradation would not seem to "hold water", IF the controller was "smart" and minimized the rapid and hot charging of quick charging AND the amount of overall rates of power transferred in/out over time from the solar system was relatively small compared to the normal driving habits. (likely TBD!)

My guess is that over the next few years, as most EV batteries become 300+ mile range capable, and most driver use 10% of the energy daily, this concept will eventually gain traction. May have to just be patient.

I finally got time to process the parallel cell data for LG HE4 in 3p, 4p, and 5p in order to extrapolate how many in parallel I would need to get acceptable charge/discharge rates on not just the LG cells, but also my currently purchased Hyundai PHEV cells, since they're pushing a bit above the spec at 8.6C discharge (max specified 6.9C).

Based on the estimates I would need only 3p to make the Hyundai pack safe to use across the entire discharge SoC range, but the LG cells won't be safe to use for max discharge until 7p (672 cells total, $2032.80 at $327/kWH) and 10p if you include quick charging (960 cells total, $2904). I'm still pursuing other options, my next cell candidate is the Sony VTC4 as mentioned previously, I just purchased 20 of these to test in various parallel groups. The base cell spec is considerably better, with up to 12A pulse charge spec, and 30A discharge, so I expect this to be safe in as low as 2-3p.