Hello, Uskiara. So, I followed your advice, but I still couldn't fix it 
. The first test of using the speed PID worked, it displayed 0 km. In the second test, I waited 30 seconds to send another request, but the problem persisted. I noticed something strange: for example, when I request pressure and then request speed, on the first click on the speed button, it seems to be using the previous request (the one for pressure), but on the second click, it displays the speed value correctly. I tried making various changes to the code, but I still haven't been able to find the solution.
I don't understand why it's reusing the previous request, even though, in my view, the code is clearing the global variable that receives the bytes.
If it's not too much trouble, could you take a look at my code? Please
OBDapp(bug).aia (1.4 MB)
Dear @diornexx,
absolutely it's not a problem to give a look to your code, but please be patient 'cause I'm involved in other activities that I cannot postpone. Anyway, please note that not all PID's are available on any car. It depends on each vehicle diagnostic services implemented. That is: different car makers (i.e. VW, or Toyota, or FIAT,.....) though all of them use the UDS (Unified Diagnostic Services) protocol, implement different services, Some services, like speed, RPM, H2O Temperature, etc. are common, but others are not. Therefore in case a service is not implemented, probably you get a negative response, and, in case you don't recognize it, you display again the previous data.
Anyway, in the next days I'll have a look to your code, so cross your fingers and keep in touch !!!
Ugo.
Dear @diornexx,
irrespective to what I've said before, I had a quick look to your aia.
I see two things: every 500 ms you scan the table of data you want to read from the ECU, and this cannot be achieved in a secure manner. In other words, if the ECU hasn't time to respond, you can miss one answer, and this can cause an "overwriting" of data. As I said in one of my previous posts, try to trigger any new request with a pushbutton, so to allow the ECU to receive your request and to have the time to respond.
Once you have seen that everything is working well with this "slow" approach, then you can try to optimize the timings.
Another thing that I've seen is that you call the "clearBT" at every new request, but this can void the BT incoming buffer, from any new data, if they are already arrived and, in this case, you miss the truly wanted answer. And, last but not least, you don't allow any time if the ECU is delaying the answer: i.e. as soon as you call a function that requires a data, imemdiately after yo call the receive BT and, if no BT data have been received, you exit from the receiveBT. This has to be avoided.
If you see my receiving function (that I've posted in an earlier answer to you), I receive one byte at a time and I definitely wait until the ">" has been received, so to be sure that the full answer has arrived (with a 10 seconds delay so to avoid that the app remains stuck in the middle).
Give it a look.
Hello Uskiara, I was able to do what you suggested! 
.Without your help, I wouldn't have been able to solve this problem. Thank you very much; I will be eternally grateful to you!
Before closing this topic on the forum, I have a question regarding your app. I saw that you can request other functions outside the loop. How did you do that? I'm thinking about making a request outside the loop, but I don't know how to do it without overriding the requests. Could I use '\n' for that? If so, how could I transform this data into hexadecimal without taking the data generated in the loop?
Dear @diornexx, Johnny,
I'm really happy that you make it working !
As far as the "asynchronous" request is concerned (i.e. out of the loop), you have to consider that my old app was intended to detect which services were available on my car, therefore I implemented the requests separately and, when I've found the way to ask the requests in a sequence, I made them in a loop. My aim was to understand which PID's were available in my car, and to implement later on an automatic series of requests, so to create a digital cockpit.
Honestly it's not pretty clear to me when you say Could I use '\n' for that?
The \n is just the ASCII LineFeed character, in hex is 0x0A. Do you mean that you think to terminate a request with \n ? This is correct, but I dont't think this is your question 
Can you please say it again ?
Ciao, Ugo.
Ps a screenshot of one of my digital cockpit layouts.
Thank you for your response, Uskiara!!
Does "\n" have the same functionality as in Python?
I had seen "\n" in your previous code, and I thought you used it to receive the loop function, jumped to the next line, and received the one outside the loop.
Like this: 41 0D 00 >
ㅤㅤㅤㅤ 41 06 80 >
Is that really the purpose of using "\n"?
Do you think it's possible to make another request outside the loop without affecting it?
Dear @diornexx, Johnny,
thanks for the explanation. I just had a look to my old app,
As I said, the \n is the LineFeed character and is typically used as a string or message terminator.
If I remember well, the ELM wants to receive that character to consider ended the command.
So to send a single command I shall end it with a \n. Like:
In effect I see that I have used the typical characters pair CRLF (Carriage Return/LineFeed). Probably the CR is not necessary, and is a little "old fashioned" ; like we used in the past for typewriters ...(you don't know how old am I ).
For what concerns the use of commands out of the loop, I suggest you to stop the loop, and raise the single command, while the loop is not running, to avoid collisions.
Just bear in mind the some ECU's exit from the diagnostic session if the communication is not alive for 5 seconds. So, when you stop the loop, to allow the single requests, remember to send an "alive" message to the ECU periodically, within 5 seconds. In other words: if the user doesn't ask for a single command withn 5 seconds, the ECU can exit from the diagnostic session. To avoid that, when the loop is not running, you can send ATZ anyway, within 5 seconds.
Please also note that not all services are allowed by all cars. To know which services are implemented, a specific command shall be used. The answer from the ECU contains a stream of bits whose position tells if the relevant PID is implemented. If I remember correctly I have annexed in the documentation of my old app, also the "manual" of diagnostic messages that explains this detail.
PS: I'll be out for three days, so probably I will not read mails.
In the meanwhile....stay tuned...
Ciao !