Good afternoon, ABG. I did what you suggested, but it's still returning the value 7F 10 12 from the request. What could it be?
learning1.aia (592.1 KB)
You have two different ideas of the BlueTooth Delimiter:
I would avoid using 62 ('>') as the delimiter brcause it appears at the front of messages, not the end.
You could remove unwanted excess like \n and > from your input messages using a text replace block, replacing them with the empty string.
You still have two timers, and two different schemes (CONT_PID vs L_MESSAGEM.Text) for responding to input.. That can be simplified. Use just one Clock Timer, have it capable of recognizing all contexts and processing all inputs appropriately, and leave it enabled.
You load the incoming message to CARRO_ENT, then ignore it and test a Label.Text?
Do not rely on the contents of Label.Text in real time. There may be delays in updating them. Instead, pass parameters to your procedures, or use a small number of global variables for traceability.
Hi, I've been out for a day, then sorry for the late reply:
Maybe you can find some hints here:
where you can find this graph:
It seems that the ECU is never understanding your request (PID not recognized).
So, once you have solved the issues highligted by @ABG, please give it a look.
Best wishes.
Hello, ABG and Uskiara. I managed to fix that code, and everything is fine now. However, I went back to that old one I was working on and fixed the hexadecimal error that was occurring, but now there's another issue with text size, and I can't seem to fix it. I would like your help, please.
I think the error is occurring in these code blocks:
My French is terrible.
Can you post English blocks?
In the meantime, the error message says the text you were working on was too short.
The segment block is unforgiving.
You have to test length before using it.
If you are getting short text, you need to track back why it is short.
Since you are receiving fragments of text, it is certain you will eventually get something shorter than you expect.
What is in global bt when you apply the Do It?
Global bt refers to the values received from the OBD. Oh, would I need to clear the global bt after each request?
This is how I'm requesting to send it to To receberBT Do
You know that \r and 13 are the same value, right?
Why do you send both?
And why did you decide to start doing receive Texts outside of the one Clock Timer?
Wasn't that working for you?
And where is the answer to the question of what was in global bt?
Out of embarrassment?
Best to face the results of your misdeeds.
Sorry, I sent the wrong block. That one was about the tests. Regarding Global BT, the error in the RPM request.
Dear @diornexx,
I see that you try to receive the answer form the ELM about 1000 times, but you break the loop when the character ">" is received. Ok, but what happens if, within 1000 trials you don't receive the end frame character ?
Apart of that, sure, at every reception completed (without the ">") you shall clear the receiving buffer, otherwise it will be filled by garbage 'till you receive the good frame. So, every buffer not ended with a ">" shall be discarded and only when you receive the buffer ended with the ">", you can analyze it, searching for the wanted data. Please be aware that the length of teh CAN messages is fixed: for example the speed data is always on one (1) byte, ranging from o to 255 (I have some doubts about a Ferrari, but I will never have a Ferrari, so it's not my problem 
). The header is always fixed also, so the data is starting always at the same position within the received frame.
When you unpack the frame, you can therefore start considering a fixed index, and this will avoid the error of starting from a position that is not present in the frame.
Having said that, anyway, what have suggested @ABG is the best way to avoid that an empty string, or a too short one, or shorter than expected, is erroneously treated.
The picture below shows how I unpack the RPM value from my car.
First of all, I check whether in the received buffer (carinp) there is the phrase "NO DATA" , because this sentence, put by the ELM, states that the answer to 010C request isn't arrived. After that, only if the received buffer length exceeds the expected one (i.e. >=8 chars) I continue in treating the buffer.
The two bytes composing the RPM data are then extracted and converted from Hex to Dec. The high byte is then multiplied by 256 and summed with the low byte. The result of the sum is then divided by 4 and rounded to avoid decimal parts.
(Since I have 5 possible screen layouts I pre-fill the labels of each screen with the result, obviously you don't need to do the same
)Hoping this can help you a bit, and sorry for typos, my eyes are getting better but they are still far from 100% ...
Ciao !
2 Likes
Good evening, ABG and Uskiara. Do you know if Bluetooth communication has changed with the updates on cell phones? I tested the app on two phones, a Motorola G6 and a newer Motorola. On the Motorola G6, the received codes were accurate; however, on the newer phone, it shows 18km even when I'm stationary. Could this be related to the phone's version or the Android version?
In the picture, I'm stopped testing.
I would guess your code is sensitive to the phone's timing.
Different phones run at different speeds.
1 Like
Thank you for the response, ABG, but I'm sorry, I didn't quite understand. I tried to change the receiving speed, but it didn't work. What can I try to change in the code?
bt_erro.aia (1.4 MB)
Ddear @diornexx,
when you say that, though you are stationary, the app shows 18 km are you talking about speed (km/h) or about a distance ? If you say 18km, this is not a speed, but its integral, i.e. a distance. So @ABG says that if you do computations relying to the phone clock to perform the integral of the speed, to obtain a distance, if the clock of the two phones are different, also the result of the integral computation will be different.
But, honestly, apart of this theoretical rant, I see in your snapshot that the figure 18 is close to its unit of measure km/h, therefore it is a speed, I believe.
In this case the phone's clock frequency is not involved, since the speed value only depends from the CAN message received by the Engine Control Unit (command 010D).
Please let me ask some trivial questions:
- Two phones but, same car ? If not, same ELM ?
- same app on both phones ?
- when you ask the ELM for the speed data, are you already stationary at least from a while ?
- are you doing (for example) an average between CAN speed and GPS speed ?
- is the wrong speed never reaching zero (0) ?
To be sure that the app is not introducing the error, you could use the Torque Light app (free) or similar, to verify what data is effectively sent by the Engine Control Unit via ELM.
By using that app on both phones, you can verify which is the root cause: i.e. whether the error is generated by the car, the phone or, if no error arise with Torque, by the app.
Ciao !
Good evening, Uskiara. The km I sent is related to the speed. The error is occurring in all requests. I tested it in the same car, with the same ELM device, using the same app, and the phones were tested separately. In all of my tests, the car was stationary with 0 km. On the Motorola G6, it shows the value as 0 km, while on the Motorola Edge, it shows 13 km (it varies from 13 to 18 each time I start it), even though the car is stationary.
I believe this problem may be related to some functionality of the phone or how I'm handling the received value. Please correct me if I'm wrong.
The videos were recorded on the Motorola Edge. Video 2 is a test using an app from the Play Store.
Hello @diornexx,
by having a look to the two videos, I see that the playstore's app shows 0 (zero) Km/h speed, while your app is showing 13. But also the refrigerator water is -14° on your app !!!
So there are other weird "things" happening with your app while with the playstore's app, not.
Please check your conversion algorithms: or, are you sure that you are decoding the correct data values ? You remember that I said that the data field within the CAN answer is always at a fixed position within the frame, so there is no need to search the initial byte of the data, and you can start to compose the data by starting always at a fixed byte (though it can be different depending on the data requested). Also the length can vary from 1 to many bytes, therefore the conversion shall take care of the "weight" of each byte. Also the conversion formulas are depending on each data.
For example the refrigerator water temperature conversion is
(you have to subtract 40 to the received value):
If you correctly apply this equation, this means that your water temperature was -14+40 = 26 degrees Celsius, which is fairly good if the engine was "cold", But this also means that the conversion from hexadecimal to decimal is somewhat wrong. Or you are converting a wrong data.
This second hypotesis returns to what @ABG has originally said, not related to the computations, but to the BT receving funcion. If you don't allow enough time to your receiving function to receive the complete frame (this can be caused by a "too fast" clock frequency on the phone), what you are converting can be a mix of different frames.
For example this is my receiving function, activated by means of a 10 millisecond clock, that retries up to 1000 times to receive any single frame.
Please pay attention to these two lines of code:
By using these two lines of code, I'm showing, for debug purposes, how many time it is required to complete a frame, and i see on the screen of my pad (I don't use a phone, whose screen is too little)that it takes up to 30 attempts (i.e. 300 ms) before a frame is being completed.
In few words: it seems that the phone's clock speed isn't affecting your computation, but your receiving function. Just to debug your code, try to wait "forever" the ">" ending character (do not use any timeout) and see what happens.
Cheers..
PS please be aware that the Engine Control Unit sends out the diagnostic messages with a "low frequency": the diagnostic services are accomplished only when the ECU has free time, i.e. only when it is not performing engine control algorithms. So a lag between your request and the answer can be introduced and can last some hundreths of milliseconds. Moreover the CAN diagnostic (B-CAN) speed is 250 kbit per second while the high speed C-CAN is 500 kbit per second, but the C-Can is not reachable by a diagnostic tool, it is just internal between the various ECU's of the vehicle.
But this is another story.....
2 Likes
Helloo Uskiara, thank you for your response. I conducted some tests, changed the data processing approach, and tried to clean up the bytes after receiving them, but I'm still facing the same issue. One of the tests I conducted revealed that when I request the PID, it's being retained for other requests (as shown in the video). Is this problem still related to data processing?
I'm using almost the same code I sent; only the interface is different.
Dear Johnny,
it is not so easy to find the solution, just by looking at your video, but what it seems to me is that there is some timing issue, because, by slowing down the reprodution speed, it seems that the value of the previously data processed is retained (or at least it is shown) also when the speed, PID 010D, is requested instead. for example I've seen that the value 0x7D (125 dec) has been displayed for the speed but it was the same value shown for the preceeding PID.
One hint could be to try to send (after the initialization sequence) only the speed PID and to see what happens (i.e. do not send any other PID) and to remove any timeout, so to allow the engine ECU to answer.
In my code when I ask for a PID, I always wait until the answer arrives before asking for a new PID, and this avoids any type of "data overwriting" (honestly I have a 10 seconds timeout but, you know, 10 seconds is an eternity in electronics !!!).
For debug purposes, you could also try to send a new request only after a button is pressed, so to slow down the repetition rate.
Sometimes a couple of milleseconds makes the difference... 
Best wishes.
Ugo.
PS be also aware the a "good" answer begins with a 0x41 (i.e. the request 01 or'ed with 0x40). If the answer does not contain 0x41, it shall be discarded.
1 Like