Stand alone OBC/PDModule EV system Can 2015 - SOLVED

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I have a Gen2 charger on the bench right now (and do not have access to a complete Leaf)
I've been feeding it your 1F2 adn 1D4 messages that you posted previously, and after several seconds I have been catching a single reply from from with ID:679 and a single empty byte 0x00 payload.
Have you seen this message pop up before?
 
https://www.divemaster.ca/RAV4EV/LEAF/PDM Can Monitor March 23.xlsx

Hi folks, I dropped off this list for a few months and have just been catching up.
Looks like some progress was made in understanding whats happening but I am not sure if anyone got it going reliably.
I have been distracted with the RAV4 EV pack conversion. I have been able to run the RAV4 EV from the leaf pack now and by spoofing the RAV into thinking it has the original pack we were even able to get the factory paddle charger to charge the leaf pack. We intend to use the leaf BMS to feed the RAV4 ECU.

Anyway as far as the OBC/PDM is concerned the link above is my data collection spread sheet from a working 2015 using MUX's man in the middle CAN device. Thanks Mux.
Many of the commands mentioned are clearly recorded here including the 393
I hope to get back on to this project by the end of next week.

Any updates ? is the above helpful, I note there is a better data base on github I have downloaded the DB tool and am looking at that now.
Thanks to everyone who is working on this.

Peter
 
Regarding message 0x679 I get this every time I plug or unplug the j1772 plug from the car. I believe it originates from the OBC as do messages 0x390 and 0x393 which follow 0x679
 
I am about to launch into another session with the OBC. Reading thru my notes, my can capture logs and the conversation here I can say the charger needs more than the 1F2 and 1D4 commands to function. I can say this because my set up includes most of the electronics except the BMS the Inverter and ABS specifically and the 1F2 and 1D4 commands are being provided by the VCM.

This is what it my set up looks like. The laptops and the can bridges are off to the side with the OBC and there is 380 volts of batteries on the floor. I am using the precharge relay and main relays from my RAV4. (so far they do not kick in).

Leaf%20on%20Plywood%20Two.jpg


As you can see in the data lists below the 1F2 and the 1D4 commands are being provided by I assume the VCM. I have not isolated the VCM with the Can Bridge to confirm yet. I have however isolated the OBC with the bridge and can confirm that the 679, 390 & 393 commands originate with the OBC.

I have two recordings here, one from a working car and the 2nd from my "Leaf on Plywood" test bed.
Sorry for the poor and different formats. I would be kicked off the android forums for it ;)
You can see that starting at line 4 of Al's Leaf there are 5 commands not present in the Plywood leaf.
I plan to insert these missing commands into the Plywood Leaf dialog one at a time to see what happens.
The comments on the left are either from some of the data that is out there that you are all familiar with or my own.
All advice and comments appreciated.

Al's 2015 100% functional Leaf ;
-------------------------------------------
J1772 Plug detection from OBC......... 0x679 0x0
On board Charger (OBC).................... 0x390 0x4 0 0 0 0 80 3C 7
On board Charger............................... 0x393 0x0 10 0 0 20 0 0 2
VCM Car wakeup cmd......................... 0x50B 0x0 0 0 C0 0 0 0
Possible VCM related to charge......... 0x54A 0xDA 80 70 E 0 0 0 54
Possible VCM related to charge......... 0x481 0x4B 0
Possible VCM related to charge......... 0x54B 0x10 8 80 0 4 0 0 0
Possible VCM related to charge......... 0x54C 0x59 FF 0 0 0 F8 FF 0
Possible VCM related to charge......... 0x54F 0x14 0 0 0 8 40 C0 14
Back ground messages VCM.............. 0x1F2 0x0 64 4 A0 0 1 0 83
Back ground messages VCM.............. 0x1D4 0x6E 6E 0 0 2 6 E0 CA
Possible VCM related to charge......... 0x50A 0x4 80 0 F 0 2 4 0
Possible VCM related to charge......... 0x50C 0x0 0 0 0 5D C8
Possible VCM related to charge......... 0x5A9 0xFF FF FC FF FF F7 FE 0
Back ground messages VCM.............. 0x1F2 0x0 64 4 A0 0 1 1 84
Back ground messages VCM.............. 0x1D4 0x6E 6E 0 0 42 6 E0 D
Back ground messages VCM.............. 0x1F2 0x0 64 4 A0 0 1 2 85
Back ground messages VCM.............. 0x1D4 0x6E 6E 0 0 82 6 E0 C1
Possible VCM related to charge......... 0x45E 0x0
Possible VCM related to charge......... 0x5B9 0x7 FF 7 FF 2F FF 80
Back ground messages VCM.............. 0x1F2 0x0 64 4 A0 0 2 3 87
Back ground messages VCM.............. 0x1D4 0x6E 6E 0 0 C2 6 E0 6

The Plywood Leaf : Including OBC, VCM, BCM, MWI,IPDM not including BMS, Inverter or ABS
-----------------------------------------
J1772 plug in....................................... 679 0
OBC:380, Byte1=04 is ac charge....... 390 04000000008C3C03
From OBC 49thdiver.......................... 393 10000020000002
VCM Car Wakeup command............. 50B 000000C0000000
From VCM : Charge Power................ 1F2 646404A00000038F
Motor Amps : From VCM................... 1D4 6E6E0000C006E075
Temperature ?..................................... 50A 042800FF00020400
VCM wake/sleep request signal........ 50C 000000015D5F
SOC ? 1 & 2 = FF while chg................. 5A9 FFFFFCFFFFF7FE00
VCM...................................................... 11A 008000AAC0000067
Charge Power..................................... 1F2 046404A000020088
Motor Amps........................................ 1D4 6E6E00000206E0CA
VCM...................................................... 11A 80005500000171
Charge Power...................................... 1F2 046404A00004018B
Motor Amps......................................... 1D4 6E6 E00004206E00D
VCM....................................................... 11A 00800055400002BC
Charge Power...................................... 1F2 046404A0000A0282
Motor Amps......................................... 1D4 6E6E00008206E0C1
VCM....................................................... 11A 008000AA800003AA
Charge Power...................................... 1F2 646464A000290380
Motor Amps......................................... 1D4 6E6E0000C006E075

Sorry for the funky formatting, if any one knows how to do formatted tables or tabulation I can fix it.
 
VCM 0x50B contains the wakeup/sleep command which most of the EV drivetrain requires to see.

0x603 and 0x679 are wakeup messages. 0x603 from VCM and 0x679 from the charger.
 
The journey continues:
I have started sending CAN Commands 54A and 481 with the appropriate data as posted earlier.
I have the man in the middle between the charger and the rest of the EVCAN bus streaming data to a terminal screen. I have a recorder and a play back device on the charger side of the MIM.
I was getting some relay clicks internally in the IPDM. I opened up the IPDM to figure out what was going on with the relay clicks and found that it is the F/S relay. Beware of the difference between the F/S relay (j1772) and the F/S CHG relay (chademo). The commands sent cause the F/S relay to kick in the VCM responds with the usual commands back 1f2,1d4 etc and the OBC even responds with 390 and 393 commands. Other than that nothing else different has happened.

The IPDM is connected via CAN and I assume that the "CPU" receives the appropriate command to turn the F/S relay on.

This is a diagram of the IPDM with the relevant circuit board detail. I added an LED to the F/S relay circuit so I could see when it comes on.

IPDM%20discovery.jpg


There are some board photo's here : https://photos.app.goo.gl/GTFeUP7SHQ1jBUNW6
check the info for descriptions.

Something other than commands is preventing the charger from powering up. I am going to double check all my connections.

Just a note in passing I manually engaged the Chademo F/S CHG relay to see what would happen, nothing obvious happened but it caused a DTC error (unknown) that locked down the VCM from responding to my inserted commands. I used LeafSpy Pro to clear the DTC's and resolved that thankfully I was beginning to think I had bricked it or blown something up.
While on the DTC subject I have 25 to 30 DTC's mostly not critical I think from systems not connected SRS, ABS, BMS, etc. I am not yet convinced that they are preventing the charger from powering up. I may have to connect the BMS which I do not have here, it is still in the battery pack. If I do not make any progress past this point I will try and post a wiring diagram of what I have so far.
Any suggestions appreciated.
 
Dear 49thdiver, you have done a great job.
I can't start the charger yet either. Could the PDM use the motor as a transformer?
Second point. When the PDM module is started on the working machine, a quiet whistle of the converter is heard. I think it might be using some command CAN.
 
ybpvin said:
I can't start the charger yet either. Could the PDM use the motor as a transformer?
I don't think so.
The one part however that is required is the main capacitor bank from the inverter.
The system watches the voltage across the capacitor once the precharge relay & resistor are turned on. When the voltage across the capacitors either stops rising or reaches some maximum it allows the VCM to turn the main relays on.
ybpvin said:
Second point. When the PDM module is started on the working machine, a quiet whistle of the converter is heard. I think it might be using some command CAN.
I have not noted this, when I have access to that car again ,probably next week, I will check that.
In my experience a "whistle" sound is usual associated with an inverter it might be the DC to DC converter.

I am just finishing up my wiring check and connecting a couple of other systems to reduce the DTC errors.
Airbags is interesting I found out you can put a 2.2-3 ohm resistor in place of the air bag and seat belt pretensioner to make the box think it's ok :)
Thanks for the feed back.
More to follow.
 
July 18 2020, a lot of work was done but no significant progress made.
What I have learned for sure and is repeatable.
Cmd's 679, 390 and 393 originate with the OBC/PD
Cmd 679 indicates that J1772 charger has been plugged in.
Cmd 605 indicates that the immediate charge button has been pressed.
I have been inserting the following commands strings on to the EV-CAN bus, they all initiate a start up sequence that is similar to plugging in the charger.
1- 54A followed by 481 : Two responses from recorded from a working car : no change to test platform response
2- 605 followed by 50B : Immediate charge button sequence : no change to test platform response
3- 679 followed by 390 : plug in charger sequence : no change to platform response.
4- 1D4 is the only one that does anything, it initiates the same start up sequence.
5- 1D4 I think triggers the OBD/PD to transmit the 390 and 393 commands and the VCM responds accordingly..

It's worth noting :
1- commands must be 300ms apart or less.
2- 393 is not required to initiate a start up sequence.

I have manually entered all of the other commands recorded during a working cars charge sequence one at a time or in the sequence recorded with no other responses.
All of the above has been brute force insertion either when the car is sleeping or when a charge sequence has been initiated by plugging in the charger.

I plan now to use Mux's man in the middle to insert commands in a controlled manner hoping that it makes a difference.
I am concerned that perhaps my charger is just not working, it came from a wrecked car that we were unable to get fully functional including charging because the of the extensive damage to the motor, inverter and wiring. I am actively looking for another car and may have to let this rest until I get one.

Here is a nice picture of the 16 bit micro-controller that runs at least the communications of the OBC/PD. It has built in CAN BUS controller. If you search for RENESAS M16 R5F35 you can find all kinds or great information.
OBC_PD_controller.jpg


Stay tuned.
Peter
 
No significant progress to report however a lot has happened. Code snippets below.
I have successfully modified the Can Bridge software to transmit the 5 messages in sequence missing from the can bus dialogue in an attempt at stimulating some response from the charger. Essentially after the first 3 messages from the charger "679, 390, 393" and a 4th message/response from the VCM "50B" as a result of plugging a live j1772 plug into the charge port as documented earlier. I have inserted 5 messages recorded from a working leaf "54A,481,54B,54C and 54F".
I had initially set the trigger with the 50B message, I have also tried triggering it on 679 and 11A messages as there is a time slot after each of these that I was able to insert the messages cleanly in sequence. Inserting them immediately after 50B ends up spacing them out between other VCM generated messages (not clean).

Any suggestions or idea's of where to go next appreciated. I am still trying to acquire a complete leaf for more testing as I still suspect something is wrong with the charger I am using or the lack of a BMS to complete the communication may be the issue.

NO APOLOGIZE, programming in C is not something I am good at so there may be better ways to do what I have done, I can only say that it works as expected.

The significant code changes are as follows: (with the full code linked below) and of course the original source is from emile_nijssen-open-source-can-bridge-f3a419e03747 on GITHUB. This works on the Muxan Bridge MITM but could work on any dual MCP25625 circuit if modified.

  • .......................These are the messages I am inserting...........
    struct can_response array_response[5] = {
    {0x54A,8,{0xDA,0x80,0x70,0x0e,0x00,0x00,0x00,0x54}},
    {0x481,2,{0x4B,0x00,0x00,0x00,0x00,0x00,0x00,0x00}},
    {0x54B,8,{0x10,0x08,0x80,0x00,0x04,0x00,0x00,0x00}},
    {0x54C,8,{0x59,0xFF,0x00,0x00,0x00,0xF8,0xFF,0x00}},
    {0x54F,8,{0x14,0x00,0x00,0x00,0x08,0x40,0xC0,0x14}},
    };..........................

and (sorry for the formatting)

  • ...........This is the core of the code that does it
    .................//test_can_msg and send to serial always moved here to stream line debugging

    SID_to_str(strbuf + 2, frame.can_id); // build frame for serial ....
    canframe_to_str(strbuf + 6, frame);
    print(strbuf,23); // now send to serial
    // CAN message modification routine ////// NOTE I HAVE swapped 50B AS THE ORIGINAL TRIGGER, AND have tried 679 and 11A
    as there are time slots that the response can be squeezed in.

    switch(frame.can_id){
    case 0x50B: /// see above
    for (int j=0; j <5; ++j){ // build 5 messages that need to be inserted
    for (int i=0; i <array_response[j].can_response_dlc; ++i){
    frame.data= array_response[j].response_data; // actual to frame done here
    }

    frame.can_id = array_response[j].can_respone_id;
    frame.can_dlc = array_response[j].can_response_dlc;
    calc_crc8(&frame); /calculates the CRC using radix 0x85 and put that CRC in frame.data[7]

    //send command
    _delay_ms(0.7); // This helps with data overflow on Can 2 but not much??
    send_can1(frame);.............................


Full modified code here : https://www.divemaster.ca/RAV4EV/LEAF/MUX Bridge code/can-bridge-firmware.c
https://www.divemaster.ca/RAV4EV/LEAF/MUX Bridge code/can-bridge-firmware.h
https://www.divemaster.ca/RAV4EV/LEAF/MUX Bridge code/mcp25xx.c

Foot note : I have one MUXAN bridge as a MITM between the OBC/PDM and the VCM doing the work and I have one arduino based MC2515 on each side of the bridge monitoring the resulting input and output. The monitoring allows me to be sure the code is doing what I want it to do. I also have a third arduino monitoring the CarCan just for fun at the moment. (which runs full time with messages when the car is in the off position). It's no wonder the battery discharges over time.
 
Note that you shouldn't ever insert delay loops into interrupt-driven code! The CAN bridge has its own internal buffering routine that buffers multiple messages for sending, you shouldn't get buffer overflows in any kind of normal code. If you're encountering overflows, break up the amount of messages you're sending and send them e.g. in the TCC0_OVF interrupt.

I'm also not sure if sending these messages one-time only will be sufficient. I think you're going to need to send a bunch of these periodically. As 0x679B is a one-off insertion detection messages, it won't be a reliable trigger for sending the rest. So again, try inserting them in the timer interrupt.
 
Thanks Mux for the quick response. Sorry I was not clear in my posting, the switch had the wrong case test listed I have corrected that on the posting. I have deleted the delay as indeed it was introducing other problems. I have been triggering on 0x50B which as far as I can tell is a response from the VCM to the three messages from the OBC 679,390 & 393 when you plug in the charger. 0x50B is sent fairly regularly and the message sequence is inserted at every instance. On the working car that I am using to record the events, the message sequence I am inserting only happens the once on the working car. I was only trying the other trigger events to try and avoid the overflows.
Thanks for the tip on using the ISR to insert the messages. My knowledge of C and this micro controller architecture is limited so this advice is very helpful. I assume to speed things up a a bit I could replace the keyboard command checking (as I am not using it) with code to insert my messages. I could also eliminate checking the 3rd mcp25625 as I am not using it at the moment either. It seesm to me from the time stamps I am using on serial port that the messages are coming pretty fast at < 100usec. I really need to get regular access to a working car now that I have got this far with understanding and being able to monitor and trigger the message handling. I will keep plugging away in the meantime. I ordered another bridge from you it should arrive this week, I plan to put that at the VCM initially to confirm that it is the message source for the 0x50B and later when I get another car at the BMS to monitor that messaging.
Thanks again, more to follow.
 
You've come far for not quite being familiar with interrupt-driven bare metal 8-bit C.

Some pointers to help in the meantime:
- There's no harm in keeping the keyboard check, it's a very fast routine when nothing's happening and most of the underlying USB stuff is interrupt-driven anyway. And the nice thing is that:
- You can use the '@' command to turn on/off CAN logging, which is beyond useful in this kind of application. Don't forget you can add other stuff as well to your liking.
- Just add the message send routines to the timer interrupt. No need to remove or replace anything there. Note that the timer triggers every 1ms, so you need to add a case that triggers every 100 cycles for a message that you'd like to send every 100ms. Then you're not dependent on other messages as triggers, and you're unloading the CAN checking routine which will improve performance of the application.

I don't generally have time to do in-depth code support, but considering this is a pretty important project for the community, feel free to e-mail me at [email protected] if you need something in particular. I'll try to answer in time.
 
Ok so I tightened up the code. I kept the case statement testing in place and corrected one error. More significantly I dumped using KiTTY a fork of PuTTY as my serial terminal it was unable to keep up with the data transmission speed from the Bridge. I switched to using the arduino serial monitor which runs at 200000 nicely resulting in no more overflow errors. This allowed me to avoid having to dig deeper into and implementing the interrupt idea, perhaps later at the moment this seems to be working as is.

I have now added 2 more case tests to insert additional messages, this is working very nicely as can be seen by a sample of the start of the 1700 entry recording below. It shows each of the case tests inserting the additional messages at the right time more or less.
The tests are 50B, 1D4, and 1F2, you can see in the sample recording that the additional messages are being added successfully.
Also below is the struct statement of the messages I am adding.
The bridge now simulates the recording made of a working car and charger very closely, messages are repeated throughout the 1700 messages.

Tragically the charger still does nothing although the can sequence on the car side seems to be behaving differently (it pauses for about 500ms regularly) but I need to analyze this closely to figure out exactly what is happening, it is not obvious.

I continue to believe there is a problem with the charger or some other component from the accident it was in.
We were unable to get it to charge even when it was complete, in it's wrecked condition and I think this is causing the charger to not respond.
FYI, The inverter was damaged beyond repair. The battery and the BMS, work fine and they are being installed in a Toyota RAV4 EV.
Still looking for another wrecked leaf at a good price. This time we are looking for one with no front end damage.
Anyone else looking to buy a wreck beware !

Full code and recordings here : http://www.evmotorworks.ca

Sample recording of bridge output on the OBC/PD side using an OLIMEX Pic32-emz64 with code from mholt999 .
Comments added to this post are not part of the recording.
,CAN ID ,DL,D0,D1,D2,D3,D4,D5,D6,D7,T Stamp,#,But 1,But 2
rx, 0x679,1;00;00;00;00;00;00;00;00,00250.38605,00;00;00 // charger plugged in
rx, 0x390,8;04;00;00;00;00;80;3C;07,00250.43612,01;00;00
rx, 0x393,8;00;10;00;00;20;00;00;02,00250.43644,02;00;00
rx, 0x50B,7;00;00;00;C0;00;00;00;00,00250.43799,03;00;00 // case 50B test
rx, 0x54A,8;DA;80;70;0E;00;00;00;54,00250.43825,04;00;00
rx, 0x481,2;4B;00;00;00;00;00;00;00,00250.43843,05;00;00
rx, 0x54B,8;10;08;80;00;04;00;00;00,00250.43878,06;00;00
rx, 0x54C,8;59;FF;00;00;00;F8;FF;00,00250.43906,07;00;00
rx, 0x54F,8;14;00;00;00;08;40;C0;14,00250.43934,08;00;00
rx, 0x1F2,8;04;64;04;A0;00;02;02;8A,00250.44229,09;00;00 //case 1DB test
rx, 0x1DB,8;FF;E0;BC;AA;2F;00;03;B0,00250.44264,10;00;00
rx, 0x55B,6;00;00;00;00;5D;C8;00;00,00250.44286,11;00;00
rx, 0x1D4,8;6E;6E;00;00;82;06;E0;C1,00250.44329,12;00;00 //case 1B4 test
rx, 0x50A,8;04;80;00;0F;00;02;04;00,00250.44357,13;00;00
rx, 0x50C,6;00;00;00;00;5D;C8;00;00,00250.44371,14;00;00
rx, 0x5A9,8;FF;FF;FC;FF;FF;F7;FE;00,00250.44413,15;00;00
rx, 0x45E,1;00;00;00;00;00;00;00;00,00250.44423,16;00;00
rx, 0x5B9,7;07;FF;07;FF;2F;FF;80;00,00250.44454,17;00;00 //vcm output
rx, 0x11A,8;00;80;00;AA;C0;00;00;67,00250.44845,18;00;00 // ...............................

List of Inserted messages:
struct can_response array_response[12] = {
{0x54A,8,{0xDA,0x80,0x70,0x0e,0x00,0x00,0x00,0x54}}, //0 CASE: 50B
{0x481,2,{0x4B,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}, //1
{0x54B,8,{0x10,0x08,0x80,0x00,0x04,0x00,0x00,0x00}}, //2
{0x54C,8,{0x59,0xFF,0x00,0x00,0x00,0xF8,0xFF,0x00}}, //3
{0x54F,8,{0x14,0x00,0x00,0x00,0x08,0x40,0xC0,0x14}}, //4
{0x50A,8,{0x04,0x80,0x00,0x0F,0x00,0x02,0x04,0x00}}, //5 CASE: 1D4
{0x50C,6,{0x00,0x00,0x00,0x00,0x5D,0xC8,0x00,0x00}}, //6
{0x5A9,8,{0xFF,0xFF,0xFC,0xFF,0xFF,0xF7,0xFE,0x00}}, //7
{0x45E,1,{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}, //8 extra's
{0x5B9,7,{0x07,0xFF,0x07,0xFF,0x2F,0xFF,0x80,0x00}}, //9
{0x1DB,8,{0xFF,0xE0,0xBC,0xAA,0x2F,0x00,0x03,0xB0}}, //10 CASE: 1F2
{0x55B,6,{0x00,0x00,0x00,0x00,0x5D,0xC8,0x00,0x00}}, //11
};
 
Sorry to hear that all your hard work did not pay off yet, maybe there is still hope when more is revealed.

One thought that may be incorrect, but would the BMS or LBC from the pack need to be on the CAN buss for charging to occur? Maybe i misunderstood that it was not connected on the plywood leaf?

i have monitored the BMS buss during charging on the iMieev which uses the same Nichicon chargger as used in a gen 1 Leaf. It communicates with an EV-ECU which controls the OBC and the charging session. The EV-ECU is the master that controls every thing else in the Miev. i know the gen 2 Leaf is a different chargger, etc., but could imagine the same concept of a master controller being used also, i.e. the VCM.

For example, if the pack temperature sensors are not reported to the VCM then it may not engage the OBC activation signal to begin or allow charging. On gen 1 that is a single wire discrete signal on pin 18, and maybe is the same pin 18 of your OBC wiring diagram?
 
nlspace said:
Sorry to hear that all your hard work did not pay off yet, maybe there is still hope when more is revealed.
Indeed, I have just acquired another complete fully functional but wrecked leaf, more testing about to begin.

One thought that may be incorrect, but would the BMS or LBC from the pack need to be on the CAN buss for charging to occur? Maybe i misunderstood that it was not connected on the plywood leaf?
I did not have an LBC up to this point, the theory that I have been working on is that simulating LBC commands on the Can bus should facilitate that need for charging.

i have monitored the BMS buss during charging on the iMieev which uses the same Nichicon charger as used in a gen 1 Leaf. It communicates with an EV-ECU which controls the OBC and the charging session. The EV-ECU is the master that controls every thing else in the Miev. i know the gen 2 Leaf is a different charger, etc., but could imagine the same concept of a master controller being used also, i.e. the VCM.
I think you are correct here, the VCM in the leaf is main controller but again simulating those commands should facilitate charging.

For example, if the pack temperature sensors are not reported to the VCM then it may not engage the OBC activation signal to begin or allow charging. On gen 1 that is a single wire discrete signal on pin 18, and maybe is the same pin 18 of your OBC wiring diagram?
Food for thought here. The changes between Gen1 and 2 are however dramatic. On Gen 2 Pin 18 is a battery connection on the PDM/OBC however. Although the hardware is different your idea may apply. The battery temperature sensors are on the LBC and transmitted via the can bus to the VCM or PDM/OBC or both. I have just started reverse engineering the LBC (based on turbo and others work) The temperature sensors come in on connector LBC12. I have hooked up a resistor string to simulate temperatures with hopes of isolating which CAN message or data bits hold temperature info.
Some significant work ahead of me. I am hoping to confirm some assumptions about plywood Leaf version 1 having some lingering hardware failure from the accident it was in or miswiring on my part or ideas like what you have suggested. I hope to determine if the message insertion is effecting anything and to isolate what the specific messages are that come from the LBC related to charging in the next couple of weeks.
Prior to disassembling this most recent leaf we were able to disconnect many of the sub systems including ABS, Power Brake,VCM as well as other hardware including A/C,cooling, fans, QC while still maintain traction and charging.
Watch for more updates, thanks for the help
 
Wow, that's cool, so how did you do that ?
I am guessing that you are not using the CAN BUS to control it.
It looks like you are manually controlling the PWM chip on the control side of the charger triggering the IGBT to deliver current.
That is a great Idea and a good bit of work if you want a manually controlled 440 volt power supply or charger.
I am hoping to control the charger via the CANBUS.
If you could share some details on how you have done this I and others would be grateful.

Thanks for the good work.
 
49thdiver said:
Wow, that's cool, so how did you do that ?
I am guessing that you are not using the CAN BUS to control it.
It looks like you are manually controlling the PWM chip on the control side of the charger triggering the IGBT to deliver current.
That is a great Idea and a good bit of work if you want a manually controlled 440 volt power supply or charger.
I am hoping to control the charger via the CANBUS.
If you could share some details on how you have done this I and others would be grateful.

Thanks for the good work.

Hello ! thanks!
Yes, you are right, the control takes place in an apparatus way) I also try to run on the can bus) I just ran out of patience. The launch takes place in 3 stages
1. Start the power corrector
2. Start PWM
3. Correct the feedback.
As I understand it, PDM only monitors the current.
I can describe in detail what points I worked on from the photo.
Thank you very much, you also did a great job, it's very cool!
Please forgive me for my translator, I am in Moscow (Russia).
 
Back
Top