Failure of sending square wave over USRPs (back-to-back)

GNU Radio
#1

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: [email protected]

#2

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 :slight_smile:

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
#3

Dear Sylvain,

On Fri, Mar 14, 2014 at 2:17 PM, Sylvain M. [email protected] 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
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.

#4

Dear Johnathan,

On Fri, Mar 14, 2014 at 2:21 PM, Johnathan C.
[email protected] 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.

#5

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

#6

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

#7

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
[email protected]
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.

#8

Dear Marcus,

On Sat, Mar 15, 2014 at 11:14 AM, Marcus D. Leech [email protected]
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

#9

Dear Martin,

On Fri, Mar 14, 2014 at 5:13 PM, Martin B. [email protected]
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

#10

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.

#11

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
If Ettus support personnel doesn’t clear things up, the Ettus products
continue to remain mystery to many newcomers.

#12

Hi,

There are no documentation of what SBX performs on incoming or
outgoing signals. 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
#13

On Sat, Mar 15, 2014 at 11:14 AM, Marcus D. Leech [email protected]
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

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?

#14

Hi,

Let’s see yourself at
http://code.ettus.com/redmine/ettus/projects/public/documents
This is the link referred by
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 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
#15

On Sat, Mar 15, 2014 at 5:14 PM, Sylvain M. [email protected]
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.

#16

On Sat, 15 Mar 2014 17:46:58 +0800
Activecat [email protected] 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/

–
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

#17

On Sat, Mar 15, 2014 at 4:05 PM, Sylvain M. [email protected]
wrote:

There are no documentation of what SBX performs on incoming or
outgoing signals. 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
This is the link referred by
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”?

#18

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

#19

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
http://www.sbrac.org

#20

On Sat, Mar 15, 2014 at 5:56 PM, Tom R. [email protected] 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