I have an analog signal(in blue), that I am required to decode to 1's and 0's using an ADC. The analog signal is manchester encoded and has a frequency of approximately 18KHz. But as can be seen from the digram the frequency is quite not the same for all the bits and varies a little bit every consective bit but remains relatively constant. My solution involved starting the ADC with an appropriate sampling frequency at the start of the data stream and taking 'n' samples over a window(4-8 bit periods), calulating the threshold/midpoint ADC value and making a decision of 0 or 1 based on a 80% majority voting of every 'n' samples. But this always doesn't work as there is a drift in the window due to the difference in frequency I mentioned above. Is there really any way or more elegant solution I can do this in software? Thanks in advance. (PS. The analog signal is the output of a differentiator and I have the flexibility to change the waveform to make it look more or less like a square waveform)

 

hi v171,
Is the analogue signal referenced to 0v?
E

 

What does it look like if you make it squarer?

 

hi v171,
Is the analogue signal referenced to 0v?
E

Yes, it is referenced to 0V

 

What does it look like if you make it squarer?

Something like this. Voltage levels are irrelevant. Just wanted to give you an idea of the shape

 

Do you have to use an A/D? A low-pass filter and a comparator would do the job just fine.

 

How about looking for a significant change in the voltages over a short amount of samples, indicating a transition of state (0-1 or 1-0).
This would not be affected by a change in frequency of the pulses.
You can do a running (moving) average of the ADC samples to detect the transition.

 

Keeping a running average is a good idea. Over the time, the average may drift; using a fixed logic threshold is not reliable. We may also keep a running min and max. Then use (average+max)/2 and (average+min)/2 as the thresholds for the logic-high and low, to further filter out small fluctuations around the average.

 

If you're stuck with having to do it in software, then pass the signal through a IIR filter, which would give you the DC level,
If signal>(DClevel+hysteresis) set the output to 1, if it is less than (DClevel-hysteresis) then set the output to zero.
Have a counter running. Whenever you change the output, load the counter value, and subtract the previous counter value, that gives you the length of the pulse. If the datastream is not too noisy, you can then make a simple decision as to whether it is a two-bit-wide pulse or a single-bit-wide pulse. Then use one of the common algorithms for decoding Manchester coding.

 

Keeping a running average is a good idea. Over the time, the average may drift; using a fixed logic threshold is not reliable. We may also keep a running min and max. Then use (average+max)/2 and (average+min)/2 as the thresholds for the logic-high and low, to further filter out small fluctuations around the average.

Keeping a running average is a good idea. Over the time, the average may drift; using a fixed logic threshold is not reliable. We may also keep a running min and max. Then use (average+max)/2 and (average+min)/2 as the thresholds for the logic-high and low, to further filter out small fluctuations around the average.

Yes, I do use a running average. Every window, I recalculate the threshold to make the decision. But this is exactly not the problem at the moment. I will try to detect the transitions as another user mentioned.

 

THAT IS NOT AN ANALOG SIGNAL!! It IS a digital signal of ones and zeros, and was used for sending digital data over longer wires, or radio links. The data is decoded by comparing the incoming stream with the recovered clock signal. I have not used such encoding but I did read the book, so I do recognize it.

 

THAT IS NOT AN ANALOG SIGNAL!! It IS a digital signal of ones and zeros, and was used for sending digital data over longer wires, or radio links. The data is decoded by comparing the incoming stream with the recovered clock signal. I have not used such encoding but I did read the book, so I do recognize it.

Do you have any ideas on how I can use an MCU to recover the clock?

 

Do you have any ideas on how I can use an MCU to recover the clock?

There's one clock on every edge.
The time between edges can be either τ or 2τ.
If you have got past 1.25τ without finding an edge, there should be a clock pulse 0.75τ later.

 

View attachment 348705


I have an analog signal(in blue), that I am required to decode to 1's and 0's using an ADC. The analog signal is manchester encoded and has a frequency of approximately 18KHz. But as can be seen from the digram the frequency is quite not the same for all the bits and varies a little bit every consective bit but remains relatively constant. My solution involved starting the ADC with an appropriate sampling frequency at the start of the data stream and taking 'n' samples over a window(4-8 bit periods), calulating the threshold/midpoint ADC value and making a decision of 0 or 1 based on a 80% majority voting of every 'n' samples. But this always doesn't work as there is a drift in the window due to the difference in frequency I mentioned above. Is there really any way or more elegant solution I can do this in software? Thanks in advance. (PS. The analog signal is the output of a differentiator and I have the flexibility to change the waveform to make it look more or less like a square waveform)

Hi,

You could try a couple things, starting with some amplification.
To determine the clock frequency you could try an FFT. That also allow you to generate a reference signal you can compare to the original to determine where the bits are and what state they have. If you already know the frequency that's even simpler.
You could also try a differentiator to detect the edges. This might get noisy so you would have to make it bandlimited.
Another technique would be to use a phase locked loop to sync to the bit transitions. Sample the signal using a high enough sample rate, use a phase locked loop or zero crossing detector to determine bit changes/states.
I think an adaptive threshold technique was already discussed.
Design a special filter to enhance the squareness of the signal first. We could look into this.

I know by a known example that a comparator would do this but it's a cheap way of doing it so it may not be that reliable, and I am not sure what the minimum quality of the signal is required for it to work at all.

 

There's one clock on every edge.
The time between edges can be either τ or 2τ.
If you have got past 1.25τ without finding an edge, there should be a clock pulse 0.75τ later.

But that's the thing. I need to find tau. I can't assume I know it

Hi,

You could try a couple things, starting with some amplification.
To determine the clock frequency you could try an FFT. That also allow you to generate a reference signal you can compare to the original to determine where the bits are and what state they have. If you already know the frequency that's even simpler.
You could also try a differentiator to detect the edges. This might get noisy so you would have to make it bandlimited.
Another technique would be to use a phase locked loop to sync to the bit transitions. Sample the signal using a high enough sample rate, use a phase locked loop or zero crossing detector to determine bit changes/states.
I think an adaptive threshold technique was already discussed.
Design a special filter to enhance the squareness of the signal first. We could look into this.

I know by a known example that a comparator would do this but it's a cheap way of doing it so it may not be that reliable, and I am not sure what the minimum quality of the signal is required for it to work at all.

Wow, Thank you so much. Out of all your ideas the PLL and the FFT are the ones I haven't tried out yet. As you said the comparator hasn't been working reliably( the orange signal overlaying the blue is the comparator output) for my application which is why I want to look into alternatives. Thank you for the ideas. I've identified that I would need to make my signal for all this to work reliably to an extent.

 

But that's the thing. I need to find tau. I can't assume I know it

Have a counter running. Whenever you change the output, load the counter value, and subtract the previous counter value, that gives you the length of the pulse.

This works because Manchester coded signal start by sending a preamble which gives 8 short pulses in a row.

 

OK, it seems that Ian0 understands what I am talking about. What the Thread Starter must know is the scheme used to encode the data being sent. There are several different schemes, and in addition, there are different data packet formats used.
When translating a language, it is very useful to know what language one is translating from. Now looking at post #1, the TS has already told us: " The analog signal is manchester encoded "!! So now the challenge is to reliably sense the changes correctly. THAT will require discovering how to interpret MANCHESTER encoding and the data package format. THose analog variations are digital!!

 

But that's the thing. I need to find tau. I can't assume I know it

Wow, Thank you so much. Out of all your ideas the PLL and the FFT are the ones I haven't tried out yet. As you said the comparator hasn't been working reliably( the orange signal overlaying the blue is the comparator output) for my application which is why I want to look into alternatives. Thank you for the ideas. I've identified that I would need to make my signal for all this to work reliably to an extent.

Since I have moved recently, I was forced to go through a lot of old stuff I had laying around for years. I'll see if I can dig up that one solution with the comparator I think I ran across it somewhere. You could at least then investigate. It was used in a very successful device made many years ago, circa 1980. That's not to say that it was that great of a solution though

 

A "line receiver IC for "Manchester encoded format" data will be effective, an A/D converter is not likely to produce much relative to what was originally encoded. This sounds like either a college assignment OR the CIA wanting to examine intercepted communications.