Syncronising serial data capture

[keithjnz]

Toyota / Lexus use a protocol called BEAN (Body Electronics area Network) to communicate between various ECU's in the vehicle. I want to intercept this data. This is because I have an engine from a Lexus that I am putting in a boat, and most of the "Dash" information, eg Engine temp is available in this data stream.

I have found enough information on the net to understand what the protocol looks like. Basically it has one start bit and then up to about 15 bytes of data. The baud rate is supposed to be 10K.

So my first approach was to write a program that used a Hardware interrupt (INT0) to capture the edge of the start bit. This then installed a timer1 interrupt that was set to expire in 1.5 bits time, this should be about smack in the middle of the first data bit.

When the timer interrupt occurs the timer interval is changed to 1 bit width, and the status of the data pin is recorded. It continues in this fashion until I detect the end of data, currently I am just looking for a couple of zero bytes.

From there the stored data is currently sent out the serial port.

All of that worked fine in theory but the captured data wasn't making sense so out came the scope. From this I determined that the Baud rate of the data stream was actually a little less than 10K, so I made adjustments to counter that. I also modified the Timer1 interrupt routine to turn on a DO so that I could compare the incoming data stream to when the interrupt routine was sampling.

I have the luxury of a digital scope and have discovered the BEAN datastream has a bit of jitter in the bit width and this causes the sync to drift out over a couple of bytes. I have spent ages playing with the timing but cannot get it to the point where it doesn't drift out.

I had a couple of scope pictures to put here but the system wont let me.

So my new plan was to keep the hardware interrupts enabled and use this to "re-sync" the timer on every "1". The protocol incorporates "bit stuffing" and so in theory there should not be more than 5 bit periods before a "1" comes along to resync off of.

But I can't get the Timer1 routines to achieve this, the stop/restart/start methods all seem to generate false interrupts so I am about to dive into direct control of Timer1 but I thought I would ask if anyone had any better ideas about how to approach this before I start.

[MorganS]

Tricky. Have you checked that you're clearing the interrupt flag before re-enabling the interrupt?

Can you sample at 3x the bit rate and use that to recover if your timing has slipped?

[DrDiettrich]

Typical RS232 devices operate at 16 times the baudrate, sync on receipt of a start bit, and continue to scan at the 8th clock pulse (middle) of every frame (start+8+16*n). Of course you can use a smaller clock divider as well, like MorganS suggested, to reduce the interrupt rate. Then you can re-sync at every change of the input signal, provided that the signal doesn't have spurious spikes.

The main difference from you approach is a continuous timer interrupt, no need to turn it on and off, and no need to change the timer frequency. When you detect multiple re-syncs in the same direction (fwd/back), you can adjust the clock rate accordingly, but perhaps such a change should be delayed to the next gap (stop bit?) in the data stream, not while receiving.

Are you sure that the transmission really is asynchronous, no extra clock signal like with SPI or I2C?
Are you sure that the transmission does not include clock pulses or other synchronization means (SWP), or some indication of the transmission rate of the current sender?

A paper on BEAN is available from SAE, but $25 exceeds my curiosity

[jboyton]

A picture is worth a thousand words. Are you sure you can't post one?

That said I think your last plan makes sense. Synch on each start bit. Set up the timer yourself, it's not that hard, and make sure you are adding the bit width time to the timer compare value, not to the current timer value.

Another approach is to generate an interrupt on every edge, rising or falling, and use a timer to back calculate the bits. That way your timer doesn't have to be perfectly synched to the baud rate, it just has to be able measure the elapsed time within a certain tolerance.

[Robin2]

Have a look at the code in yet another software serial. It can probably be modified for what you want. It is an offshoot of a somewhat similar Thread.

You should be able to attach a JPG or PNG file. Another option is to host the photo somewhere (I use photobucket) and post a link to the image using the image button.

...R

[agent73]

any news ?)))

frame: