Optimizing Data Acquisition: The Architecture of GET, SET, RIG, and NAB

Posted on by

High-Throughput Instrument Control Protocol

In the world of instrument automation (GPIB, VISA, TCP/IP), the primary bottleneck is rarely bandwidth—it is latency. Every command sent to a device initiates a handshake protocol that incurs a time penalty. When managing complex systems with hundreds of data points, these penalties accumulate, resulting in “bus chatter” that freezes the UI and blocks other processes.

To solve this, I designed the OPEN-AIR architecture around four distinct communication primitives: GET, SET, RIG, and NAB. While GET and SET are industry standards, RIG and NAB are custom implementation methods I developed to compress the timeline of data acquisition and maintain a “quiet bus.”

The Enemy: Latency and “Bus Chatter”

Standard communication follows a synchronous pattern:

  1. PC sends command. (Latency)

  2. Device processes. (Processing Time)

  3. Device acknowledges/replies. (Latency)

If I need to fetch 10 different metrics (Voltage, Current, Frequency, etc.), a standard approach triggers this handshake loop 10 times. This is inefficient. It clogs the communication bus, preventing other instruments from talking, and results in asynchronous data where the first measurement might be hundreds of milliseconds older than the last.

1. The Primitives: GET and SET

These are the foundational atomic operations found in almost every driver.

  • SET: I tell the device to perform a single action.

    • Command: Device.Write(":FREQ:CENTER 1GHz")

    • Outcome: The device sets the center frequency.

  • GET: I ask the device a single question.

    • Command: Device.Query(":FREQ:CENTER?")

    • Outcome: The device returns a single value (e.g., 1000000000).

While useful for ad-hoc adjustments, relying on these for system-wide updates is the primary cause of interface lag.

2. The Innovation: RIG (Batch Configuration)

RIG is my method for atomic state configuration. Instead of sending commands sequentially, I concatenate them into a single “Rigging String” using standard SCPI delimiters (usually a semi-colon).

How It Works: Rather than sending five separate packets to configure a spectrum analyzer, I package the entire state into one payload.

  • Standard Method (5 Transactions):

    • SET Start Freq → ACK

    • SET Stop Freq → ACK

    • SET RBW → ACK …

    • Result: High latency, “busy” bus.

  • The RIG Method (1 Transaction):

    • RIG ":FREQ:START 10MHz;STOP 1GHz;RES:BW 100kHz;VID:BW 100kHz;SWE:TIME 50ms"

    • Result: The device receives the full configuration instantly.

Benefits:

  1. Bus Efficiency: The bus is free immediately after the packet is sent.

  2. Atomic State: The instrument snaps to the new configuration instantly. There is no intermediate state where the Frequency is set but the Bandwidth is wrong.

3. The Innovation: NAB (Batch Acquisition)

NAB (“Narrow And Burst”) is the query equivalent of RIG. It allows me to harvest multiple data points in a single request cycle.

If I need to update a GUI dashboard with 20 indicators, asking for them individually causes the screen to populate slowly or “popcorn” in. NAB solves this by asking all questions simultaneously.

How It Works: I construct a multi-query string and send it as a single request.

  • The Request:

    • NAB ":MEAS:VOLT?;:MEAS:CURR?;:SYST:ERR?;:SYST:TEMP?"

  • The Response:

    • "12.5;0.5;0,No Error;45.2"

My software intercepts this raw string, splits it by the delimiter, and distributes the values to their respective GUI widgets.

Benefits:

  1. Speed: I capture 4 (or 40) data points for the latency cost of one.

  2. Synchronization: Since the instrument processes the query sequentially in one interrupt cycle, the data represents a true snapshot in time. The voltage reading and the current reading are perfectly aligned.

4. The Philosophy of the “Quiet Bus”

By implementing RIG and NAB, I achieve what I call a “Quiet Bus.”

When we compress 10 interactions into 1, the communication line sits idle for the majority of the operational time. This non-blocking approach means the software is waiting less and processing more. It allows:

  • Higher scalability: More instruments can share the same interface without collision.

  • Smoother UI: The GUI updates in single, fluid frames rather than staggered steps.

  • Reliability: Fewer packets on the wire means fewer chances for collision or timeout errors.

SET and GET are for precise, individual adjustments. RIG and NAB are for high-performance system orchestration.