Hi,
As I have known, GSM uses GMSK modulation which BT = 0.3 and it
uses Viterbi algorithm for demodulation. And I took a look at the code
of
GMSK demod code in GNU Radio, it use quadrature_demod but not Viterbi as
demodulation method. So which one is better in doing demodulating GMSK?
Moreover, GSM uses Viterbi algorithm to decode the convolution encoding.
Would it be possible to use quadrature_demod to demodulate GSM signal
instead of Viterbi? What about the convolution decoding part (maybe by
some
other method)?
Cheers,
Zhenhua
other method)?
I think you are mixing up the modulation and coding components.
At the transmitter, you first code (convolutional code), and then you
modulate (GMSK).
At the receiver, you first demodulate (quadrature demodulate) and then
you
decode (Viterbi).
Coding takes a stream of bits and converts it to another stream of bits.
Modulation refers to the process of converting the post-coded bits into
“symbols” that you will then send over-the-air.
best,
aditya
What confused me is the Viterbi algorithm. I saw it can be used to
demodulate GMSK in more than one place (such as here:
http://www.mathworks.cn/cn/help/comm/ref/comm.gmskdemodulatorclass.html
)
I think it’s better for me to read some materials of Viterbi and find
out
what really it is.
Cheers
Zhenhua
2014-2-28 10:40 “Aditya D.” [email protected]д
Hi Zhenhua,
as Aditya pointed out: Viterby is /not/ a demodulator.
You should read something on digital communication that explains the
difference between channel coding and modulation, then everything will
be clearer to you.
Greetings,
Marcus
Also as a side note, you can’t demod GSM and then slice it. You have
to demod it burst by burst so that you can lock to the training
sequence of each. So the demod block of GR is pretty much useless
here.
airprobe has a viterbi demod (which is probably one of the few good
part of airprobe to re-use).
Cheers,
Sylvain
On Fri, Feb 28, 2014 at 10:12 AM, Marcus M. [email protected]
wrote:
2014-2-28 10:40 “Aditya D.” [email protected] д
other method)?
Coding takes a stream of bits and converts it to another stream of bits.
Modulation refers to the process of converting the post-coded bits into
“symbols” that you will then send over-the-air.
best,
aditya
Actually, guys…
You can demodulate GMSK using the Viterbi algorithm.
Zhenhua,
We don’t implement this method in our GMSK demodulator, though I have
wanted to see someone do it. The Viterbi is the maximum likelihood
detector for GMSK, but it’s more complicated to implement. The
quadrature method we use is simple and intuitive but suboptimal.
Tom
I’m working on a generalized CPM demod based on Achilleas’s previous
work
in gr-trellis/src/examples/test_cpm.py, and I have it more or less
working
although there are plenty of little bugs to work out. Since the Viterbi
part was more or less worked out for me, synchronization is the hard
part;
my application isn’t GSM, and I’d like the solution in Gnuradio to be
applicable to a wide range of systems – this means closed-loop timing
and
freq synchronization instead of just doing data-aided estimates from the
preamble. I’ve implemented a timing synchronizer based on the D’andrea,
Mengali, Reggiannini paper following MATLAB’s example, and I’m using an
adaptation of the correlate_and_sync block to synchronize to (G)MSK
preambles.
Don’t know when I’ll have it ready to release (i.e. when the code isn’t
an
embarrassment to look at) but it’s Working In The Lab ™. It also
takes
quite a bit of setup to apply to each use case.
If you don’t need those extra few dB, it’s a whole heck of a lot simpler
both in implementation complexity and CPU cycles to just stick with the
existing noncoherent GMSK block. When I release code I’ll also release
an
updated noncoherent GMSK receiver block which uses the new timing
estimator, as the primary weakness of the existing GMSK block is timing
recovery.
–n
Nick,
Are you going to release the non-coherent timing recovery improvement as
a
separate block too (not baked into a GMSK hier block)? Thanks!
Very Respectfully,
Dan CaJacob
On Fri, Feb 28, 2014 at 11:51 AM, Nick F. [email protected]
wrote:
I’m working on a generalized CPM demod based on Achilleas’s previous work in
gr-trellis/src/examples/test_cpm.py, and I have it more or less working
although there are plenty of little bugs to work out. Since the Viterbi part
was more or less worked out for me, synchronization is the hard part; my
application isn’t GSM, and I’d like the solution in Gnuradio to be
applicable to a wide range of systems – this means closed-loop timing and
freq synchronization instead of just doing data-aided estimates from the
preamble.
I don’t have much to add, but Nick and Sylvain touched on the largest
difference between the Gnuradio GMSK demod and GSM/TDMA type burst
processing - and it’s not the Viterbi. The use of synchronization
loops (or lack thereof) in the demod is really the separating factor.
-TT
It’s already a separate block, so yes.
On Fri, Feb 28, 2014 at 1:54 PM, Nick F. [email protected]
wrote:
the loop gain pretty low and still acquire quickly. This is what Tom (R) is
doing with the correlate_and_sync and polyphase_clock_sync blocks, and it’s
what I’m doing in my MSK timing recovery block, although I’m still dealing
with a bug in that estimate. If you want to rely strictly on the timing
phase estimate of the preamble as in GMSK’s case you could just turn the
loop gain of your favorite timing sync block to zero and let it act as a
naive (and inefficient) decimator.
I wasn’t implying that a combined method couldn’t be done. But for
GSM, the assumption is that frequency sync is acquired separately
(with embedded tones), timing is derived from frequency, and Doppler
effects restricted (i.e. high speed train is not a supported use
case). Add in short durations before/after mid-amble and the benefits
of closed-loop timing begin to diminish.
Of course, these assumptions from GSM specification don’t extend to
the generalized case and collapse when we handle continuous signals.
That was really the only point I was trying to make.
-TT
On Fri, Feb 28, 2014 at 10:21 AM, Tom T. [email protected] wrote:
and
freq synchronization instead of just doing data-aided estimates from the
preamble.
I don’t have much to add, but Nick and Sylvain touched on the largest
difference between the Gnuradio GMSK demod and GSM/TDMA type burst
processing - and it’s not the Viterbi. The use of synchronization
loops (or lack thereof) in the demod is really the separating factor.
Sample tagging in GR makes it easier to have it both ways in this case.
If
you have a correlator block that outputs timing phase estimates based on
the preamble (or whatever), this should be used to initialize a
closed-loop
timing recovery block’s phase. For bursty transmissions this lets you
keep
the loop gain pretty low and still acquire quickly. This is what Tom (R)
is
doing with the correlate_and_sync and polyphase_clock_sync blocks, and
it’s
what I’m doing in my MSK timing recovery block, although I’m still
dealing
with a bug in that estimate. If you want to rely strictly on the timing
phase estimate of the preamble as in GMSK’s case you could just turn the
loop gain of your favorite timing sync block to zero and let it act as a
naive (and inefficient) decimator.
–n
W dniu 28.02.2014 15:31, zhenhua han pisze:
GSM signal instead of Viterbi? What about the convolution decoding
part (maybe by some other method)?
Cheers,
Zhenhua
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
Hello all,
Regarding usage of viterbi algorithm for maximum likelihood sequence
estimation in GSM - you may look at and try gsm-receiver that I once
submitted to airprobe. I’ve prepared version where I thrown out all of
decoding stuff and left only synchronization, channel estimation and
detection of bits with viterbi algorithm. It’s available for download in
here:
It compiles with newest gnu-radio and it has gnuradio companion xml file
as well. It can be easily connected to different sources in gnuradio
(file, rtl-sdr, usrp) and it has a message sink where burst bits and
gsmtap headers are sent. I’ve corrected some issues with synchronization
and turned off frequency offset correction that introduced instability
of the receiver. After compiling and installing you can start with
examples.
–
Best Regards,
Piotr K.
W dniu 28.02.2014 15:31, zhenhua han pisze:
GSM signal instead of Viterbi? What about the convolution decoding
part (maybe by some other method)?
Cheers,
Zhenhua
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
Hello all,
Regarding usage of viterbi algorithm for maximum likelihood sequence
estimation in GSM - you may look at and try gsm-receiver that I once
submitted to airprobe. I’ve prepared version where I thrown out all of
decoding stuff and left only synchronization, channel estimation and
detection of GMKS symbols with viterbi algorithm. It’s available for
download in here:
It compiles with newest gnu-radio and it has gnuradio companion xml file
as well. It can be easily connected to different sources in gnuradio
(file, rtl-sdr, usrp). I’ve corrected some issues with synchronization
and turned off frequency offset correction that introduced instability
of the receiver. There are examples of in the “examples” directory.
P.S. If someone applied Achilleas’s implementation of viterbi algorithm
from gnu-radio in GSM I’m very interested to see how it can be done.
–
Best Regards,
Piotr K.
Hi Perper,
I took a look at your code, and I found this
//set_frequency(d_freq_offset);
It seems you have turned off the the frequency offset correction as you
said.
Do you know the reason of the introduced instability by this part?
Best,
Zhenhua
2014-03-04 1:42 GMT+08:00 Perper [email protected]:
Hi guys,
I’m reading the code of Airprobe and I found this function.
double gsm_receiver_cf::compute_freq_offset(const gr_complex * input,
unsigned first_sample, unsigned last_sample)
{
double phase_sum = 0;
unsigned ii;
for (ii = first_sample; ii < last_sample; ii++) {
double phase_diff = compute_phase_diff(input[ii], input[ii-1]) -
(M_PI /
2) / d_OSR;
phase_sum += phase_diff;
}
double phase_offset = phase_sum / (last_sample - first_sample);
double freq_offset = phase_offset * 1625000.0 / (12.0 * M_PI);
return freq_offset;
}
It calculates the frequency offset with “freq_offset = phase_offset *
1625000.0 / (12.0 * M_PI);” I guess the (1625000.0/12*pi) equals
(1625000/6)/(2pi) and 1625/6 kbit/s is the modulation rate of GSM.
So, what is the principle of this calculation? How to calculate the
freq_offset with phase_offset. I tried some derivation but failed. Can
anyone help me to find out the derivation ?
Best wishes,
Zhenhua
2014-03-04 9:28 GMT+08:00 zhenhua han [email protected]:
2014-03-04 9:32 GMT+08:00 zhenhua han [email protected]:
for (ii = first_sample; ii < last_sample; ii++) {
Best wishes,
Zhenhua
BTW, this is a question I raised in my former email.(But no one
replied…).
Maybe, there is some relationship between the introduced instability
and
my question.
OK, I’ve got it.
Thank you for your help.
Cheers,
Zhenhua
2014-03-04 10:28 GMT+08:00 Tom T. [email protected]:
On Mon, Mar 3, 2014 at 8:32 PM, zhenhua han [email protected] wrote:
I’m reading the code of Airprobe and I found this function.
double gsm_receiver_cf::compute_freq_offset(const gr_complex * input,
unsigned first_sample, unsigned last_sample)
~
It calculates the frequency offset with “freq_offset = phase_offset *
1625000.0 / (12.0 * M_PI);” I guess the (1625000.0/12*pi) equals
(1625000/6)/(2pi) and 1625/6 kbit/s is the modulation rate of GSM.
So, what is the principle of this calculation? How to calculate the
freq_offset with phase_offset. I tried some derivation but failed. Can
anyone help me to find out the derivation ?
The offset is derived assuming the signal is a constant tone. The code
is averaging the phase shift between subsequent samples in a burst.
Frequency is the first derivative of phase with respect to time, so
the phase shift multiplied by the sample rate will give you the
frequency of the tone.
-TT
Best,
Zhenhua
Hi Zhenhua,
The reason of instability is in the method of correction of the
frequency offset.
The offset is computed inside of gsm-receiver gnuradio block and it is
fed to a frequency shifting fir filter.
The connection of the blocks look like this:
__freq. offset_____
| |
v |
xlating_fir_filter → gsm-receiver
There is lact of synchronization between computation of frequency offset
and its correction inside of xlating_fir_filter. Synchronisation in this
case is needed because the moment of computation of the estimate affects
it.
When new estimate of frequency correction is computed before previous is
applied the connection with frequency offset becomes additive feedback
loop.
This problem can be corrected by integration frequency correction inside
of the gsm-receiver or with use of stream tags.
Generally I would like to split gr-gsm into smaller blocks that are
easier to test but it will happen only if I find enough time for this.
P.S. for some reason I didn’t get your reply through my mailing list
subscription (together with many more missing messages)…
I’ve found it through the webpage
discuss-gnuradio Archives .
–
Best Regards,
Piotr K.