Add lots of DTC codes for Volvo 850/SVC70

[brendandburns]

See #67

Sourced from http://jonesrh.info/volvo850/freediag_v1_08_20171212.zip

More to come eventually.

[fenugrec]

Oh wow that is quite a list, thanks for extracting that.

Is there a reason for the ordering of the sections ? e.g. one block of codes starting with {0x01 is after 0x58, etc.

[brendandburns]

This is cut/paste straight from that zip file. I preserved the existing order. If you'd prefer a different order, I can do that.

[brendandburns]

fwiw, this change fixed it so that I got a human readable description for my ECC error code (0x37)

[aaeegg]

The current table of just two DTCs is almost just a placeholder. It would be nice to use this longer table, but it could use some cleanup.

@fenugrec, any thoughts on moving the DTC table out of scantool_850.c into its own file?

Here is some background on the big DTC table:

This is an accurate representation of how the KWPD3B0 interpreter at
http://jonesrh.info/volvo850/kwpd3b0_interpreter.html translates the
2 hex digit raw DTC code sent from the ECUs into the 3-digit Volvo DTC code
that the Volvo world discusses (as of the date of this document).

However, THERE IS ABSOLUTELY NO GUARANTEE THAT THE 2-DIGIT RAW TO
3-DIGIT VOLVO DTC INTERPRETATIONS SHOWN BELOW ACCURATELY REFLECT THE
CORRECT MEANING OF THE RAW DTC CODE!!! This is simply our best attempt
at understanding them with the limited resources available.
So, DIYer, feel free to use them as a guide, but do not consider them
as an authoritative guide. We have no idea how well they correlate with
the DTCs declared by an official Volvo VST tool (or a VST-lookalike tool).
Determining their accuracy is left as the proverbial "exercise for the reader".

[fenugrec]

It would be nice to use this longer table, but it could use some cleanup.

Agreed. Not familiar with D2 but it looks like it could almost be a table-of-tables (one table per "ECU" type (first byte), and one table that holds all these known types) ? Whatever makes further maintenance and/or restructuring easier.

@fenugrec, any thoughts on moving the DTC table out of scantool_850.c into its own file?

Totally in favour.

[aaeegg]

Changelog doesn't belong in code, we have version control for that. But Richard H. Jones should get credit for the DTC table.

[fenugrec]

Richard H. Jones should get credit for the DTC table.

agreed. Does he have a presence on github ? unclear if https://github.com/jonesrh is the correct profile

[aaeegg]

I guess that's probably him. I will ask.

[aaeegg]

@fenugrec Richard says: "The GitHub user known as jonesrh is very likely me. I don't have any records of login credentials for GitHub and I don't remember registering."

[aaeegg]

These are Richard's notes on his contribution, they don't belong in the code.

[aaeegg]

Don't comment this out, just get rid of it.

[aaeegg]

The "ECU xx has xx DTCs" lines are an artifact of how the DTC list was generated, they don't belong here.

[aaeegg]

I'm not crazy about the, sometimes extremely long and with web links, tips / reference material in some of the descriptions. Also I don't think the cross-references to J1979 OBD2 codes are that useful.

[aaeegg]

Note "exhaust value" = "emission level" per Green Book, ie, misfiring badly enough to cause elevated emissions, but not enough to cause catalyst damage.

[aaeegg]

According to the Green Book, EFI-551...555 and 545 are misfires with catalyst damage (flashing CEL). EFI-451..455 and 543 are more minor misfires.

[aaeegg]

You might be saying to yourself, "I've never had ignition in cylinder 6, so shouldn't this DTC always be set?" But the Motronic M4.4 (or M4.4.1) was also used in some model years of 960/S90/V90/C90. But then 0x37 should probably map to something like EFI-456 instead of EFI-445.

[aaeegg]

I'm sure that 0x1D is EFI-666 DTC in TCM / MIL request from TCM. So 0xA4 EFI-335 must not be MIL request from TCM - it must be cable fault between TCM and ECM (the MIL request signal is shorted or open).

[aaeegg]

I guess these say "Driver's (or passenger's)" because which side is the driver's side depends on whether it's a left or right hand drive vehicle. But VADIS says 4-1-2 is for the driver's side sensor intake fan whether you have a LHD or RHD vehicle selected. So either the localization in VADIS is wrong, or the driver's side DTCs are driver's side regardless of market.

[brendandburns]

fwiw, there's a manual with codes here:

https://www.volvo-forums.com/threads/heater-ac-blower.32164/

Which seems to indicate that you are correct it is always "Driver's side"

Since, I'm going to be trying to fix this soon-ish, so I'll let you know if it's right :)

[aaeegg]

Looking into this a bit further... up to model year '97 there were two passenger compartment temperature sensors, in the headliner, one on each side. From model year '98 up, there was a single passenger compartment temperature sensor, between the steering wheel and the climate controls. '98 was the first model year where the ECC could be queried by D2; before that, it could only do blink codes, so we can't talk to it. (Although it would be cool to try to get blink code reading working with a KKL cable and the appropriate wiring!)

So the only ECC we can talk to uses a single interior temperature sensor... we should just drop "driver's side" from these DTCs.

[fenugrec]

this can be a separate discussion, but you guys mention this DTC list was somehow generated from another source. Is that process automated, with an 'upstream' we should link/refer to ? We don't need to absorb all of that into freediag of course, but maybe worth looking into tweaking that generation step to produce something directly usable in freediag (i.e. already trimmed of the items @aaeegg marked as 'doesn't belong in here', the less well-defined entries, etc )

[aaeegg]

it looks like it could almost be a table-of-tables (one table per "ECU" type (first byte), and one table that holds all these known types) ?

Yes, there's structure in the data that's not represented by the current format. Splitting into a table-of-tables would also let us remove the duplication between the Power Seat Left and Power Seat Right DTCs. The advantage of leaving it in its current format is that no one has to change the code...

[aaeegg]

this can be a separate discussion, but you guys mention this DTC list was somehow generated from another source. Is that process automated, with an 'upstream' we should link/refer to ? We don't need to absorb all of that into freediag of course, but maybe worth looking into tweaking that generation step to produce something directly usable in freediag (i.e. already trimmed of the items @aaeegg marked as 'doesn't belong in here', the less well-defined entries, etc )

Richard has a website where you can paste the raw ELM327 output from a terminal program, and it will interpret the DTCs. This list is the DTC list he maintained for that website. He has updated his site since this list was exported in 2017 - so the list in this PR is outdated. I've asked his permission to scrape a new list.

The previous export was manual, but it should be possible to automate it.

[brendandburns]

@aaeegg I'm happy to see about writing some code to automate this if you want. I'll also attempt the cleanups that you describe above, specifically the table of tables.

[aaeegg]

Richard has given permission to pull an updated DTC list from his interpreter, but he suggested another developer who might be willing to share a better list. Waiting for a response from that person.

[fenugrec]

splitting into a table-of-tables would also let us remove the duplication between the Power Seat Left and Power Seat Right DTCs. The advantage of leaving it in its current format is that no one has to change the code...

Ok. What do you guys think about this sequence :

1. split out current handful of DTCs in separate file, with some kind of structure (table of tables or whatever is appropriate) in preparation for next step
2. add either the 2017 list of DTCs above (including fixes from @aaeegg 's review), or a newer scrape of Richard's list, or that potential other dev you mentioned
3. optional future step for a separate PR, anything needed to automate or bring the DTC list in a state that makes it easier to maintain and/or regenerate

[aaeegg]

Splitting the DTC table into a separate file is definitely the first step.

A table of tables is probably better than the current format. That said, I don't see an immediate pressing need to change the format. If @brendandburns wants to do the work, I have no objection.

Automation would depend on which DTC list we end up using. If we don't hear back on the better list soon (maybe by Monday?), an updated version of Richard's list should be the best way to move forward.

[aaeegg]

Aleksi Venäläinen, author of the 850 OBD-II Android app, has agreed to provide us with his DTC list.

[brendandburns]

@aaeegg once you get it, if you want to attach the DTC list to this PR, I can refactor this PR to contain that list.

In the meantime I bought Aleksi's app, so maybe that's Karma :)

[aaeegg]

@brendandburns @fenugrec

DTC_List_850OBDII_D2.txt - Aleksi's current DTC list
export_2024-04-06_frobbed.txt - Richard's current DTC list

Aleksi's list has more DTCs, but Richard's list seems to have a few that aren't in Aleksi's, so I attached both.

Aleksi's list retains some of the problems of Richard's, such as the typo of EFI-445 for cylinder 6 misfire on 960 (confirmed in VADIS as EFI-456; raw value remains unconfirmed), and the lack of detail on minor vs major misfires.

It turns out that Motronic M4.4, Siemens EMS2000 and Denso ECUs all respond to address 7A, but have different DTCs. So, to handle all these ECUs, we will need to split the table, like fenugrec suggested.

Richard has tried to include as much helpful information as possible in the text, but my opinion is the DTC table should just have the DTC description, and either remove the parentheticals entirely, or put them in a separate "tips" table. Any thoughts on this?

As an aside, it would be nice to also add decoding for J1979 DTCs.

[fenugrec]

either remove the parentheticals entirely, or put them in a separate "tips" table

agreed. Either would be fine. Could also be formatted as an extra field in the eventual DTC struct ?, i.e.

struct {
  u8 dtc[?];
 ...
  const char *short_description;
  const char *tips;

If the source list is in a fairly uniform format, a fancy sed command may even be able to automatically generate the table entries. Whatever the automation method, I think it should be documented / included in one of the table files.

[brendandburns]

Ok, I will take a stab at adding the extra tips field.

Thanks for all the info!

[brendandburns]

Closing in favor of #99