(Canned Reply: ABG- Export & Upload .aia)
Export your .aia file and upload it here.
Dear @diornexx,
as far as I can see (1 week ago I've got an accident and for th enext 15 days more-or-less, I'm blind to my left eye 
) the number conversion could fail since it seems that in front of the digit that you want to convert there is always a "space" (or blank character).
Moreover the character "N" isn't for sure an hexadecimal value (only ranging from A to F).
Probably these two errors are related (or even caused) by the last error indication: you try to extract a substring starting from a certain character, the 84th, while the mother string is only long 84 characters. So please check your code where you handle the string and verify the length before trying to extract parts of it. I apologise if I cannot go deeper for the moment but my remaining eye leaves me a poor visual capability.
Anyway, keep in touch for further attempts.
Ciao.
.
I'm sorry to hear about your vision problems. I sincerely hope you recover well in the coming days. I know this can be a challenge.
I reviewed the code and didn't find any white spaces that could be causing interference. Could you please give me instructions on what I can do? Please.
What OBD manual are you following?
https://www.elmelectronics.com/wp-content/uploads/2017/01/ELM327DS.pdf
?
Have you investigated the code in the thread I posted?
Did you try the @TimAI2 code at http://ai2.appinventor.mit.edu/?galleryId=6562490234699776
?
Did you know that Carriage Return in AI2 is \r ?
Regarding your app code,
- looping over a ReceiveText block is not the way to request a response from the BlueTooth buffer. Specifying Carriage Return (13) as the Bluetooth Delimiter and requesting -1 bytes should return exactly one message. Do it in a single Clock Timer.
- You have 19 Clocks, 10 of them inactive and 9 of them active, and no Clock Timer event in the lot of them. What were you thinking? Perhaps trying to make your doomed ReceiveText loop work?.
If I were you, I would start over with the @TimAI2 sample.
P.S. Rename all your proceduresto name their purposes. You are asking for trouble leaving them named procedure1,2,3,...
Dear @diornexx , @ABG ,
thanks both for your wishes about my health.
I believe that what @ABG has already said is absolutely correct and shall be your "start poni" to review your code.
In addition to @TIMAI2 sample, you could also take a look to my old app on OBDii.
You can find annexed the .aia and an explaining doc here below.
Hoping they can help you a bit.
CAN_IF_SW_achitecture.pdf (223.4 KB)
CAN_IF_01.aia (1.5 MB)
You can find also other details here in my old post:
Best wishes for your success.
The uskaria sample has a critical piece you need to keep track of your input.
He saves the last outgoing command in a global variable, to help when an incoming response arrives and it is necessary to massage it and display it based on the question to OBD that prompted that answer.
Examine the procedures called from hos Clock Timers to see the if/then/elseif tree of commands and response handlers.
Use that structure instead of your ReceiveText loops.
Sorry about the code; I'm new to App Inventor and still learning. I hadn't seen your link. Thanks for the tips ABG and Uskiara; I'll try to improve the code. I have a question about OBD: can I make it display real-time information in the app?
Yes, just like the professional Torque app, since it talks to the same hardware as you.
Except they read the manual.
Dear @diornexx,
sure you can display real-time data. But only those data that the Engine Control Unit is sending out on the diagnostic CAN bus (not the high speed one, which is not reachable from outside).
Typically you have available: Speed, RPM, H2O temp, Load, Throttle, Air temp, EGR On/off and many others
By asking every 250 ms on the BT (via ELM327) the ECU for some of those data, I have created a digital cockpit for my Peugeot cabrio (207CC) Thie picture below shows one of the graphical layouts that I've implemented.
.
i.e. every 250 ms I send a series of queries to the ELM 327 to have back the requested info, then I display them in various graphical modes.
In order to know which are the "services" (PID's) that your car is capable to send out, you can ask the ECU itself, by sending appropriate commands. The ECU answers with a binary string, in which every bit (set to one or zero) tells you what PID is active or not.
The annexed document is the related "Bible"... 
where you can find all the explanations and the PID meanings.
OBD_PIDs.pdf (723.5 KB)
Best wishes !
Ugo.
PS the data shown are not real ones (108 Km/h @850 RPM in not realistic, of course) These data are generated by an ECU simulator that I've on my desk, built with an Arduino.
In effect if you can create an ECU simulator with an Arduino (or similar ready made HW) so to ease your development and debugging phases. To understand which messages you need, you can "sniff" the protocol between Torque and your car, for example.
Thank you for the tips and teachings! I will be very grateful to you. However, I'm currently facing an issue receiving the requested OBD value (using "\r"). Every time I request it, it returns the value 7F1012. I've read the manual and searched the internet, but I couldn't find anything that helped me solve it. Could you help me with this?
What do you send to request it?
Different requests get different answers.
Show us how you receive BlueTooth text.
I'm trying to apply and understand how Uskiara and you managed to make the OBD respond to the requested query
(Canned Reply: ABG- Export & Upload .aia)
Export your .aia file and upload it here.
You are reading Bluetooth in 3 places and 3 timers.
Simplify.
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.
