How to Actually Use an Oscilloscope With Netflix-Style Signal Playback
I got asked about this a lot after that video went around last year where someone ran a real oscilloscope feed through a Netflix-style UI and called it "the Scjoeysc King." The term itself is basically fan-made jargon — nobody at Keysight or Tektronix uses it — but the actual technique behind it is legitimate and more useful than the meme version lets on. What people are actually talking about is streaming oscilloscope waveform data into a modern UI framework so it looks and behaves like a Netflix browse interface, with waveform clips organized by capture type, trigger conditions, or protocol decode results. The "alliance" part is just the uncomfortable truth that test equipment vendors still ship desktop software that feels like it was built in 2004, while everyone else has gotten used to streaming media interfaces that just work. Here is how I set it up, not the polished version from a conference talk but the one that actually works on a Tuesday night when your scope is sitting on a bench and you need to compare five different I2C captures side by side.
Step one: get the waveform data out of the scope. Most modern scopes support SCPI over LAN or USB-TMC. If yours does, you can query the acquisition buffer directly. The command sequence I use is straightforward — connect via TCP to the scope's IP, send IDN? to confirm the link, then WFMOutpre:SRC CH1 to set the source channel, followed by WFMOutpre:BYTE CNT to get binary format, and finally WAV? CH1 to pull the actual samples. The scope returns raw bytes that you then decode using the vertical scale, offset, and sample interval values you read from the preamble. This usually takes about three to five seconds per capture on a typical 4-series scope. It is slower than you might hope if you are pulling megasamples at high resolution, and the scope will lock up your other commands while it streams the buffer. I learned that the hard way during a production debug session when I accidentally sent a trigger configure command mid-transfer and the scope hung for forty seconds. Now I queue everything and only poll after the transfer completes. Step two: build the playback UI. You do not need a full web app. A Python script using PyQt or even a lightweight Electron wrapper is enough. I use a simple Flask backend that serves the waveform data as JSON and a React frontend that renders the traces on canvas elements. The trick that makes this feel like a real product instead of a science project is the sampling strategy. Do not try to render every single point. Downsample using the largest-step algorithm — group adjacent points into bins and output the min, max, and average for each bin. This keeps the visual fidelity intact at any zoom level while reducing a 10-million-point capture to maybe eight thousand renderable points. Without this, your browser tab will eat 2 gigabytes of RAM and your fans will sound like a small aircraft. Step three: add the Netflix-style organization layer. This is where the "Scjoeysc King" naming comes from. You create categories based on capture metadata rather than file names. Group by protocol (SPI, I2C, UART), by error condition (break frames, parity errors, missing ACKs), or by amplitude range. Each category becomes a row in the UI, and individual captures are cards you can click to bring up the waveform player. I store the metadata in a small SQLite database on the host machine. When a new capture comes in, the script parses the SCPI response, extracts the relevant tags, and inserts a row before adding the waveform data to the database. This takes roughly two hundred milliseconds per capture on a decent laptop. The database query for a category view — say, all I2C captures with NACK conditions in the last hour — runs in under fifty milliseconds.
There are real limitations to this approach that the enthusiastic posts online tend to gloss over. The biggest one is that your scope has to support the remote commands you are using. Older scopes without LAN connectivity require a GPIB-to-USB adapter, and GPIB transfers at full resolution can take twenty to thirty seconds per channel. You will not be doing real-time monitoring with that setup. Another limitation is that the scope's internal clock drifts. If you are capturing multiple channels and comparing timing across separate acquisitions, the timestamps from the scope's firmware may not line up precisely with your PC's clock. I worked around this by adding a manual sync pulse — a quick square wave generated by a function generator that I capture once at the start of each session, then use as a timing reference to realign all subsequent captures in post-processing. It adds about ten seconds to the setup but saves hours of head-scratching when you need accurate inter-channel timing. If you want the actual tooling, there is no single downloadable binary called "Scjoeysc King." The closest open-source project that implements most of this pipeline is a GitHub repo called scope-ui by a developer who goes by "waveform_fan." It handles the SCPI communication, the downsampling, and a basic React frontend. It is not polished. The documentation is sparse and the README hasn't been updated since 2023. But it is functional for basic use. For anything more complex, you end up writing your own wrapper anyway. The community fork with the Netflix-style browse view exists on a personal GitHub account and is not under any active development, so treat it as a starting point rather than a finished product. I would also recommend looking at what Keysight is doing with their PathWave software and Teledyne LeCroy's WaveSurfer approach. They have already solved some of the harder problems around buffer management and multi-channel synchronization. Their tools are expensive and proprietary, but if you are doing this professionally, the time you save on debugging edge cases is worth the license cost. The open-source route works fine for hobbyist projects and occasional bench use, but you will hit walls around concurrent channel streaming and deep memory buffering that are easier to sidestep with vendor tooling.
Get the Full Details
The core idea behind all of this is simple enough that it does not need a branded name. Take oscilloscope data, stream it efficiently, organize it by meaningful metadata, and present it in an interface that does not make you feel like you are operating a piece of industrial equipment from the nineties. The rest is just implementation detail.
