smime.p7sDescription: S/MIME cryptographic signature
|
| From: | Neil Schafer |
| Subject: | Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync |
| Date: | Thu, 29 Sep 2016 13:41:52 -0400 |
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:address@hidden 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 <address@hidden> wrote:
|
smime.p7s
Description: S/MIME cryptographic signature
| [Prev in Thread] | Current Thread | [Next in Thread] |