Decode Manchester encoded Signal with PCIe-6321

[Oweo4711]

Hello, I'm really new to this, but I'm doing an internship where we are using the PCIe-6321 port0/line0 to receive a digital 200kBit PCM signal with visual studio and c#. 

The signal is Manchester encoded and has a certain pattern of bits at fixed intervals that I'm supposed to detect. The pattern is 32 bits long, followed by 255 other data words of 32 bits length.

What I've tried so far:
- Make a sample clock set to 200kHz to read samples on rising edges, use the readMultiPortByte(-1) function to read all the data in the buffer into an array and then look at the transitions between the array[i] and array[i+1] to decode back into usable data (This doesn't work, since I'm not actually detecting the rising/falling edges of the signal, but whatever value the signal has when the clock has the edge)
Weirdly enough, if I don't do the 'decoding' step I can actually find the pattern, but the intervals it appears at is irregular and the data isn't where it's supposed to be.

-Then I've looked into using the changeDetection Timing in a similar setup, to detect both rising and falling edges of the signal on line0 of port 0, but that only gives me a bit array of alternating 0's and 1's. I'm probably doing something wrong here.

- I've tried using NI MAX task to see what the waveform looks like in there, but that hasn't really helped much.

Due to security reasons the pc with the card isn't connected to the internet so sadly I can't attach any of my code, I'd still appreciate any kind of input on things to try or where I've made mistakes.
Hope this was readable since english isn't my first language, have a nice day.

[Oweo4711]

I've progressed a little and understood why the change detection didn't work.
I'd need to measure the time between the edges to see if they are in the middle of the bit period and actually represent data.
So now I'm looking into a way to do that.

Also, thought that maybe using the Waveform datatype that I can read would help with that, or be the solution in itself.

[Oweo4711]

Another Update: Since I need the time between edges, or rather the width of the pulses to determine where the pcm signal has its data encoded I am now trying to set up a counter with the help of the examples.

Only problem is I'm not quite sure what the min/max value should be and if I need to add any wiring to use the ctr0 to measure the width of the pulses of the digital port0/line0.

[Kevin_Price]

Generically, bringing in counters will help give you a lot of flexibility with the timing signals you need to either characterize or control.

Specifically, I don't know any details about "Manchester encoding", particularly timing specs related to data bit(s) and any possible clock signal.  Can you please give a detailed description of the timing relationships? 

    For example, when you mention a stable bit value happening in the "middle" of a pulse width, what are the specs around that?  Is it guaranteed stable from 45-55% of pulse width, from 10-90%.

    Also, is the 200 kHz a steady stable data rate coming in?  Or can it vary?

-Kevin P

[Oweo4711]

Thank you for the reply.

Basically, Manchester encoding takes a clock signal and a data signal and combines them with an x-or gate so you can transmit both in a single stream.

As a result of that kind of encoding, a data bit of 1 will be represented by a low to high transition in the middle of a bit period, and a 0 by a high to low transition.
The tricky part, at least for me, is that if a lot of 1's or 0's occur in a row in the data, there are other transitions not in the middle of the bit period(I'll attach a png of the manchester encoding convention to make this more clear, the 802.3 is the one we're using)

So, to decode the signal again I need the high/low as well as low/high transitions AND how wide the pulse was so I know if it was a transition representing actual data.


The stable bit value I mention is unfortunately something that should only occur after the signal is decoded again, as that is a part of the data that is transmitted. It should be pretty stable since it gets injected by the transmitter into the datastream at fixed intervals.

The 200kHz is a stable data rate coming in and shouldn't vary.

[crossrulz]

Going way back in order to remember how I handled Manchester encoding...  I did it in LabVIEW FPGA with an R Series board.  The FPGA just passed up the resulting values instead of the bit pattern.  But from what I remember, we sampled at 2 or 4 times the data rate so that we could detect the rising and falling edges.  It looks like your PCIe-6321 can handle up to 1MHz sample rate on the digital line, so I would just go with that.  The rest is just processing the bits as they come in.

[Oweo4711]

Thank you for the reply as well.
I think I've tried doing something similar to what you're suggesting, but I think I did something wrong there.
I'll try using the counter for now and if that doesn't work, I'll try the higher sample rate and then process the data, I'm just a little concerned the performance might be too slow for the amount of incoming data. We'll see.

Have a nice day! 

[rolfk]

---

@Oweo4711 wrote:

Thank you for the reply as well.
I think I've tried doing something similar to what you're suggesting, but I think I did something wrong there.
I'll try using the counter for now and if that doesn't work, I'll try the higher sample rate and then process the data, I'm just a little concerned the performance might be too slow for the amount of incoming data. We'll see.

Have a nice day! 

---

Definitely need to sample with at least twice the data frequency to get any meaningful data. Doing a buffered counter acquisition might be also an option but you would need to create a counter value on both the rising and falling edges of the trigger (your data signal). In terms of processing the resulting data I think both will be fairly equally time intensive. With the counter solution it may be however a bit of a challenge to determine the initial digital state of the input unless you can search for a specific pattern that indicates the start of your frame.

If I would need to do it, I would not hesitate one second to use a cRIO/sbRIO and do this on the FPGA side rather than with a PCI card and trying to decode everything in the PC software (LabVIEW, C# or Python)