Reading Nissan Consult OBD-1 through USB to TTL, not TX or RX

Hey fellow hobbyists!

I'm working on a project where my Arduino reads data from my 1993 Nissan 240sx from it's OBD-1 port. I've been stuck on this pat for a while and I just can't figure it out!

This project has done before, and people have run into the same error but when they find the solution, they never posted the fix. So I come to you for help.

The way I have this set up is:

  • A Nissan Consult adapter (Amazon Link))

  • Which uses a mini-USB to mini-USB wire

  • That wire is connected to this USB to TTL adapter (MicroCenter Link)

  • That adapter is connected straight to my Arduino Mega 2560 as such:

  • GND -> GND

  • CTS -> NOTHING

  • V -> 5V

  • TX -> RX

  • RX -> TX

  • DTR -> NOTHING

The way the program works is that it sends 0XFF, 0XFF, 0XEF to the car's computer and receives a 0x10 if it was initialized correctly. This is a code from somebody else (when I find his username from long ago I will post it)

  skorost:     if(ii==false)
              {
                  Serial.write(0xFF);
                  Serial.write(0xFF);
                  Serial.write(0xEF);
                  delay(1);
                  iinit=Serial.read();
                  if(iinit==0x10)
                  {
                    //Serial.println("Initialized");
                    delay(2000);
                    ii=true;
                  }
              }
              if(iinit!=0x10){goto skorost;}

Where, in the void setup() is Serial.begin(9600).

My thoughts:
The RX and TX LEDs on the USB to TTL adapter is not blinking. My guess is that the transmission is never reaching chip. BUT, the TX led on my Arduino is lighting up. This means that it is trying to send the data.

The serial monitor is reading "ïÿÿïÿÿïÿÿ" repeatedly. This is from Serial.write(xxx);. I know this because I tested it by commenting serial.read() out and then serial.write() out to see where it was coming from.

Questions:
Any idea on what it might be? From my understanding, the consult connector has a ftdi chip in it so the logic is going from RS232 -> USB -> USB -> TTL. So I do not believe it is the connector, but I could be wrong.

Thank you so much.

So, maybe I have not typed in proper keywords when I searched before but I have found this:

https://forum.arduino.cc/index.php?topic=459444.0

Where post #21 by MorganS states that a USB -> USB -> TTL would not work. Why is this? If the USB is outputting logic at readable levels, then the input of the USB -> TTL should be able to read it and then translate it to TTL for the arduino, no?

I can not follow the microcenter link (ip address blocked :frowning: )

Can you find the same (or similar product) somewhere else (e.g. amazon)?

USB needs a host (usually your PC). So unless your microcenter adapter acts as a host (has the same connector as your PC), it will not work. You can buy an USB host shield and connect your consult adapter to it; not sure how well they work (no idea about the programming side of things).

So at this moment it's not 100% clear to me how you have everything connected.

Serial.write sends raw data; 0xFF and 0xEF are characters that the Serial monitor does not understand and hence the funny output. The flashing TX led on the Mega means that data is send (not: is trying to send).

The Mega has multiple serial ports; why do you use Serial and not e.g. Serial1? The Serial port (connected via USB to the PC) is extremely useful for debugging.

sterretje:
I can not follow the microcenter link (ip address blocked :frowning: )

Can you find the same (or similar product) somewhere else (e.g. amazon)?

USB needs a host (usually your PC). So unless your microcenter adapter acts as a host (has the same connector as your PC), it will not work. You can buy an USB host shield and connect your consult adapter to it; not sure how well they work (no idea about the programming side of things).

So at this moment it's not 100% clear to me how you have everything connected.

Serial.write sends raw data; 0xFF and 0xEF are characters that the Serial monitor does not understand and hence the funny output. The flashing TX led on the Mega means that data is send (not: is trying to send).

The Mega has multiple serial ports; why do you use Serial and not e.g. Serial1? The Serial port (connected via USB to the PC) is extremely useful for debugging.

Thank you for the quick response.

The chip is a normal FTDI breakout board. Unfortunately I can't find the one that microcenter sells anywhere but it is this similar to these two:

From your explanation it sounds like I do need the USB shield; so it is a hardware issue. I was unaware of the USB needing a host because I assumed that the simple 0V to 5V logic could just be read as that, just like TTL, but it sounds like a computer is needed to tell what the 5V and 0V is. So it seems like I need to research how USB communication actually works.

Thank you so much for that. I now have a better idea of where I am stuck.

Are there any other ways of getting around this or I definitely need the USB shield to work properly? Or, if I wanted to, how would I go about making my own 'USB shield'? Not that I will make one but my curiosity is itching so understand how and what the host is actually doing.

Regarding the 0XFF and 0XEF sending, wouldn't they send as binary numbers?

Once again, thank you so much. You helped me climb my first hill and I appreciate that.

Regarding the 0XFF and 0XEF sending, wouldn't they send as binary numbers?

They are send as a byte (being 8 bits); I think you understand that any data send over the serial line goes 8 bits at a time. But it does not mean that the serial monitor understands what they mean.

Maybe this analogy helps. We're now communicating in English using words (bytes) and letters (bits). If I switch to some other language like Zulu (unlikely that you speak it), you will still understand the letters but not the words.