The fact that the characters returned correctly probably indicates that the data rate is set correctly and the device sees the characters you need. It sounds, however, that the device still does not see the correctly completed query string (which ends with a carriage return).
I mention this because you noted the addition of "/ r", which is not the same as "\ r" (CR character). For example, in Java:
OutputStream out; String correct = "ATRV\r"; //This line will correctly write 5 bytes (in hex): 41 54 52 56 0D out.write(correct.getBytes()); String incorrect = "ATRV/r"; //This line will incorrectly write 6 bytes (in hex): 41 54 52 56 2F 72 out.write(incorrect.getBytes());
The 0x0D symbol is what the ELM327 is looking to complete the AT command and parse it.
Edit:
If you manually enter the characters "atrv \ r" using your keyboard in the sample application, the same problem exists. The text is interpreted as 6 unique letters (ie "A", "T", "R", "V", "\" and "r" or hex 41 54 52 56 5C 72
), and "\ r" is not interpreted as a single CR character.
You probably wonβt be able to do this from your sample code unless you add special code to analyze combinations with "\" and replace them with special character values. A better solution would be to change the code sample so that you always add the character "\ r" (remember ... different from just adding "\" followed by "r") to everything you type when you press the submit button, so all you need to do is enter "ATRV" in the text box. Something like this in your OnEditorActionListener
code (again, pay attention to the direction of the slash or just add two characters):
public boolean onEditorAction(TextView view, int actionId, KeyEvent event) {
You can also change your example by hard-coding a string command, as it was in the above example. Java interprets the string literal value "ATRV \ r" correctly by putting this CR character at the end (making it a 5-character string).
source share