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.
Do you have the VCM and the BMS disconnected, you also do not need the inverter.
If you have any of these connected you could get message crc conflicts as the message must be sent in a specific order.
My code was designed to work with only the OBC connected. That is how it works on the Gen2. Are you able to observe messages from the OBC.
You should get a message when you plug in the charging station and messages once the system is live before your turn on the DUE and execute the arduino code.
 
I have not connected anything except for 2, 12 volt power supply and ground. I did got change to take data from working OBC and tried to put to that message still not progress. While getting the datas I found out that the values of 0x1D4, 1F2 has more than for different values and I am trying to figure that out.

Thanks
Rochak
 
There definitely are more values as the status of the battery pack changes and so reports other information that is not relevent to getting the charger started.
 
TrueSoln said:
I just kept the code simple for number sequence, and seem that I was getting the charger to turn on.

Still have to work out actual pattern but below is what I used for code on an UNO
I look at the logs for a charge from MUX and Damien
ID 50B is same message during the whole charge (Every 100ms)
ID 1D4 & ID 1F2 Both come from VCM also and need to be simulated. (Every 10ms)


1D4 and 1F2 do still need to work out what it all means
But on Byte[5] of 1D4 seem to be control value

//F7 07 00 04 87 46 E0 64
//F7 07 00 04 C7 46 E0 A3
//F7 07 00 04 07 46 E0 6F
//F7 07 00 04 47 46 E0 A8
//- Every 10ms
uint8_t 1d4_incremental_counter = 0;
byte SendSignal_0x1d4()
{
byte messageData[8] = {0xf7, 0x07,0x00,0x04,0x00,0x46,0xe0,0x00 };

byte seqCtr[4] = {0x87, 0xc7,0x07, 0x45 };
messageData[4] = seqCtr[1d4_incremental_counter];

// Set the CRC and send
nissan_crc(messageData, 0x85);

1d4_incremental_counter++;
if (1d4_incremental_counter >= 4)
1d4_incremental_counter = 0;

return SendCanMessage(0x1d4, 0, 8, messageData);
}

//30 64 20 00 00 82 00 0B
//30 64 20 00 00 82 01 0C
//30 64 20 00 00 82 02 0D
//30 64 20 00 00 82 03 0E
//- Every 10ms
uint8_t counter_1f2 = 0;
byte SendCanMessage_1f2()
{
byte messageData[8] = { 0x30, 0x64, 0x20, 0x00, 0x00, 0x82, 0x00, 0x00 };

byte seqCtr[4] = {0x0b, 0x0c,0x0d, 0x0e };

//- Sets the sequence
messageData[6]=counter_1f2;
messageData[7] = seqCtr[counter_1f2];

counter_1f2++;
if(counter_1f2 >= 4)
counter_1f2 = 0;

//- Not sure if a CRC or Just a sequence pattern
//nissan_crc(messageData, 0x85);

return SendCanMessage(0x1f2, 0, 8, messageData);
}

//- Every 100ms
void Send50bMessage()
{
byte gen1_MessageData[6] = {0x00, 0x00, 0x00, 0xc0, 0x00, 0x00 }; // While charging
byte sndStat = CAN_OK;

return SendCanMessage( 0x50b,0, 6, gen1_MessageData);
}


Could you please provide the full code?
I have send all the messages as show. I have connection of 12v, ground and CAN high and CAN low. I am not seeing any DC voltage after sending these code?
 
@ETrrijal2 Did you ever get the OBC for Gen1 working?

I am new on the forum and new to Arduino. I have my Gen1 OBC wired on the bench, and i have an Arduino UNO with a Seeed Can-bus shield. I am seeing the 0x380 and 0x5BF messages. I do not have the HV Battery or the LBC connected yet; I have been trying to confirm that the EVSE plug in/out is working (I kind of think it is) but don't get any additional CAN messages when I do that - the EVSE charge light does come on when plugged in. Maybe the plugin status is embedded in the x5BF message and not a separate message?

My goal is to be able to use the OBC to charge the HV Battery in a simple stand alone mode if I can by simulating the VCM messages with the Arduino.

Any guidance from the group is appreciated, I have read the Gen2 blog a couple times and probably will do it again. Meanwhile I will connect the HV Battery up and work on simulating dumb Gen1 messages from the UNO using info provided above in the blog.

Thanks, TomD
 
tomdickmeyer said:
@ETrrijal2 Did you ever get the OBC for Gen1 working?

I am new on the forum and new to Arduino. I have my Gen1 OBC wired on the bench, and i have an Arduino UNO with a Seeed Can-bus shield. I am seeing the 0x380 and 0x5BF messages. I do not have the HV Battery or the LBC connected yet; I have been trying to confirm that the EVSE plug in/out is working (I kind of think it is) but don't get any additional CAN messages when I do that - the EVSE charge light does come on when plugged in. Maybe the plugin status is embedded in the x5BF message and not a separate message?

My goal is to be able to use the OBC to charge the HV Battery in a simple stand alone mode if I can by simulating the VCM messages with the Arduino.

Any guidance from the group is appreciated, I have read the Gen2 blog a couple times and probably will do it again. Meanwhile I will connect the HV Battery up and work on simulating dumb Gen1 messages from the UNO using info provided above in the blog.

Thanks, TomD
I spent a couple of weeks trying to get my Gen1 OBC to charge the HV battery but in the end I went with the Outlander PHEV charger. It is smaller, a better shape for installing has the 12V charger built in and is better documented so was a better solution all round for me.
If you ever get it working please share your findings.
 
tomdickmeyer said:
@ETrrijal2 Did you ever get the OBC for Gen1 working?

I am new on the forum and new to Arduino. I have my Gen1 OBC wired on the bench, and i have an Arduino UNO with a Seeed Can-bus shield. I am seeing the 0x380 and 0x5BF messages. I do not have the HV Battery or the LBC connected yet; I have been trying to confirm that the EVSE plug in/out is working (I kind of think it is) but don't get any additional CAN messages when I do that - the EVSE charge light does come on when plugged in. Maybe the plugin status is embedded in the x5BF message and not a separate message?

My goal is to be able to use the OBC to charge the HV Battery in a simple stand alone mode if I can by simulating the VCM messages with the Arduino.

Any guidance from the group is appreciated, I have read the Gen2 blog a couple times and probably will do it again. Meanwhile I will connect the HV Battery up and work on simulating dumb Gen1 messages from the UNO using info provided above in the blog.

Thanks, TomD

I have not, I have a similar set up, I was able to read the can and send the data. I think I was not able to send the correct data or in a correct manner, but I was not able to turn that on for now. I will be starting that project later but for now I bought elcon charger.
 
I have been troubleshooting my Gen1 OBC and it looks like the control board has R897 missing. Can someone look at their board and tell what the value is supposed to be so I can replace it? It is located on the bottom of the board near IC509. TIA for any help. TomD
 
Can someone out there that has a Gen1 OBC on the bench look at R897 and tell me its value? It looks like mine has fallen off and needs to be replaced; mine looks like a component used to be soldered on the board. R897 is located inside the Gen1 OBC on the bottom of the top board. I have embedded an image of the missing component below. I can't find R896 or pads for it either. I know this thread is somewhat dormant but don't know a better place to post my question.

TIA again, TomD

BtITIpJ.jpg
 
@49thdiver and @jackbauer

I have tested the Gen2 setup as posted by Peter, but no luck. The OBC sends 0x679, 390 and 393 frames. I can see the AC voltage being signaled going up from 0 to 200V. The DCDC output is there as well, charging the 12V battery, but nothing is happening on the high voltage side. I have a Leaf battery connected and the contactors are closed.

1. I noticed a few differences between Damien's CAN messages and Peter's. See table below. I was wondering if either of you could comment on the relevance of this, particularly the 'HV supplied' signal and the 'Main Relay Output' signal in 1D4, and the 'CAN failures authorised' signal in 50B.

2. Peter, the 'credits' on one of your videos shows quite different CAN data as well. The data strings are probably back to front, but even then the values are quite different from those in your code. Can you explain?

Code:
Frame  Byte  Peter        Damien         Comment
1D4    0     6E           F7             function unknown
1D4    1     6E           F7             function unknown
1D4    4     42/B2/C2/02  07/47/87/C7    Bit 2 is HV status. 0x*2 = HV not supplied, 0x*7 = HV supplied.
1D4    5     06           44             0x06 = main relay not output, 44 = main relay on
1DB    0     01           calculated     battery current
1DB    1     20           *0, calc'd     battery current
1DB    2     BE           calculated     battery voltage
1DB    3     AB           calc | 2B      different battery voltage; same bits for No Cut Req, Main Relay ON, Normal P Limit
1DB    4     2B           40             SoC for dash
50B    2     00           06             bit 2 (04) = Storage of CAN mute/absent failures authorised - otherwise not authorised
59E    2     0B           0C             LB_FULL_CAP_QC
59E    3     94           76             LB_FULL_CAP_QC, LB_REM_CAP_QC
59E    4     C0           18             LB_REM_CAP_QC

Cheers!
 
My only comment would be is that Jacks code is different from mine and there are many variations on the data packets that might work particularly regarding the output power ie charge current. In my case it pumps out about 16 amps. My code works in my car and others have also been successful in implementing it.
What's important is to download the code from the github repository listed earlier. It for sure works, timing and sequence is everything.
You can not change the data without also changing the checksum and the prun byte as the OBC will reject it.
The code is written for an arduino due, the details also on github. The data I am using was copied from recordings I made of an intact working leaf system

I note that at the end of the example you posted you refer to QC, I have never tested the quick charge function. I am only using the level2 J1772 to charge.
Make sure you do not have any other leaf systems connected to the can bus only the OBC and the arduino, other messaging from the VCM or inverter will corrupt the data. 24hours may have other thoughts.
 
Thanks for your response Peter.
Just to clarify a few things.

The 'example' at the end of my previous message is not code but is my way to present a table, an overview of the differences between the frames in your and Damien's code. I used the code markup in order to layout a table as rows and columns of single-spaced text.

I have ported your code to Python as I'm using different hardware from the Arduino Due. But that's the only difference. Functionally it's doing the same thing: same data, same timing, same sequence, with just a controller and the OBC on the bus.

I'm not attempting to do QC. The data you sent in message 59E relates to QC, at least according to Dala's CAN database. I don't think that's the show stopper, though.

Any further thoughts are welcome.
 
Hmmm, 2014 should work. I am wondering about the timing, do you have a way to measure the timing between the 10ms messages, the 100ms and 500ms to be sure that its right. You are sending one of each message sequence every 10ms ie 11a,1f2,1d4,1db,1dc repeat with next sequence repeat 4 times with each discrete message packet, then repeat the whole thing over gain until charged. Insert 100ms and 500ms message accordingly. Note charge cut off is not set in this version.
You said the relay comes on and the 12 volt aux is charging. Do you know if the relay is staying on or does it drop out. I had that problem when I first got it going and that is when I discovered the 1d4 message was missing. If you put a volt meter or current meter on the high voltage do you see a momentary jump up or current flow. A light bulb in series might work but do not know for sure, never tried that.
It's been a while since I was in troubleshooting mode on that system so I am working from memory.
Do you have a 120 ohm resistor across the can transceiver I/O on what ever device you are using.
Can you get access to a Due to try.
You have the interlock jumped ?
I think you need to know if the relay comes on and stays on or if it switches off again. If this is the case you are very close to getting it going.
You could easily wire an led and a resistor across the relay coil and have a visual indicator of what's going on if you do not have a scope or logic analyzer. Check the relay voltage to determine the resistor value. I imagine it is a 12 volt but it might be higher.
Just kind of rambling as it is so long ago that I thought about this in depth on other projects at the moment.
Think about the suggestions above. It will be the new year before I can really turn my mind back to the code.
Let ,me know how you make out with the relay testing.

Peter
 
Thanks Peter. I appreciate your effort.
Are you saying it has been done on a 2014 before?

Sorry again for a misunderstanding: where I wrote "the contactors are closed" I meant that I closed the contactors on the battery. I have not heard the relay(s) clicking in the OBC.
I will doublecheck the timing. Yes on the interlock loop, and Yes on the termination resistors. I have ordered a Togglebit board. I will report back when that comes in.

Thanks again.
 
I have two of these here and one other that I used for data collection earlier on. I am pretty sure one of them was a 2014.
The Toggle bit boards are great, I have used a number of them and have a canfduino board waiting to be used in my next project.
If that is the board you ordered it has a built in sd card slot so you can set it up to record can data.
Recording data from a known working car was the key to debugging my code by playing the recorded data back in a loop and comparing the results.
A shout out for Dan at Togglebit he does good work.
What hardware are you running the python on ?

By the way do you know that the charger and the associated J1772 socket is in good shape. I had one socket from a wrecked car that I discovered was not working properly wasted a lot of time troubleshooting code that was not broken.
The proximity and pilot signals all need to be working properly for the system to work.

Peter
 
The python code is running on a Raspberry Pi with an SkPang PiCan board. Just a leftover from a previous project.
The OBC detects and reports the AC voltage on CAN 390 when it plugs in, so I have no reason to doubt the J1772.

On another note. When your setup is working, does it stop charging when the battery is full? Does it follow a Constant Current / Constant Voltage charging regime, i.e. does the current taper off when it's nearly full?
 
No the code provided does not provide cut off as there are so many ways to do that depending on the battery pack and BMS you are using.
I am actually using a nissan leaf pack and bms independently with an additional due that manages charging and uses the SOC to determine when to shut down. I believe that the OBC is a constant current source, it may be that Nissan ramps the current down as it reaches full charge but I have not investigated that on a leaf. There may be others that know more about this than I do. I charge at about 16 amps and shut off at 92% SOC. That regime works for me. One can tweak it.

I have a raspberry pi and a waveshare hat on a 5" TFT display, I would be interested to try your code on my charger to see if it works.
I have never used python on a pi. I think I used it once on a windows platform to run some web browser code for an OBD2 device on bluetooth but that is a long time ago and do not recall the details.

If you could figure out how to send me a boot loader or other method of getting it running here I would be happy to try it. That would certainly confirm hardware function on a working system. I will PM you my contact info. LMK
 
Hi, I have just started to scratch the surface on this and immediately found a few interesting remarks, regarding Raspberry Pi and Python.

Regarding PPi.GPIO
- If you need more accurate timing use bare metal RPi (which makes it work like a microcontroller), use a real-time OS with a better pre-emptive dispatcher or run the timing function on an Arduino (which is a single task microcontroller).

Regarding the Python function Time
- Note that this module is unsuitable for real-time or timing critical applications. This is because you can not predict when Python will be busy garbage collecting. It also runs under the Linux kernel which is not suitable for real time applications - it is multitasking O/S and another process may be given priority over the CPU, causing jitter in your program. If you are after true real-time performance and predictability, buy yourself an Arduino

In my experience capturing and processing CAN on a Nissan Leaf is a challenging feat, the sheer volume of data is huge. The leaf is sending and receiving data at millisecond (ms)speeds perhaps microsecond (us) speeds. Just to fake out the OBC you need to send on average 5 messages every 10ms. To do rea-ltime CAN filtering I ended up using Mux's bare metal processor design with "C" to be able to catch and process the messages from the Leaf.

So my Question out to the group before I dig too much deeper does anybody else have any experience and success with using a RPi and Python in this kind of a real-time application where the timing is critical ie sending multiple messages every 10ms with sustained accuracy
General comments welcome my only experience with Python is with processing data for user interface for a web based OBDII device.

Thanks, all the best to everyone over the winter season -10 on Vancouver Island this morning, very unusual. the Ev got us where we needed to go, YEAH.
Peter
 
Back
Top