RF Symbol Recovery and Nyquist Criterion / General Science and Electronics / Forums

Forums

4hv.org :: Forums :: General Science and Electronics

« Previous topic | Next topic »

RF Symbol Recovery and Nyquist Criterion

Move Thread

LAN_403

deef

Fri Jun 10 2011, 07:09PM

Registered Member #207 Joined: Sat Feb 18 2006, 05:14PM
Location:
Posts: 45

Hello,

I'm praying to the RF gods, here. Lets see if someone can fill in a couple holes in my understanding.

I am designing a circuit to recover data symbols from a FSK modulated RF signal. However, it seems my understanding has lead me into a couple brick-walls of confusion. Also, it seems my knowledge of sampling continuous time signals isn't what it used to be. Here's my situation.

Carrier Frequency: 2.25 MHz (it's actually a down converted IF frequency)
Symbol Rate: 4800 symbols per second
Operational Bandwidth: 12.5 KHz

Note: The operational bandwidth is determined not only by the FSK modulation scheme, but by filtering that is done prior to transmission. Regardless, the signal is specified to fulfill an emission mask of 12.5 kHz bandwidth on the carrier.

I'm not sure how I should go about sampling my continuous wave such that I can recover the digital data portion of it. Not to mention, what should my minimum sampling rate be to prevent aliasing? The Nyquist criterion reflects that I should sample the data at a frequency of at least twice the signal bandwidth.

- Does that mean I should be sampling at least 25,000 times per second (2 times 12.5 kHz)? Or, is it based upon the symbol rate (2 times 4.8kHz)?

- The digitizing sub-system I've put together that's responsible for digitizing the RF data provides me with I/Q data at a clock rate of 18 MHz (eg: 18 million samples per second), but it's tied into an adjustable decimation stage. Should my decimation stage be set to capture I/Q data at a rate of 25,000 times per second to fulfill the nyquist criterion? (eg: 18MHz / 720 = 25k)

How is digitization normally done? Anyone have any good links or resources for this kind of thing?

I appreciate it!

Dr. Slack

Sat Jun 11 2011, 02:17PM

Registered Member #72 Joined: Thu Feb 09 2006, 08:29AM
Location: UK St. Albans
Posts: 1659

It all depends ...

Assuming your symbols are aligned and ISI-free, the final sampling rate only has to be 4800

However, if they are not aligned, but still ISI-free, it's quite usual to sample at 9600, and use the half-sample times to servo the sampling times into alignment.

If they aren't ISI-free, eg the transmitter has applied some sort of filtering, then you will need to inverse filter, and you will need to sample at over twice Nyquist, or north of 25kHz.

That's all assuming you have a nice clean channel. If you want to filter out your wanted channel fom noisy djacent channels, then you will need to sample at more than twice the total bandwidth of all the channels that are getting through your IF filter with significant energy.

How are you down-converting from your 2.25MHz IF? Analogue to IQ basebands, sub-sampling at a suitable sub-mutliple+0.25 of the IF, sampling at 9MHz (so the IF is fs/4 for convenient downmix?

deef

Sun Jun 12 2011, 08:26PM

Registered Member #207 Joined: Sat Feb 18 2006, 05:14PM
Location:
Posts: 45

Thanks for the information, Dr. Slack. That's exactly what I was looking for.

There's a significant receiver front end prior to the digitization of my IF at 2.25MHz, so I *shouldnt* need to worry about adjacent channel interference, or any noise from outside the operational bandwidth of channel I'm interested in. However, thanks for reminding me that inverse filtering is required. What I'm receiving will be far from ISI-free. Thus, inverse filtering will definitely need to be applied.

I'm converting from my 2.25MHz IF using a stand-alone digitizing subsystem IC from Analog devices. It does the analog to digital conversion, then translation into I-Q data automatically. It also provides decimation if need be. I've chosen a sampling clock of 18MHz for my 2.25MHz IF signal. My question about sample rate was an attempt to figure out how much further I should decimate my signal down from the native 18MHz sample clock.

Thanks again for your help, Dr Slack.

I guess the next step is compensation for imperfect carrier and sampling frequencies (eg: the reality of my IF not being *exactly* 2.25MHz, or my sampling clock not being *exactly* 18MHz). I suppose I'll have to come up with an algorithm that compensates my I-Q data. Otherwise, I wouldn't be seeing the same part of the IF frequency each time I take a sample. I assume this would help any phase noise issues or frequency jitter issues I have in my IF and sampling clocks as well... then onto the inverse filter, etc.

Does that seem reasonable?

Dr. Slack

Tue Jun 14 2011, 06:10AM

Registered Member #72 Joined: Thu Feb 09 2006, 08:29AM
Location: UK St. Albans
Posts: 1659

I notice that your chosen 18MHz sampling is an integer multiple of 4800. That's convenient, but not essential.

I would assume that the clock frequency is more or less right, decimate to your channel bandwidth of >25kHz, then do the ISI filter, then do symbol timing recovery. Even without doing clock frequency sync you can assume that your symbols will stay in sync for many 100s or 1000s of symbols, assuming even modest accuracy for the 18MHz and the 4800, which is job done if the data is bursted, or nearly done if it's continuous.

Of course most of this is buried in your doozy AD chip. I'm sure they have app notes on how to use it. Any advice I gave would be based on first principles, which might all be moot if the chip contains everything you need to get from RF to bits.

deef

Wed Jun 15 2011, 01:27PM

Registered Member #207 Joined: Sat Feb 18 2006, 05:14PM
Location:
Posts: 45

Thanks again for your help, Dr Slack. You're right. I'm lucky enough to have *most* of the grunt work done in the chip.

Taking this thread slightly off topic now: Do you have any suggestions for forming my inverse filter? Obviously, I have the coefficients of the filter that encodes the symbol stream to baseband (prior) to transmission. And, I'm at the step, with respect to receiving and demodulation, that I have access to baseband, again.

However, I can't seem to turn my baseband back into a symbol stream effectively.

My encoding filter isn't anything fancy, it's simply a raised cosine filter. Google provides a lot of good links for filtering with a RCF, but not too much on inverse-filtering.

Does anyone have any experience with this?

Dr. Slack

Wed Jun 15 2011, 06:43PM

Registered Member #72 Joined: Thu Feb 09 2006, 08:29AM
Location: UK St. Albans
Posts: 1659

A raised cosine filter is ISI-free, so no inverse filter to design.

If you have FSK at baseband, it's not going to look obviously like data. You will need to demodulate it to frequency, or to phase changes, and sample those.

deef

Thu Jun 16 2011, 07:20AM

Registered Member #207 Joined: Sat Feb 18 2006, 05:14PM
Location:
Posts: 45

Yeah, sorry. When I was referring to ISI earlier, I was intending to convey some value of sampled baseband that sits between two symbol states due to the "blending" (in the time domain) a raised cosine filter does. I understand this isn't the conventional understanding of ISI. And I agree that a raised cosine filter would remove ISI from a circuit. The way I was referring to it was not correct.

I mean, with a symbol rate of say 4800 symbols per section, if I were able to sample my baseband at *exactly* center symbol, I would receive a value that is directly proportional to whichever symbol was received at that time. However, if my sampling time is off, I'll be capturing some value that is "off symbol".

And, as you mentioned, due to the "lowpass" nature of a raised cosine filter, there's really nothing I can do to restore a perfect series of impulse functions, versus time, that represent my symbol stream. Naturally, this is because I would have to make an "inverse filter" that adds an infinite number of high frequency components to my baseband signal. Thus, undoing the raised cosine.

However, I was hoping there was something I could do such that it would be easier for me to determine center symbol. Or at least a different approach.

Even if I "demodulate it to phase changes", if i'm not sampling my baseband at center symbol, i'm going to be at some intermediate between-symbol state that isn't easily resolvable to the reality.

Am I way out to lunch here?

I appreciate your patience :)

Dr. Slack

Thu Jun 16 2011, 04:45PM

Registered Member #72 Joined: Thu Feb 09 2006, 08:29AM
Location: UK St. Albans
Posts: 1659

It's not so much that a rasied cosine filter removes ISI, it's that it doesn't add it. When a link has to work at maximum efficiency, most bits per occupied Hz and most receiver resistance to noise, a root riased cosine is used at both transmitter and receiver. The product of both filters is then a raised cosine, meeitng the ISI free criterion.

The official way to servo your sampling instants onto the correct symbol timing is to use a "Costas Loop". All professionals do it like this. Wikipedia has an entry on it, but it's far too vague to be useful. It points to other papers which might be more help, though a quick look at the "practical" one looked heavy going, and was for BPSK rather than FSK. The principles are the same, but it's one removed from what you need.

However, it turned out that many moons ago, before I'd met said loop, I had to demodulate some data, and invented what I called the "velocity method", which is rather more intuiitive. Sample the demodulated signal at perhaps 10x the symbol rate, then plot its absolute rate of change against a time axis modulo the symbol period. The method is based on the observation that the speed will tend to peak mid-way between symbols, and will be lower, or zero, depending on the data, at the symbol sample points. Once you've collected data for several 10s of symbols, the pattern will emerge, and you can adjust your sampling times accordingly.

In retrospect, the velocity plot is just the differential of the better-known eye-diagram, which also shows you where to sample.

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob