2.1 RX Streamer

Overview

The purpose of this application is to buffer and stream data from the RX port(s), analyze it, and plot / save it during runtime.

Start it up!

To test it out, try these commands from the python terminal:

>>> import pycrimson.applications
>>> r = pycrimson.applications.rx_streamer([0,2,3])

This creates an instance of the rx_streamer application, and connects to the Crimson, enabling channels RXA (0), RXC (2), and RXD (3), as specified by the first argument of rx_streamer(). It will start the data flow, and a window should pop up that looks something like this:

Settings

First, notice the list of settings on the left-hand side of the window. As discussed in the next sections, the settings are conceptually divided into two categories, "Crimson" and "Software". The "Crimson" category basically has to do with the hardware itself (e.g., its sample rate, which channels are enabled, etc), and the "Software" category has to do with what the host computer does with all data coming through the SFP+ ports. All of these settings will be stored as a header in any saved data files, and all of them can be manipulated either in the GUI or via the r.settings, a Spinmob TreeDictionary.

"Crimson" settings

This area is where you can control the Crimson itself. Upon initialization, rx_streamer asks the Crimson for its current internal values (sample_rate, RXA center frequency, etc) and populates the list. You can change these values by typing in whatever you like in the GUI, or via the terminal / script, for example:

r.settings['Crimson/sample_rate'] = 1.27e6
r.settings['Crimson/RXA/center_frequency'] = 127.27e6

You will notice that the number you see after you enter is not always equal to what you entered. This is because the Crimson only allows specific values, and after entering a number, rx_streamer queries the Crimson for the actual number it ended up using. The item post_command_settle determines how long the computer will pause between setting a value and asking for the actual value.

Now notice the check boxes next to each channel. These determine which of the enabled channels' data will be collected by the host computer. Unchecking RXD and pressing the "Go!" button at the top left should produce something like this:

The Crimson has now become a demodulating oscilloscope. By default, both quadratures of the buffered data for each channel will now be periodically grabbed and plotted versus time. The green progress bar at the top indicates how full the buffer is (discussed more below).

"Software" settings

This area is where you can control which data to collect and what to do with it.

• Acquisitions: How many times to collect data after pressing "Go!". If set to zero, it will continue taking data indefinitely.

  • count: How many acquisitions have occurred since the last time "Go!" or "Reset" was pressed.
  • buffer_size: How many packets the buffer should hold. By default (with payload set to 1400, if that means anything to you), the Crimson will supply 346 samples per packet, though if there is a temporary bottleneck (e.g. on startup), sometimes this number can be multiplied by an integer. Making the buffer larger prevents overruns (i.e. the situation in which data is thrown away because it was not pulled off the buffer quickly enough) at the expense of RAM. Making it too large can also will grind your system to a halt if you enable "keep_extra" (see below).
  • calibration: The number by which the raw data is multiplied to convert to volts (the second tab of the plotting area).
  • time: How many seconds of data to pull off the buffer during each acquisition. Note that, in the interest of efficiency, each acquisition pulls all of the data from the buffer.
  • timeout: Maximum time to wait for the aforementioned data to accumulate before giving up.
  • keep_extra: Whether to keep the the data pulled from the buffer that is in excess of the desired time. Use this option if you wish to take continuous data (and keep an eye out for buffer overruns in that case!). Without this checked, excess data from the buffer is discarded.
  • trigger_channel: Which channel we should use to trigger the data. Currently this just looks for where the data crosses the horizontal yellow cursor and shifts the time axis to that value. It also currently only works on the X quadrature. Basically it isn't developed very well yet. :)

• PSD: Whether to take a power spectral density (and an FFT along the way, both plotted tabbed plotting area).

  • window: FFT window to apply. Can be any of the numpy fft windows (e.g. hanning, hamming, ...) or "None".
  • pow2: Whether to truncate the data such that the number of samples is a power of 2. This greatly increases the speed of the FFT, but can throw away data.
  • averages_RX*: How many averages each channel's PSD has had thus far. Note that once the number of samples used for the FFT is known, each time trace is chopped into the maximum number of such windows, and the PSD is the average of these; this is particularly important if keep_extra is enabled, as the FFT sample count is determined by time and pow2.

Top controls

The widgets along the top allow you to start, stop, and reset the acquisition ("Go!" and "Reset"), as well as monitor the buffer (green progress bar and "Buffer Overrun" indicator), and timeouts ("Timeout" indicator). Programmatically, buttons can be accessed via r.b_*, and the progress bar via r.pb_buffer.

Plot tabs

In this region, you can see the raw and analyzed data during runtime. The plotter is a Spinmob DataboxPlot object, which is a very flexible plotting (and runtime analysis) widget based on the fast and amazing library pyqtgraph. Programmatically, plots objects (and their data!) can be accessed via r.p_*.