Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

retry attempts on "UNABLE TO CONNECT" #29

Closed

Conversation

samifruit514
Copy link
Contributor

@samifruit514 samifruit514 commented Mar 3, 2020

Description

With my obd-ii adapter (this one https://www.amazon.ca/Revesun-ELM327-Engine-MODELS-DIAGNOSTIC/dp/B00R285RU6) I get the error "UNABLE TO CONNECT" if I re-try after in succeeding one. If I wait 5 seconds, it works.

This PR does an auto-retry.

Checklist

  • [ x] Running go test locally is successful
  • VERSION has been changed
  • Changes has been documented in CHANGELOG.md

@rzetterberg
Copy link
Owner

Thanks for the PR! 👍

I don't think I understand the problem you are trying to solve. Can you take me through what you are doing, step by step, and then explain what the problem is?

@samifruit514
Copy link
Contributor Author

Sure!

1- I plug my usb OBD-II adapter in my laptop
2- I turn the car on (just ignition, no engine start)
3- I plug the OBD-II adapter in the car's port
4- I run any command (let's say example_2, but with NewDevice instead of NewTestDevice)

  • Expecting 0 rpm, Actual: 0 rpm <<<< PASS
    6- I run the same command right away, without waiting (last command in shell)
  • Expecting 0 rpm, Actual: error: UNABLE TO CONNECT.

Now this "change" would retry the command if we get a "UNABLE TO CONNECT" error. The problem is that I don't know if this problem of retries is with my car, or with my usb adapter. But in any case, I think retrying could be a good thing (defensive coding?).

Also, please note that I've changed the readtimeout. With a timeout of 5 seconds, I get an EOF error. I think my car is just too slow to answer - but I also think a lot of cars could be slow so.

Thanks a lot for your feedback!

@rzetterberg
Copy link
Owner

rzetterberg commented Mar 8, 2020

Thanks for the explanation! Now I get it.

I've been looking at the datasheet for the ELM327 IC and here's the explanation for the error you are receiving:

UNABLE TO CONNECT
If you see this message, it means that the ELM327 has tried all of the available protocols, and could not detect a compatible one. This could be because your vehicle uses an unsupported protocol, or could be as simple as forgetting to turn the ignition key on. If you are sure that your vehicle uses an OBD II protocol, then check all of your connections, and the ignition, then try the command again.

I also found a reference to this problem here:

Sometimes, when this happens, it does not directly imply that the vehicle is not compatible. Usually the software is configured to test the connection protocols automatically and always in the same order. This can cause it to remain in a closed loop trying to connect to an inappropriate protocol.

When you run NewDevice there a couple of things that happen "under the hood":

  1. RealDevice is constructed via NewRealDevice
    1. The serial port is opened
    2. The serial port is flushed
    3. ATZ is written to the serial port (ATZ is an internal ELM327-command that resets the device configuration and restarts the device)
    4. The response is read from the serial port (this response contains the device identification (name and version), such as "ELM327 v2.2")
    5. The device identify is checked so that it starts with "ELM327"
    6. The serial port is flushed
  2. Device is constructed (with the constructed RealDevice)
  3. The function SetAutomaticProtocol is executed
    1. ATSP0 is written to the serial port (ATSP0 is an internal ELM327-command that configures the device to automatically select the protocol to use)

So there are actually 2 commands sent to the device before you, as the user of the library, get back the device instance.

What I'm wondering if your problem could be related to using automatic protocol selection, like the one quoted above or if it's related to timeouts. By default the ELM327-device uses something called "Adaptive Timing" which checks how long it takes for the vehicle to respond and then sets the timeout thereafter. "Adaptive Timing" can be used with 2 different settings or be disabled.

I think we should start by looking closer at the conditions of your use case and then try to figure out what the root cause of your problem is.

I have created a separate issue #30 where I've put in the information you've written so we can continue the investigation. Can you fill in the missing information and correct the assumptions I've made that are wrong?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants