Forum: GNU Radio USRP2 PPS and REF

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.
Suprin, Charles E. (Guest)
on 2009-02-09 17:58
(Received via mailing list)
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
Eric B. (Guest)
on 2009-02-09 18:13
(Received via mailing list)
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
Douglas G. (Guest)
on 2009-02-10 18:49
(Received via mailing list)
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
removed_email_address@domain.invalid
removed_email_address@domain.invalid
Suprin, Charles E. (Guest)
on 2009-02-10 19:26
(Received via mailing list)
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
Eric B. (Guest)
on 2009-02-10 22:06
(Received via mailing list)
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
Douglas G. (Guest)
on 2009-02-10 23:41
(Received via mailing list)
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
removed_email_address@domain.invalid
removed_email_address@domain.invalid
Douglas G. (Guest)
on 2009-02-10 23:54
(Received via mailing list)
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
removed_email_address@domain.invalid
removed_email_address@domain.invalid
Johnathan C. (Guest)
on 2009-02-11 00:11
(Received via mailing list)
On Tue, Feb 10, 2009 at 1:26 PM, Douglas G.
<removed_email_address@domain.invalid> 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
Douglas G. (Guest)
on 2009-02-12 19:58
(Received via mailing list)
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
removed_email_address@domain.invalid
removed_email_address@domain.invalid
Douglas G. (Guest)
on 2009-02-13 21:02
(Received via mailing list)
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
removed_email_address@domain.invalid
removed_email_address@domain.invalid
Newman, Timothy (Guest)
on 2009-02-13 21:07
(Received via mailing list)
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-
> bounces+trnewman=removed_email_address@domain.invalid] On Behalf Of Douglas G.
> Sent: Friday, February 13, 2009 2:02 PM
> To: removed_email_address@domain.invalid
> Subject: Re: [Discuss-gnuradio] USRP2 PPS and REF
>
>
>  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
Matt E. (Guest)
on 2009-02-13 21:36
(Received via mailing list)
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
Suprin, Charles E. (Guest)
on 2009-02-13 21:44
(Received via mailing list)
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
Matt E. (Guest)
on 2009-02-13 21:55
(Received via mailing list)
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
Suprin, Charles E. (Guest)
on 2009-02-13 23:17
(Received via mailing list)
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
Douglas G. (Guest)
on 2009-02-14 00:49
(Received via mailing list)
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
removed_email_address@domain.invalid
removed_email_address@domain.invalid
This topic is locked and can not be replied to.