A brick wall that i've smacked into with hex codes

I’m currently attempting to make an app for my mechanic shop. I’ve mentioned this before. I bought a Bluetooth obd2 plug that was capable of transmitting live data. the issue is, apparently the obd system has an immensely complicated hex system that ive been trying to wrap my head around for about a week now. . .

I see all of these apps using a (not web) api to parse this data. I’ve spent almost a year on this platform trying to get this app working only for the thing, that i assumed was going to be the simplest, and is the most crucial to be something that I don’t think, from what i know, thunkable is capable of helping with.

all I’m attempting to do is get some data from the sensors every so often based on time or the cars mileage, assuming i can parse it.

does anyone know of a function that i could possibly use to overcome this?

the wiki page showing the, rather confounding, hexadecimal stuff.

The obd2 program “api” that i would like to use if possible to do so

i forgot to mention that this is a Bluetooth device, but i think the input and output responses are the major part of this and less the Bluetooth part

I honestly love these kinds of challenges. But I know how they can drive you mad!

I had some success parsing hexadecimal data here. Maybe this has some similarities? I’ll have to sit down with this when I have some more time.

this is the most sense something on this has made, but i was looking for someway to translate hex to
the actual values. i.e. hex code to actual value in rpm, it’d spit out 4000 in the example, but the simple math i can do on my own. lol, creating something as complex as a hex dictionary, not so much lol

however, it doesn’t seem like you got to making anything functional… :thinking:

the elm device only outputs numbers, so, that actually limits this quite a bit i might be able to work with that!
but i think we might need to get a petition going to add codes to the translation function, that’d be an incredibly amazing addition, don’t you think?

I see this table, an i wonder if it would be possible for me to rig a real time database to do it…

Can you tell me what a possible hex code would be and what a possible numeric value would be? I don’t expect you to translate them because that’s obviously what you need help with but… it would really help me understand this to know something like:

“The device might output something like 1B91842FED7 and I need to know what the decimal value is between 99999 and 999999 or I need to know which four two-digit codes are represented by it.”

In other words, what is an initial sensor value you expect to get from the device and what is a sample expected final value you hope to see to understand that data from a mechanic’s perspective?

Edit: is this the sort of conversion you need to be a part of your app? And if so, then this documentation might prove useful to me and others trying to help you solve this challenge.

Also, does the table you posted right above this show the actual values you need or is it just an example of a table that would translate values? I’m trying to hone in on actual sample values that you could see.

And I have no understanding of obd2 data (I had to Google the acronym) but it seems to me that you need an API that uses REST calls and JSON formatting. I couldn’t make heads or tails of the API github link you posted but I’m curious if this might do the trick: REST API for Oracle IoT Fleet Monitoring Cloud Service - Retrieve vehicle on board diagnostics 2 (OBD2) parameters

Ah, but I did! Well, I believe I did. @pittsgal never quite confirmed my theories but I was pretty confident of them. :smirk:

sorry, this is the right link, this one made the most sense.

from what i understand, it’ll only ever return numbers for the most part, unless its an error code.

you have to se the mode, the example in that link is “auto” which is fine, because all I’m going to do is set it to do something like this:

connect to car obd2 bluetooth thing
get the mileage, check if the car has driven, lets say, 20 miles since the last time it checked the milage
if so
grab a few data points
coolant temp, tire pressure, and a few others.

issue is, i dont know how to get this part
hex. . . | . . actual ascii value
0x0FA0 = 4000

after i get the 4000, there’s a little calculation, but it can totally handle that, its no big deal.
the main issue is the conversion FROM the hexadecimal to the ascii

the idea is to have more frames of diagnostic data to work with, and to have a way to actively tell the customer that they might need this or that based on legit stuff

1 Like

i also just realized that its not converting from hex to ascii… its converting from hexadecimal to decimal

Right but you’re not getting 0x0FA0 from a physical device/sensor, are you? You’re getting a value like 41 0C 0F A0, right, according to the updated “Reading Real-Time Data” link you posted?

Just trying to understand the starting and ending points. Because if you have a device that gives you 0x0FA0, that’s going to be a different set of steps in Thunkable compared to the steps you’d need if you’re given 41 0C 0F A0. By the way, the 0x0FA0 is just the last four digits of 41 0C 0F A0. If you join them together and remove the space, you get 0FA0. And if you run 0FA0 through a hex to decimal converter online, you get 4000.

I think you’re going to want an API that will convert hex to decimal. It’s probably not that hard to convert hex to decimal manually in Thunkable but it would be extra work.

It’s going to be an obd2 bluetooth device

So I have to send a request

And it responds in hex

Yes but… lol… what does the hex look like?

If I was holding the bluetooth device and sent it a request, what would I see on the screen?

Can you post a photo of such a screen?

And no it’ll be simpler now that I get it

“Get substring”
Make a function block that decodes them, bla bla bla.

My main issue was the hex… It was spitting out emojis and stuff :roll_eyes: damn… It was a waste of time…

It’s like this

The first 2 are the I’d of the sensor

Xx and the rest are a number from 0 to 9999

I haven’t gotten it working yet, admittedly. But I’m trying to get a grip on the hex before I do something wrong.

This description makes it perfectly clear

Okay, I’ve read that and I understand what it says but I think we’re having a problem communicating (text-based discussion is always a little tricky) because I’ve asked about four different ways what you actually see… a real example… and I still don’t know.

I know if I could see the physical device screen after you sent a request, I could help you solve this. None of this sounds difficult to me. A little time-consuming but not beyond what can be done in Thunkable.

I’m hoping someone else can pick up where I left off… I feel like we’re close to getting this figured out!

1 Like

Yea, tomorrow morning I’m going to try to get some samples from my car, and then I’ll post some stuff.

Because I figured out what I was doing wrong… Now I just need to make a basic test-build for the bluetooth device.

I’ll show you when/if I get it going… I doubt it’ll be easy in any sense though, lol

1 Like


I made a base-16 to base-10 converter that took me a bit too long to figure out! I messed up on the exponent thing at first, but now it works!