Hi Usman,
I just verified that a raised cosine filter used for the pfb clock sync taps will effectively shape a square wave and allow the synchronizer to properly track the symbol timing. I wanted to be sure before I continued to push anybody else down this path (now also verified by John, albeit the results are not ideal enough for his purposes). As you probably know, raised cosine filters are typically used to pulse shape a digital baseband signal (the square wave) before transmission. A raised cosine minimizes inter-symbol interference and narrows the transmitted bandwidth of the signal. It also provides that nice, modulated signal shape with easily identifiable peaks when viewed in the time domain. Many communication systems actually share the responsibilities of the pulse shaping by using the root raised cosine (RRC) filter. One of the benefits of this is that it allows a receiver to detect the optimal symbol timing by correlating the received signal with its own matched RRC pulse shaping filter, while also generating the optimal raised cosine filter as a result of the two shared operations. The PFB clock sync is designed to take advantage of this. In addition to tracking optimum symbol timing, the pfb clock sync is actually performing the receiver-side RRC matched filtering as well. It performs the symbol timing by comparing the outputs of the RRC matched filter and the derivative of the RRC matched filter. At the ideal sampling point for a symbol, the RRC matched filter output should be at a peak, and the derivative filter should be at 0, resulting in a timing error of 0. When the symbol timing isn’t perfect, the combination of the two outputs informs the clock synch whether to advance or delay the symbol timing (in this case, really just a change in the phase of the filter bank). In the case of the rectangular pulse shape, this is actually unusual since you’re unlikely to actually see such a thing wirelessly transmitted. Although it’s not impossible. An OOK signal could be detected at a receiver and translated to a square wave at the digital domain. In this case, you would be in a position of having demodulated a square wave without having recovered the symbol timing. All of this is a roundabout way of getting to what I meant when I said the suitably vague “the end result should be the same.” What I meant was the using a raised cosine filter in the pfb clock sync on a rectangular pulse should be “the same” as performing the typical RRC on that same square wave at the transmitter and then again on the receiver. The raised cosine filter acts as a differentiable filter that the pfb clock synch will apply to pulse shape the signal and identify timing error. I did not mean to imply that applying a raised cosine would be “the same” as applying a square wave matched filter. As Paul and Andy already pointed out, a pfb clock sync can’t use a square wave as its filter, since the output of the differential filter will be useless. I was only trying to describe how to manipulate the pfb clock sync filter taps to allow it to be used to recover symbol timing of a square wave. As John found and pointed out, applying any non-rectangular filter to a square wave will introduce implementation loss. However, given the constraints of this particular set up, I would argue his results are still pretty good. They might also be improved by increasing the length of the filter and maximizing the rolloff factor, but I’m not sure what specific taps he used in his implementation. Hope this helps, Neil From: Usman Haider [mailto:usmanhaide...@gmail.com] Sent: Thursday, September 29, 2016 10:47 AM To: Neil Schafer <neil.scha...@nrl.navy.mil> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync Hi Neil, Can you please share some more details on how the end result could be same? Regards, Usman On Wed, Sep 28, 2016 at 6:41 PM, Neil Schafer <neil.scha...@nrl.navy.mil <mailto:neil.scha...@nrl.navy.mil> > wrote: I haven’t tried it myself, but wouldn’t using a raised cosine or Gaussian filter for your taps still provide some pulse shaping for the PFB clock sync to track? You’re essentially leap-frogging the RRC matched filters at transmitter and receiver, and placing the entire burden at the receiver, but at the decision point of the clock synch the end result should be the same. Neil From: Discuss-gnuradio [mailto: <mailto:discuss-gnuradio-bounces%2Bneil.schafer> discuss-gnuradio-bounces+neil.schafer= <mailto:nrl.navy....@gnu.org> nrl.navy....@gnu.org] On Behalf Of Garver, Paul W Sent: Wednesday, September 28, 2016 7:49 AM To: John Malsbury < <mailto:jmalsbury.perso...@gmail.com> jmalsbury.perso...@gmail.com> Cc: <mailto:discuss-gnuradio@gnu.org> discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync I have tried to use PFB clock sync without success on rectangular pulses as well. Presumably you've seen the documentation [1] on nfilts and taps. I tried making the filter a rectangular pulse with x sps upsampled by nfilts. One theory I have is that the polyphase clock sync may not work with rectangular pulses. If you read the paper, the derivative of the pulse is required. Perhaps that's a problem since for typical RRC pulses the derivative is well defined but for a rectangular pulse the derivative is 0. [1] http://gnuradio.org/doc/doxygen/page_pfb.html Paul Garver On Sep 28, 2016, at 3:09 AM, John Malsbury <jmalsbury.perso...@gmail.com <mailto:jmalsbury.perso...@gmail.com> > wrote: I'm struggling with something pretty basic. I am trying to achieve near theoretical performance detection of a rectangular (no RRC) QPSK signal at 2 or 4 sps. I have an existing solution that uses a discrete FIR filter followed by a Gardner timing recovery loop. The taps of the FIR filter are a box car function. It works quite well and implementation loss is negligible. However, I'd like to achieve the same thing using the stock PFB clock sync. For the life of me I can't figure out the proper specification of nfilts, and taps. Given a signal with rectangular pulse shape at 'sps', can someone spell out the taps and nfilt i need to enter into PFB clock sync for a properly matched filter bank? -John _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
