SpeedCommand always returning speed of 52 even when not moving

[Abushawish]

Using ELM327. I think it may have something to do with the hex code that's being returned/parsed incorrectly. Thoughts?

[pires]

Probably some protocol issue.

[frandrago]

Hi, I do not know how to write in Inglés, but I am going to try.

I have the same problem, you've found the solution?

Thank you!!

[frandrago]

I have this problem when I use the Bluetooth ELM327 V2.1 ODBII. With earlier versions do not have this problem.

[Pho3niX90]

@Abushawish @frandrago Could you please supply your rawData value?

Easiest to do the above is edit the SpeedCommand.java public String getCalculatedResult() { //return useImperialUnits ? String.valueOf(getImperialUnit()) : String.valueOf(getMetricSpeed()); return rawData }

[phamels]

@pires @Pho3niX90

Had the same issue using android-obd-reader (which uses obd-java-api) The speed was displayed as a constant 65km/h while standing still and engine RPM of 4163. Also the runtime was a constant 04:37:51.

A similar application (not to use any names) uses the protocol ISO15765-4CAN11/500 on this car & adapter combination but returns the data just fine.

Included the obd-java-api into the android-obd-reader project and changed the getCalculatedResult() to return the rawData though that didn't change anything to the data being displayed on the android-obd-reader app.

Anything I can do to test / help / give more data / results?

[Pho3niX90]

@phamels the library does not support the can protocol properly. So that would be your reason, however hopefully in the next month it will ;)

[pires]

@pho3nix90 that would be truly amazing.

[phamels]

@Pho3niX90 aha ok, expected it would be something like that :-) that would be awesome :-) This is my first dive into the OBD protocols but if there's anything I could do to provide feedback or help in any way, let me know!

[Pho3niX90]

Thanks for the offer, it is taking longer than I initially anticipated, since all my vehicles are K-LINE, and cannot find a simulator that communicates solely in CAN. Thus making testing difficult. I will post a pull request for the speed command first to make sure it works for everyone.

[Pho3niX90]

@phamels if you could do me a favor though, if you could install a obd2 terminal app on your phone, and send a command to the OBD2 adapter, could you please post the response from the vehicle up?+

[phamels]

@Pho3niX90 was actually already preparing my laptop as you wrote this to do this :-) heading down to the garage as we speak to to that for you :-)

[phamels]

@Pho3niX90 as promised:

TeraTerm:

`

ATI ELM327 v2.1 ATZ ELM327 v2.1 ATSP6 OK ATMA STOPPED ATCS T:00 R:00 ATRV 11.2V STI ? 0100 41 00 BE 3E A8 13 011c 41 1C 06`

Android OBD Terminal:

`

ATZ ATZ

ELM327 v2.1

ATH1 ATH1 OK

ATDP ATDP ISO 15765-4 (CAN 11/500)

ATMA ATMA STOPPED

010D 010D 7E8 03 41 0D 00

010C 010C 7E8 04 41 0C 00 00

010C 010C 7E8 04 41 0C 0A A0

010C 010C 7E8 04 41 0C 0A 88

010C 010C 7E8 04 41 0C 0A B4 `

ATMA doesn't seem to return much data, neither on the android terminal or on the TeraTerm using windows

010C 010C 7E8 04 41 0C 00 00 --> Engine not running

010C 010C 7E8 04 41 0C 0A A0 --> Engine running

010C 010C 7E8 04 41 0C 0A 88 --> Engine running

010C 010C 7E8 04 41 0C 0A B4 --> Engine running

[Pho3niX90]

Was your RPM around 685?

[phamels]

Pretty sure it should be around there as I was just idling. Could issue some more commands in various states if you want that

[Pho3niX90]

OKay. Could you please try that again for me.

First turn off the headers ATH0

Then do RPM 010C

[phamels]

I'll go down in a minute to do that and take note of the RPM on the dash while doing it :-)

[Pho3niX90]

Thank you! Also, which vehicle are you testing this in, and which country?

[phamels]

My pleasure! Currently doing it on a 2010 Skoda Yeti (Imported it from Belgium; now doing it/living in Sofia, Bulgaria) (also have a BMW 640d available as well for dumping if required)

[Pho3niX90]

Awesome thanks. The API should work flawlessly with the 640d, unless it's a 2008+ model, then can might become an issue. However, as far as I know the ECU stayed the same for the E63 up until 2010

[phamels]

This one is a F13 :-) could do some tests on that as well :-) Heading down now to do a dump

[Pho3niX90]

Thanks, yeah F13 might be a problem. Would be great if you can do tests on it. And we can fix both in one go. The N57D30 is a brilliant engine.

[phamels]

In the car right now :-)

First engine off; then on at idle and at the last few tried to keep it around 1000rpm give or take a little:

010C 010C 41 0C 00 00

010c 010c 41 0C 0A B8

010c 010c 41 0C 0A 78

010c 010c 41 0C 0F BC

010c 010c 41 0C 10 54

010c 010c 41 0C 10 A4

010c 010c 41 0C 10 8C

I'll check for the F13 as well asap (not in the garage right now :-))

[Pho3niX90]

Hmm strange, from those results the library should work perfectly. Have you tried the latest build of the app?

[phamels]

Seems to be correct; as far as I've been studying the output: PID 0C which returns RPM in this case 10 8C converted to decimal 4236 divided by four returns 1059 RPM; correct?

[phamels]

Yeah I have, compiled the source yesterday. What I did was download the android-obd-reader source; tried it with the default lib included; then downloaded the obd-java-api and included it manually into the project as suggested in the android-obd-reader readme

[Pho3niX90]

The equation is as follows: So output is: 010c 41 0C 10 8C

410C gets removed, since it's just an echo of the command sent, you are left with 2 bytes, 10 and 8C, converted 10 = 16 8C = 140

Full equation is = (A * 256 + B) / 4 = 1059.

[Pho3niX90]

OKay could you set the protocol in the app to KWP, as a test

[Pho3niX90]

I think what is happening is the following. The terminals are infact not setting to automatic but hardcoding the protocol to some kline protocol, thus the vehicle is responding in the same manner. Where the app is by default on AUTO and the car is expecting CAN messages. This however is just a theory

[phamels]

Aha, thanks for the clarification on that! Just started my exploration into all of this since yesterday :-)

I'll do that, head down and come back with the results! I tried yesterday using AUTO and ISO_15765_4_CAN with same results. I'll try the ISO_14230_4_KWP now and perhaps a few others as well as a matter of testing

[Pho3niX90]

Yes that would be great. Any of the protocols that do not contain CAN. I will still however try and get the CAN working, since it is a way faster protocol.

[phamels]

Damn, KWP displays all data correctly! How could I have missed trying that! I will try to do some testing on the F13 though asap

[phamels]

Oh, can try with the F13 now if you like? What could I dump for you?

[phamels]

Weird, tried again now and getting businit error using kwp and the errorous values with can

[Pho3niX90]

Hmm strange. I think the app is sending the commands too fast. Plug out the adapter and back in, en check if you can modify the sleep time in the settings to something a little but higher, you could try one of the other non CAN protocols as well. Yes if you can send the same test scenarios for the F13 that would be great.

[Pho3niX90]

When you received the businit error, was it via the android compiled app or your own app?

[phamels]

The Businit error was with the android compiled app which was working earlier. Tried different protocols again, ATZ command then trying it, restarting the phone even just to be sure :-) but now kept receiving protocol error where it was working before, strange indeed :-) Also tried the F13; actually just gives the exact same values and uses the exact same protocol as the Skoda Yeti :-)

[Pho3niX90]

That is strange. And if you go back to the terminal after the app give you a buss error, does it still bring back results?

[phamels]

it is strange indeed, yeah it actually does when I try to use the terminal after the app. Going to look more into it this evening and see what's going on there

[Pho3niX90]

Okay great. Will have a look on my side as well what would cause the error in the interim, until I can get a working version of the CAN protocol.

[phamels]

Can't get it to work on KWP at all anymore. Not in the app, not on terminal (also get the bus errors there using atsp4 and trying to fetch data)

[phamels]

Didn't test it before though with atsp4 on terminal, only atsp6. Kind of weird however i got the app to display correct data before with kwp including VIN number and all

[Pho3niX90]

I am going to implement a tester in my app to try all protocols from 1 to 7 to automatically find the correct protocol, instead of leaving it to the hardware. I eill uploaf the apk here for you to test if that is okay? If all is well I will do a PR.

[phamels]

sounds good! pretty much went through all the protocols in the terminal; the one that worked for me was number 6 (using the AT command to select the protocol 6 (ATSP6) or the auto one (ATSP0)) the rest threw up bus errors.

[Pho3niX90]

and on protocol 6, does it return in the same format you posted results earlier?

[phamels]

Yeah, that's what it did all along; it only gave me that output on the CAN protocol. I'm still puzzled why it even worked on the KWP in the app :-)

[Pho3niX90]

Hmm weird. And when you set the app to protocol 6, and then try to read data what does it do?

[Pho3niX90]

@phamels Could you try this one on the vehicle? It uses the same library that has been modified to pass Parcels. However, it's a highly modified version of the original android project, and have also included to display the raw responses from the vehicle in the logcat, that will help diagnose why you are getting the errors.

Hazmat-Reader-debug-0.8.0.zip

[phamels]

When I set it to protocol 6 (or ISO_15765_4_CAN) in the app; I get the wrong values; as in a fixed speed of 65km/h at 4163RPM with a fixed trip time of 04:37:51 and a vehicle VIN with funky chars :-)

I'll go ahead and tre APK you attached!

[Pho3niX90]

Okay thank you, that would explain what is happening if you can extract the logcat.

[phamels]

Logs have been mailed!