CAN Bus Sniffing

I recently got an ESP32 CAN Bus hat and have been sniffing off the OBDII port. Lots of data, but I have no idea what any of it means. I take that back, just sitting in the driveway in ACC mode I was able to figure out which ID shows the lights, doors, and locks status. Which is cool and all, but I really want to know my speed, rpms, gear, pressures, and temps. GPS data would be cool too. Anyone ever come across a database with that info. There are a couple of Toyota DBC files floating around the interwebs but they don't seem to apply to Gen3 Tacos.

There are pleanty of IDs where the data moves, but I don't know if it is Oil pressure, RPMs, MPHs, kmPHs, or the phase of Mercuy's retrograde cycle. Also, from YT videos I've seen, the number is usually scaled by something so when it says 16, it really means something else, like 3200. There are about 100 unique IDs and I'd rather not have to try to reverse engineer ever single one of them if someone has already done it.

ID 0x4A5

Byte(2) Ignition
Off 0000 0000
Strt 1000 0000
Acc 0100 0000
Run 1100 0000

Byte(3) Doors Open
FD 1000 0000
FP 0100 0000
RP 0010 0000
RD 0001 0000

Byte (4) Not Locked
FD 1000 0000
FP 0100 0000
All 1111 0000
Back doors don't seem
to have active values,
Even though it looks
like they should.

Byte(5) Lights On
High 1000 0000
Tmp 0100 0000
Fog 0001 0000
DRL 0000 1000
Low 0000 0100
Prk 0000 0010

 

Why invent the wheel?
Phone based apps will do it for you for $30-40, included obdII adapter

 

It’s not Friday.

 

It's different. It really depends on what the OP is wanting to do. The apps you are referring to are making generic service tool requests to the ECM. The ECM is then responding. This is a slow process, relative to the speed of electronic controls, and results in very filtered data because these are low priority to the ECM and to the CAN Bus. A lot can happen in 250ms. It may sound funny, but it's true.

For most. This is more than enough.

What the OP is doing is listening to all the regular traffic on the CAN Bus during normal operation. The modules are communicating at a much faster rate and with "better" data. This is how the Hypertech Speedo Calibrator works. The difference is that it has setup more of a barrier and it filters messages. It is like a repeater. For every message that comes in from one side, it rebroadcasts to the other. But for the message that sends speed, it scales those bits. The OP is only listening in on the conversations.

There is a lot of info out there. Much of it is also protected with rolling counters, validity bits, encryption, ... the list goes on. So some of the rolling numbers you may see a pattern in like 1, 2, 3, 4, 1, 2,..... It can be fun trying to figure out what bit is what.

 

I've been using Techstream and OBB fusion app.
I know the limits of OBD fusion app compare to Techstream. But there is no filtering of messages.
I've been using obd fusion during my tunning fling

 

It is all relative to what you want to do and what data you need. In the world of data, most service applications, like Techstream, are slow. But they are generally fast enough for 90% of their use.

I am by no means trying to downplay any of this or anything anyone here is doing. For my tuning and the variables that have been decoded and we have access to, slow tools and my eyes, ears and right foot have been enough. But I was on the other side once upon a time and it is impossible to tune some activities without faster data. It is much different when you are just trying to dial in one truck versus hundreds of thousands with slight manufacturing variances that will exist all over the world in different driving situations with different environmental factors. In our world of aftermarket and driveway modifications, we are playing with less than 1% of the variables so "slow" data is generally more than enough.

Snooping is good if you have a particular need. Like I said above, that is how things like the Hypertech speedo calibrator work. The Freedom locker is similar (I think - it may not be manipulating serial data, but it is manipulating signals). Manipulating serial data is much easier than figuring out which bits inside a module need to change to do "x". There are a lot of things you can do if you know what messages you can manipulate.

Just reasons why someone may want to reinvent the wheel and build a Tacoma DBC file.

 

Sure, but OP is looking for a trivial data.
BTW, Techstream does 10 frames per sec ( a frame per 100 milliseconds). Or 2.5 frames in 250 milliseconds. Can that sniffer beat the rate?

 

I agree with you. There are far easier ways to get the data the OP mentions in the original post.

I am by no means trying to say that what you or anyone else here is doing is wrong. For the aftermarket, unless you are trying to design a product, there is not much need in sniffing the datalink. Generic OBD data and Techstream data should be good enough. So I hope I didn't give the impression I was standing up on a soapbox preaching that we all should be pulling available data straight off the link. But it is fun and interesting to learn. Just make sure you know what you are doing before you start writing your own messages.

I tend to overshare on these types of posts because I have 15 years in the industry with an OEM designing, testing, and calibrating powertrain controls, with a focus on OBD and diagnostics in general. I've used all the methods of getting data from a module. Most often in development it is through an instrumented controller and in that case its almost live data.

But to answer your question, is there faster data on the bus? Yes. On a 500k link that the 3rd gens have, there will be messages transmitted at the 12.5ms rate. Not everything, the bus would be overloaded if everything came that fast. Depending on the data there are different update rates. Generally speaking, the lower the ID number, in the example above 0x4A5, the higher priority the message and the faster the data. The ID dictates the priority of the message. Lower number, higher priority. So if there is a conflict, that is the message that will win. Service tools and OBD scanners will use a higher number ID because they are lower priority.

So what kinds of data would be needed at a 12.5ms rate? Torque requests and commands, engine crank position, transmission clutch status, transmission torque/speed requests, catalyst information, wheel speed (think traction control or ABS). Things like engine oil temperature, door lock status, items you would find on a 0x4A5... these may only be coming across every 500ms or slower.

Again, for the limited variables we have access to through the available tuning software, how fast do we really need data? The service tool is fast enough. Now if I were trying to calibrate shift solenoid duty cycle across temperature ranges to have a consistent pressure apply for a smooth shift at all temperatures, well, I am going to need faster data, a lot happens in 100ms during a shift. Even trying to work with a service tech looking at data captured by a service tool to pinpoint a specific problem on a hard to diagnose customer complaint, sometimes the service tool data isn't fast enough to capture the event or it doesn't have a piece of data you need to see. I know it seems crazy.

So my point is, there are a ton of ways to get data and "fast" is subjective.

 

I want to make the 3rd gen instrument cluster function in my 2nd gen not sure if it would be possible for me to get all the ids to make it work

 

That's the hard part. First you have to figure out what messages the 3rd gen needs into the cluster. Then you have to figure out what data the 3nd gen supports and what it needs out of the cluster. You'll also need to see what other inputs and outputs the cluster needs to support, there are more than just CAN wires connected to the cluster. Doable, yes. Time and money. Schematics are easy to come by, CAN messaging specs are not as easy. Decoding messages isn't terrible with the right tools. The right tools tend to be $$$.

I'd start by comparing schematics first and see what wires you may be missing. There may be better options out there for you , like a generic aftermarket digital dash. My guess is you will need a device between the datalink and the cluster to translate some messages. Might be able to get away with an arduino with a couple of CAN chips.