Johannes, I really appreciate the response, I know you're busy with your SOCIS project.
I'm actually struggling with sync_freq_c_impl.cc, the CP-based FFO sync block. I've tried to do some reading on FFO techniques, but I'm kind of spinning my tires. I've modified the block to take a usrp_source pointer, but I'm struggling to understand "the fancy stuff": (https://github.com/kit-cel/gr-lte/blob/master/lib/sync_frequency_c_impl.cc#L157) // The next line does the fancy stuff -> calculate the frequency offset. float f_off = arg(corr_val[pos]) * float(float(d_samp_rate)/(2*M_PI*float(d_fftl) ) ); d_f_av=d_f_av - (0.01 * f_off); //f_vec.push_back(d_f_av); (*d_sig).set_frequency((-1)*double(d_f_av) ); So right now I have something like this: // The next line does the fancy stuff -> calculate the frequency offset. float phase = std::arg(corr_val[pos]); float f_off = phase * float(float(d_samp_rate)/(2*M_PI*float(d_fftl) ) ); d_f_av = d_f_av - (0.01 * f_off); float new_tune_freq = -1 * static_cast<float>(d_f_av); printf("%s tuning new frequency: %f, LO offset: %f\n", name().c_str(), new_tune_freq, d_lo_offset); ::uhd::tune_request_t tune_req(new_tune_freq, d_lo_offset); d_tune_result = d_usrp->set_center_freq(tune_req); Obviously I should be using DSP-only tuning, but right now my confusion is in the value I'm getting for "new_tune_freq". I'm getting lines like this: sync_frequency_c tuning new frequency: -289.257874, LO offset: 7680000.000000 sync_frequency_c tuning new frequency: -296.508209, LO offset: 7680000.000000 sync_frequency_c tuning new frequency: -303.749878, LO offset: 7680000.000000 Goes up by about 7 hertz (?) each time. Is this an offset from my original tuned frequency (~751000000 Hz) or what? Just not sure how to use this. Any help/hints/pointers-to-required-reading much appreciated. -Doug ________________________________________ From: discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org [discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org] on behalf of Johannes Demel [uf...@student.kit.edu] Sent: Thursday, June 25, 2015 9:15 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] gr-lte vs gr::digital::ofdm* Hey Doug, there are a few differences between gr-ofdm and gr-lte. When I started the project, gr-ofdm wasn't available. Later on I tried to use an API as similar as possible to gr-ofdm. Though, gr-lte is designed for FDD mode. That being said, it is quite a difference to gr-ofdm which is primarily designed for bursty transmissions. Also the LTE standard includes a few tricky parts. Those include different CP lengths in every slot, different sync symbols which carry further system information and dependencies between those parts. e.g. you need to detect the correct PSS symbol first in order to be able to do anything useful with the SSS. Also, there are always 2 different SSS symbols depending on the position within each frame. And their position in a frame is not right at the beginning of a frame. If you have specific questions about parts of the flowgraph, just ask. Cheers Johannes On 24.06.2015 18:07, Martin Braun wrote: > On 24.06.2015 08:48, Anderson, Douglas J. wrote: >> Lately I've been working with gr-lte and trying to use some of >> those blocks in my own application (not grc). >> >> I'm still in the learning phase about ofdm/lte, and I'm >> struggling with the lack of documentation or comments in gr-lte. >> >> I think I would prefer to use GNU Radio's built-in OFDM blocks >> for time/freq sync, CP removal, etc, and then lean on gr-lte >> blocks for decode/unpack operations. >> >> My question is, is that practical? gr-lte uses a flowgraph like: >> >> source -> cp-based timing sync -> lte PSS sync -> cp-based freq >> sync -> LTE SSS sync -> lte esimator -> decode stuff... >> >> Are the gr::digital::ofdm* blocks too generic to understand >> things like LTE's primary and secondary sync symbols? > > Hi Doug, > > that's a big part of it. However, another part was that Johannes > was writing gr-lte while the OFDM subsystem was still maturing. I'm > sure at this point we could achieve more synergy between the > projects. > > Johannes hopefully has more insight he can provide. > > Cheers, 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
