Stepping down baud rates

Forum 2005-2010 (read only) Hardware Interfacing
1

Hi everyone,

I wrote a post a little while ago, but it may not have been very specific enough to get a response.

I have come across a problem that I wanted to ask everyone here about.

I am interfacing with an OBD-II port, which may have up to 1 megabit baud rates (Controller Area Network).

Has anyone ever stepped down a baud rate with the use of an IC? Once we get the signal translated, we're going to be sending it wirelessly somewhere else, through XBee, at a maximum of 250kbaud. So, does anyone haev any suggestions? Would I need a buffer to save the information that is coming in and send it over the wireless connection until we've buffered all the data?

What started as us thinking was going to be a simple "Voltage on one pin is being transmitted as the voltage on another pin" has turned into somewhat of a nightmare! Any help or links that anyone can find (I've probably searched the entire internet already!) would be appreciated, or any helpful hints would be best that I could research on my own.

Thanks again, I look forward to contributing the community!

-Sean

2

The mega168 running at 16 MHz should be able to handle 1 Mbps serial communication, but I'm not sure if the Arduino serial software is tight enough to be able to handle this high a baud rate. The other question is whether you can process the incoming data fast enough.

If the signal doesn't have to be intensively processed, you should be able to receive it with hardware serial, buffer it (assuming there isn't more data than can be stored in the mega168's meager RAM), and retransmit it using software serial at a lower baud rate.

  • Ben
3

There are several different communication protocols involved in this bus see:- On-board diagnostics - Wikipedia

Only one - "# ISO 9141-2. This protocol has a data rate of 10.4 kbaud, and is similar to RS-232."

is compatible with the Arduino. The higher speed you talk about is a CAN protocol and is not supported. You might be able to get a chip and attach it to an Arduino but this is probably a bigger project than you were expecting.

Just because it is easy to explain what the project should do dosn't mean it is easy to implement.

4

Grumpy - I could have misunderstood your tone, so if i did, i apologize, but thanks for the tip about implementation being tougher than explanation, not sure what it added, but we got it, thanks. Also, it should be reasonable to assume that if we have done the work to find processors, development boards, and wireless units, I probably ended up on the Wikipedia for OBD once or twice.

Ben, I see what you're saying, and it makes a lot of sense.. I have been thinking a lot about this and drawing up schemes on how to get this thing working correctly. I think i've come up with a neat idea, which obviously is not original .. It basically expands a little bit on what you said. I have a higher level explanation below.

Originally I was saying that it would be easy to spoof the look and feel of a car on one side, and a obd-ii scan tool on the other. I walked away from the idea when I realized that the Baud may be a little too big for the processor / wireless units we're looking to use. I think i'm going to come back to the idea now, though, due to there being all sorts of different speed Ethernet ports on the same internet. Mimicking this on a very small scale, we would be creating a layer structure like that. Separating the message layer from the physical layer would help us figure out how to transmit messages (albeit at a slower pace) across a medium that it was not originally done

There are two main concerns I have:

1 - ISO / PWM / VPM

Since the messages from OBD-II are small, and are not much longer than 12 bytes which means 96 bits. At a transfer speed of 10.4kbaud, that would take 0.9 ms to transfer the 12 byte message. While queuing all of the messages may not be the best option, I think that the slowest speed we are considering using for wireless data communications may allow for us to send the data to the base station before the second message comes. We aernt worried about this transmission speed because the arduino and the wireless units can handle this baud rate.

Once we get to 41kbaud it gets iffy.

If I use half of the SRAM for a character array, that allows the queuing of 42 messages before they are sent wirelessly. This baud rate still sends 42 messages in 0.32 seconds, well fast enough for any purpose we are looking to fulfill.

the 255 byte message is the longest message (an alteration of the ISO standard), it would still take 200 ms to receive the message from the car, and at this speed again we aren't worried about the arduino processing the data before sending it over.

2 - CAN

Now, after we found out that the Arduino is not able to handle such a high speed CAN, maybe the thing to do is interface a component that can step the speed down and queue by message? This was more the question I had before. I am interested in seeing if anyone's used the Arduino to interface with serial communication devices at higher baud rates.

I think it's going to come down to buffering the data and sending them one by one. This may mean that I wont get to use the arduino afterall... (Sad)

But it may make sense to have the arduino understand which messages on this CAN network (redundant, i know, like PIN number) are appropriate to send to the scan tool, thus eliminating any extraneous messages, but we wnot know if there are such thing as extraneous messages until we get in and start playing.

The last piece of the puzzle is this CAN. It is really making me nervous!

I was all over the place in this post, I know. Thanks for at least starting the conversation with me!

Thanks for the replies,
Sean