I did some more digging to decide how I was going to approach the protocol used.
I came across the Consult II hand held scanner manual which specifies 3 protocols used of which ISO9141 and KWP2000 are specified as using the DLC-II connector in the car (the OBDII connector).Watch Full Movie Online Streaming Online and Download
ISO9141 is mentioned in the service manual as being used for OBDII communication (with any generic scan tool) – however I confirmed in our version it definitely doesn’t support the OBDII standard, whilst, KWP2000 is used for the Consult II protocol.
Not a lot to go with initially, but I also came across a manual for a key reprogrammer (the keys for our car are coded to the immobiliser and then to the ECU – meaning if you replace the key, the ECU needs reprogramming, if you replace the ECU, the new ECU needs reprogramming).
The baud rates mentioned there are 9600 or 10472. My bets are on 10472 baud being used.
With this, it’s now going to be a case of setting up a test of KWP2000 to the ECU at 10472 baud and attempt to request information from the car.
The KWP2000 protocol is documented, but the requests and responses, the calculations to translate the hex responses to valid data just don’t seem to be publicised.
I do know there are two items out that apparently accomplish very similar to the Nissan Consult II scanner (4000.00 on Ebay). The alternatives are the BlaztII cable for $120 USD (requires a PC in the car), or a handheld scanner from china – “Memoscan N607” – also typically around the $120 mark.
As I considered last time I was thinking about this, the ECU really is just calculating values from sensors around the car. There’s no reason why the sensors themselves couldn’t be monitored directly and then calculate the same desired information.
I just don’t really want to be running additional cables through the engine bay to get the desired data when a perfectly good data line already exists.
If only the request / responses were readily available!