# Fwd: Proposal for GSoC on gr-gsm

**URL:** <https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709>\
**Category:** GNU Radio\
**Created:** [March 11, 2014, 11:16am UTC](https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709 "2014-03-11T11:16:44Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\
**Post date:** [March 11, 2014, 11:16am UTC](https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709/1 "2014-03-11T11:16:44Z")

</div>

---------- Forwarded message ----------  
From: zhenhua han [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Date: 2014-03-11 16:00 GMT+08:00  
Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm  
To: Bogdan D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

Thank you, Bogdan. Your work is a great help in developing the channel  
hopping part.  
As there are only 14 weeks in GSoC, the schedule is a little tight.  
However, I will continue working on this project after GSoC (if I am  
selected). And Channel hopping will be the first task after I finish all  
the tasks planned in GSoC.

Best wishes,  
Zhenhua

2014-03-11 15:34 GMT+08:00 Bogdan D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

Hi Zhenhua,

---

<div class="post-metadata">

**Author:** ![zhenhua\_han](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d2c977/32.png) [@zhenhua\_han](https://www.ruby-forum.com/u/zhenhua_han)\
**Post date:** [March 11, 2014, 1:32pm UTC](https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709/2 "2014-03-11T13:32:07Z")

</div>

On 03/11/2014 11:14 AM, zhenhua han wrote:

> As there are only 14 weeks in GSoC, the schedule is a little tight.  
> However, I will continue working on this project after GSoC (if I am  
> selected). And Channel hopping will be the first task after I finish all  
> the tasks planned in GSoC.

You should definitely check out the PFB channelization, though. For  
multi-ARFCN applications, this will always be a requirement.

M

---

<div class="post-metadata">

**Author:** ![zhenhua\_han](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d2c977/32.png) [@zhenhua\_han](https://www.ruby-forum.com/u/zhenhua_han)\
**Post date:** [March 11, 2014, 2:42pm UTC](https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709/3 "2014-03-11T14:42:16Z")

</div>

I totally agree with Martin regarding PFB channelizer. The PFB for gsm  
will be also a good challenge for gnuradio in general as obtaining only  
a moderate number of channels(say 50) takes a lot of processing power  
and achieving realtime processing is not possible currently. Split per  
thereads and VOLK should be taken in consideration.

Bogdan

On Tuesday, March 11, 2014 2:30 PM, Martin B.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

On 03/11/2014 11:14 AM, zhenhua han wrote:

> As there are only 14 weeks in GSoC,  
> the schedule is a little tight.  
> However, I will continue working on this project after GSoC (if I am  
> selected). And Channel hopping will be the first task after I finish all  
> the tasks planned in GSoC.

You should definitely check out the PFB channelization, though. For  
multi-ARFCN applications, this will always be a requirement.

M

---

<div class="post-metadata">

**Author:** ![zhenhua\_han](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d2c977/32.png) [@zhenhua\_han](https://www.ruby-forum.com/u/zhenhua_han)\
**Post date:** [March 13, 2014, 4:26am UTC](https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709/4 "2014-03-13T04:26:32Z")

</div>

Hi,

I have implemented the algorithm in the paper for test and uploaded my  
code  
to github.

> **[GitHub - hzhua/gr-fchdetection: Detecting FCCH of GSM with GNU Radio](https://github.com/hzhua/gr-fchdetection)**
>
> Detecting FCCH of GSM with GNU Radio. Contribute to hzhua/gr-fchdetection development by creating an account on GitHub.

The result given by the algorithm seems great.

Here is a figure generated by my program which is the ratio of average  
error power to input power. It is very low at frequency burst and high  
at  
other bursts.  
[image: ǶͼƬ 1]  
I have also added this part in my proposal.

Best,  
Zhenhua

2014-03-11 21:41 GMT+08:00 Bogdan D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![zhenhua\_han](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d2c977/32.png) [@zhenhua\_han](https://www.ruby-forum.com/u/zhenhua_han)\
**Post date:** [March 13, 2014, 2:13pm UTC](https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709/5 "2014-03-13T14:13:42Z")

</div>

The figure in the previous mail is incorrect.  
It is too weird that the ratio is so low and with narrow transition. And  
the sample count is not match the FB.

After some debugs, I found the reason. I got the sample data with GNU  
Radio  
companion. When I execute the flow graph, it starts to write data into  
the  
file before my RTL-SDR started. So there are lots of invalid samples at  
the  
start.

I have fixed this bug. Here is a correct (maybe 🙂 ) figure. The sample  
rate is 1.25M sps. The FCCH burst lasts about 700 samples which equals  
0.56  
ms. The duration of a standard FB is 0.57 ms. It seems correct.

I have updated this part in my proposal. Sorry for my mistakes.[image:  
ǶͼƬ  
1]

Best,  
Zhenhua

2014-03-13 11:27 GMT+08:00 zhenhua han [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![zhenhua\_han](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d2c977/32.png) [@zhenhua\_han](https://www.ruby-forum.com/u/zhenhua_han)\
**Post date:** [March 16, 2014, 8:28am UTC](https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709/6 "2014-03-16T08:28:39Z")

</div>

Hi,

My proposal has been updated on github.  
The proposal has been changed a lot according to the comments on  
Melange.

1.The flow graph has been changed. A new architecture is designed.  
2.A state machine is added which explains more details on GSM decoder.  
3.The deliverable list has been changed.  
4.The schedule has been changed according to the new architecture.

Looking forward to further advises 🙂

Best wishes,  
Zhenhua

2014-03-13 21:12 GMT+08:00 zhenhua han [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![zhenhua\_han](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d2c977/32.png) [@zhenhua\_han](https://www.ruby-forum.com/u/zhenhua_han)\
**Post date:** [March 13, 2014, 4:28am UTC](https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709/7 "2014-03-13T04:28:59Z")

</div>

Oh, I forgot to say. The data is sampled by a RTL-SDR.

Zhenhua

2014-03-13 11:25 GMT+08:00 zhenhua han [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![zhenhua\_han](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/d2c977/32.png) [@zhenhua\_han](https://www.ruby-forum.com/u/zhenhua_han)\
**Post date:** [March 21, 2014, 4:18pm UTC](https://www.ruby-forum.com/t/fwd-proposal-for-gsoc-on-gr-gsm/239709/8 "2014-03-21T16:18:08Z")

</div>

Great thanks to all of you here and in melange! The content below is  
updated according to the advises above: 1.More details in time  
synchronization and burst extraction; 2.More details in using streamed  
tag  
to get more stable frequency resetting; 3.More details in frequency  
correlation; 4.A state machine is added;  
5.The structure of flow graph is changed; 6.New deliverable list and  
schedule; 7.More references.  
8.Deleted the words of promising some tasks after GSoC.

2014-03-16 15:27 GMT+08:00 zhenhua han [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):
