[XantheFIN]

Thanks for your concern, and while it IS a cheap chinese clone(4EUR through amazon.com, incl. shipping!), it is 'genuine' with a PIC, proper BT module, and responds 'as it should' with ATZ, ATAL etc etc.
The PCB also have designated locations for the FT232 chip and USB cable - pre-tinned and all. So its not hard to convert it at least :)

Ah.. Sir you have made new record lol to find cheapest working ELM327 in my knowledge. :D

ATPPS and ATPP works too i assume? Doesn't need answer if it does.. i assume they do then. Have fun.

[Lucif3r]

There, finally managed to get the piece of junk to spit out the milage... Ironically it refused to work properly when typing the commands manually in realterm, but using jonesrh's script worked fine...?
Need to figure out what that script is doing differently from me typing manually... And then I can start messing around with the arduino sketch. Not today though...

Interesting fact though; even though my cluster is in kilometers, the reading came out in miles. Once converted to km it matched decently well with the display, not as well as I expected though...
My car's display is showing 246600(I dont remember the last 2 digits, lets pretend its 00), and readout was 18 3C, byteswapped 3C18, convert to DEC 15384, * 10 = 153840, 153850 * 1.6 = ~247580, 247580 - 246600 = ~980km difference. :| Ah well, at least it works :d
And my car is an italian V70 T5 -97, motronic 4.4, B5204T3, manual trans.

[esl97850T5]

1. For people that want an Android app to read the 97 850 vehicle mileage, XantheFIN's app will do it. You'll have to contact him to evaluate his latest BETA version.

2. For people that want a very simple Python program to read the 97 850 vehicle mileage, check out:

- mikeri's volvoforums.com thread: http://volvoforums.com/forum/volvo-850- ... 327-84508/
This works for M44 as well as M43.

- mikeri's MVS post: http://www.matthewsvolvosite.com/forums ... 14#p371344

I think mikeri's program is a **very** good, simple introduction to how to initiate a connection to the '97 850 COMBI using an ELM327 compatible device and to interpret the responses in realtime. It's true that mikeri's executable is for Windows. But he supplies you the Python source, and you can run Python apps on many different platforms, so it should be adaptable to about any common platform. That's one reason I think it is such a good example.

I'm in the process of making mikeri's Python program more robust, since sometimes it reports an erroneous mileage in the 10000-11000 miles range due to a lack of sufficient error processing.

3. For people that want a more extensive (open source) program to read the 97 850 vehicle mileage, reset the SERVICE light, reprogram the Service intervals, read/clear DTCs, perform both COMBI / ABS / SRS / AW 50-42 style diagnostics as well as standard OBDII emission diagnostics, the Window's based volvo850diag / IE / Realterm / Javascript program will work. However, with volvo850diag / IE / Realterm you have to perform interpretation of the data in a non-realtime fashion using a server based interpreter. volvo850diag can be downloaded from http://jonesrh.info/volvo850/volvo850.zip. For info, view pages at the http://jonesrh.info/volvo850/ portal.

4. Lucif3r, glad to see you've gotten hooked up with XantheFIN and with volvo850diag. Remember volvo850diag is "super"-open source, since it's using the CC0 license, which is essentially public domain.

5. Also, glad to hear you are trying to get an Arduino interface to your 97 V70's Motronic 4.4.

An Arduino should be able to communicate with a '96-'98 850/S70/V70 Motronic 4.4 with either an ELM327 or a VAG/COM KKL cable.

5a. I think you already can see from volvo850diag that you'll be able to get an ELM327 connecting the Arduino with the Motronic 4.4.

Be sure to use volvo850diag's "Full Scan All ECUs" facility. That's the main place in volvo850diag v0.7 that there is a small amount of scanning of Motronic 4.4. There's only 3-5 items that are interpreted by kwpd3b0_interpreter at present, since I don't have a Motronic 4.4 to work with and haven't had time to combine some of the rkam-sourced info and the MotronicSuite M44 conversion tables into proper M44 intrepretations.

PM me or e-mail me if you would like me to send you some snippets from the in-development volvo850diag v0.8beta that have exhaustive scanning of the M44 using the rkam-sourced info on one of the Volvo forums. You can then just paste the snippet into your present volvo850diag version. You'll have to figure out how to interpret most of them yourself.

Like XantheFIN mentioned, the ELM327 totally eliminates the need for you to do any detailed 5-baud programming.

And the ELM327 can inherently do regular OBDII emission diagnostics, and can also be made to do the KWPD3B0 diagnostics (COMBI, ABS, SRS, Motronic 4.4 via KWPD3B0, etc).

5b. But you can also connect your Arduino interface to M44 using the VAG/COM KKL cable (probably either FTDI based or CH340 based or whatever based). In some ways its more difficult than the ELM327, but in other ways it's simpler than the ELM327. Plus with the VAG/COM KKL approach, you could do M44 flashing, logging of the high-speed data acquistion from flashed M44 ECMs that output for Tuner-Pro, do OBDII pin 7 to pin whatever programming for other ECMs (eg, the M43), etc. Those later 3 things an ELM327 will never do.

The approach you were going to use to perform your 5-baud connection is what I think everyone uses nowadays, since I don't think there are any serial chips that allow setting the baud rate to 5-baud -- namely, toggling the transmit line every 200 ms to simulate the 1 start bit, 8 data bits (or for some of the bytes in the init sequence, 7 data bits + 1 parity bit), then 1 stop bit. The trick after sending the target ECU address at 5-baud is to get your ISO 9141-2 mandated timing correct enough so the rest of the init sequence exchange transpires to the target ECU's satisfaction and to your Arduino's satisfaction. There's also some complication in the init sequence where at least 1 or the last 2 bytes exchanged involves odd parity (according to the ISO 9141-2 spec). So basically you've got something like:

- Toggle the transmit line for an extended time -- you would probably want to do this for 500-750 ms at least -- I forget if it is high or low.
- Toggle for 200 ms to produce the start bit.
- Toggle for 200 ms each for each of the target ECU's bits -- I don't remember if it is LSB first or MSB first. Check the spec.
- Toggle for 200 ms to produce the stop bit.
- Set baud rate to 10400 baud.
- Initiate a read for 3 bytes.
- Wait for the 3 bytes which represented in hex are "55 D3 B0". If you don't get those in -- say double whatever the ISO 9141-2 spec's maximum time for those bytes -- and, most certainly, if they are "55 08 08" or anything other than "55 D3 B0" (when you are trying to connect to M44 with KWPD3B0 or performing any KWPD3B0 comm), then I'd abort the init sequence and wait at least 2.1 full seconds before starting another init sequence. If you did get those 3 bytes...
- Forget the ISO 9141-2's spec about determining the baud rate from the timing of those bytes or the spacing between them. Just assume the baud rate is 10400 baud, for simplicity sake.
- Wait for halfway between the ISO 9141-2's spec's min and max before sending the response byte. The timing before sending that byte after the 55 D3 B0 can be critical to establishing the link to the target ECU, so play around with it if necessary.
- Initiate a read for 1 byte.
- Wait for the ECU's 1 byte response for an appropriate time.
- Verify that byte if you like.
- Wait a significant length of time before sending your first request after the Slow Init sequence is finished. IIRC, this delay was ~300 ms.
- Now you can send your KWPD3B0 requests.
- You'll have to remember to send a KeepAlive within about 4.8 seconds of the last communication. Otherwise, the target ECU will timeout and disconnect. Make sure you don't use an unreasonably frequent KeepAlive timer like Brick-Diag Free v0.0.6.6 does -- less than 1 second. That's way too frequent. Anything in the 3-4 second range should be fine.

Rather than me list what you might send at this stage and the consequent KWPD3B0 exchange, let's take this approach...

Since you have both an ELM327 and a VAG/COM KKL cable, I'd suggest you get an OBDII Y splitter, hook your Bluetooth ELM327 to one leg, hook the VAG/COM KKL cable to the other leg, first connect to your target ECU with the ELM327 (similar to what you've seen volvo850diag do), then type ATPC, then type ATMA, then have the terminal emulator controlling the ELM327 to just wait and record activity. If you have an OBDLink SX, OBDLink LX, or OBDLink MX, I'd use that to do the ATMA recording, since it'll record all the byte of the Slow Init, except for the target byte.

After you get the ELM327-compatible device in ATMA mode, run Vol-FCR (either Full or Demo, but if you use the Vol-FCR FTDI Demo, you'll need a VAG/COM KKL FTDI cable) or run Brick-Diag Free v0.0.6.6. For either of these programs you'll see B9F0 / F9F0 exchange for every ECU, optional other B9xx / F9xx exchanges for other ECUs (eg, for the M44), then the A1 / E1 KeepAlive exchanges.

This ATMA log can be your primary instructor of what you would send from your Arduino app to perform KWPD3B0 comm with an M44, and the primary instructor of what are the normal responses.

DO NOT try to communicate on both legs of the OBDII Y cable at the same time.

6. As far as why manual issuance of commands didn't work with Realterm, whereas volvo850diag did work with Realterm, I'd guess the problem was either:

6a. inadvertently typing the wrong command, or

6b. taking too long to establish the ISO 9141-2 connection via either ATSI or the initial KWPD3B0 request and the Bluetooth ELM327 goes through some sort of Low Power shutdown.

There is one of the 3 ELM327 terminal emulator Android apps that I consistently had this problem with when I was first testing my OBDLink LX Bluetooth device with terminal emulators. It seems like the problem was with the Android terminal emulator by Qbek. I had already setup the OBDLink LX to have a long time before the Low Power shutdown kicked in. So I don't really know what the problem really was. I dealt with the problem by simply typing fewer commands and typing them quicker.

7. COMBI Vehicle Mileage in B903 indicates: 153840 miles * 1.60934 = 247581 km.

Not sure the reason for the COMBI (ECU 51) B903 value being higher than your digital odometer by ~980 km. I thought the S70/V70 cars normally had very little disparity between the two. But having a several hundred mile disparity between the two is common for the 850 cars.

8. By the way, thanks VERY, VERY MUCH for verifying that your ECU 51 B903 value is in miles / 10 (without me having to ask the question!). Several days ago, XantheFIN convinced me his 850's ECU 51 B903 is in miles / 10, yet his mechanical odometer and Trip Computer Odometer are in km (or 0.1 km). I believe at least one other owner from Canada has also witnessed this same behavior. So (sometime in the coming weeks) I'll go ahead and update the jonesrh.info/volvo850/ portal to reflect that ECU 51 B903 may be in miles always, worldwide, even for cars whose Instrument Panel (naturally) displays the speedometer and odometer(s) in metric units for cars targeted at metric countries.

9. Your volvo850diag submission showed an ECU 51 B90A value of "1F 00" = 001F -> 31 (engine hours of "lost" mileage per 1000 km of B905 SRI Mileage limit). That's one of the highest values I've seen. This tells me your SERVICE light comes on far sooner than you would expect it to, **if** the SERVICE light is coming on due to the SRI Mileage limit. A good way to test this is to use volvo850diag to (temporarily) change your ECU 51 B905 SRI Mileage limit from 30000 km to 1000 km (until the SERVICE light is illuminated again).

9a. Is your ABS supplying the Vehicle Speed Signal consistently now?
9b. Does the speedometer ever fail to function?
9c. Do you ever see ECU 51 B90A increment?

If your answers are Yes, No, No, and if you change ECU 51 B905 SRI Mileage limit from 30000 km to 1000 km, then I (presently) predict that your SERVICE light would come on 546 km +/- 16.1 km after the last Reset SRI. The "COMBI B903 & B904 are in miles/10, and B90A > 0" calculation is explained at http://jonesrh.info/volvo850/elm327_rea ... .html#b905 and goes like this:

(((B903 - B904) * 10) + (B905 * B90A * 9.1 miles per engine hour)) >= (B905 * 1000 * 0.621) +/- 10

In your car's case, assuming B90A holds steady at 31 (ie, 1F hex), and assuming you change B905 to 1 (ie, 1000 km), this equation becomes:

(((B903 - 15384) * 10) + (1 * 31 * 9.1 "lost" miles per engine hour in B90A per 1000 km)) >= (1 * 1000 * 0.621) +/- 10

or:

(((B903 - 15384) * 10) + 282.1 "lost" miles) >= 621 miles +/- 10 miles

So:

(B903 * 10) >= 153840 miles + 621 miles - 282.1 "lost" miles +/- 10 miles

(B903 * 10) >= 154178.9 miles +/- 10 miles

and I'd expect the SERVICE light coming on at:

ECU 51 B903 = 15416 (remote probability), 15417 (possible), 15418 (more probable), 15419 (remote probability)

Since the 282.1 "lost" miles ~= 282.1 * 1.60934 km ~= 454 km, if you had reset the Odometer the same time you had done the last Reset SRI, I'd expect the odometer to say somewhere between 1000 - 454 "lost" km +/- 16.1 km, ie between about 529.9 and 562.1 km.

If you've removed the SERVICE light from your dash or if your SERVICE light is burnt out, you can monitor when the SERVICE would normally have come on (if the SERVICE light were in the dash and working correctly) by looking at bit 3 of the data in the ECU 51 E506 response to the A506 request or bit 3 of slot 6 of the data in the ECU 51 E507 response to the A507 request.

10. Lucif3r, I have other questions about your COMBI DTCs and freeze frames that kwpd3b0_interpreter saw. I'll PM you about those. I've never seen a COMBI with as many DTCs as yours. Apparently, you created some DTCs very recently while testing. I'm curious to know which are real and which are "manufactured" as test cases.

11. To anyone: Are you willing to perform some details research to figure out the following on your 97 V70 and its Motronic 4.4?

11a. Meaning of each bit in the ECU 51 A506 status byte? There are differences from the 850 cars and don't yet understand fully the S70/V70 cars.

11b. Meaning of ECU 51 B90C's 3 values? I'm not convinced they are temperatures since Brick-Diag Free v0.0.6.6 threads don't mention any temperatures.

11c. Meaning of ECU 51 B901, B90B, B90D, and B90E, and all their valid values?

11d. Do you know how to clear ECU 51 B90A?

11e. If I send you the volvo850diag v0.8beta snippets relating to M44 scanning, could you get scans both with ignition pos II, as well as engine idling, as well as while driving at somewhere between 30-70 mph (at a steady cruise control controlled speed on fairly flat road)?

esl97850T5

[Lucif3r]

Okay, thats a lot to read...
First of all, ALL DTC's from my COMBI is from when I ran it out of the car, on the bench. I basically just powered it up, simulated some signals and watched how the gauges etc reacted.
That, of course, means the gauges have been both out of their range, and getting the wrong signals in order to find the limits. The fuel gauge related ones is, as the code describes, from applying a full->empty, or empty->full signal faster than whats normally possible in the car. It doesn't appreciate being voltage-controlled rather than resistance-controlled
And while on the bench, I also "drove" uh... 20km or so, as the odometer was ticking when testing the speedo.
Anything related to "short to ground" is... ehm... lets not talk about that

As for the lost mileage. The ABS is working fine, speedo works perfectly, never failed or behaved abnormally... HOWEVER, a previous owner has cut the trace leading to the ABS-warning light, indicating there HAVE been a problem with the ABS earlier(and said owner cheated his way through inspection rather than fixing the issue).

The service light hasn't been reset in god-knows-how-long(min. the 3 years and ~15000km Ive had it for), vol-fcr has been unable to reset it, always timing out or crying about ECU not responding. Never really tried to dig into it as it never bothered me.
Ironically though, resetting it through volvo850diag worked first try :roll:

As for the issue with manual commands.. It was pure EBTKB(error behind the keyboard) I had missed the part where it said to use for example "B903" instead of "B90300" :roll:

Im fairly sure I got enough info to hook it up to the arduino by now, just need to mash up a sketch and confirm it...
Except one thing... How in the world do you convert the error codes to a readable format...? How does "05" become "CI-113"(as reported by AE01) etc? Well, the CI part is easy to figure out of course... but the rest? I cant even work out how to convert it to a generic OBD code. :|

I have not looked into any of the Axxx codes, or anything other than B903 for that matter, as my initial intention was to just be able to sync the mileage from the combi to the arduino(which is going to replace the odometer display).
Being able to read DTC's directly in the car without any extra equipment(phone or tablet or laptop or whatever) would be a very nice feature though.

As for figuring out what various values represent... Yeah.. Thats way above my pay grade I'm afraid lol.. I struggle with 1+1 :-DD , and am more of a hardware guy than software.

[esl97850T5]

Lucif3r,

1. Thanks for letting me know about the bench testing. That explains a lot!

Thanks for letting me know that the ABS is presently fine, but the ABS trace had been cut. I think undoubtedly the ABS had failed for the previous owner, and that explains the relatively high ECU 51 B90A > 0 value.

2. So I still stand by my previous prediction of when the SERVICE light comes on due to the mileage interval limit, assuming you change the SRI Mileage limit to a low value like 1000 km by reprogramming ECU 51 B905 from 1E (30000 km) to 01 (1000 km).

3. For your future reference -- if you had performed the SERVICE light resetting via volvo850diag's ATZ Reset SRI function instead of via volvo850diag's ECU 51 * function (at the end of the ECU 51 line), the ATZ Reset SRI function would have recorded when the previous reset was performed:

- exactly how many days ago (down to the 1/4 day) -- it's the interpreted value of B907 before resetting to 0;
- exactly how many engine hours ago -- it's the value of B909 before resetting to 0 (+/- 1); and
- exactly how many miles ago -- in your case, that's the value of (B903 - B904) * 10 (since your ECU 51 B903 measures in miles / 10) (+/- 10 miles).

4. You asked: "How does "05" become "CI-113"(as reported by AE01) etc?"

This is an error that I've seen many times on my car and is highly correlated with the Low Fuel light staying on persistently when the fuel level gets sufficiently low (when typically 15 - 17+ gallons are needed to fill the car up to the first click of the gas station fuel pump). So I personally associate ECU 51 DTC 05 with Low Fuel.

Furthermore, I've seen a bunch of cars in kwpd3b0_interpreter.html that have the ECU 51 DTC 05 and also have very Low Fuel conditions.

As far as the ECU 51 rax hex DTC 05 vs. CI-113 association:

- Brick-Diag Free v0.0.6.6 reported 1-1-3 Fuel level sensor (at least in English it does), when I had the one single COMBI DTC: 05.

As far as the explanation of CI-113:

- Notice the wording for "DTC CI-113" on the http://www.volvotips.com/index.php/850- ... ir-manual/ page: . That page is also available in .pdf form inside the http://www.matthewsvolvosite.com/downlo ... vo_850.zip file.

I merged all those into the volvo850diag explanation and emphasized my "Low Fuel" observation (since that's what I think it most often means):

ECU 51 DTC #1: 05 -> CI-113 -- Low Fuel / Fuel Level signal interrupted

when there is only that one single COMBI DTC.

5. If you had asked: "How in the world do I convert the error codes to a readable format...?", then I would say:

You've already seen how to do that. Look at your ECU 51 EE01 response to the AE01 request. Look at the DTC #s in that message. Look at the explanations shown by volvo850diag for each of those DTCs. Then create yourself a table of every COMBI DTC which you already know about. The table should include:

- ECU #,
- 2-digit DTC #,
- short explanation (eg, like "CI-113", everything after the " -> " and before the " -- "),
- long explanation (eg, like "CI-113 -- Low Fuel / Fuel Level signal interrupted").

Now construct fake COMBI EE01 responses for any other 2-digit #s that you want to know about and see how volvo850diag responds. For example, change your "8C 13 51 EE 01 05 0F 0B 06 02 04 0C 0A 11 31 " request & response to:

-- Lucif3r's probe of more volvo850diag COMBI DTCs.
8C 13 51 EE 01 00 01 03 07 08 09 0D 0E 10 FF

and feed that to volvo850diag. Then add those new DTCs to your table. You can include any 2 hex digits for the checksum in the EE01 responses, since volvo850diag seldom verifies the checksum at present. Eventually you would need to repeat the process for other ECUs. If you find that there's errors in the volvo850diag 2-digit raw DTC to 3-digit Volvo DTC associations or explanations, you can correct them, since they are not guaranteed to be correct.

So once you get your Arduino prototype going and it receives certain DTC inside an EE01 response from a certain ECU, the Arduino looks up that ECU # and 2-digit DTC # in the table, then outputs either the short explanation or long explanation (your choice). Voila!

I suggest not spending much time on this. Do it for the few DTCs you already know about from volvo850diag. Then do it for a few more potential COMBI DTCs (eg, in the suggested example EE01 response). Then go to this next item...

6. Get your prototype operational so the Arduino can connect to the COMBI (ECU 51) using the special ISO 9141-2 init using either an ELM327 or a VAG/COM KKL. Then demonstrate:

- Reliable connections (where connections are establish successfully >= 95% of the time, and where the connection can be maintained for as long as you need it with very, very infrequent unplanned disconnects, if any).
- 2-digit to 3-digit associations for the COMBI DTCs that you already know about.
- Those 2 things running in the car.

Once you get that going, you can apply the item 5 approach of determining the 2-digit raw to 3-digit Volvo DTC associations for the remainder of the COMBI DTCs. Then you can do the same for your next most important ECU and get that ECU's connections operating reliably and displaying DTCs reliably. I'd suggest taking it one ECU at a time.

7. You said: "Being able to read DTC's directly in the car without any extra equipment(phone or tablet or laptop or whatever) would be a very nice feature though."

More power to you. Go for it. You have been elected to create the Arduino-based Volvo 850/S70/V70 mileage / DTC display tool.

esl97850T5

[Lucif3r]

ah.. damn.. I was hoping for something similar to reading the miles... like "take the hex, convert it to magic, multiply by 5321 and divide by pi while standing on one foot, and there you have your DTC!". :lol:
Manually making a list by trial and error is a lot of hassle, not to mention it would be quite slow to read through that document with the arduino.

Also, the OBD-part of the arduino will not be active during driving, since that would cause issues with my other functions. So I wont be able(or chose not to) to read any live data. It takes a good 10-20ms per sent request to the ELM, and while 10-20ms doesnt sound like much, assume a polling rate of ~2sec, those 10-20ms quickly adds up and becomes a major headache.
As for the DTC's.. Reading a single ~20char line from an SD card(storing the list directly in the arduino is a no-no due to limited EEPROM writes and limited flashmem) takes between 50 and 100ms. So assuming a list of 50 obd codes, each 6 char long(hex+space+3-code), that could be up to a 3 sec delay, during which time the arduino cant do anything else. And then the data would need to be processed and printed to the display...
That is of course not an issue when the car is just on ignition, but would cause tremendous issues if the car was running.

Had (my)the arduino done nothing but OBD-interfacing things would be easier, but my poor thing is working triple-time lol. I even had to upgrade to a mega2560 simply because the 328p didnt have enough SRAM to process everything.

Of course, another option would be to use a 2nd arduino for the OBD-interfacing and processing, then just send the processed data to the main arduino through i2c, and simply print it on the display. hmm...
Well, we'll see what happens. I think for now though that Im going to put the OBD-thingy to the side, and focus on actually getting my initial arduino-project finished and mounted in the car.. Its been a few months since I started^^