Using PPS as a sampling trigger

GNU Radio
1

Hello Everyone,

I am a relatively new user to the USRP2 and currently would like to make
some changes to how an external PPS signal is deciphered. As of now, I
believe that once the first rising edge of a PPS signal is detected, the
USRP2 will continually collect data until it is programmed to stop.
What I
am hoping to do is collect data when the PPS sends a rising edge and
pause
the data collection when a falling edge is detected. Basically the
external
PPS signal is going to act as a TR switch. So far I have been looking
through the rx_timed_samples.cpp and the header file clock_config.hpp
programs to plan out my approach. The problem where I am getting stuck
is
telling the USRP to pause data collection on a falling edge. I have not
found any function in the libraries that is able to do this. Has
anybody
been able to program the PPS input to act as a TR switch or have any
ideas
about how to about this? Any information on this would be greatly
appreciated.

Thank you very much,
Rob

View this message in context:
http://old.nabble.com/Using-PPS-as-a-sampling-trigger-tp33312321p33312321.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

On 02/13/2012 08:21 AM, rmsrms1987 wrote:

through the rx_timed_samples.cpp and the header file clock_config.hpp
programs to plan out my approach. The problem where I am getting stuck is
telling the USRP to pause data collection on a falling edge. I have not
found any function in the libraries that is able to do this. Has anybody
been able to program the PPS input to act as a TR switch or have any ideas
about how to about this? Any information on this would be greatly
appreciated.

Thank you very much,
Rob

Generally, this falls into the realm of customizing FPGA, since there is
no stock way to trigger streaming from the PPS input.

However, while continuously streaming, you can poll get_time_last_pps(),
which will tell you the time when you pulsed the PPS input. Use this
information and the time stamps on the RX packets.

-Josh

3

Hi Josh,

Thank you for the reply.

I have been trying to implement what you mentioned using the
rx_timed_samples program but am having some trouble making sense of the
results. Here are the changes I have made to the code in order to
acquire
PPS timing information.

usrp->set_clock_source(“external”);
usrp->set_time_source(“external”);

usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));

uhd::time_spec_t pps_time = usrp->get_time_last_pps();

These are the initial variables that are created outside of the “while”
loop. Inside of the “while” loop I added:

if (pps_time != usrp->get_time_last_pps()){
pps_time = usrp->get_time_last_pps();
std::cout << boost::format(“PPS Trigger: %u full secs, %f frac
secs”)
% pps_time.get_full_secs() % pps_time.get_frac_secs() << std::endl;
}

Basically what this is supposed to do is print out the time value of the
last PPS trigger, once a new trigger value has been detected.

The problem I am having right now is that the timing information is not
matching up to the signal I am inputting to the PPS port. I started off
with inputting a signal that has an IPP of 1ms, but each PPS Trigger
output
incremented in values of 5ms. I made additional changes to the input
signal
by making the IPP 5ms, then the increment of the printed PPS trigger was
10
ms. Inside each IPP there are also some trigger variations, but these
were
never detected. Is there something I am not doing correctly in my code
in
order to detect each PPS trigger? It seems like once a PPS is detected,
the
program assumes each subsequent PPS will occur in equal time increments.
Please let me know what you think.

Thank you very much,
Rob

–
View this message in context:
http://old.nabble.com/Using-PPS-as-a-sampling-trigger-tp33312321p33374458.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

This method of polling get_time_last_pps() is only going to work if you
are pulsing the input “slowly” enough. You can measure the duration of a
read by calling get_time_now() twice and calculating the difference in
time. If you cant satisfy this condition, then I can suggest a few other
mods that should work for you.

  1. Pass the trigger input along with the sample stream as the lowest
    bit. This would be an FPGA mod replacing the DDC’s input.

Basically, you monitor the sample for when this bit goes high/low to
know which samples where triggered on.

1.1) A slight variation on this would be to use the second RX DSP chain
to sample the trigger. Replace the ADC input to the DDC with the
trigger.

http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/usrp2/top/N2x0/u2plus_core.v#L612

  1. Use jcorgan’s gpio branch. This mod produces an async packet with
    timestamp when the state of the GPIOs changes. For this you might use
    one of the daughterboard GPIOs rather than PPS input for the trigger
    (unless you mod it).

http://gnuradio.org/cgit/jcorgan-uhd.git/log/?h=gpio

For this option, you read the async message queue for events to
determine which times refer to triggered sample events.

  1. And other FPGA mod option: Use the trigger to “&&” with this
    run-signal assignment:
    http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/usrp2/top/N2x0/u2plus_core.v#L584

For this mod to work, you will need to issue “finite” stream commands
such that the number of samples requested is less than the duration of
your trigger activation duration. You will only see packets that start
exactly on the trigger event.

-Josh