[John_Hatchett]

If I am understanding some of the materials, it seems like an soft ECU can spoof any other vehicle ECU by remapping the original ECU onto a temporary bus id, echo it back onto the bus using the original bus id, and selectively replacing values like SOC. If that is the case, then hold mode might be accomplished by remapping the actual SOC values into a range of normal CS mode cut in values, i.e. just subtract a snapshot value from the real SOC and put it back on the bus.

 

[dpeilow]

At least for now that was not even on my radar to try. but I could see the folks in the EU wanting that. Me I just want data, not really commands. I have onstar and dont' precondition now. I could see preconditioning being a bite more complex as one as to wake the car's systems, but at least it does not need a firmware change ;-)

That would be fantastic if you could try. Pre-conditioning was so useful during the recent cold snap but I can only do it at work for my return trip. My garage at home is too far from the apartment for the key fob to reach in the morning.

If it can be done, I'll order an OVMS immediately

All the other stuff will be great too, but bells and whistles compared to remote pre-heat.

 

[tboult]

If I am understanding some of the materials, it seems like an soft ECU can spoof any other vehicle ECU by remapping the original ECU onto a temporary bus id, echo it back onto the bus using the original bus id, and selectively replacing values like SOC. If that is the case, then hold mode might be accomplished by remapping the actual SOC values into a range of normal CS mode cut in values, i.e. just subtract a snapshot value from the real SOC and put it back on the bus.

From my reading that is not how the dynamic PIDs work, and even if they did its not clear the core systems are using dynamic PIDs..

Dynamic PIDs provide a way for a instrument to request data in less overhead. If one issues a dynamic PID, the other data stil keeps flowing on the bus, and the ECU still responds to normal PIDs. One of the points of the DPID is to allow lots of data to flow without repeated requests.. but if the normal request happens it is still honored.

One could spoof data on the bus and answer questions that are intended for a real ECU, but this is likely to cause problems as the receiver will get two sets of conflicting data... and someone would through a error or worse.
(I though about doing that for the ERDTLT, and just spoofing temp data.. but the I realized the OAT goes into HPCM2 which is likely where the decisions are made.

I would expect the same type of thing happens, the core control for switching to hold mode is probably in the ECU that directly measures the battery.. So one could not spoof the battery level.. it would need to keep sending commands to keep the engine on, while the EPCM2 sends it commands to turn off.

 

[Burro]

I have agree with tboult. What you are asking to do is much more complex than just requesting information. PIDs don't have anything to do with this type of request, it will all come across the bus as general CAN messages between modules. It is easy enough to monitor the bus to see what happens when different things are requested but in order to simulate information you would need some way to remove the module from the bus during that simulation. Given the complexity of the interaction, I don't think it would be a good idea.

Since I don't have a Volt I will give a generic example. Say you want to remote start the vehicle. In order to accomplish this, you monitor the bus during a typical remote start and figure out that message 0x100,8,12,34,56,78,11,22,33,44 must be sent across the bus. That is easy enough to accomplish but the module that natively sends that message will be sending out something different. Best case scenario is that the car simply won't start. Now, if you could isolate the module from the bus, you might get the car to start but in addition to message 0x100, that same module also sends out 0x101, 0x102, 0x103, and 0x104. Now you need to know what information those messages contain in order to accurately simulate them. Any variation in that content could have dire consequences. Simply sending the same messages you recorded in the earlier bus monitoring session might be good enough, it might not.

 

[tboult]

For the precondition-remote start I think it may be doable. Since the car already has two modules, one that is receiving the remote control's signal, and the on-star modules. Thus I would conjecture that it is likely what ever module can send remote start signal, is aware the other might also, so at least in the EU, where there is no onstar module, sending the sequence as if its on-star doing the remote-start, should not make the remote-control's module freak out.

I see hold mode I see it as much more difficult to spoof, as the other modules in the car for real would want to keep doing their jobs, which would want to turn off the ice.

My ideas for hold-mode spoofing were originally to mess with the OAT signals, and/or to splice into the OAT thermistor and be able to change the effective temperature by changing resistance. However that is much more hacking and I've not had much time, and with maybe 1-2 gallons a year lost to ERDTLT, its not a priority. Figuring out the stuff on the bus is at least fun for me

 

[RScott]

So I have a burning desire to display instant watts/mile or something similar on my android/torque setup.

eventually would like to have any extraneous loads, like cabin heating and lighting, extracted from that display.

As a reminder for those in this thread, there are two very different ways of getting data from the Volt:

[1] The traditional 'active' method (that the DashDAQ and Torque use), where you make a request for data and get it. This is by far the most common (close to only) method.

[2] The passive ("Monitor All") method, where you can listen to all messages that the Volt sends/receives. I believe that OVMS uses this method.

I believe you cannot easily use both methods at the same time (I.E. you cannot send out a request while in the "Monitor All" mode), but I'm not 100% certain.

So going back to watts/mile, that's doable with method #2. You can get take 2 separate readings of the battery SOC (to determine net kWh used), as well as figure out the mileage between the two (slightly trickier, due to a number that rolls over), and determine the watts/mile. If Torque or other apps can use the "Monitor All" mode, and do calculations, they should be able to display watts/mile.

 

[markwj]

As a reminder for those in this thread, there are two very different ways of getting data from the Volt:

[1] The traditional 'active' method (that the DashDAQ and Torque use), where you make a request for data and get it. This is by far the most common (close to only) method.

[2] The passive ("Monitor All") method, where you can listen to all messages that the Volt sends/receives. I believe that OVMS uses this method.

I believe you cannot easily use both methods at the same time (I.E. you cannot send out a request while in the "Monitor All" mode), but I'm not 100% certain.

Mark (from OVMS) here. I'm really grateful to dpeilow for starting this thread, and to all the other contributors here. While my primary focus is OVMS and helping you guys to get it work on the Volt/Ampera, it is also gratifying to see all the other useful stuff come out of this discussion (such as in-car real time displays for performance monitoring).

From OVMS point of view, we are a direct CAN bus interface with full control of the CAN bus (we don't use an ELM chipset, but instead are a direct CAN bus participant). We can both monitor (passive mode 2, in RScott's terminology) and actively request data (mode 1 in RScott's terminology). Looking at what is on the bus, I suspect we will have to do both to get us all the information we require (as some of the data does not seem to be always transmitted for passive collection, and is only available on request).

Regarding remote vehicle monitoring (state of charge, temperatures, charging, etc), I think we have enough now to be able to code this - and have already started work. The Apps are already showing SOC, and with the extended PIDs discovered here we should be able to get charge state, voltages, current and temperatures (including alerts for charge interrupted).

Regarding remote vehicle pre-condition start, what we need to start is a CAN bus dump of a remote start from OnStar (best) or key fob (also may work). The dump should start when the car is idle (hopefully no bus activity at all), and end a few seconds after the car has finished its startup. Hopefully we can identify the new CAN bus commands used to instruct the car to start.

The Tesla Roadster (the first OVMS car) has a VMS on ID#100 and a VDS display/touchscreen on ID#102. The VDS listens for messages on ID#100 to produce its display, and when you issue a command (e.g. lock car, stop charge, etc) the VDS transmits on ID#102 to the VMS. For OVMS, all we do is spoof those exact same ID#102 messages. From the VDS point of view, it doesn't care (it is probably not even listening to those ID#102 messages), and from the VMS point of view, it looks like the VDS is sending it commands. It works very well, and allows us to remotely do pretty much anything that can be done in the car itself (from the VDS). Now, I realise that the Volt/Ampera may be different, but I think there is a good chance this will work (otherwise it would be very hard for OnStar to implement remote start / pre-heat).

Regards, Mark.

 

[tboult]

As a reminder for those in this thread, there are two very different ways of getting data from the Volt:

[1] The traditional 'active' method (that the DashDAQ and Torque use), where you make a request for data and get it. This is by far the most common (close to only) method.

[2] The passive ("Monitor All") method, where you can listen to all messages that the Volt sends/receives. I believe that OVMS uses this method.

I believe you cannot easily use both methods at the same time (I.E. you cannot send out a request while in the "Monitor All" mode), but I'm not 100% certain.

So going back to watts/mile, that's doable with method #2. You can get take 2 separate readings of the battery SOC (to determine net kWh used), as well as figure out the mileage between the two (slightly trickier, due to a number that rolls over), and determine the watts/mile. If Torque or other apps can use the "Monitor All" mode, and do calculations, they should be able to display watts/mile.

I've tried some MA in bluetooth to the android but I get many corrupted packets suggesting it cannot keep up. USB passive monitoring was okay but I don't really want a wire every day.

How many bytes are you getting for SOC in MA mode?

If 1 byte then it is too course for instantaneous kWh.. But with only 16kwy/255 each "tick" is .062 kWh. Okay for a running average every min or so) as its about 4 ticks per mile (if one is doing 40miles/charge).

There are fields for instant volt and amps which is what I'm looking for for instant kWh..
If I don't any more help from dashdaq folks, I'll probably do some Y-cable work with MA and torque in parallel so I use what you've learned to try to figure out the PIDs.

 

[RScott]

I've tried some MA in bluetooth to the android but I get many corrupted packets suggesting it cannot keep up. USB passive monitoring was okay but I don't really want a wire every day.

How many bytes are you getting for SOC in MA mode?

If 1 byte then it is too course for instantaneous kWh.. But with only 16kwy/255 each "tick" is .062 kWh. Okay for a running average every min or so) as its about 4 ticks per mile (if one is doing 40miles/charge).

There are fields for instant volt and amps which is what I'm looking for for instant kWh..
If I don't any more help from dashdaq folks, I'll probably do some Y-cable work with MA and torque in parallel so I use what you've learned to try to figure out the PIDs.

The Volt does have a massive amount of data constantly being sent. It uses a 500kbps speed, but most OBD2 adapters transmit the data in ASCII, which more than doubles the amount of data being transferred. From my understanding, Bluetooth cannot quite handle the traffic (for passive/MA). Wifi would be ideal, but is expensive (as very few cars would need it).

For SOC, I get 3 bytes: 2 with the SOC, and a null byte. For example, "206 8CBA00" where the SOC is 8CBA (hex) or 36,026 decimal, or 9.0065kWh (36,026/4000).

There are some instantaneous electric usage readings available in MA, but I haven't figured them all out. I believe 3E3 is power flow in/out of the battery (sent about 1-2 times per second), but not certain of that.

 

[Burro]

The Tesla Roadster (the first OVMS car) has a VMS on ID#100 and a VDS display/touchscreen on ID#102. The VDS listens for messages on ID#100 to produce its display, and when you issue a command (e.g. lock car, stop charge, etc) the VDS transmits on ID#102 to the VMS. For OVMS, all we do is spoof those exact same ID#102 messages. From the VDS point of view, it doesn't care (it is probably not even listening to those ID#102 messages), and from the VMS point of view, it looks like the VDS is sending it commands. It works very well, and allows us to remotely do pretty much anything that can be done in the car itself (from the VDS). Now, I realise that the Volt/Ampera may be different, but I think there is a good chance this will work (otherwise it would be very hard for OnStar to implement remote start / pre-heat).

Regards, Mark.

Mark,

You may very well be right but I would be surprised if you can remote start the vehicle and keep it running just by sending the request across CAN. Sending a command like unlock a door is easy enough because you aren't fighting the existing control module. You send the command and the module carries out that request. There is no need to continually send the unlock request. I bet after the first time you send the remote start request, either the telematics module or BCM will come to life and contradict the request, shutting the engine down(if it even gets started). If you continually send the remote start request and a competing module sends a shutdown request, the module should default to the safest state which would be engine off.

I know this has been tried before on other GM vehicles. I don't think anyone ever got it to work without editing the module programming. That being said I am all for someone giving it a shot, if any one can get a passive recording of the HSCAN bus during a keyfob remote start event you are probably looking for a signal that contains databytes 04 0B. I don't know the arbitration ID.

 

[John_Hatchett]

Regarding remote vehicle pre-condition start, what we need to start is a CAN bus dump of a remote start from OnStar (best) or key fob (also may work). The dump should start when the car is idle (hopefully no bus activity at all), and end a few seconds after the car has finished its startup. Hopefully we can identify the new CAN bus commands used to instruct the car to start.

All I have is an Elmscan. If I get the OVMS hardware module and cable can I log the CAN bus and send it to you?

 

[tboult]

All I have is an Elmscan. If I get the OVMS hardware module and cable can I log the CAN bus and send it to you?

is your the elmscan with USB or rs232 connector? I still think any ELMSCAN can log all bus data (using MA to monitor all. )It would need the serial port set to its highest speed (1 or 2 mbit).

 

[markwj]

All I have is an Elmscan. If I get the OVMS hardware module and cable can I log the CAN bus and send it to you?

With something like ELMSCAN, you need a MA (Monitor All) dump. I think one of the other members on this forum could help with that.

The OVMS module can't (at the moment) get a can bus dump. While it can capture data from buses running at up to 1Mbps, it really doesn't have anything fast enough to get the data out (to a laptop, whatever).

 

[markwj]

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?

 

[John_Hatchett]

is your the elmscan with USB or rs232 connector? I still think any ELMSCAN can log all bus data (using MA to monitor all. )It would need the serial port set to its highest speed (1 or 2 mbit).

USB. I also have a Bluetooth version that I use with Torque on several vehicles.

My elmscan came with OBDwiz which has a terminal mode so I think it isn't too hard to get into MA mode and log the file. I'll try it when I get the Volt back from my son later this week. He disappears with the car during school breaks.

Could we get "hold mode" by spoofing a low OAT message onto the bus or would that only get it to warm up the coolant?

 

[tboult]

USB. I also have a Bluetooth version that I use with Torque on several vehicles.

My elmscan came with OBDwiz which has a terminal mode so I think it isn't too hard to get into MA mode and log the file. I'll try it when I get the Volt back from my son later this week. He disappears with the car during school breaks.

Could we get "hold mode" by spoofing a low OAT message onto the bus or would that only get it to warm up the coolant?

If OBDwiz does not work, http://sourceforge.net/projects/pyobd2/ has a record all mode which is pretty easy to use.


My concern with spoofing OAT messages is that they are sent from the HPCM2, which is likely the same ECU that makes the decision and sends out message about starting the engine.. so not clear it would listen to us sending data about the OAT. (Note that would not be a PID.. it would have to watch to see what OAT was sending and then spoof it. Since OAT sends data regualrly it would be a fight.

A slightly safter approach might be to try to spoof it with the hood open switch, but that too is directly connected into the HPCM2 (connector X1 pin 52).. so I don't think it could be spoofed. (It also seems to go to the body-control-module, so it may be worth checking if the BCM is sending out anything, but again I expect its a direct connect to the HPCM2 so not spoofable). It would likely be possible to add a swtich (X1 connector is under the passenger seat), to spoof open/close.

 

[tboult]

USB. I also have a Bluetooth version that I use with Torque on several vehicles.

My elmscan came with OBDwiz which has a terminal mode so I think it isn't too hard to get into MA mode and log the file. I'll try it when I get the Volt back from my son later this week. He disappears with the car during school breaks.

Could we get "hold mode" by spoofing a low OAT message onto the bus or would that only get it to warm up the coolant?

If OBDwiz does not work, http://sourceforge.net/projects/pyobd2/ has a record all mode which is pretty easy to use.


My concern with spoofing OAT messages is that they are sent from the HPCM2, which is likely the same ECU that makes the decision and sends out message about starting the engine.. so not clear it would listen to us sending data about the OAT. (Note that would not be a PID.. it would have to watch to see what OAT was sending and then spoof it. Since OAT sends data regualrly it would be a fight.

A slightly safter approach might be to try to spoof it with the hood open switch, but that too is directly connected into the HPCM2 (connector X1 pin 52).. so I don't think it could be spoofed. (It also seems to go to the body-control-module, so it may be worth checking if the BCM is sending out anything, but again I expect its a direct connect to the HPCM2 so not spoofable). It would likely be possible to add a swtich (X1 connector is under the passenger seat), to spoof open/close.

 

[Burro]

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. 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?

Mark,

I would do everything you can to try to identify the signals as they come across the bus natively. If the stories about scangauge causing problems are due to a limited amount of bus capacity left, you should do as much with the signals that are already there as possible to avoid causing problems in the future when the inevitable request for more parameters comes along. Once you have that done, I don't think it really matters whether you use 0x22 or 0x2C. With such a low raster rate, you really arent buying yourself anything by using 0x2C. I think coding the 18F(assuming you are using the OVMS) for mode 22 action would be much easier than trying to lump all 10 signals into one big 0x2C request and then trying to parse out the results through the continuation frames. I havent looked at your OVMS coding too closely but if you use mode 22 you can probably use some of your existing functions without the need to write all new routines.

If you are set on using 0x2C I would try to lump the signals into manageable packets that don't require the handling of the continuation frame on either the Tx or Rx side. That probably limits you to 2 signals per request. I don't know if the dashdaq always uses identifiers in the Fx range but all the traffic I have seen so far seems to indicate that is the case. With 256 possible identifiers you should be able to find a sweet spot that won't interfere.

Your idea of a table with id's and polling times is a good one. Once you determine that and which signals you can passively acquire, the mode will probably fall into place based on the amount of time you want to spend coding and the memory left on the 2685.

 

[tboult]

If there is a table with "needed" data and timing, then passive monitoring could be used as much as possible and when the needed data is not there, then a mode 22 pID request could fill it in. Using PID request could help us identify the data that is just naturally flying around, allowing us to correlated values. and then the PID usage could be reduced as much as possible.

I've been doing some pretty hefty logging these past two days, with 120 PIDs being polled and have not had any problems. I did reduce my polling rate to about 6 polls of 120 per second (so about 720 PIDs per second) and at that rate I never noticed any problems with the car.

 

[markwj]

I don't think it really matters whether you use 0x22 or 0x2C. With such a low raster rate, you really arent buying yourself anything by using 0x2C. I think coding the 18F(assuming you are using the OVMS) for mode 22 action would be much easier than trying to lump all 10 signals into one big 0x2C request and then trying to parse out the results through the continuation frames. I havent looked at your OVMS coding too closely but if you use mode 22 you can probably use some of your existing functions without the need to write all new routines.

The 2C is quite messy as it is a 2-stage request. First the setup, wait for reply, then request for data, then wait for data.

Is 22 easier? Given the small number of PIDs being polled and slow poll rate, I don't see the one-pid-per-request of 22 being a problem. Do you have a simple example for a 22 request (for example for the 0x0046 PID on 7E0)?

I pushed the code for polling to github last night. You can see it at:

https://github.com/markwj/Open-Vehi.../Open-Vehicle-Monitoring-System/blob/master/vehicle/OVMS.X/vehicle_voltampera.c

Not too complex. But, according to first reports it is not getting the responses (which I suspect is because I'm not doing the 2-stage request but merely transmitting both requests together).

What I see on the can bus, for my code is the following pair of messages transmitted once every ten seconds:

7E0 8 04 0C A0 00 46 00 00 00
7E0 8 03 AA 01 A0 00 00 00 00

I don't have the car, so can't know the reply