Thanks for your help Doug. I thought I knew which bits to monitor which
contained the timestamp but now im not sure! The packets received seem very
large. I have included a screenprint of one below. Please could you tell me
which bits are the timestamp in this packet?
The data appears to start from line 0020 but every other 32 bits are either
ff or 00.
Do we add the sync_every_pps() to txrc.c immediately before the while loop?
Which version of gnuradio are you running? If you’re using the
usrp2-vrt git branch, the frame format has changed dramatically. If
you’re using the released code (or the master branch from git) the frame
structure is (IIRC) defined in
usrp2/firmware/include/usrp2_eth_packet.h. There’s the standard ethernet
header (dst, src, ethertype), a short ‘transport’ header (some flags,
sequence number, etc.), and the ‘fixed’ header which has some more
flags, and the 32-bit timestamp. The VRT format has a much longer
header, and includes a seconds count and a fractional seconds count.
You don’t need to call sync_every_pps() in the firmware (do you really
want to reset the clock every PPS?). The host can send the command to
sync_*_pps() when setting up the connection to the USRP2. For example,
in rx_streaming_samples, call u2->sync_to_pps() (or sync_every_pps() if
you really want that) before calling u2->start_rx_streaming. Then you
can have the copy handler print out the timestamp from each frame
received by the USRP2. In the VRT branch I believe there is already an
example application that prints out the timestamp from received frames.
U.S. Naval Research Laboratory
Washington, DC 20375