3

This question is related to another question I posted here on the new Reverse Engineering site.

I'm working with a small public transit agency on a neat open-source project that will help us to offer realtime data to local developers. A key piece of data we need is the current bus route a given vehicle is on. Currently, there is only a single electronic system that knows this information: the vehicle logic unit (VLU) that each vehicle is equipped with.

When a bus driver begins a route, they type its ID number into the keypad on the operator control unit (OCU). This ID number is sent to the VLU, which then displays the appropriate text on the LED signs on the bus.

On the OCU, there are two DB9F ports. In the manual, they are described as "J1708 PORTS". One of them is connected to the VLU, and the other one is available for me to plug in to. Connecting to it gets me some data that you can read about in my other question.

Essentially, I'm questioning whether my computer is even properly hooked up to the OCU. Currently, I'm just running a plain old 6ft Straight Through Serial Cable (DB9 M/F) between my computer's serial port and either of the "J1708 PORTS". I can consistently get the same data this way, but I'm beginning to doubt that the data is being properly... transmitted?

I am now fairly certain that I'm using the wrong cable or something. Here's a diagram of the cable that is running between the OCU and the VLU: J1708.png

Do I need a similar cable to connect the OCU to my computer? If so, why is it still sending me non-random data when I use a plain old straight through DB9 cable?

drewbug
  • 133
  • 1
  • 3

3 Answers3

10

The SAE J1708 protocol is a low level protocol designed for use in heavy vehicle applications and is based on RS485 but using pull-up/pull-down resistors instead of line termination (hence the RTX+ and RTX- pins shown in your cable diagram).

The protocol is basically 8N1 serial, but messages are separated from each other using an idle timeout (minimum 10 bit times - at 9600 baud this works out to be 1.25milliseconds). Messages consist of one message identifier (MID) followed by one or more data bytes and a checksum byte. The checksum should be the two's complement of the eight-bit sum of the MID and all the data bytes (a message is considered valid if the eight-bit sum of all the characters including the MID, data bytes and checksum is equal to 0). The total message length cannot exceed 21 bytes.

You cannot connect this directly to your PC without at least an RS485 to RS232 converter - you can get away without the pull-up/pull-down resistors for testing but should ensure that any termination resistor is open.

Looking at this cable diagram it looks like you've got one side of the bus connected to the PC RS232 receive pin (RXD) and the other connected to data carrier detect (DCD). While your signals are way outside the range defined by RS232 I suspect there will be enough of the signal to cause the port to see something.

IMHO the J1708 protocol has been poorly designed, particularly for noisy environments as automotive systems tend to be. There is no clearly defined header value (the MID is binary and all values are valid), the is no clear packet length indication (this is much worse when combined with J1587 which is the most commonly used higher level protocol) and the checksum will still be correct if two or more packets are joined together (which is very easy to do without decent idle detection hardware).

A simple interface circuit for your requirements (receive only) is shown below. Due to the nature of the J1708 protocol however this should not really be used in conjunction with an RS232 to USB converter as these generally play merry havoc with the signal timing when converting the RS232 stream into USB blocks, and can cause two or more packets to be combined.

enter image description here

timrorr
  • 1,713
  • 10
  • 10
  • This is a fantastic answer that is extremely helpful. As far as an RS485 to RS232 converter goes, I have two questions: would it be cheaper to get a one-way converter (so that I can only receive on my computer's end, not send, as I don't want to send), and can you point me towards any specific model number? – drewbug Apr 04 '13 at 03:36
  • Can't recommend anything as I have only used DIY interfaces in the past, but I have included more information above. – timrorr Apr 04 '13 at 05:09
  • Thank you so much for your help! It is sincerely appreciated. – drewbug Apr 04 '13 at 05:27
3

Warning: J1708 is not the same as RS-485!

The only time you can use an RS485 port on the J1708 bus is if you NEVER transmit. The receiver is compatible but the transmitter is not. So if you just want to read the data, any RS485 interface should be okay (just don't transmit). But since some of the data you would likely want to see is "by request", you will need to transmit and that is where it gets more complicated.

And also, as timrorr said in his excellent answer, there are tight timing considerations as well, so even if you are just reading, you are likely to have timing issues as he described (because messages are separated by idle time, requiring some other high speed interrupt in your computer hardware to detect the message separation pauses)

RufusVS
  • 131
  • 4
  • My original header line was all caps, but was edited because it looked like shouting. Shouting was my intent, actually. I fight the "J1708 is not RS485" battle at work, too. At best it won't work properly, and at worst, it could be dangerous. – RufusVS Aug 28 '15 at 18:47
0

According to Wikipedia, J1708 is based on a physical RS-485 port.

There are many RS-485 interfaces available out there. There are also resources to build RS-232 to RS-485 interfaces yourself. This may help with your reverse engineering activities.

Adam Lawrence
  • 32,921
  • 3
  • 58
  • 110
  • I have two questions. One, that Wikipedia article says "The hardware utilized are RS-485 transceivers wired for open collector operation through the use of a pullup and pulldown of the separate data lines." Does that mean that I have to use some kind of special cable? Additionally, why am I still able to consistently receive the same data when I connect the OCU to my computer's serial port using a straight-through DB9 cable? – drewbug Apr 04 '13 at 02:04
  • RS-485 uses a differential bus whereas RS-232 is single-ended, and the voltages are different levels. This could explain your noise issues. So long as the interface has the correct resistors, I don't think there's an issue with open-collector. – Adam Lawrence Apr 04 '13 at 02:35