# Failure of sending square wave over USRPs (back-to-back) **URL:** \ **Category:** GNU Radio\ **Created:** [March 14, 2014, 5:34am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781 "2014-03-14T05:34:38Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [March 14, 2014, 5:34am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/1 "2014-03-14T05:34:38Z")
Dear Sir, I try to send square wave from one USRP to another. The received signal at the receiver USRP is very different from what was being sent. This is just a very simple setup. What could be wrong …? ## Setup: There are two N210 USRPs with SBX daughtercards, connected back-to-back using direct cable with a 30dB attenuator. In the transmitter flow graph, there is one Signal Source feeding complex signal to USRP Sink. In the receiver flow graph, there is one USRP Source feeding complex signal to WX GUI Scope Sink. The pictures of WX GUI Scope Sink are attached. ## Blocks setting: Signal Source Block in the transmitter flow graph: Sample Rate: 32k Waveform: Square Frequency: 100 Amplitude: 1 Offset: 0 USRP Sink in the transmitter flow graph: Samp Rate(Sps): 32k Ch0: center Freq(Hz): 400.0045e6 (after calibration) Ch0: Gain (dB): 0 USRP Source in the receiver flow graph: Samp Rate (Sps): 32k Ch0: Center Freq (Hz): 400M Ch0: Gain (dB): 0 ## Software version: Transmitter PC runs gnuradio 3.7.2.1 on debian 7.4 (32bit) using Dell PC. Receiver PC runs gnuradio 3.7.2.1 on Ubuntu 13.10 (64bit) using iMac hardware. Please advise, thank you very much. Regards, Activecat Email: removed\_email\_address@domain.invalid ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 14, 2014, 7:18am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/2 "2014-03-14T07:18:44Z")
Hi, > I try to send square wave from one USRP to another. > The received signal at the receiver USRP is very different from what > was being sent. > This is just a very simple setup. What could be wrong ..? Apparently your understanding of how things work 🙂 First thing, square waves have infinite bandwidth, the DAC can’t generate them properly, the ADC can’t capture them properly and they’ll be modified by the IF filters. The effect of that is to “round off the edges”. And since you sample at 32k, that’s probably going to be fairly visible. Then the second and major thing is that I & Q aren’t magically transmitted and received perfectly aligned. Unless you use the _exact_ same totally phase aligned LO and ensure the propagation delay to have the ADC sample exactly on your DAC transmitted symbols, the I & Q you receive won’t be the I & Q you transmit, you’ll have random time and phase alignement. That’s kind of why people use modulation rather than TX raw binary waveforms. Cheers, ``` Sylvain ``` ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 14, 2014, 7:56am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/3 "2014-03-14T07:56:29Z")
Dear Sylvain, > On Fri, Mar 14, 2014 at 2:17 PM, Sylvain M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > First thing, square waves have infinite bandwidth, the DAC can’t > generate them properly, the ADC can’t capture them properly and > they’ll be modified by the IF filters. The effect of that is to “round > off the edges”. I am using Ettus SBX daughtercard at the transmitter USRP to transmit complex square wave (means the signal is in IQ form). [https://www.ettus.com/product/details/SBX](https://www.ettus.com/product/details/SBX) I understand that SBX performs quadrature up-conversion automatically, and this feature cannot be disabled. Hence, the signal sent to the transmitter antenna is no longer square waves, but IQ up-converted signal. That’s why I guess the “round off the edges” effect is no longer applicable here. At the receiver side, another SBX daughtercard should have automatically down-converted the signal back into IQ form. Here I expect the signal output from SBX become (nearly) square wave. > And since you sample at 32k, that’s probably going to > be fairly visible. I repeat the test with sampling rate changed to 1MHz at both sides, this gain similar undesirable result. > Then the second and major thing is that I & Q aren’t magically > transmitted and received perfectly aligned. Now I am focusing on the frequency and phase alignment issue. Thank you very much. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 2:55am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/4 "2014-03-15T02:55:02Z")
Dear Johnathan, On Fri, Mar 14, 2014 at 2:21 PM, Johnathan C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > In spite of “calibrating” things, you have only made the transmitter and > receiver local oscillator frequencies “close”. All real-world receivers > must implement a correction loop to estimate this frequency and > compensate for it, which eliminates the rotation. This correction loop > often takes the form of a phase-locked loop, of which there are several > in GNU Radio. For the type of waveform you are transmitting, the “PLL > Carrier Tracking” loop should work, as your baseband waveform results in > significant carrier energy when upconverted to passband. I was told that the Ettus SBX daughtercard has built-in PLL capability. In this case is the flowgraph-based PLL still necessary ..? Refer below message from Ettus support engineer. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 12:25am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/5 "2014-03-15T00:25:36Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 3:17am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/6 "2014-03-15T03:17:38Z")
On 14.03.2014 09:50, Activecat wrote: > In this case is the flowgraph-based PLL still necessary ..? > Refer below message from Ettus support engineer. Hi Activecat, our synthesizers use PLLs, but this won’t solve frequency offset issues with your transceiver. This is not a limitation of USRPs, but fundamentally necessary in every receiver. Here’s a very brief explanation: The PLL for the synthesizer makes sure the locally generated frequency is stable (per-device). It’s physically impossible to make perfectly aligned oscillators. By throwing money at the problem, you can reduce the potential offset. But since you can never get rid of it entirely, you also need a mechanism (e.g. a PLL) to lock on the incoming signal. Phase is another story. Even in a world with perfect oscillators, your phase can be rotated. That’s something else you have to account for. Have a look at the examples in gr-digital/examples/demod. You’ll see many mechanisms to correct offsets between tx and rx (time, phase and frequency). These are all standard components for digital transceivers. Martin ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 4:15am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/7 "2014-03-15T04:15:35Z")
On 03/14/2014 10:51 PM, Activecat wrote: > daughtercard before being sent it to the host (which is the PC). > Activecat > > * * * > > Discuss-gnuradio mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) > The SBX does analog downconversion, nothing more. It knows nothing > about the incoming signal, and doesn’t demodulate it in any way. That is what SDR is all about–the signals are represented as complex-baseband (i/Q) format for processing by computer algorithms. The SBX (or any other daughtercard) is simply doing downconversion (or, upconversion for TX). Frequency offset in a digital demodulator implemented in software generally drives a local correction–not the hardware. You achieve this by bringing in a bit more bandwidth than you actually need, and then applying frequency corrections in software. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 5:12am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/8 "2014-03-15T05:12:59Z")
Dear Marcus, On Sat, Mar 15, 2014 at 11:14 AM, Marcus D. Leech [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > The SBX does analog downconversion, nothing more. It knows nothing about > the incoming signal, and doesn’t demodulate it in any way. Please be clarified what do you mean by “analog downconversion”. At the transmitter side, complex-based (I/Q) signal is fed into USRP. Says, the signal is x(t) = I(t) + j.Q(t) I think this is performed at transmitter SBX: y(t) = I(t).cos(wt) - Q(t).sin(wt) where w = central frequency, t = time here the y(t) is the output of SBX to the antenna. Is this what you meant by “analog upconversion” ? Whereas at the receiver side, the received signal from antenna is real signal, says, z(t) = c.y(t) = c.I(t).cos(wt) - c.Q(t).sin(wt) where c = channel attenuation The receiver SBX performs this: Retrieved I(t) = LPS( z(t).cos(wt) ) where LPS = low pass filter Retrieved Q(t) = LPS( z(t). sin(wt) ) With this process the receiver SBX is able to produce complex-based (I/Q) signal from the real signal from antenna. Is this what you meant by “analog downconversion”? If not, please describe what you mean by “analog upconversion” and “analog downconversion”, because I have no idea of what you are trying to explain. It is impossible that SBX only mix the incoming complex-based signal with a central frequency and then send directly to antenna for transmission, because the simple mixing (analog upconversion) produces another complex-based signal which cannot be transmitted through antenna. A physical antenna can only transmit real signal, not complex-based signal. Please clarify, thanks. Regards, Activecat ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 4:03am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/9 "2014-03-15T04:03:59Z")
Dear Martin, On Fri, Mar 14, 2014 at 5:13 PM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Here’s a very brief explanation: The PLL for the synthesizer makes sure the > locally generated frequency is stable (per-device). It’s physically > impossible to make perfectly aligned oscillators. By throwing money at the > problem, you can reduce the potential offset. But since you can never get > rid of it entirely, you also need a mechanism (e.g. a PLL) to lock on the > incoming signal. At the receiver side, the received signal is first processed by SBX daughtercard before being sent it to the host (which is the PC). The IQ demodulation is performed at the receiving SBX, not at the host. In this case the clocking of SBX must be synchronized to the received IQ-modulated signal. Hence the PLL must be done precisely in the SBX, not in the host, correct? If the PLL is done at the gnuradio flow graph, then this flow graph must be able to adjust the local oscillator of the SBX daughtercard, via softare. Does gnuradio flow graph have this capability? Regards, Activecat ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 5:39am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/10 "2014-03-15T05:39:16Z")
On 03/15/2014 12:10 AM, Activecat wrote: > y(t) = I(t).cos(wt) - Q(t).sin(wt) where w = central frequency, t = time > With this process the receiver SBX is able to produce complex-based > real signal, not complex-based signal. > > Please clarify, thanks. > Regards, > Activecat The term “upconversion” and “downconversion” are common terms used in the radio engineering industry, but may not be common among other technical folks. The complex upconverter simply sums the two components after mixing, to produce a valid real-valued analog signal. But, again, none of the daughtercards that Ettus produces are designed to extract _information_ from the signal–they merely manipulate it so that it is represented in a complex baseband form that can easily be digitized by the ADCs. One impresses _information_ on an RF carrier by modulating it–doing “stuff” to that carrier so that the information can be recognized by a suitable receiver. There are hundreds of different ways of doing this, depending on the required attributes of the resulting signal, etc. You square-wave example is roughly similar to so-called OOK–on/off keying. Such techniques are generally only used for very-low-speed data transmission, owing to the unpleasant spectral properties of signals with sharp edges. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 7:59am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/11 "2014-03-15T07:59:32Z")
Dear Marcus, Please avoid adding more confusions rather than clarities. > The term “upconversion” and “downconversion” are common terms used in the > radio engineering industry, but may not be common among other technical folks. In radio engineering industry, there are more than 1 type of upconversion or downconversion. The common types include: a). analog up-conversion: The baseband real signal x(t) will be mixed with a carrier frequency, that its output is a real signal of y(t) = x(t).cos(wt) where w = central frequency b). complex up-conversion: The baseband complex-based signal x(t) = I(t) + j.Q(t) will be quadrature upconverted so that its output is a real signal of y(t) = I(t).cos(wt) - Q(t).sin(wt) For clarity sometimes we need to clarify which one you were referring to. These two (analog vs complex upconverter) are significantly very different from each other. > The complex upconverter simply sums the two components after mixing, to > produce a valid real-valued analog signal. Are you saying SBX performs this complex upconversion? But earlier you said SBX just performed analog upconversion and nothing more. > But, again, none of the daughtercards that Ettus produces are designed to > extract _information_ from the signal–they merely manipulate it > so that it is represented in a complex baseband form that can easily be > digitized by the ADCs. You are saying the output of SBX is in complex baseband. This means SBX perform complex down-conversion. But earlier you said SBX performed just analog down-conversion and nothing more. > One impresses _information_ on an RF carrier by modulating it–doing “stuff” > to that carrier so that the information can be recognized by > a suitable receiver. There are hundreds of different ways of doing this, > depending on the required attributes of the resulting signal, etc. Are you saying SBX daughtercard will automatically select the correct way depending on the received signal? In my flow graph there is no configuration to tell the SBX which way to use. > You square-wave example is roughly similar to so-called OOK–on/off keying. > Such techniques are generally only used for very-low-speed > data transmission, owing to the unpleasant spectral properties of signals > with sharp edges. There are no documentation of what SBX performs on incoming or outgoing signals. [https://www.ettus.com/product/details/SBX](https://www.ettus.com/product/details/SBX) If Ettus support personnel doesn’t clear things up, the Ettus products continue to remain mystery to many newcomers. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 9:06am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/12 "2014-03-15T09:06:38Z")
Hi, > There are no documentation of what SBX performs on incoming or > outgoing signals. [https://www.ettus.com/product/details/SBX](https://www.ettus.com/product/details/SBX) IMHO Ettus is among the brands where there is the _least_ surprises just because the exact schematic is published, you can see _exactly_ what the SBX does to your signal … > If Ettus support personnel doesn’t clear things up, the Ettus products > continue to remain mystery to many newcomers. Just a thought, but have you considered that “newcomers” aren’t the target audience ? SDR has “radio” in it, and to use them properly you kind of need an understanding of how radio works. Ettus isn’t here to teach you the fundamentals of RF, Radios, DSP, SDR, … you’re supposed to learn those by yourself beforehand. Cheers, ``` Sylvain ``` ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 8:57am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/13 "2014-03-15T08:57:29Z")
On Sat, Mar 15, 2014 at 11:14 AM, Marcus D. Leech [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > The SBX does analog downconversion, nothing more. It knows nothing about > the incoming signal, and doesn’t demodulate it in any way. > > That is what SDR is all about–the signals are represented as > complex-baseband (i/Q) format for processing by computer algorithms. > > The SBX (or any other daughtercard) is simply doing downconversion (or, > upconversion for TX). Even the simplest quadrature downconversion also needs to avoid clock drift. [http://en.wikipedia.org/wiki/Quadrature\_modulation#Clocking](http://en.wikipedia.org/wiki/Quadrature_modulation#Clocking) If your “analog downconversion” above refers to quadrature downconversion, then it is very important to have a phase lock loop (PLL) on the SBX to avoid clock drift. How could this PLL only present at the host (gnuradio flow graph), but not Ettus SBX daughtercard ? Does the flow-graph PLL able to correct all effects due to clock drift of SBX? ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 10:15am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/14 "2014-03-15T10:15:34Z")
Hi, > Let’s see yourself at > [http://code.ettus.com/redmine/ettus/projects/public/documents](http://code.ettus.com/redmine/ettus/projects/public/documents) > This is the link referred by > [http://www.ettus.com/kb/detail/frequently-asked-questions](http://www.ettus.com/kb/detail/frequently-asked-questions) > > This link leads to ----\> “The page you were trying to access doesn’t > exist or has been removed” ! Wow, they have a broken link because there was a reorganization recently, big deal. Use the power of google … 4th link when searching for “Ettus SBX schematic” And it’s also in their file repo [http://files.ettus.com/schematics/sbx/sbx.pdf](http://files.ettus.com/schematics/sbx/sbx.pdf) if you want it from official source. > You may refer to previous conversations. Do you agree with him that a > simple quadrature downconverter doesn’t need to care about clock drift > because it just “simply downconverter and nothing more”? Yes … Cheers, ``` Sylvain ``` ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 10:48am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/15 "2014-03-15T10:48:31Z")
On Sat, Mar 15, 2014 at 5:14 PM, Sylvain M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > You may refer to previous conversations. Do you agree with him that a > > simple quadrature downconverter doesn’t need to care about clock drift > > because it just “simply downconverter and nothing more”? > > Yes … > > Cheers, > Sylvain In this case I shall rephrase my question to: “How to compensate the error due to clock drift which is not handled by a simple quadrature upconverter ?” Could anyone of gnuradio forum gives me some idea ? I hope this is no longer categorized as expecting Ettus to teach me the fundamentals of RF. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 10:58am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/16 "2014-03-15T10:58:17Z")
On Sat, 15 Mar 2014 17:46:58 +0800 Activecat [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > In this case I shall rephrase my question to: > “How to compensate the error due to clock drift which is not handled > by a simple quadrature upconverter ?” I do not want to sound rude or anything, but you are asking very basic questions on radio communications. You should read a textbook or go to an introductory class on that topic. You can find recommended documents on the suggested reading page[1]. Especially the “Digital Comms” section. Also a good idea would be to do an Ham Radio licensing course. These usually cover the most basic modulations and how it relates to real devices too. ``` Attila K. ``` [1] [http://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading/](http://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading/) – It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. – Miss Matheson, The Diamond Age, Neil Stephenson ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 9:58am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/17 "2014-03-15T09:58:30Z")
On Sat, Mar 15, 2014 at 4:05 PM, Sylvain M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > There are no documentation of what SBX performs on incoming or > > outgoing signals. [https://www.ettus.com/product/details/SBX](https://www.ettus.com/product/details/SBX) > > IMHO Ettus is among the brands where there is the _least_ surprises > just because the exact schematic is published, you can see _exactly_ > what the SBX does to your signal … Let’s see yourself at [http://code.ettus.com/redmine/ettus/projects/public/documents](http://code.ettus.com/redmine/ettus/projects/public/documents) This is the link referred by [http://www.ettus.com/kb/detail/frequently-asked-questions](http://www.ettus.com/kb/detail/frequently-asked-questions) This link leads to ----\> “The page you were trying to access doesn’t exist or has been removed” ! > > If Ettus support personnel doesn’t clear things up, the Ettus products > > continue to remain mystery to many newcomers. > > Just a thought, but have you considered that “newcomers” aren’t the > target audience ? “Newcomers” refer to those who purchase Ettus products for the first time. Sadly they are not given appropriate attention even through they are consumers of Ettus. > SDR has “radio” in it, and to use them properly you kind of need an > understanding of how radio works. Ettus isn’t here to teach you the > fundamentals of RF, Radios, DSP, SDR, … you’re supposed to learn > those by yourself beforehand. I do not expect Ettus to teach me the fundamentals, but to clarify fundamental details with Ettus support personnel who seem to confuse with RF fundamentals. You may refer to previous conversations. Do you agree with him that a simple quadrature downconverter doesn’t need to care about clock drift because it just “simply downconverter and nothing more”? ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 11:09am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/18 "2014-03-15T11:09:17Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 11:14am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/19 "2014-03-15T11:14:47Z")
On 03/14/2014 01:05 PM, Johnathan C. wrote: > It is an unavoidable reality of designing radio receivers that one must > compensate for this offset in transmitter and receiver local oscillator > frequencies. In software radio systems, this is most often done by > estimating the frequency/phase error and performing de-rotation on the > resulting waveform. > I would emphasize that this requirement isn’t a “quirk” of SDR > hardware–every digital radio system ever has needed some kind of > offset error estimator to track differences between TX and RX > phase/frequency. In analog systems (like NBFM voice, or FM radio, or AM audio), it’s generally not as necessary, because it’s hard for humans to hear minor frequency offsets. But for data systems, an error estimator is vital. Even in WBFM, I’ve implemented an AFC block to compensate for the crappy (RTLSDR) master clock on the receiver. But each modulation type and coding system will have its own way of estimating phase/frequency error which you’ll have to implement, or just “live with” bad BER. – Marcus L. Principal Investigator Shirleys Bay Radio Astronomy Consortium > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 15, 2014, 11:53am UTC](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781/20 "2014-03-15T11:53:51Z")
On Sat, Mar 15, 2014 at 5:56 PM, Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Thanks, > Tom I saw those PLL blocks but basically these blocks extract clocking at the host (PC), while clock locking is needed at the SBX. I feel you guys doesn’t understand my concern. Nevertheless I understand this starts to get confrontational, so I have to stop here. Sorry for any misunderstanding and offense arisen. Thank you very much. Regards, Activecat [Next page](https://www.ruby-forum.com/t/failure-of-sending-square-wave-over-usrps-back-to-back/239781.md?page=2)