Hello,
I have hooked up the USRP2 to a PPS and a GPSDO 10MHz reference.
Is there a way I can tell if the FPGA is seeing these signals and
locking onto them?
Charles
On Mon, Feb 09, 2009 at 10:50:44AM -0500, Suprin, Charles E. wrote:
Hello,
I have hooked up the USRP2 to a PPS and a GPSDO 10MHz reference.
Is there a way I can tell if the FPGA is seeing these signals and locking onto them?
Charles
Hi Charles,
You have to tell it to use them.
Take a look in <usrp2/usrp2.h>:
config_mimo(MC_WE_LOCK_TO_SMA)
sync_to_pps()
There are python bindings for these.
(Oops, looks like we’re missing the python binding for config_mimo…)
Are you using this from Python? If so, I’ll fix this later on today.
Eric
Eric B. wrote:
There are python bindings for these.
(Oops, looks like we’re missing the python binding for config_mimo…)
Are you using this from Python? If so, I’ll fix this later on today.Eric
On a related note. If I have two (or more) USRP2’s locked onto my 10MHz
and 1PPS signal (calls to ->config_mimo(MC_WE_LOCK_TO_SMA) and
->sync_to_pps() return true, so I believe they are), do I need to do
anything else special?
I’m working C++, based on the rx_streaming_samples.cc code - I have two
usrp2 sptr’s, u2a, and u2b (each created with a separate make() using
the specified mac address from the command line).
Once I start streaming samples (making two calls:
u2a->start_rx_streaming(0), and u2b->start_rx_streaming(0)), and then
with two different handlers for receiving the samples:
bool oka = u2a->rx_samples(0, handlera.get())
bool okb = u2b->rx_samples(0, handlerb.get())
Where the handler is just writing to the specified files.
I’m getting some odd results: both files typically end up with exactly
the sample results (i.e. in octave, subtracting the results of one from
the other results in all zeros). Since I’ve now tried this a few times
doing things like: removing the antenna from one (and not the other),
moving them far apart, etc. - I’m fairly certain this is a software
problem, and not the correct results.
I can post my code if that would be helpful - I’m hoping I’m just
making some silly mistake with my calls to rx_samples, and the copy
handler or something similar. E.g., should I be using different channel
numbers?
I just updated the firmware on my USRP2’s to r10377, and the fpga
bitstream to r10183.
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
On Tue, Feb 10, 2009 at 10:48:18AM -0600, Douglas G. wrote:
(Oops, looks like we’re missing the python binding for config_mimo…)
the specified mac address from the command line).
Once I start streaming samples (making two calls:
u2a->start_rx_streaming(0), and u2b->start_rx_streaming(0)), and then
with two different handlers for receiving the samples:
bool oka = u2a->rx_samples(0, handlera.get())
bool okb = u2b->rx_samples(0, handlerb.get())
Where the handler is just writing to the specified files.
I’m getting some odd results: both files typically end up with exactly
the sample results (i.e. in octave, subtracting the results of one from
the other results in all zeros).Since I’ve now tried this a few times
doing things like: removing the antenna from one (and not the other),
moving them far apart, etc. - I’m fairly certain this is a software
problem, and not the correct results.
OK. Just to be sure, are you explicitly specifying different mac
addresses in the calls to usrp2::make?
I can post my code if that would be helpful - I’m hoping I’m just
making some silly mistake with my calls to rx_samples, and the copy
handler or something similar.
Please post a link to your code.
E.g., should I be using different channel numbers?
Nope, channel number zero is the only one you need.
I just updated the firmware on my USRP2’s to r10377, and the fpga
bitstream to r10183.
Eric
Eric B. wrote:
Since I’ve now tried this a few times
doing things like: removing the antenna from one (and not the other),
moving them far apart, etc. - I’m fairly certain this is a software
problem, and not the correct results.OK. Just to be sure, are you explicitly specifying different mac
addresses in the calls to usrp2::make?
Yes - I have two command line arguments, and when I print out
u2a->mac_addr().c_str() and u2b->mac_addr().c_str() I get the expected
results.
I can post my code if that would be helpful - I’m hoping I’m just
making some silly mistake with my calls to rx_samples, and the copy
handler or something similar.Please post a link to your code.
http://cspl.okstate.edu/index.php/Code/rx_mimo.cc
E.g., should I be using different channel numbers?
Nope, channel number zero is the only one you need.
I just updated the firmware on my USRP2’s to r10377, and the fpga
bitstream to r10183.Eric
Somewhat more disturbing. I’ve turned off the 1Hz/1PPS, and I’m not
getting errors from sync_to_pps() (i.e. it still thinks they are
synchronized - even after power cycling). When I added the code to the
copy handler to print out the timestamp, etc. from the frame/metadata, I
still get identical timestamps being sent: i.e. when I run:
./rx_mimo -m 30:80 -n 30:81 -f 2.412G -d 128 -g 30 -N 500 -o test1.dat
-O test2.dat -v -M LOCK_TO_SMA
I get:
USRP2 (A) MAC address: 00:50:c2:85:30:80
Daughterboard configuration:
baseband_freq=2412500000.000000
ddc_freq=500000.000000
residual_freq=0.011176
inverted=no
USRP2 (B) MAC address: 00:50:c2:85:30:81
Daughterboard configuration:
baseband_freq=2412500000.000000
ddc_freq=500000.000000
residual_freq=0.011176
inverted=no
USRP2 (A) using decimation rate of 128
USRP2 (B) using decimation rate of 128
Started streaming
Receiving 500 samples
test1.dat: Timestamp: 1423196227(0,9.15527e-05) 0
test2.dat: Timestamp: 1423196227(0,9.15527e-05) 0
test1.dat: Timestamp: 1423243734(0.000274658,9.15527e-05) 0
Stest2.dat: Timestamp: 1423243734(0.000274658,9.15527e-05) 0
S
Copy handler called 2 times.
Copy handler called with 2968 bytes.
Elapsed time was 0.001 seconds.
Packet rate was 3040 pkts/sec.
Approximate throughput was 4.51 MB/sec.
Total instances of overruns was 1. (A)
Total missing frames was 254. (A)
This is with no 1PPS, no 10Mhz reference signal, and the antenna on
30:80 was removed (installed on 30:81). I’m going to pull up wireshark
to compare the frames I’m getting from each USRP2.
Doug
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
Eric and Doug,
I like Doug am basing things off the rx_streaming_samples.cc. It
seemed easier to work with to get access to timestamps.
Charles
Douglas G. wrote:
This is with no 1PPS, no 10Mhz reference signal, and the antenna on
30:80 was removed (installed on 30:81). I’m going to pull up wireshark
to compare the frames I’m getting from each USRP2.
Doug
Ok, looking at the frames in wireshark, looking for the timestamps that
were sent to the copy handler, it looks like only the frames from 30:80
are being used, and they’re being used twice (i.e. u2b->rx_samples(0,
handlerb.get()) got the same samples that u2a->rx_samples(0,
handlera.get()) got). Is sync_to_pps() supposed to reliably return false
if the FPGA did not find a signal to sync to?
Doug
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
On Tue, Feb 10, 2009 at 1:26 PM, Douglas G.
[email protected] wrote:
Ok, looking at the frames in wireshark, looking for the timestamps that
were sent to the copy handler, it looks like only the frames from 30:80
are being used, and they’re being used twice (i.e. u2b->rx_samples(0,
handlerb.get()) got the same samples that u2a->rx_samples(0,
handlera.get()) got).
Thanks for the info and update, this really helps narrow it down. We
may have a bug in our GbE driver packet filter, where the source mac
address is being set to the wrong USRP2. Unfortunately, both Eric and
I are out of the office at the moment, but we’ll look at this tonight.
Is sync_to_pps() supposed to reliably return false
if the FPGA did not find a signal to sync to?
Unrelated to the above. The ‘true’ return from the call only means
that the command was successfully received by the USRP2 and processed,
not that the sync succeeded.
Johnathan
Ok - so I have packets coming in from both USRP2’s now, getting dumped
to their separate files.
My app prints out the timestamp of each frame that gets sent to the
copy handler: if my 1PPS source is working properly, should the
timestamps coming out of the two USRP2’s be identical?
Another question: no matter what, there is going to be some time delay
between when I tell one USRP2 to start, and when I tell the other one to
start: with the timestamps I could do something like
align_on_samplenumbers (but with the timestamps - at least I could do
this in the copy handler where I have access to this information). Of
course this requires that the timestamps do end up being based on the
1PPS. Should I take that as a sign my USRP2’s are not currently getting
sync’d to the 1PPS?
Thanks,
Doug
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
Johnathan C. wrote:
may have a bug in our GbE driver packet filter, where the source mac
address is being set to the wrong USRP2. Unfortunately, both Eric and
I are out of the office at the moment, but we’ll look at this tonight.
In an effort to try to help solve this:
The packet filter (the used in make_ethertype_inbound at least) looks
like it just sorts filters in packets with the correct ethertype, and
filters out any of those from ‘our’ (i.e. the host PC) mac address.
Unless I’m not following the code correctly - is there somewhere else
which looks for the target USRP2’s mac address in receive packets?
Doug
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
Couldn’t you just tell the USRP’s to start at a specific time to get
them to start in sync? Rather than in real-time telling them to start
immediately and having that lag.
Tim
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041
-----Original Message-----
From: discuss-gnuradio-bounces+trnewman=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-
[email protected]] On Behalf Of Douglas G.
Sent: Friday, February 13, 2009 2:02 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] USRP2 PPS and REFOk - so I have packets coming in from both USRP2’s now, getting
dumped
to their separate files.
My app prints out the timestamp of each frame that gets sent to the
copy handler: if my 1PPS source is working properly, should the
timestamps coming out of the two USRP2’s be identical?
Another question: no matter what, there is going to be some time
delay
between when I tell one USRP2 to start, and when I tell the other one
to
start: with the timestamps I could do something like
align_on_samplenumbers (but with the timestamps - at least I could do
this in the copy handler where I have access to this information). Of
course this requires that the timestamps do end up being based on the
1PPS. Should I take that as a sign my USRP2’s are not currently
getting
Newman, Timothy wrote:
Couldn’t you just tell the USRP’s to start at a specific time to get
them to start in sync? Rather than in real-time telling them to start
immediately and having that lag.
Yes, you need to use the “receive at” functionality. The call to
receive on the host side takes a control struct which contains this
info.
Matt
Doug,
Working only on my single channel setup, what appears to happen is that
there is the time stamp for the first sample in the frame. The frame
alignment seems to remain a function of when the device was turned on.
Now if sync_every_pps worked with the 31 December 2008 firmware. I
think I need to wait for a newer FPGA/VHDL firmware release for that to
happen.
Charles
Suprin, Charles E. wrote:
Doug,
Working only on my single channel setup, what appears to happen is
that there is the time stamp for the first sample in the frame. The
frame alignment seems to remain a function of when the device was
turned on.
NO. Frame alignment is under explicit control from the host, as long as
you do a “receive at” request. That will allow you to specify EXACTLY
when you want your samples. If you do a “receive now” request, which is
what you’re doing, you’ll get samples starting right away, which will be
a function of host computer latency.
Now if sync_every_pps worked with the 31 December 2008 firmware. I
think I need to wait for a newer FPGA/VHDL firmware release for that
to happen.
Honestly, sync_every_pps is a hack and I don’t know why you would want
it. It causes you to not know what second it is, since the clock is
reset every second.
The normal “sync at next pps” makes more sense. Since all the
oscillators are locked, you only need to sync once, and everyone will
remain in sync forever.
Matt
Matt,
I had not seen your other post before I responded to the first one.
How do you do a “receive at”? Looking at
usrp2/host/apps/include/usrp2/usrp2.h, the only function I see is
start_rx_streaming which does not have a timestamp in it.
As for the sync_every_pps, if one is running two setup, physically
separate, then the timestamps of the same time will agree if they both
reset on separate GPS generated PPS’s. That way if one reboots or
restarts the application, the time ambiguity is in units of seconds
which can generally resolved with a NTP on the host computer.
If I am missing something that could solve this more easily, let me
know.
Charles
Suprin, Charles E. wrote:
Charles
Johnathan mentioned the “receive at” call to me as well - and I see
there is a ticket #341 for USRP2 send-at and receive-at. So this is
something that is still in-development? Looks like it will be coming
with the new message passing architecture.
Doug
–
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]