-
Notifications
You must be signed in to change notification settings - Fork 388
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
Synchronisation issue with ELM327 #226
Comments
I ran into this today too. I have a fix where I made the end marker an argument to the reading function, pulled it through to I will try and make a PR of this soon; I have to pull it off the computer that can go into the car. |
Right now __read() will stop reading at "OK" even if a ">" is still coming. This can cause the ">" to be seen as the response to the next command, which confuses the initialization sequence, since the initialization sequence expects a very specific set of responses to its commands. This changes __read() so that by default it only treats ">" as the response terminator. When we issue the "ATLP" command to enter low-power mode, we will use "OK" as the response terminator instead, since that's the only time we don't expect to see a prompt. This should fix brendan-w#226 and should alo fix brendan-w#227.
Right now __read() will stop reading at "OK" even if a ">" is still coming. This can cause the ">" to be seen as the response to the next command, which confuses the initialization sequence, since the initialization sequence expects a very specific set of responses to its commands. This changes __read() so that by default it only treats ">" as the response terminator. When we issue the "ATLP" command to enter low-power mode, we will use "OK" as the response terminator instead, since that's the only time we don't expect to see a prompt. This should fix brendan-w#226 and should also fix brendan-w#227.
Right now __read() will stop reading at "OK" even if a ">" is still coming. This can cause the ">" to be seen as the response to the next command, which confuses the initialization sequence, since the initialization sequence expects a very specific set of responses to its commands. This changes __read() so that by default it only treats ">" as the response terminator. When we issue the "ATLP" command to enter low-power mode, we will use "OK" as the response terminator instead, since that's the only time we don't expect to see a prompt. This should fix #226 and should also fix #227.
I was having problems getting the python-obd library to reliably sync with a cheap ELM327 clone. I believe the problem is due to some code added to elm327.py to support low power mode.
Specifically the line line elm327.py:548
During start up the following exchange happens with the ELM327:
Note how after ATE0 is sent to the ELM327 we receive back the echoed command and then an OK. This OK matches the ELM_LP_ACTIVE clause and the command returns before reading the next line containing the chevron prompt. When the ATH1 command is sent to the ELM327 the chevron prompt is then read and the code assumes this command has failed.
The fix is to always attempt to read up to the chevron prompt and to not bail out early if we read OK in the response stream.
If I change line 548 to the following the adapter connects reliably everytime:
I am not sure how my change will impact the low power mode as I am not using this but I am happy to test out an alternate fix if required.
The text was updated successfully, but these errors were encountered: