Forum: GNU Radio USRP Synchronization

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
628baa3c453c0bd218cb4d07363cad15?d=identicon&s=25 Ges (Guest)
on 2006-05-06 22:29
(Received via mailing list)
Hi,

 I am trying to do to and fro transmission using 2 USRP boards. I have
connected the tx and rx daughter cards together using SMA Tees (3 SMA
Tees connected together giving me 4 ports for connecting the 2 tx and 2
rx). I am trying to do a TDMA type of transmisson. the TX on one usrp
transmits and then after x secs the tx on the other transmits. The way I
am controlling the trasnmission is by not writing to the buffer on the
host side. But even if I am giving a large time gap, the data I get at
the receiver seems to be garbled. Only the very first guy that transmits
gives me perfect reception. How can I ensure that the USRP sends out
data only when I want it to and not otherwise, such that there is no
overlap between the txs of the two USRPs?


 Thanks
 Gesly
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-05-11 05:44
(Received via mailing list)
On Sat, May 06, 2006 at 01:26:15PM -0700, Ges wrote:
> Hi,
>

>  I am trying to do to and fro transmission using 2 USRP boards. I
>  have connected the tx and rx daughter cards together using SMA Tees
>  (3 SMA Tees connected together giving me 4 ports for connecting the
>  2 tx and 2 rx). I am trying to do a TDMA type of transmisson. the
>  TX on one usrp transmits and then after x secs the tx on the other
>  transmits.

What daugherboard(s) are you using?

What you're describing is currently tough with the basic tx since it's
effectively "always on" once you fire it up.  If you underrun, the
FPGA will continue transmitting the same value to the DAC (which has
the upconverter in it), thus even if you're "not transmitting", it's
highly likely that you really *are* still transmitting.

There are a couple of ways to solve/work-around this behavior:

 * use a RFX-<foo> board with auto transmit switching enabled.
 * modify the FPGA code such that when the TX fifo is empty, you
   ramp the value fed to the DAC down to zero over say 8 clocks.

If this doesn't make sense to you, please attach an oscilloscope to
the DAC output and watch what you're currently getting.

> The way I am controlling the trasnmission is by not
> writing to the buffer on the host side. But even if I am giving a
> large time gap, the data I get at the receiver seems to be
> garbled. Only the very first guy that transmits gives me perfect
> reception. How can I ensure that the USRP sends out data only when
> I want it to and not otherwise, such that there is no overlap
> between the txs of the two USRPs?
>
> Thanks
> Gesly

Eric
891c140a55f53b9a238adcb9cc5febb6?d=identicon&s=25 John Gilmore (Guest)
on 2006-05-12 22:30
(Received via mailing list)
> What you're describing is currently tough with the basic tx since it's
> effectively "always on" once you fire it up.  If you underrun, the
> FPGA will continue transmitting the same value to the DAC (which has
> the upconverter in it), thus even if you're "not transmitting", it's
> highly likely that you really *are* still transmitting.
> ...
>  * modify the FPGA code such that when the TX fifo is empty, you
>    ramp the value fed to the DAC down to zero over say 8 clocks.

Why would it take 8 clocks?  Surely the hardware could do the hard
part (jam it to zero immediately) and the software could do the rest
(if it needs to taper off over 8 clocks, end with the right samples).

Hmm, in fact, why is this a problem at all?  Why can't the software
ensure that the final sample before underrun is a zero?  The hardware
will then keep repeating this final sample forever.

(I suppose this would be possible if you aren't using any of the
upconverters -- but if the FPGA or the DAC is upconverting, then you
have to jam a real zero, not an upconverted zero?  Is this even
possible?)

	John
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2006-05-12 22:33
(Received via mailing list)
> Why would it take 8 clocks?  Surely the hardware could do the hard
> part (jam it to zero immediately) and the software could do the rest
> (if it needs to taper off over 8 clocks, end with the right samples).
>

Ramping down results in a cleaner spectrum.  Immediate shutoff splatters
the band.

> Hmm, in fact, why is this a problem at all?  Why can't the software
> ensure that the final sample before underrun is a zero?  The hardware
> will then keep repeating this final sample forever.

That would be the best way to go.

> (I suppose this would be possible if you aren't using any of the
> upconverters -- but if the FPGA or the DAC is upconverting, then you
> have to jam a real zero, not an upconverted zero?  Is this even
> possible?)

An upconverted zero is still a zero.  It's a multiplicative process.

Matt
Ce36ad4142338c14c9b260303e847f71?d=identicon&s=25 Robert McGwier (Guest)
on 2006-05-13 00:40
(Received via mailing list)
John:

An abrupt change in the time domain signal produces wide band energy
(hams call it "key clicks").   The fourier transform of a dirac delta is
a flat line for a constant energy across all frequencies.  Now the dirac
delta is a mathematical object but in a sampled work an abrupt change
from one sample to the next cannot be easily distinguished from one and
the "wide band energy" is aliased and wrapped and is a mess.

Bob



John Gilmore wrote:
> Why would it take 8 clocks?  Surely the hardware could do the hard
> possible?)
>
> 	John
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as
charged!
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-05-13 19:15
(Received via mailing list)
On Fri, May 12, 2006 at 01:27:14PM -0700, John Gilmore wrote:
> part (jam it to zero immediately) and the software could do the rest
> (if it needs to taper off over 8 clocks, end with the right samples).

Jamming it to zero creates a square wave, which in the frequency
domain is really ugly (infinite harmonics...  Like bad CW key
shaping).  Ramping it down avoids the problem.  If we right shift by 2
(with proper handling of the -1 and -2 cases) every clock, after 8
clocks it'll be zero.

> Hmm, in fact, why is this a problem at all?  Why can't the software
> ensure that the final sample before underrun is a zero?  The hardware
> will then keep repeating this final sample forever.

With the current flow graph, it's *really* hard to do this.  I would
have done it already otherwise ;) The input to the flow graph is data
to be modulated, the output is the stream of modulated samples.
There's no way simple/sane way to get the last samples to be zero --
it's FSK.  This is part of the motivation for the m-block stuff.  It
allows us to run the existing flow graph and then tweak/append to the
output.

> (I suppose this would be possible if you aren't using any of the
> upconverters -- but if the FPGA or the DAC is upconverting, then you
> have to jam a real zero, not an upconverted zero?  Is this even
> possible?)

An upconverted zero is still a zero.   The complex mag is zero, so
even though we're using the upconverter in the DAC, sending zeros will
work.

Eric
This topic is locked and can not be replied to.