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 <hzhua...@gmail.com>: > 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 <hzhua...@gmail.com>: > > Oh, I forgot to say. The data is sampled by a RTL-SDR. >> >> Zhenhua >> >> >> 2014-03-13 11:25 GMT+08:00 zhenhua han <hzhua...@gmail.com>: >> >> Hi, >>> >>> I have implemented the algorithm in the paper for test and uploaded my >>> code to github. >>> >>> https://github.com/hzhua/gr-fchdetection >>> >>> 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 Diaconescu <b_diacone...@yahoo.com>: >>> >>> 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 Braun < >>>> martin.br...@ettus.com> wrote: >>>> On 03/11/2014 11:14 AM, zhenhua han wrote: >>>> > ---------- Forwarded message ---------- >>>> > From: *zhenhua han* <hzhua...@gmail.com <mailto:hzhua...@gmail.com>> >>>> > Date: 2014-03-11 16:00 GMT+08:00 >>>> > Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm >>>> > To: Bogdan Diaconescu <b_diacone...@yahoo.com >>>> > <mailto:b_diacone...@yahoo.com>> >>>> > >>>> > >>>> > 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. >>>> >>>> You should definitely check out the PFB channelization, though. For >>>> multi-ARFCN applications, this will always be a requirement. >>>> >>>> >>>> M >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
