Looking for a method of finding a bit-pattern arriving in unstructured serial data

[Pags1968]

Hey all!  First time on the boards.

I am currently attempting to perform a real-time serial read to look for a bit pattern contained within the raw serial stream.  My biggest issue is that the serial data stream is unstructured coming up from a sensor so this is similar to what I think would be a device driver.  So the system I have is an optical to RS-232 converter (RLH industries) that provides my data as "bytes".   The pattern (e.g. 0xFD --> 1111 1101) indicates the sync for my data frame.  This is not guaranteed to arrive on a byte alignment boundary, so I need to scan as the data is arriving the bit-representation shown above until I get a match, then grab the next 1024 bits from the serial stream as my data frame.

Sounds fun right?

I have been able to get the "sliding detector" working on some static data, but now I need to move to the real-world of data arriving on a serial port.  Any suggestions would be greatly appreciated.   Not sure exactly how I'm going to solve this yet, but thought I'd ask before I dive into the unknown if anyone has had to deal with this before.

Thanks...   Chris (Pags1968) 

[santo_13]

Please share the manual or document of the Serial protocol or the device, maybe there are other creative ways to approach the problem.

[Pags1968]

Santosh:

The Digitizer is a custom build device, so there is not a lot of true documentation.  I'll try to provide some items here though that might help understanding what is happening.

So the digitizer is pushing up straight optical as a series of bit pulses (re: 1's and 0's effectively).  I have a optical to RS-232 device that is basically collecting from power on each pulse (bit) into a 8bit register (UART) and then once full shifts the 8-bits to the data bus.  So I get a "byte framed" 8-bits of data coming to the host computer at 9600baud N-8-1.   So that's all good, and works great.

Now, the challenge is that we have no guarantee that my message start pattern for data (0xFD) is byte-aligned coming in.  So I've added a a couple crude diagrams below that shows how I need to approach the problem from a logical perspective. 

The key is is that I have transpose the arriving "bytes" into bits, and work from the "bit buffer" not directly from the serial stream.   That's what makes this a challenge I believe.

Hope to hear back.

Chris

[Kyle97330]

Have you tried this on your device at all yet to confirm it works?

The reason is that "RS-232" isn't just a straight conversion of ones and zeroes over time into bits, it has a structure.  Specifically, it has a start bit and a stop bit:

(Stolen from wikipedia)

So I kind of doubt how this whole thing will work unless the converter you're using is specifically designed for something like this... which is a weird thing to be specifically designed for.

[jjohn1]

This is a bit notional (I have not tried it and my logic may be off) but:

One approach might be to use a U16 as a two byte buffer, and bit shifts to align the incoming stream to the pattern using the following (rough) steps:

1 convert each incoming char to U8, then build a U16 out of the next two bytes, with the first incoming char in the lower byte.
2 extract the lower byte from the U16 and compare it with your pattern flag
3 If is equal, you have found the flag
4 If it is not a match, right shift the U16 1 bit and go back to step 2
5 Do this up to 8 times, and if the flag is not found, replace the upper byte in the U16 with the next char from the input stream and go back to step 2

[santo_13]

I think this could become simpler if you implement the bit stream to serial packet framing in hardware, like in an RP2040 or simple FPGA or CPLD.

[daveTW]

As a starting point this could be a first approach:

[paul_a_cardinale]

Maybe something like this:

[Pags1968 · Accepted solution]

Santhosh

That's where I'm landing right now.   I'll probably push this thru a cRIO with the Artic 7 FPGA.  I was just trying to see what I could do with what I had on hand.   

All the solutions are definitely awesome!!!!   Great ideas for going forward.

Chris

[Pags1968]

This is a great option, I'm definitely going to experiment with it more.

Chris