On Mon, Jan 5, 2015 at 5:00 AM, Andy Walls <[email protected]> wrote:
> On Fri, 2015-01-02 at 09:56 -0800, Nick Foster wrote: > > > > I'm in the middle of generalizing correlate_and_sync_cc to allow use > > with any candidate vector you want (although I hadn't considered the > > real-only case). > > > --n > > Hi Nick, > > Since you're reworking the correlate and sync block, I thought you might > want to address some additional things I've found regarding the matched > filter generation. I've noticed 1 end-user pitfall that you may want to > document and 1 bug in how the matched filter is generated. > Great! Thanks! > > 1. Pitfall: The pulse filter tap specification requirments are not > obvious. In my experimentation over the weekend, the pulse filter taps > have to be generated assuming a rate of: > > nfilts samples/symbol, or equivalently > (nfilts * symbol_rate) samples/second > > where > > nfilts is the number of filters in the polyphase resampler > symbol_rate is the symbol rate in symbols/second > > regardless of the user's "sps" (samples/symbol) value. > > This is certainly the case for the real rectangular pulse with no ISI > and real half-sinusoid pulse with no ISI, with which I was playing. > > So, if nfilts = 32, these are my proper pulse filter taps specifications > in python: > > rectangular: [1.0]*nfilts > half-sinusoid: [math.sin(math.pi*float(i)/float(nfilts)) for i in > range(nfilts)] > > even though my sps = 13.3333. > > This was very non-intuitive and should be documented for the end-user. > Yeah, this annoyed me, too. The new system actually takes in unmodulated symbols, modulates them with the modulator of your choice, and then applies the (non-polyphase) filter taps of your choice to the modulated symbols. This way, you can pass the same symbols into (for instance) a GMSK modulator with the shaping filter taps set to [1] since GMSK typically needs no additional post-modulation filter, a PSK modulator with RRC taps for the channel, etc. The correlate_and_sync block in my branch doesn't take in symbols, but bits, and lets a modulator block (passed into it as an argument) handle the modulating. I'm avoiding the polyphase filter because I don't have to do resampling in the correlate_and_sync block. The caveats are: 1) Every digital modulator in GNURadio seems to use its own input data format -- packed or unpacked bits, signed vs. unsigned, NRZ or straight binary, etc. Your input vector has to be constructed to match the format the modulator expects. 2) Many of the modulators don't support fractional samples per symbol. There are of course workarounds, but I consider this a bug. > > > > 2. Bug: The generated matched filter appears to be short a symbol. > Using my real variant of correlate_and_sync, I specified the following: > > symbols: [1,0]*10 + [1,0,1,1,1,1] (block converts > these to NRZ) > pulse filter taps: [math.sin(math.pi*float(i)/float(32)) for i in > range(32)] > samples/symbol: 13.3333333333 > nfilts: 32 > > and the block generates the matched filter in the attached PNG. The > missing final symbol from the start of the filter is obvious. Since my > block is a very closely cut-and-paste clone of > correlate_and_sync_impl.cc and msk_correlate_impl.cc, the bug probably > exists in them as well. > Pretty sure my changes have obviated this bug but I'll check it out. My branch has bugs right now (mostly in tag alignment) but you can see it at https://github.com/bistromath/gnuradio/tree/msk_from_master. Suggestions and improvements of course welcome. Seems to me that we should collaborate on this, using my branch as a starting point. Still need to redo the test case and example, too. Attached is a working example showing the misalignment. Probably something simple but I was pulled away from working on it this weekend. --n > > > Regards, > Andy >
test_modulators.grc
Description: application/gnuradio-grc
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
