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?
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- 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?
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?)
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.
On Fri, May 12, 2006 at 01:27:14PM -0700, John G. 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.
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 G. wrote:
Why would it take 8 clocks? Surely the hardware could do the hard
possible?)
–
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!
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
The input to the flow graph is data