Quote from: Gjkrisa on February 28, 2019, 11:03:58 AM
Quote from: ecoboostsho on February 28, 2019, 10:41:43 AM
Hey there! Appreciate the references but I am far from an expert on CANBUS communications - that said I will happily chime in what I do know. (I did get your PM as well Gjkrisa). The challenge with scanning the PID's per se is that the method I used originally to figure out the numeric values for them involved using a known scan tool to do so. The modules communicate directly between them via addresses on the CANBUS so you need to be able to intercept that communication or have it originate on the scan tool. With a scan tool (like FORSCAN for instance) you could sniff the traffic between the PC and the car to see what the responses were. If you are actually trying to intercept a communication between modules (like what the Explorer does when you put it in SAND mode as the example you sent me via PM) you have to have a way to see that PID response and that won't be easy.
Bottom line is if you can replicate the action/request with a SCAN tool and use a serial sniffer to see it then we can interpret the results and possibly make some progress. Without that I don't know of a way to essentially see all of the traffic on the CAN bus and even if you could picking out the one thing you are after would be difficult because we don't really know what we are looking for.
Right yeah I had gotten a log on my phone but had messed up a few times so when I finally started logging the packets it supposedly filled the 1mb buffer and only showed me 15 lines of which also have no idea what they were so yeah was curious how you could even tell what your even looking at so that makes sense
They mention on a artical on obd hacking that you just keep flipping your trigger few different patterns so you can find that one object
Thank you for that little bit of insight.
You remember any of the commands of what you used to establish connection and get it all prepared?
Sent from my Pixel 2 XL using Tapatalk
Here are some notes I made for myself a long time ago. You may need to tweak the STP setting and the STCAFCP to get what you want (assuming all this still works). This is based on an OBDlink MX adapter which utilizes the STN1100 chip set. After you establish a serial session with the car you can type the following to set things up. You may need to tweak the settings depending on your terminal server serial connection to get the display you are after.
ATI (Just prints ELM 327 version ID string)
STI (Prints Firmware ID string)
STP53 (Sets Protocol to 53 - MS CAN as an example)
ATPC (Protocol Close)
ATE0 (Echo off)
ATL0 (Line Feed Off)
ATH1 (Headers On)
ATST32 (Sets timeout to 32ms)
ATS0 (Print Spaces off)
ATAT1 (Adaptive timing Auto)
ATCAF1 (Automatic Formatting On)
ATTP6 (Try Protocol 6)
ATBI (Bypass Initialization sequence)
ATAL (Allow long messages)
ATSH0007E0 (Set header to 00 07 E0 - this is typically your scan tool address if I recall correctly)
STCAFCP7E0,726 (Adds a flow control 11-bit ID pair, 7E0 is your scan tool and 726 is your target module address...you could request a known PID from the AWD module and see what header it responds with and use that going forward)
Here is the entire guide for the chipset...
https://www.scantool.net/scantool/downloads/98/stn1100-frpm.pdfYou can actually monitor all messages and then filter for what you are after...challenge is you don't know the PID but I think you could at least limit it to the communication between the module in question.
It's been quite awhile since I dug in to this so take the above with a grain of salt and maybe experiment a bit! (But don't go too crazy.
)
