Hi,
I’ve been trying to get two USRP2’s with their clocks both synced to a
10MHz
reference (for now the same reference from the back of some test
equipment)
-
to do this I’m using the following code:
in_pipe1=usrp2.source_32fc('eth0')
in_pipe2=usrp2.source_32fc('eth2')
in_pipe1.config_mimo(usrp2.MC_WE_LOCK_TO_SMA)
in_pipe2.config_mimo(usrp2.MC_WE_LOCK_TO_SMA)
As a quick test I then connected each usrp2 to a complex oscilloscope
(i.e
scopesink2.scope_sink_c)
This sort of works – checking on the test clock pins on each USRP2 the
100MHz clocks are locked.
Unfortunately putting in a sine wave from a lab sig gen garbage is seen
– a
constant DC signal on the BasicRX and what looks like modulated noise on
the
DBSRX (testing at different frequencies on both boards) – the signal
looks
as expected if the config_mimo line is commented (and the usrp2’s
restarted).
Am I missing something obvious?
Both USRP’s have the latest compiled firmware I could find (11370).
We’re on
a svn version from a few months ago due to the old short packet problem
could this be the issue though it seems more hardware-y as from reading
the
firmware code all that command should do is change one of the output
registers on the microprocessor?
I’m also trying to attach the timestamp data do each sample – as far as
I
can tell this is sent to give the sample timestamp for the first sample
in
each ethernet frame (then incremented by 1 for each subsequent sample in
the
frame)
I think I have to create a new C++ block based on USRP2_SOURCE_32FC() to
define a second output stream and connect the rx-metadata::timestamp
(which
is a uint32) to this output – is this correct or can I access the data
within a custom (or current) block further down the line somehow
already?
Thanks in advance,
Tim
Tim P. wrote:
in_pipe2.config_mimo(usrp2.MC_WE_LOCK_TO_SMA)
the signal looks as expected if the config_mimo line is commented (and
the usrp2’s restarted).
Am I missing something obvious?
There is no frequency which can be received by both the BasicRX and the
DBSRX. What frequency are you putting in? What frequency are you
telling the USRP2s to tune to?
Matt
There is no frequency which can be received by both the BasicRX and the
DBSRX. What frequency are you putting in? What frequency are you telling
the USRP2s to tune to?
Matt
Hi,
Sorry I probably confused things by mentioning the BasicRX
DBSRX is the only receiver we have 2 of at the moment so I was testing
with
a 2 GHz Sine wave, tuning the USRP2 to 2GHz and setting decim to 50.
The problem was seen on both usrp2’s after enabling the 10MHz ref lock.
Before enabling the ref lock the sine wave appeared on the oscilloscope
as
expected.
I tried one USRP2 with the BasicRX just to check the same problem was
appearing – a 25MHz and 150MHz signal were tested (same decim and
tuning to
the frequency the sig gen is generating on). Both frequencies looked
correct
on the scope sink until the program was run with the clock locked to the
reference in. - the symptom was slightly different (appearing as a DC
signal
rather than noise) which is why I mentioned.
Thanks,
Tim
Tim P. wrote:
Hi,
Sorry I probably confused things by mentioning the BasicRX
DBSRX is the only receiver we have 2 of at the moment so I was testing
with a 2 GHz Sine wave, tuning the USRP2 to 2GHz and setting decim to 50.
The problem was seen on both usrp2’s after enabling the 10MHz ref lock.
When you lock the reference of the USRP2, it will be exactly on 2 GHz.
So if you put in a 2 GHz sine wave which is also locked to the same
reference or locked to something very close, it will also be at exactly
2 GHz. Thus, when it is downconverted to baseband, it will be at DC,
and will be removed by the DC offset correction. Everything is
functioning exactly as it should.
Before enabling the ref lock the sine wave appeared on the oscilloscope
as expected.
That is because without the ref lock you will have some frequency error,
and the signal won’t be on exactly 2 GHz.
I tried one USRP2 with the BasicRX just to check the same problem was
appearing – a 25MHz and 150MHz signal were tested (same decim and
tuning to the frequency the sig gen is generating on). Both frequencies
looked correct on the scope sink until the program was run with the
clock locked to the reference in. - the symptom was slightly different
(appearing as a DC signal rather than noise) which is why I mentioned.
The BasicRX has no DC offset correction, so you will see a DC level,
which is exactly what you are asking for.
I think that what you really want is to tune the USRP2 and the sig gen
to different frequencies.
Matt
Ah! The 10MHz was coming out the back of the siggen so would have been
locked to the same reference.
Thanks for your help Doug/Matt – next time I’ll stop and think through
my
test setup!
Cheers,
Tim
On Tue, Oct 20, 2009 at 12:20 PM, Tim P. [email protected]
wrote:
Thanks in advance,
Tim
One thing to keep in mind: the timestamp increments at the FPGA’s
clock (100Mhz), so depending on your decimation you’d be incrementing
at some multiple of that for each sample on the host. You are correct
in that you need a custom version of the source block to pass along
timestamps with each sample.
Doug
–
Doug G.
[email protected]