We can probably use FX2LA firmware as is. It's GPL but that's a non-issue since none of our code is linking to it, we can just redistribute it as as a separately licensed blob.

My understanding is it just spits out a firehose of 24 Msps sample data over USB.

Proposed architecture: create a custom TCP server under scopehal-apps that listens to the USB stream, runs software based triggering, then pushes waveforms to glscopeclient. Use a 2-socket protocol with SCPI data + raw binary waveforms, maybe somewhat compatible with the proposed MAXWELL and PicoScope socket protocols.

We can add arbitrarily complex protocol triggering in the future.

I am interested in this not because I'm a big fan of the FX2LAs, but because my custom scope will have most of the control logic on PC and send low level control commands to the hardware over USB.

This also provides a nice license boundary if I want to make the control software GPL.

Any opinions on the TCP server architecture, protocols, etc? Could you link the MAXWELL socket protocol you're mentioning?

I am interested in this not because I'm a big fan of the FX2LAs, but because my custom scope will have most of the control logic on PC and send low level control commands to the hardware over USB.

Did you see https://github.com/azonenberg/scopehal-pico-bridge ?

That implements something like what you are mentioning, but for Oscilloscopes from Pico Technology instead of FX2 LAs. Maybe you can get some ideas about protocols from there.

I see. Normal SCPI over the control channel. Is the data plane format standardized?

The data plane format for the Pico bridge isn't officially documented as it's subject to change at this point.

Informally, it's (as of this writing)

uint16 num_channels
uint64 sampleInterval //femtoseconds
for i = 1 to num_channels
    uint64 channelID
    uint64 numSamples
    if channel is analog
        float32 gain
        float32 offset
        float32 phase //offset in fs from trigger event to sample clock
        uint16 rawADCValues[numSamples]
    if channel is a digital bank
        float32 phase //offset in fs from trigger event to sample clock
        uint16 rawDigitalPortValues[numSamples] //data for up to 8 channels in LSB, MSB unused (pico native data format)

I would recommend using something similar as a guideline, perhaps without wasting half the data in the digital banks, but operate under the assumption that you'll be making your own driver in libscopehal. You can probably copy a lot of code from the Pico driver but it will have to be a separate class.

operate under the assumption that you'll be making your own driver in libscopehal

Got it. Wasn't sure if you wanted to unify this protocol. If not, perfectly fine!

The protocol will probably get unified eventually but it's too early to think about doing so now, since we haven't made enough of them to have a good idea of what the needs of different instruments will be.

But the driver side will be different per instrument at least to some extent due to all of the quirks of particular hardware. A sizeable amount of the code in the Pico driver, for example, is implementations of all the rules to see whether a given sample rate is valid for a particular set of enabled channels.