Ettus Research USRP-1 + gnuradio software as a radar digitizing system

USB packets

There are 256 16-bit words in each USB packet.  The upper 4 bits (or eventually upper 2 bits, for the 14-bit USRP model) are used to hold up to 1024 (or up to 512 for the 14-bit USRP model) bits of metadata - see below.

Digitizing modes

One of these is active at a time.  The mode is selected by sending a command to the USRP.

1. normal: USB packets are sent each time a trigger pulse is detected;  samples are unsigned 12-bit integers encoded as bits 11:0 of a 16-bit word.  The number of packets sent for each pulse, the sampling rate, and the trigger delay are all set by commands sent to the USRP.
2. raw video: USB packets are sent continuously, with 12-bit samples from the video line
3. raw trigger:USB packets are sent continuously, with 12-bit samples from the trigger line (note: we are using a 12-bit ADC for trigger)
4. raw ACP/azimuth:USB packets are sent continuously, with 12-bit (or 1-bit, using Dave's front end) samples from the ACP line
5. raw ARP/heading:USB packets are sent continuously, with 12-bit (or 1-bit, using Dave's front end) samples from the ARP line
6. multiplex: USB packets are sent continuously; 12-bit samples are interleaved from all 4 signal lines.  This allows 4 MSPS simultaneously on each channel.  (32 MB/s USB bandwidth = 4 channels * 4 MSPS * 2 bytes per sample).  This mode is intended for an "intelligent setup" client, which will more or less automatically determine appropriate gain, delay, and threshold parameters for all channels. 

Metadata

Every USB packet is stamped with a serial number (32 bits) encoded in the first 32 available bits of metadata (i.e. top 4 bits of bytes 0, 2, 4, ..., 14 for the 12-bit unit; top 2 bits of bytes 0, 2, 4, ..., 30 of 14-bit unit).
In normal digitizing mode, additional metadata are sent with the first USB packet from each digitized pulse.  The metadata in the 12-bit unit are as follows (taken from file gnuradio/usrp/host/include/usrp_bbprx.h

 // NB: order of fields in metadata must be reverse of instance "stage_4" of pack_metadata in usrp_bbprx.v

      unsigned int USB_serial_no;               // serial number of USB packet
      unsigned int n_ACPs;                      // number of ACPs since last reset
      unsigned int n_ARPs;                      // number of ARPs since last reset
      unsigned int n_trigs;                     // number of triggers since last reset
      unsigned int ACP_interval_last_ARP;       // ticks in ACP interval that included last ARP pulse (only valid once n_ACPs != ACP_count_last_ARP)
      unsigned int ACP_age_last_ARP;            // ticks since last ACP pulse at last ARP pulse
      unsigned int ACP_count_last_ARP;          // ACP counter at last ARP pulse
      unsigned int ticks_since_last_ACP;        // clock ticks since last ACP pulse
      unsigned int ticks_since_last_ARP;        // clock ticks since last ARP pulse
      unsigned int ACP_interval;                // clock ticks between most recent consecutive ACP pulses that contained a trigger pulse
      unsigned int ARP_interval;                // clock ticks between most recent consecutive ARP pulses
      unsigned int trig_interval;               // clock ticks between most recent consecutive trigger pulses
      unsigned long long clock_ticks;           // number of (64MHz) clock ticks since last reset

Note:

• the metadata use up 448 of the 1024 metadata bits, leaving room for additional metadata such as inclinometer readings or weather station data
• no attempt has been made to optimize the size of counters (we don't really need 32-bits to count heading pulses!), but this can be done to make more room for other metadata
• the apparently overlapping meanings of these fields allow us enough information to very precisely estimate the azimuth angle for each digitized pulse
• so far, I haven't incorporated Dave's "window" scheme for determining whether the azimuth has returned to heading based on the heading line, or whether the ACP count should be used
• the USB packet serial numbers allow us to detect various buffer overruns, and to throw away data from incomplete pulses
• only the first USB packet for each pulse contains the radar metdata; these metadata (except for the USB serial no) are zero in the subsequent packets for a given pulse.  This lets us determine which packets are the first packet of a pulse by checking whether the clock_ticks field is non-zero.
• we keep track of the true radar PRF independently of how we are digitizing, by counting trigger pulses.  For example, even if the listen period is longer than the inter-pulse interval, so that we are dropping pulses, we can detect this by looking at the n_trigs field.  It is guaranteed not to miss valid pulses because this counter is updated independently of any video digitizing or USB data transfers