[Ovmsdev] Volt/Ampera

Thu Jan 3 04:22:59 HKT 2013

Mark,

we have the following functioning data at this moment:

*	Ambient temperature (the air around the car) - I think this is your
'outside temperature'
*	PEM temperature (the temperature in the charger / drive power
conversion unit - the electronics that convert AC to DC for charging, regen
and driving)
*	BATTERY temperature (the temperature in the battery itself)
*	Charging current
*	Charging voltage

The motor temperature doesn’t work at this moment, we have to analyze it.

The request is (in sequence ~10 ms):

7E4   8 10 0C 2C FE 43 69 43 68
7E4   8 21 80 1F 43 4F 1C 43 00
7E4   8 03 AA 04 FE 00 00 00 00

The answer would be ~160 times:

5EC  8  FE xx yy zz uu vv 00 00

charging current = xx * 0.2 A

charging voltage = yy * 2 V

outside temperature = zz * 0.5 °C – 40

battery temperature = uu * 1 °C – 40

pem temperature = vv * 1 °C - 40

this should be enough for the next beta.

Regards,

Johannes

Von: ovmsdev-bounces at lists.teslaclub.hk
[mailto:ovmsdev-bounces at lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson
Gesendet: Mittwoch, 2. Januar 2013 02:40
An: OVMS Developers
Betreff: Re: [Ovmsdev] Volt/Ampera

Tachy / Johannes,

Nice work. That is very useful, and I have added this to the volt/ampera can
bus notes file in the repository. This is the sequence we will use.

The Tesla Roadster show (and hence the Apps currently support) 4
temperatures in total:

*	Ambient temperature (the air around the car) - I think this is your
'outside temperature'
*	PEM temperature (the temperature in the charger / drive power
conversion unit - the electronics that convert AC to DC for charging, regen
and driving)
*	MOTOR temperature (the temperature in the wheel motors)
*	BATTERY temperature (the temperature in the battery itself)

It would be good if we could find those for the Volt/Ampera.

I think we now have enough to get the charge behavior.

Will you / MichaelJ work on the code to implement this, or do you want me to
do it? It does not look to hard to do, and I think we can use the same logic
as the Twizzy (and Michael J previously suggested).

Regards, Mark.

On 31 Dec, 2012, at 10:38 PM, <info at opel-ampera-forum.de>
<info at opel-ampera-forum.de> wrote:

Hi Mark,

here is „tachy“ from opel-ampera-forum.de, i’ve analyzed the requests from a
DashDAQ on CANBus.

To request current and voltage of the charger and the outside temperature,
you have to send the following sequence:

7E4      8 10 08 2C FE 43 69 43 68 
7E4      8 21 80 1F 00 00 00 00 00 
7E4      8 03 AA 04 FE 00 00 00 00

The answer (160 times) is:

5EC      8 FE xx yy zz 00 00 00 00

xx = Charging Current, units 0.2 A (ex. 0x43 = 13.4 A)

yy = Charging Voltage, units 2 V (ex. 0x70 = 224 V)

zz = outside temperature, units 0,5°C, offset +40 ( ex. 0x60 => 8°C )

Regards,

Johannes

Von: ovmsdev-bounces at lists.teslaclub.hk
[mailto:ovmsdev-bounces at lists.teslaclub.hk] Im Auftrag von mikeljo at me.com
Gesendet: Sonntag, 30. Dezember 2012 13:59
An: OVMS Developers
Betreff: Re: [Ovmsdev] Volt/Ampera

Hi,

it continues

Direct reading here:
http://gm-volt.com/forum/showthread.php?12958-CAN-bus-reading-remote-viewing
-of-charge-state
<http://gm-volt.com/forum/showthread.php?12958-CAN-bus-reading-remote-viewin
g-of-charge-state&p=226884#post226884> &p=226884#post226884

or main here: http://www.opel-ampera-forum.de/viewtopic.php?f=39
<http://www.opel-ampera-forum.de/viewtopic.php?f=39&t=1147&start=60#p17254>
&t=1147&start=60#p17254

It seems that 5EC returns what you request in 7E4.

Not only Voltage and Current, also Outside Temp and HV-Batterie Temp or
HV-Cooling Temp.

The Meaning of the values depends on the Request in 7E4.

----- It "could" be that 7EC is an answer from the bus too.

And i think that this is a "user generated" output. Generated only by the
Gateway?

Here is a log when DashDaq starts:

34,152 7E0      8 02 01 00 00 00 00 00 00 

34,154 7E8      8 06 41 00 BE 7F B8 13 AA 

34,180 7DF      8 02 01 00 00 00 00 00 00 

34,182 7E8      8 06 41 00 BE 7F B8 13 AA 

34,185 7EB      8 06 41 00 80 40 00 01 AA 

34,186 7EF      8 06 41 00 00 00 00 01 AA 

34,187 7EC      8 06 41 00 80 00 00 01 AA 

34,187 7E9      8 06 41 00 80 00 00 01 AA 

34,188 7EA      8 06 41 00 80 00 00 01 AA 

34,196 7ED      8 06 41 00 00 00 00 01 AA 

34,528 7E0      8 02 AA 00 00 00 00 00 00 

34,533 5E8      8 00 00 00 00 00 00 00 00 

34,591 7E1      8 02 AA 00 00 00 00 00 00 

34,592 5E9      8 00 00 00 00 00 00 00 00 

34,656 7E2      8 02 AA 00 00 00 00 00 00 

34,660 5EA      8 00 00 00 00 00 00 00 00 

34,721 7E3      8 02 AA 00 00 00 00 00 00 

34,728 5EB      8 00 00 00 00 00 00 00 00 

34,787 7E4      8 02 AA 00 00 00 00 00 00 

34,804 5EC      8 00 00 00 00 00 00 00 00 

34,851 7E5      8 02 AA 00 00 00 00 00 00 

34,862 5ED      8 00 AA AA AA AA AA AA AA 

34,916 7E7      8 02 AA 00 00 00 00 00 00 

34,928 5EF      8 00 00 00 00 00 00 00 00 

34,981 7E1      8 04 2C FE 28 E8 00 00 00 

34,984 7E9      8 02 6C FE AA AA AA AA AA 

34,987 7E4      8 10 0C 2C FE 43 4F 43 69 

34,997 7EC      8 30 00 14 AA AA AA AA AA 

34,998 7E4      8 21 43 68 80 1E 80 1F 00 

35,010 7EC      8 02 6C FE AA AA AA AA AA 

35,014 101      8 FE 01 3E 00 00 00 00 00 

35,015 7E1      8 03 AA 04 FE 00 00 00 00 

35,018 5E9      8 FE 00 00 00 00 00 00 00 

35,045 5E9      8 FE 00 00 00 00 00 00 00 

35,058 7E4      8 03 AA 04 FE 00 00 00 00 

35,072 5E9      8 FE 00 00 00 00 00 00 00 

35,099 5E9      8 FE 00 00 00 00 00 00 00 

35,117 5EC      8 FE 34 48 6E 63 60 00 00 

35,126 5E9      8 FE 00 00 00 00 00 00 00 

35,154 5E9      8 FE 00 00 00 00 00 00 00 

35,171 5EC      8 FE 34 48 6E 63 60 00 00 

35,180 5E9      8 FE 00 00 00 00 00 00 00 

35,207 5E9      8 FE 00 00 00 00 00 00 00 

35,226 5EC      8 FE 34 48 6E 63 60 00 00 

It looks like that a 7Ex starts an output from 5E(x+8).  x is between 0 and
7

7E4 -> 5EC

---- 7Ex ( 8 < = x <= F) could be a "control" output from the gateway.

Info from RScott:

I've got some at  <http://www.evtools.info/ChevyVoltOBD2CAN.html>
http://www.evtools.info/ChevyVoltOBD2CAN.html, but really need to update
that page (I've found some more, but not ranges).

If the first byte in 0BC has bit 8 set (leftmost), the car is on; if bit 5
is set, the car is off.

For charging, I can only tell indirectly (e.g. by monitoring the battery SOC
in 206, or the battery kW usage in 3e3 bytes 4-5).

Speed is in the first two bytes of 3E9, as MPH*100 (so hex of 0102 would be
decimal 258, or a very slow 2.58MPH).

4C1 byte 5 has the outside temperature, in degrees Fahrenheit with an offset
of 50 (so 0x76 or 118 decimal would be 68 degrees F).

---------------------------------------

For 4C1 i can say this is correct. But in Germany it is °C. T =( (4C1 Byte
5) / 2 ) - 40

I checked it with my old Logs and the Temperature are right.

Bye

Michael

Am 30.12.2012 um 07:23 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:

Michael,

OK. This looks like an extension to standard OBDII over CAN. See:

http://en.wikipedia.org/wiki/OBD-II_PIDs#CAN_.2811-bit.29_Bus_format

http://mbed.org/cookbook/OBDII-Can-Bus

send:  7E4      8 06 2C FE 43 69 43 68 00

OBDII extension:

*	06 is the number of bytes in the message
*	2C is a custom mode
*	FE 43 69 43 68 00 would normally be the OBDII PID code, but here we
don't know as it is custom

send: 7E4      8 03 AA 04 FE 00 00 00 00

Similarly, 03 is the length, AA 04 FE is the message.

return: 7EC      8 02 6C FE AA AA AA AA AA

02 is the length, 6C FE is the message. The rest is garbage.

return: 5EC      8 FE 4A 6F 00 00 00 00 00 [repeat 160 times]

I think this is just the raw message (not OBDII). It is completely different
from an OBDII over CAN reply.

It is not unusual for the physical controller ID to be a fixed offset from
the OBDII response ID. In standard OBDII over CAN, the offset is often 8.
Here, we're seeing an offset of 0x0200.

Idea:

car is off. -> no data on can bus.

car is off and charging -> can bus wakes every ~30 MInutes up. You can see
in my Logs.

When the can bus is awake (it gets valid SOC Data for example), the Module
send the initialization sequence and then the demand sequence.

It can send the demand sequence every 10seconds until the the can bus go
sleep.

When there are no valid values in 5EC (the rest is valid) (temperature is
zero, we normally don't have -40°C), the module sends the initialization
sequnece again.

I think this is a fine approach.

For your convenience, I've added a hook function vehicle_fn_ticker10() to
the vehicle layer. You can hook into that to get a callback once every 10
seconds.

I suggest you wrap this logic around a "if (sys_features[FEATURE_CANWRITE])"
so that you only do this if canwrite is on. Don't write to the can bus
unless it has been opened in active mode (otherwise the system will loop
waiting for the bus to be writable, then watchdog timeout as it never does).

Other than that, the charging / not-charging state can be maintained in the
way you suggest. You should also be able to detect charging is stopped
(charging -> not-charging) and check the SOC% to decide whether to alert or
not. I think "twizy" Michael does something similar, so you may want to see
how he does it and do it the same way.

The temperature is a nice bonus. I wonder what other fun stuff is hiding :-)

Regards, Mark.

On 30 Dec, 2012, at 12:50 AM, mikeljo at me.com wrote:

Hi,

Johannes find some interesting stuff:

send:  7E4      8 06 2C FE 43 69 43 68 00

return: 7EC      8 02 6C FE AA AA AA AA AA

Set Configuration to get Voltage and Current

send: 7E4      8 03 AA 04 FE 00 00 00 00

return: 5EC      8 FE 4A 6F 00 00 00 00 00 [repeat 160 times]

Byte 1 (4A) Current

Byte 2 (6F) Voltage

Calculation:

I = Byte 1 * 0.2 in Ampere

U = Byte 2 / 2 in Volt

And continue:

Sending this two sequenzes immediately 

7E4      8 10 08 2C FE 43 69 43 68

7E4      8 21 80 1F 00 00 00 00 00

gives with this:

send:  7E4      8 03 AA 04 FE 00 00 00 00

return: 5EC      8 FE 4A 6F 64 00 00 00 00  [repeat 160 times]

Byte 1 and 2 same as before, and in Byte 3 Temperature in °C

T = (Byte 3 / 2 ) - 40

This is the Temp. in raw. in Byte 4 could be Temp filtered. Still searching
the Sequence for this.

Strom: 0x4A * 0,2 = 14,8A

Spannung: 0x6F * 2 = 222V

Temperatur: (0x64 / 2) - 40 = 10°C

Current and Temperature are ok. I think the Voltage must have an Offset (8
or 9) too. Cause my Voltage is around 230V.

It seems that the config send only once (every x Minutes, or so) and the
"give me data" ID (7E4 8 03 AA 04 FE 00 00 00 00) every time you want to get
it.

Then you get ~160 times the requested Values in ID 5EC.

Idea:

car is off. -> no data on can bus.

car is off and charging -> can bus wakes every ~30 MInutes up. You can see
in my Logs.

When the can bus is awake (it gets valid SOC Data for example), the Module
send the initialization sequence and then the demand sequence.

It can send the demand sequence every 10seconds until the the can bus go
sleep.

When there are no valid values in 5EC (the rest is valid) (temperature is
zero, we normally don't have -40°C), the module sends the initialization
sequnece again.

Bye

Michael J.

Am 28.12.2012 um 01:41 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:

Can he provide the logs from the moment the DashDAQ is connected? Perhaps 10
seconds without charging, then start the charge and continue to monitor for
1 minute.

It seems possible that this is enabled by turning on a monitoring mode, but
unexpected. This sort of thing would normally just be transmitted as part of
the normal message stream.

Regards, Mark

On 27 Dec, 2012, at 11:58 PM, mikeljo at me.com wrote:

Am 27.12.2012 um 01:11 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:

Now, on to the other messages (I spoke about yesterday in the other thread).
I'll try to drum up some interest in the forums to see if anyone can help
with the decodes. It would be good if you could do the same.

And here some first results from tachy:

CANUSB mit DashDAQ kombiniert bringts! Ich habe soeben den Code für das
Ladegerät (Ladestrom/Ladespannung) rausbekommen:

5EC Byte 3 Ladestrom Einheit 0.2 A (Bsp: 14.2 A = 47h)
5EC Byte 4 Ladespannung Einheit 2 V (Bsp: 222V = 6Fh)

He works with a DashDAQ and a CANUSB, both connected with a ODB2 Y-Cable.

So he find the Charging Current und Charging Voltage:

5EC Byte 3 Charge Current Unit 0.2 A (Example: 14.2 A = 47h)
5EC Byte 4 Charge Voltage Unit 2 V (Example: 222V = 6Fh)

Fast enough?

BUT!!! This IDs doesn't exist in my Logs. i Think the DasDaq send a Command
to get this ID.

Bye

michael

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130102/501b6fdd/attachment.htm>