discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] The GMSK demodulation


From: Perper
Subject: Re: [Discuss-gnuradio] The GMSK demodulation
Date: Fri, 07 Mar 2014 12:46:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

W dniu 07.03.2014 06:06, zhenhua han pisze:
>
> 2014-03-04 21:55 GMT+08:00 Perper <address@hidden <mailto:address@hidden>>:
>
>     > 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
>     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
>     lists.gnu.org/archive/html/discuss-gnuradio/
>     <http://lists.gnu.org/archive/html/discuss-gnuradio/> .
>
>     --
>     Best Regards,
>     Piotr Krysik
>
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> Hi Perper,
>
> I'm writing the proposal to gr-gsm in GSoC.
> Would it be possible to let me to fix the frequency correction as a
> deliverable in my proposal ? 
> No matter if I get accepted in GSoC, I will finish this as a practice
> of coding.
>
> Best,
> Zhenhua
>
Hi Zhenhua,

I'm not a member of GNU Radio developers team, so I'm not deciding about
anything being accepted for GSoC.
In my opinion fixing frequency correction on its own is a too simple
task. I think that what is really needed is to solve the same problem
that the airprobe's gsm-receiver tried to solve in more modular and
easier to understand fashion by taking advantage of GNU Radio
capabilities such as stream tags and message inputs/outputs. What
gsm-receiver does is frequency offset correction, synchronization,
channel estimation and detetection of bits. You can think about clever
ways to separate those tasks into smaller blocks.

As of now only broadcasting channel can be received by airprobe.
Possible improvement would be implementation of reception of multiple
frequency channels transmitted by a given GSM BTS.

On a little higher level - you can also implement gnuradio blocks that
decode channel codes used in gsm using available sources such as
airprobe and osmocom.

Best Regards,
Piotr Krysik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]