On Tue, May 31, 2011 at 4:56 PM, Colby Boyer <[email protected]> wrote:
> > > On Tue, May 31, 2011 at 1:46 PM, Tom Rondeau <[email protected]>wrote: > >> On Tue, May 31, 2011 at 4:37 PM, Colby Boyer <[email protected]>wrote: >> >>> Related. It seems that this delay is not taking in account for the MM >>> clock recovery block? It some cases, this delay will not matter (2 or 4 >>> samples per symbol), but for other rates it will. >>> >>> --Colby >> >> >> >> That's an excellent point. Any chance for a patch? :) >> >> Tom >> >> >> >> >>> On Tue, May 31, 2011 at 1:29 PM, Tom Rondeau <[email protected]>wrote: >>> >>>> On Tue, May 31, 2011 at 4:25 PM, Colby Boyer <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> On Tue, May 31, 2011 at 5:59 AM, Tom Rondeau >>>>> <[email protected]>wrote: >>>>> >>>>>> On Tue, May 31, 2011 at 2:13 AM, Colby Boyer >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Recently I've been using the MMSE interp filter. I found that when I >>>>>>> shift a signal by a fractional amount of 0 (or anything really), the >>>>>>> signal >>>>>>> goes way off! I would expect SOME difference, but not this much... >>>>>>> >>>>>>> Some example output. >>>>>>> >>>>>>> Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734) >>>>>>> >>>>>>> Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883) >>>>>>> >>>>>>> Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428) >>>>>>> >>>>>>> On the imgur links are two Re-Im scatter plots of a bpsk signal, one >>>>>>> with the fractional shift of 0 and the other with a fractional shift of >>>>>>> 0.1 >>>>>>> The points with 'x' are the resampled points and points with 'o' is the >>>>>>> original signal. As you can see, the mmse fractional interp more or less >>>>>>> destroys the signal! Unless I'm using it wrong!? >>>>>>> >>>>>>> Any comments? >>>>>>> >>>>>>> imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is >>>>>>> 0.1 delay. >>>>>>> >>>>>>> Thanks! >>>>>>> Colby >>>>>> >>>>>> >>>>>> >>>>>> Colby, >>>>>> This block has been around for years without any changes, and I and >>>>>> others have been successfully using it in various projects, so my guess >>>>>> is >>>>>> that you have some misconception about what it's doing or what the >>>>>> parameters are. >>>>>> >>>>>> You can see how it's used to simulate a timing offset in >>>>>> gnuradio-core/src/lib/hier/gr_channel_model.cc where it's used inside of >>>>>> the >>>>>> gr_fractional_interpolator_cc block. We also use it in the >>>>>> gr_clock_recovery_mm_XX and gr_mpsk_receiver_cc. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>> >>>>> Hi Tom, >>>>> >>>>> I looked at the issue again and I was not taking in account the group >>>>> delay of the interp filter (its 5 taps into the future or 3 in the past), >>>>> so >>>>> I was sampling a few taps out of phase! After a time shift, it passes the >>>>> sanity check of '0.0' delay. Thanks for the response! >>>>> >>>>> --Colby >>>>> >>>> >>>> Excellent, glad that worked out. I was pretty sure it works, but you >>>> never know... good to have extra confirmation. >>>> >>>> Tom >>>> >>>> >>>> >>>> >>> >> > Sure thing, perhaps later this week? I can submit all my patches at once > (this fix, gardner algorithm, multi-order loopfilter). > > --Colby > Excellent, thanks! So this gets into the question of how to best submit work to the project. There's some work being done now to help convey this information. I'll take the time now to comment on what you are proposing here. There are two main ways to best contribute code. The simplest is the patch and the more complex is creating a branch on a git server somewhere that I can then pull in and merge with our code. In this case, I would rather get the submissions done as three different git branches. The fix for the clock recovery loop _could_ be easily done as a patch, but if we're going all out on the other two items, it'll just make things simpler to do it all in the same way. The thing to do is start a github (or your-favorite-git-service-here) repo that is based on either my branch on github or the git master on gnuradio.org. The one from gnuradio.org will of course always be more up-to-date, but it sounds like there are nice visualization tools on github that would be more usable if you branched from me directly. I'll leave that up to you for now. We tend to like to see branches solve one particular problem. So you would have three branches here: one for the MM fix, one for the gardner loop, and one for the loopfilter work. I can then merge in the branches individually. This will help keep me organized, and each branch can be independently audited and tested. Just a note on the form of the branches, too. The MM fix and Gardner loop branch should be easy submissions because one is a simple internal fix and the other is a new block. This easily fits into the current API of the blocks and doesn't break anything. I'm not sure how you plan on implementing the work in the loopfilter branch, but if possible, make sure there is no change to the API of any blocks using it. Also, in this case, we shouldn't be changing the behavior of any of the blocks, just the code structure, so the PLL blocks should provide the same output given the same input as ever. We have QA code for each of the three PLL blocks in gnuradio-core/src/python/gnuradio/gr, so they should still pass after these changes are made. I hope that gives people some insight into how we think about things as we are working on the project. BTW, if there is a change in the API of a block, we would put that change into the next branch. Thanks! Tom
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
