A quick question, is there any way to do channel estimation on a (G)FSK receiver. I'm trying to build a DASH7 receiver.
I found that there is a block for a OFDM channel estimator, but i can't find it for FSK.
6
-
$\begingroup$ hm, honest question: What kind of channel estimate do you need for FSK? The whole point of using FSK instead of say PSK or QAM (or PSK or QAM in a multicarrier system like OFDM) is the simplicity of the receiver that doesn't require any phase information about the channel. Amplitude knowledge at the actually used frequencies is nice, but most FSK systems are designed to use channels narrow enough to be presumed flat, and then you need exactly no channel estimation at all. $\endgroup$– Marcus MüllerMay 15 '20 at 10:15
-
1$\begingroup$ GFSK is a constant envelope modulation. If you're doing noncoherent demodulation (as most do with FSK) amplify and clip after the IF filtering and before the FM discriminator to restore the constant envelope. Or use some other constant envelope restoration algorithm. Or after the FM discriminator, use an LNS algorithm against the known preamble and sync word to adaptively build channel equalization filter taps. None of this is available out of the box in GNURadio though. It's also all probably unnecessary as GFSK system are usually pretty narrow so the channel is usually pretty flat. $\endgroup$– Andy WallsMay 17 '20 at 9:35
-
$\begingroup$ I can only stress what @AndyWalls says; you don't estimate the channel, you just assume your SNR is robust enough for e.g. a periodicity-based frequency estimate or even simpler things like a delay-and-conjugate-multiply-then-decimate approach. $\endgroup$– Marcus MüllerMay 17 '20 at 12:58
-
$\begingroup$ @AndyWalls hm, amplify and clip is essentially binary slicing (for sufficiently large amplification), right? So, receive real-valued low IF, be sure to have removed DC (=HPF if necessariy), binary slice, then do a relaxed BPF to avoid the harmonics when subsampling (or choose IF so that subsampling leads to nicely aligned harmonics), subsample, gives you low multiply of f_sym stream of 0/1, use a moving average to make symbol decision. $\endgroup$– Marcus MüllerMay 17 '20 at 13:06
-
$\begingroup$ @MarcusMüller : The amplify and clip happens before the FM discriminator, so you're not making squared baseband symbols. Amplify and clip before the FM discriminator works because, with constant envelope modulations like FSK, all of the information is essentially in the zero crossings. So we can, in a sense, ignore channel fades by amplifying things up and then clipping. It doesn't get back the SNR losses that the fades caused, but one gets the constant envelope back rather easily. $\endgroup$– Andy WallsMay 17 '20 at 22:13
|
Show 1 more comment
$\begingroup$
TL;DR: Don't. Your system design implies the channel is flat, and hence you don't need a channel estimate. Spend your time on something else!
$\endgroup$
In FSK, you don't care about the frequency-varying phase properties of your channel – they simply don't matter to your signal, so a (relative) amplitude estimate for all mark frequencies would technically suffice.
Most FSK receivers don't even do that – it's only helpful to know that "mark frequency A gets through stronger than frequency B" if you use that to adjust your decision boundaries (e.g. for an MAP decision, you'd need that knowledge).
I don't have access to any DASH7 phy layer documentation, but if it's really derived from RFID tag technology, then you can be 100% certain the thing works without channel state information. Complexity wouldn't allow that. That doesn't mean you can't make it work better at further distances – but it does imply that if you're well within the specified ranges and environments, getting a channel estimate will not help you significantly much.
Wikipedia says "range up to 2 km, less than 200 kHz bandwidth", and that basically means your second observable multipath component would have to have a 1.5 km longer way to travel than the first one you receive – that is physically practically irrelevant, as that delayed version of the signal will be so much weaker than the quicker path that it can't lead to significant frequency-selectivity.
So the answer to your question is "you don't do that at all".
The rest of this answer, hence, is of merely academic interest:
Now, if your channel is actually strongly frequency-selective, so that knowing the relative amplitude becomes desirable, you can also be sure that the transition between different frequencies (which is Gauss shaped, transmitter-side) isn't nice anymore – and that's bad for your Gauss-expecting receiver.
Now, the only thing that could be FSK-specifically done here is some form of nonlinear emphasis on some values – that really doesn't sound very tempting, because estimating the necessary distortion to counteract the nonlinear memory-affected effect of a frequency selective channel on the FM demodulation of a frequency transition sounds pretty hard. And whenever possible, we try to compensate systems where they are linear – that gives us at least some guarantees about invertibility/well-posedness of the inverse problem.
So, don't try to deal with your FSK in any special way. Instead, just do what works for any transmission type:
- transmit something you know – for example, a preamble, or a known data packet – that is as white as you get with the given scheme (in this case: transmit pseudorandom white data through your GFSK transmitter)
- Correlate with that at the receiver
- Since that correlation will be mathematically equivalent to (noisy) convolution of your transmit signal's autocorrelation function and the channel impulse response: It's your channel estimate. You don't need it any better than that, because it excites exactly the frequencies present in your signal.
The first step – transmission of something you know – is in many systems done via a decision feedback equalizer, where "something you know" is what you received and decided for, but that means block-wise operation in an FSK case, since your system is not linear in modulation pulses, but has memory.
TL;DR: Don't. Your system design implies the channel is flat, and hence you don't need a channel estimate. Spend your time on something else!
answered May 17 '20 at 9:33