[Ovmsdev] Volt/Ampera
Mark Webb-Johnson
mark at webb-johnson.net
Wed Jan 9 14:32:42 HKT 2013
Burro suggests:
Service 0x22 explanation by Burro:
Service 0x22 is an easier single state call.
Let say you wanted engine RPM then you would send
7E0 03 22 00 0C 00 00 00 00
And this will hopefully return:
7E8 04 62 00 0C 10 7E 00 00
Letting A=10 B=7E from the return, RPM = (A*255+b)/4 or 1055 RPM.
Format of the return data is
requsedID+0x08,
length,
confirm of requested mode+0x40 (i.e. 22 + 40)
2 bytes for PID
length-2 bytes of data
For your request for OAT
7E0 03 22 00 46 00 00 00 00
would response something like
7E8 03 62 00 46 30 00 00 00 00
(answer as before is Temp (now in in Byte 4) where 0x30 => 8°C (unit 1 °C offset 40) )
Can Michael / Johannes try:
7E0 03 22 00 46 00 00 00 00 (ambient temperature)
(and see what comes back on 5E8 and/or 7E8?)
7E4 03 22 43 69 00 00 00 00 (onboard charger current)
7E4 03 22 43 68 00 00 00 00 (onboard charger voltage)
7E4 03 22 80 1F 00 00 00 00 (outside temperature filtered)
7E4 03 22 80 1E 00 00 00 00 (outside temperature raw)
7E4 03 22 43 4F 00 00 00 00 (high voltage battery temperature)
7E4 03 22 1C 43 00 00 00 00 (PEM cooling loop temperature)
(and see what comes back on 7EC and/or 5EC?)
I think mode 0x22 will be much neater to code with.
Regards, Mark.
On 9 Jan, 2013, at 9:55 AM, Mark Webb-Johnson wrote:
> Michael,,
>
> On my simulator, I saw the following pair of messages transmitted every 10 seconds:
>
> 7E0 8 04 0C A0 00 46 00 00 00
> 7E0 8 03 AA 01 A0 00 00 00 00
>
> If I stopped the simulator transmitting bus messages, the poll requests stopped as well. So, I'm pretty sure the logic works.
>
> The problem is most likely the car response to those messages. We're listening on CAN ID #5E8, and the reception code seems to be ok. Perhaps the car needs a delay between the two request messages, as we should really be waiting for the acknowledgement response? If so, that is a little bit tricky, but possible.
>
> Can you, or Johannes, try to send those messages and check the car response? Or, T the can bus and monitor the car response with the module in place (the best way) to see what is coming back?
>
> Regards, Mark.
>
> On 9 Jan, 2013, at 12:46 AM, mikeljo at me.com wrote:
>
>> Hi,
>>
>> burn it in the module. Can_write set to 1
>> All data (VIN, SOC, etc) are here, except the temperature.
>> In the car since 17:40 (MEZ), you can have a look at the logs.
>>
>> Bye
>> Michael J.
>>
>>
>> Am 08.01.2013 um 15:44 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:
>>
>>> I've committed some template code for this, trying to do what Michael J suggests, but in an expandable way.
>>>
>>> Here are some notes:
>>>
>>> vehicle_voltampera_polls is a rom array of struct that stores the pids to be polled, and the seconds between each poll. Each entry should be given a unique requestid, as that is what you will be using to pickup the result. The last entry is 0, which acts as a terminator.
>>>
>>> Polling code is in vehicle_voltampera_ticker1() and should be fairly self-explanatory. It should cope with 1, 2 or 3 PIDs per poll - but I've only tested 1 :-) Note that if either the CAN_WRITE feature is off, or the bus has not recently seen activity, then the polling doesn't happen (I've tested this, and it seems to work well).
>>>
>>> vehicle_voltampera_poll1() needs to handle filter 5 for the received data, then looks in the first byte for the requestid to know the format of the data that is coming back.
>>>
>>> vehicle_voltampera_initialise() must be modified to setup a receive filter. The example uses filter #5 on ID#0x5E8. Hopefully this filter can be extended (by mask) to allow other responses to be picked up.
>>>
>>> I hope it is clear. It is not complete, but should be able to be tested to see if it picks up the temperature.
>>>
>>> Regards, Mark.
>>>
>>> On 8 Jan, 2013, at 8:50 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>
>>>>
>>>> I just posted this, and repeat here to see if someone can test:
>>>>
>>>>> Burro writes:
>>>>> According to the bus data presented above the DashDaq is using mode 0x2C to request the identifiers. The message structure for mode 0x2C for one, two and three parameters is as described above. Using that example, the ID 0x7E4 is the battery module, 8 is the message length, 04 is the significant bytes in current message, 2C is the mode(dynamically defined data identifier), FE is the requested response ID and the next two bytes are the PID.
>>>>> ...
>>>>> 04 is the next byte and that lets the module know you are looking for a fast response rate. Decreasing numbers here means decreasing response speed. 01 will get you one response and 00 will stop the response all together.
>>>>> ...
>>>>> This is a good way to reduce the clutter on the bus because you can request and receive multiple pids in one shot. As opposed to mode 22 which nets you one response per request. If you want to set up more than three you can just change the response ID from FE to one of the others like FD, FC, FB.... add your PIDs and then ask for the response.
>>>>
>>>> OK. Having reviewed all this, it looks like we're going to have to regularly poll perhaps 10 extended PIDs. Most of these don't need to be polled very often (perhaps once a minute or so would be fine).
>>>>
>>>> What we should probably do is setup a table of modules and PIDs we want with corresponding poll times. The code will then check this and poll each one in turn. We can rely on the +0x08 and -0x200 offsets from the module ID (which will allow us to query different PIDs on different modules). The reply doesn't seem to contain information on the PID being returned, so presumably we'll have to use the response ID to match responses to requests. To avoid conflicting with DashDaq, does anyone know if DashDaq uses a specific range, or is there some other way of avoiding conflict?
>>>>
>>>> My question is: what is the best way of polling these? We've seen DashDaq use mode 0x2c with response rate 0x04, but that generates a stream of 160 or so responses and seems excessive for what we need. Do you think it best we use mode 0x2c with response rate 0x01 (single response?), or mode 0x22?
>>>>
>>>> Can someone try a mode 0x2c request with response rate 0x01 and see what comes back? Perhaps:
>>>>
>>>> 7E4 8 04 2C FE 43 4F 00 00 00 (command: request 0x434F)
>>>> 7EC 8 02 6C FE AA AA AA AA AA (answer: OK)
>>>>
>>>> 7E4 8 03 AA 01 FE 00 00 00 00 (command: display data)
>>>> 5EC 8 FE 30 00 00 00 00 00 00 (answer: HV Temp in Byte 2, 0x30 => 8°C (unit 1 °C offset 40) )
>>>>
>>>> How may 5EC responses come back?
>>>>
>>>> I think that once this is answered / tested, then we can actually code it. It doesn't look very hard and the table driven approach should work well for future expansion (just add a row to the table for the request, and add the code to extract the response) - the generic OBDII stuff I'm working on looks very similar.
>>>>
>>>> Regards, Mark.
>>>>
>>>> On 5 Jan, 2013, at 8:40 PM, mikeljo at me.com wrote:
>>>>
>>>>> Hi mark,
>>>>>
>>>>> in this post was a very good description about decoding the Message transfer:
>>>>> http://gm-volt.com/forum/showthread.php?12958-CAN-bus-reading-remote-viewing-of-charge-state&p=228397#post228397
>>>>> from Burro. Easier than reading the Full GM3110 Doc.
>>>>>
>>>>> i think that we must look at the bus to identify witch IDs are active. So we can use a free one. And listen only to this.
>>>>> >>"FE is the requested response ID"
>>>>> I think is necessary when there is more than one "diagnostic tool" connected to the bus
>>>>>
>>>>>
>>>>> Bye
>>>>> michael
>>>>>
>>>>> Am 03.01.2013 um 02:28 schrieb mikeljo at me.com:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> thx.
>>>>>> But it was only the first quick try.
>>>>>>
>>>>>> I think you are quicker than i with implementing it. So please go on.
>>>>>> I the Moment we can only get data when the Bus is awake from the car itself.
>>>>>> I can wake the Bus, but can't get Data in this time. I get only an answer from one Gateway (641).
>>>>>> Search to get more answers from different ECUs.
>>>>>> So i think the trigger to start the timer is, when there are valid data on the bus.
>>>>>> The timer collects the wanted data and goes to sleep for a Minute, or so.
>>>>>> Timer stops and reset itself after ~30 seconds with no data on the bus.
>>>>>> So we can get data when the car is on and approx. every 30 Minute when car is charging.
>>>>>>
>>>>>> Bye
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Am 03.01.2013 um 00:46 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:
>>>>>>
>>>>>>> Fantastic.
>>>>>>>
>>>>>>> Do you/Michael want to try to implement this, or shall I?
>>>>>>>
>>>>>>> Regards, Mark
>>>>>>>
>>>>>>> On 3 Jan, 2013, at 4:22 AM, <info at opel-ampera-forum.de> wrote:
>>>>>>>
>>>>>>>> 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&p=226884#post226884
>>>>>>>> or main here: http://www.opel-ampera-forum.de/viewtopic.php?f=39&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, 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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>
>> _______________________________________________
>> 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/20130109/c7ddf97e/attachment.htm>
More information about the OvmsDev
mailing list