Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Electric smart CAN bus. OBC #17

Open
aospan opened this issue Jun 24, 2018 · 33 comments
Open

Electric smart CAN bus. OBC #17

aospan opened this issue Jun 24, 2018 · 33 comments

Comments

@aospan
Copy link

aospan commented Jun 24, 2018

Hello,

I'm digging into my car (2015year smart fortwo electric). ED BMSdiag is up and running fine - I can get BMS, cooling, etc info.
Now I want to dig deeper and control charging cycle. First of all I want to "ask" OBC drain less current from J1772 socket. I need currents lower than 6A - this minimum can be achieved with 10% duty cycle on pilot pin. But I need lower than 6A for charging from solar panels (using microinverters).
Do you know any CAN bus ID's related to on board charger (3.3kW) ?
I'm trying to identify those ID's analyzing CAN bus traffic.

thanks !

P.S.
OBC drain smaller currents (about 1-2A) when battery is almost full. So, I hope OBC can be controlled over CAN bus to drain less currents.

@aospan
Copy link
Author

aospan commented Jun 24, 2018

I have made dump of CAN bus today while charging from 94.2% to 100%. Here is dump and some info. May be it will be useful for someone in the future.

https://github.com/aospan/smart_fortwo_electric_charge_canbus

@MyLab-odyssey
Copy link
Owner

Hello aospan,

my project with the 451ED started a long time ago and without access to this type of car I can't help with new findings. But here are my thoughts:

I was able to control the charging current buy using the same IDs as the dashboard. It was so easy to get, that I did not document it. The dashboard uses 0x5nn IDs, so just scan for alternations in this range, when changing the value in the dashboard. Then write one of those current message to the bus and sniff for reply messages from the charger (rqID 0x61A, respID 0x483) to get the charging current content (also monitor 0x62F).

But: I don't think that you can use currents below the 6A limit. This is the defined limit by the charging standard and currents below that value are only controlled internally by the charger itself. The battery is first charged on a constant current basis (13.4A as in your dump). When the first cell is almost reaching the limiting voltage of 4.2V the charger will switch into constant voltage mode and the charging current is smoothly reduced to top off the cells. This algorithm is implemented into the charger. You can try to get lower currents-setpoints, but I think they will be coerced to a defined window.

I will overview some old logs and if I find the bus ID, I will report here...

Best regards
odyssey

@aospan
Copy link
Author

aospan commented Jun 25, 2018

@MyLab-odyssey huge thanks for info !

I have found how to read charging current with 0x61A and 0x483 (using your source code, thanks !) and updated my README with this info.

Also, I have made CAN bus dump while changing charging current from 12A to 8A on dashboard. Charging current actually changed (I'm controlling on OpenEVSE unit). I have uploaded this dump to my repo too. So, interested PID somewhere in this file :)

BTW, is OBD port directly connected to CAN bus and really can sniff 100% traffic between dashboard and charger (obc) ? If no then I should connect to CAN bus near OBC (green/white-green wires as I suspect).

@aospan
Copy link
Author

aospan commented Jun 25, 2018

@MyLab-odyssey Please explain what is 0x62F PID for ?

@MyLab-odyssey
Copy link
Owner

MyLab-odyssey commented Jun 25, 2018

a)
So, did find old logs from 2015 ;-) and I did document the charger current selection:
-> look at ID 0x512 for byte 6 (counting b1 to b8):
8A = 0x74, 12A = 0x7C and 32A = 0xA4 (had the fast charger with three phases and 22kW).
So you have to calculate an offset from 0xA4 = d164: e.g. 12A = 0xA4 - 0x7C = 0x28 = d40 -> divide by two to get the current reduction of 20A from 32A base. As this was the total limit a current of 32A should also be the base for your calculations. I also inspected your scan and found the values of 0x74 and 0x7C ;-)

I wrote the following command to ID 0x512 to set the current:
cansend can0 512#00001FFF007C0000 for 12A

Please test values in between, I only tested the three standard values, but I think it should work - please report!

b)
I think you will sniff the full traffic, as the bus load will normally be about 38%. I did my work with a raspberry pi and aPican shield. Using the can-utils it worked well.

c)
ID 0x62F (and rqID 0x62D) mirrored some messages - maybe only in the system with fast charger?!

Hope this helps and great that someone is using my findings ;-) I tried to structure the queries within separate header files to easily analyze the possible commands.

Best regards
odyssey

@aospan
Copy link
Author

aospan commented Jun 25, 2018

@MyLab-odyssey it works ! thanks ! I can set charging current limit in range 8Amps to 16Amps (I have 3.3kw OBC).

I have updated my README with this info.

Unfortunately, values lower than 8Amps is ignored by OBC as you wrote above.
Ok, i'm thinking about workaround. I will do small external "energy buffer" (like battery bank) and will store lower amps (when insolation is not enough to provide 8Amps@240V) from solar there. And will provide "burst" charge to car (full 8Amps@240V) when enough energy stored. This will wear battery bank faster but it's different story.

thanks for your help ! :)

@MyLab-odyssey
Copy link
Owner

Hello aospan,

I hope the current control is still working for you?! When controlling the control pilot of the charging station (e.g. simple EVSE) you could go down to 6A, as per definition of the charging standard.

Now I have a to ask you for a favor: A lot of people are asking for the pre-condition setup, as the vehicle homepage is shut down. I was not able to replicate the gsm-modem commands from the EV-CAN some years ago. But I think replication of the commands from the dash should work! I need someone with your skills and access to the car to test my theory:

ID-range 0x5nn seems to be the dash. I retrieve the time from the first two bytes of ID 0x512. To write a time you need to get the current setpoint and then send the new value in an minutes offset. Not the absolute wanted time, only the change in minutes. I think there must be a change in this ID(s), if you manually setup a precondition / charging as done with the OBL current.

Can you investigate this? - that would be great!

THX in advance
odyssey

@aospan
Copy link
Author

aospan commented Aug 21, 2018

@MyLab-odyssey Sorry for late reply. Just found time to check time change.
I have tried to send 0x512 to modify time but it ignored.

Then I change time on dashboard (minutes 4 to 59) of the car and made the CAN dump. Here is small dump (100 msec) when time changed:

change-time.pcapng.zip

you can open it in Wireshark. File starts with old time:
1 0.000000 16 STD: 0x00000512 0e 04 1f ff 00 ff 00 00

and finish with new time:
153 0.100009 16 STD: 0x00000512 0e 3b 1f ff 00 ff 00 00

so, something happens in between. I will try to identify packet that caused time change but if you can look too it will be great.

@aospan
Copy link
Author

aospan commented Aug 22, 2018

I have checked all this 153 packets between time change and doesn't find any that cause time change.
So, I suspect that dashboard is "timekeeper" in the car and change time inside itself. May this happens ?
In this case we can't determine how to change time from CAN bus ;(
Or we need docs to dashboard - hope it can be controlled from CAN bus.

@MyLab-odyssey
Copy link
Owner

Thanks for your efforts!

Did you alter the system time of the dash or did you change the departure time for climate control (for climate controlled departure, when the car is attached to mains)?
As I remember changing the system time was writing two bytes as an minutes offset, e.g.: to add an hour I wrote to ID 0x512: 00 3C 00 00 00 00 00 00, could you please retry?

If this works you can maybe alter the departure time the same way?

Please give it a try again, as this would be a useful feature.

THX, Odyssey

@aospan
Copy link
Author

aospan commented Sep 1, 2018

I just tried to send:

$ cansend can0 512#003C000000000000;

and here is the dump:

  can0  512   [8]  0F 27 1F FF 00 FF 00 00
  can0  512   [8]  0F 27 1F FF 00 FF 00 00
  can0  512   [8]  0F 27 1F FF 00 FF 00 00
  can0  512   [8]  00 3C 00 00 00 00 00 00
  can0  512   [8]  0F 27 1F FF 00 FF 00 00
  can0  512   [8]  0F 27 1F FF 00 FF 00 00
  can0  512   [8]  0F 27 1F FF 00 FF 00 00

as you can see nothing changed ;(
should I try something else ?

@MyLab-odyssey
Copy link
Owner

If ID 0x512 is an response you could try to send the delta to ID 0x50A (-8).
Do you have activities of ID 0x26A (Cooling controller) or 0x380 (System controller)? But I am not sure if I monitored these on the EV-CAN of the COM-Module CAN signals (shame on me).

@MyLab-odyssey
Copy link
Owner

I am still trying to remember and maybe the 1F FFis suspicious? Can you try to send the offset to 0x512 on byte 2,3? the other FFposition (byte 5) we found to be the charging current set position ;-)

Please test!

THX Odyssey

@aospan
Copy link
Author

aospan commented Sep 1, 2018

0x50a - no luck

  can0  512   [8]  11 36 1F FF 00 FF 00 00
  can0  512   [8]  11 36 1F FF 00 FF 00 00
  can0  512   [8]  11 36 1F FF 00 FF 00 00
  can0  50A   [8]  00 3C 00 00 00 00 00 00
  can0  512   [8]  11 36 1F FF 00 FF 00 00
  can0  512   [8]  11 36 1F FF 00 FF 00 00

offsets too ;(

  can0  512   [8]  11 38 1F FF 00 FF 00 00
  can0  512   [8]  11 38 1F FF 00 FF 00 00
  can0  512   [8]  00 00 00 3C 00 00 00 00
  can0  512   [8]  11 38 1F FF 00 FF 00 00
  can0  512   [8]  11 38 1F FF 00 FF 00 00

and:

  can0  512   [8]  11 39 1F FF 00 FF 00 00
  can0  512   [8]  11 39 1F FF 00 FF 00 00
  can0  512   [8]  00 00 3C 00 00 00 00 00
  can0  512   [8]  11 39 1F FF 00 FF 00 00
  can0  512   [8]  11 39 1F FF 00 FF 00 00

@MyLab-odyssey
Copy link
Owner

MyLab-odyssey commented Sep 2, 2018

Please write can0 512 [8] 00 00 00 3C 00 00 00 00 because 1F FF is the mask for that input!

But did you check if the departure time (in the "charge and depart menu") changed? Byte 3,4 could directly refer to the submenu, as the charging current value (byte 6) will do?! It should be one hour later to the actual system time...

Please test this as a final attempt - THX!!!

@aospan
Copy link
Author

aospan commented Sep 2, 2018

I found how bytes 3,4 (or 2,3 if count from 0) works.
I have sent:
$ cansend can0 512#0000121E00000000

and departure time changed to 18:30 (0x12 0x1E):

img_0417

Don't hesitate to ask me if you have any more ideas to try :)

@MBTP
Copy link

MBTP commented Sep 3, 2018

please check for AIC on and off

@MyLab-odyssey
Copy link
Owner

Cool! Great finding ;-) So we can write the new time in hours and minutes. MBTP is asking the right question for the next step:

Could you please post the changes for the following IDs when you activate AC on in the depart menu:
0x504 (most likely only ODO)
0x508 (lot of status data)
0x510 (only active if changes to the BC are made)
0x512 (but I think the AC on/off is in another ID)
0x518 (related to charging data)
and maybe also in the
0x608 ID (where I found also cooling loop data)

@MBTP
Copy link

MBTP commented Sep 3, 2018

I just found out that, to turn on the AC, we have to add 0x3F to the minutes, so for 18:30 instead of
$ cansend can0 512#0000121E00000000
from aospan example, I sent
$ cansend can0 512#0000125D00000000
So it's in the same ID : 0x512

@MyLab-odyssey
Copy link
Owner

Congrats! This is really exiting and can help to build a replacement for the unsupported COM module.
But I think an offset is a bit strange?! Adding a flag bit (eg mask 0100 0000, 0x40) would be much more intuitive. So please check, if the AC really kicks in to the new programed time and what is happening if you program a zero minute (0x3F) and let say one hour into the future for AC start.

The next step I failed to replicate was waking up the sleeping car with a ID sequence. But I never tried to send a programmed time to the BC, so please test sending a new time when the car is asleep.

@MBTP
Copy link

MBTP commented Sep 4, 2018

i send with arduino with [(https://www.hackster.io/MyLab-odyssey/ed-bmsdiag-6bece5?ref=user&ref_id=61675&offset=0)] the dashboard change a/c on and off. i send the command 10x at 200ms and the change read ok

@MyLab-odyssey
Copy link
Owner

MyLab-odyssey commented Sep 4, 2018

But does it really start the AC when the desired (new programed times) is reached?

With your offset you changed bit 6 (edited) which could hold the AC on/off value. Please test what is happening if you only write a minute value of 0x3F. If AC on/off does not change write 0x40 and please report. I don't have access to an old 451ED any more and can't test.

@aospan: can you also try the suggestion from MBTP and mine?

@nsb002
Copy link

nsb002 commented Sep 5, 2018

@MyLab-odyssey and @aospan, we really have to add 0x40 to enable bit 6 I tried it with @MBTP for 17:00 and the AC started immediately (it was 16:57).
We sent this with the CAN_send example :
byte data[8] = {0x00, 0x00, 0x11, 0x40, 0x00, 0x00, 0x00, 0x00};

I confirm that when the car is asleep it cannot receive a departure time change. But @MBTP already had a module with an output on the door locking button, it wakes up the car for a couple minutes. He initially installed it to lock the car while leaving the AC ON when going at a store for a little while.

So now we know that :

  • The first 5 bits are for the minutes
  • Bit 6 for the AC
  • Bit 7... does anyone have a guess?

@MBTP
Copy link

MBTP commented Sep 5, 2018

video the remote control [https://youtu.be/5iYPVjuNdk4)]

@MBTP
Copy link

MBTP commented Sep 5, 2018

The is a draft code functional
I add 64+1 for enter time now

if(digitalRead(A0)== HIGH)
{
if(!digitalRead(2)) // If pin 2 is low, read receive buffer
{
CAN0.readMsgBuf(&rxId, &len, rxBuf); // Read data: len = data length, buf = data byte(s)
if(rxId==0x512)
{
Serial.print("ID: "); // Print the message ID.
Serial.print(rxId, HEX);

Serial.print(" Data: ");
for(int i = 0; i<4; i++) // Print each byte of the data.
{

      Serial.print(rxBuf[i], HEX);
    Serial.print(" ");
  }
    Serial.print(len);
											
  Serial.println("M");
		data[2] = rxBuf[0];
		data[3] = rxBuf[1]+65;													
		data[0] = 0x00;		
		data[1] = 0x00;		
		data[4] = 0x00;		
		data[5] = 0x00;		
		data[6] = 0x00;		
		data[7] = 0x00;		
							
byte sndStat = CAN0.sendMsgBuf(0x512, 0, 8, data);

if(sndStat == CAN_OK){
Serial.println("Message Sent Successfully!");
} else {
Serial.println("Error Sending Message...");
}
delay(2000); // send data per 100ms
}}}}

@MyLab-odyssey
Copy link
Owner

So we still have to get the car to wake up. Can someone please test these two queries when the car is asleep:
0x218 00 00 00 00 00 00 00 00 or
0x210 00 00 00 01 00 00 00 00

Both patterns should comply with the Bosch CAN bus spec. for waking up a sleeping bus with recessive bits.

@zkertesz
Copy link

Hi,

on the C453 both queries seems to wake some parts of the car but only for a few seconds.

can0@500000 0 0 0 0%
can0@500000 0 0 0 0%
can0@500000 180 22140 9792 4%
can0@500000 1122 138470 61408 27%
can0@500000 1147 140635 62040 28%
can0@500000 1135 139065 61312 27%
can0@500000 222 25500 10632 5%
can0@500000 1 75 16 0%
can0@500000 0 0 0 0%
can0@500000 0 0 0 0%

@MyLab-odyssey
Copy link
Owner

(Y) THX Zoltan! So it will be the right wakeup on the physical layer?! Waking up the C453 will be the next task (for ED4scan and upcoming projects...), but I want to finish the ED3 tasks for now.

But can someone please test on the 451ED? Please also check if the dashboard does react and if it gets up the "P" at the "shift lever".

@bhorrock
Copy link

I'm travelling right now but if you haven't got a second person to check the 451 by next weekend I'll try to take a crack at it.

@MyLab-odyssey
Copy link
Owner

THX Blaine, would really appreciate your help!

@MBTP
Copy link

MBTP commented Jan 14, 2019

Please help me for resetting message HV System workshop. If I drop 12v battery to low this message appears.I use sonoff remote for programming departure time with Arduino mega. This control is full functionality for programming departure time am and pm automatically

@martingraml
Copy link

if i send 0x423 05 10 00 02 the can bus wakes up and deliveres the following messages.
so 0x512 is also there to set conditioning. Can anybody check this?

key records ms last
can1/236 1505 19 00 | .
can1/305 31 967 37 00 ff | 7..
can1/408 302 99 ff 00 69 00 69 00 33 02 | ..i.i.3.
can1/412 302 99 45 ff 00 bd 62 7d 00 15 | E...b}..
can1/423 1 30000 05 10 00 02 | ....
can1/504 302 99 00 00 fb 00 35 65 00 00 | ....5e..
can1/510 1 30000 01 | .
can1/512 302 99 0d 09 1f ff 00 ff 00 00 | ........
can1/6fa 3 10000 03 36 34 34 ff ff ff ff | .644....

the last message before sleeping is 0x236 00 00 00 00
This has also the most records, maybe this keeps the bus awake.

@nsb002
Copy link

nsb002 commented Apr 22, 2020

Update: Turns out it was a defective coolant sensor mounted on a T plugged on a hose easily accessible from underneath or via the service hatch.


Hi,
Does anyone know where is this temperature sensor? (The one showing 62.4 degC for me)
It makes my cooling fan and pump run at 100% all the time (when plugged in or with the key turned).

-----------------------------------------
Temperatures Charger-Unit /degC: 
Reported       : 24
Cooling plate  : 17
Inlet socket   : NA
-----------------------------------------
Reading data.OK
-----------------------------------------
Status Cooling- and Subsystems: 
Temperature   : 62.4 degC
Cooling fan   : 100.0 %
Cooling pump  : 100.0 %, 13 degC
              : 13.4 V, 5.6 A
OTR:
Cooling fan   : 236 h
Cooling pump  : 10922 h
Battery heater: 121 h, OFF
Vaccum pump   : 80.046 h
Pressure 1, 2 : -713 mbar, -713 mbar
-----------------------------------------

As you can see there it was cold outside that day:

-----------------------------------------
Temperatures Battery-Unit /degC: 
module 1: 6.2, 7.0, 6.5
module 2: 5.8, 7.2, 5.7
module 3: 6.2, 7.2, 6.1
   mean : 6.4, min : 5.8, max : 7.2
coolant : 5.7
-----------------------------------------

@MBTP FYI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants