Siglent SDS800X HD Control Panel | View or Change Scope Settings & State from PC

[CJSouthern]

Because the scope has to dedicate most of its screen real estate to displaying waveforms, a lot of information and settings must, by necessity, be restricted to small information areas or buried in menus.

Personally, I've always found that somewhat "sub-optimal". It often took several actions to dig something out, it was easy to miss that something wasn't quite set right, and there were features I simply didn't bother using because it wasn't worth the effort of going to battle with the interface to beat it into submission.

So I got to thinking: what if I could extend the scope interface onto a full 1920 x 1080 monitor, where I could not only see its current settings and state at a glance, but control it as well?

Then the idea expanded. What if I could also back up and restore preferred configurations, copy screenshots straight to the clipboard or save them to a file in one or two clicks, provide programmable setups and labels, expose commonly used controls directly, and generally make much more of the scope accessible without constantly diving through menus?

It's also evolved into rather more than a remote front panel. It continuously interrogates the scope so that the dashboard reflects its actual state, and can flag settings that differ from either my normal defaults or a state I've explicitly told it to regard as "normal". There are multiple configurable views and control styles, programmable setups, states and labels, quick access to measurements and cursors, reversible reset and undo operations, and quite a lot of functionality aimed simply at making repetitive bench work faster.

It can save, recall and transfer scope setups, make a verified backup of the scope's entire user-accessible file system and restore it later, and grab screenshots directly to the clipboard or a file. There are also different presentation modes so I can choose between a fairly traditional control layout, rotary controls, more compact layouts, or a more physical front-panel style arrangement depending on what I'm doing.

And thus began the trip down the rabbit hole.

Some 500+ iterations and around 40,000 lines of Python later, which is not a misprint, I think it's reached the point where it's worth introducing it to the world and getting some constructive feedback. From there I'll probably choose a handful of interested people to beta test it.

For now I'll start with some screenshots.

As with any project like this, there are competing design requirements. There is a LOT of functionality available, but simply putting everything on screen at once would defeat the purpose. I've therefore tried to make both what is displayed and how it is displayed highly configurable.

There is also a master tooltip control, so the interface can explain itself when required without constantly getting in the way. The tooltip system has become quite comprehensive because, with this much functionality, I wanted someone to be able to explore the interface without having to continually refer to a manual.

The dashboard communicates with the scope primarily using Standard Commands for Programmable Instruments (SCPI) over the network, with Server Message Block (SMB) file access for things such as setup files, screenshots, backup and restore.

If people find the idea useful, the same general concept could obviously be applied to other oscilloscopes and other pieces of test equipment, whether by me or someone else.

Interested to hear your thoughts. Happy to answer questions.

[tautech]

Ahhhhh......as you mentioned Python needs be installed and the .exe install stalled without it.

Please provide a Python download link.

[CJSouthern]

Hi Rob,

I'll be converting anything I release to EXE versions. The EXE version can be compiled into 1 of 2 different flavours though; (1) an "everything in 1 file" or (2) a zipped version that leaves some of the required libraries as separate files.

The (1) flavour is "cleaner" but I did get a false-positive by Microsoft Defender (which, somewhat unhelpfully, quarantined the file until I realised what was going on and over-rode the detection). The (2) flavour didn't (seem to) have this problem.

The version I put up for you a few days ago is very old now; I'll compile a new single-file EXE for you now and send you an eMail with the link. Step 1 when you run it is to let it find the scope; you can click the SCPI button and have it either search the 192.168.0.x and 192.168.1.x ranges, or just type your scope ID in directly. Once found it'll write it to the registry so you won't need to enter it again on that PC.

[CJSouthern]

I thought anyone else considering a similar project might appreciate some of the insights I picked up while working on this.

First up: the rotary encoders.

They can be displayed permanently, appear only on hover, or be replaced by more conventional controls. All of the encoders can also optionally have additional +/- controls for use without a mouse wheel. Of course, the rest of the channel layout then has to shuffle around to make room for whichever version is being shown. That was straight-forward enough.

The fun part was getting the on-screen rotary encoders to feel like real controls rather than remote controls with a long piece of elastic attached.

The panel continuously polls the scope using Standard Commands for Programmable Instruments (SCPI) so that what it displays reflects the scope's actual state. That works well until you start spinning an encoder.

The mouse wheel can generate adjustment events far faster than the scope is being polled. My first approach was the obvious one: every wheel click generated another relative SCPI adjustment. The problem was that I could spin the encoder much faster than the scope could process the resulting command/query sequence. I'd stop turning the control, but the scope would continue stepping through the backlog for another second or two while the panel tried to catch up.

Polling could make matters worse. A poll might return the value the scope had a fraction of a second earlier and temporarily overwrite the value I'd just selected, producing jumps or flicker in the displayed setting. Both contributed to visual glitches, and I really hate things like that.

The eventual solution was to stop treating every mouse-wheel click as an instruction that had to reach the scope.

Instead, the panel maintains an "intended" absolute value locally. If I rapidly turn an encoder from, say, 5 V/div through several steps to 20 V/div, the display responds immediately and the important information becomes simply "the user now wants 20 V/div". Intermediate targets that the scope hasn't processed yet are discarded.

The SCPI worker therefore sends the latest absolute target rather than faithfully replaying every wheel movement. Meanwhile, polling continues to provide the authoritative scope value, but a short-lived pending-value mechanism prevents an older poll from overwriting the new setting while the scope is catching up. Once the scope reports the requested value, normal polling takes over again.

That seemingly simple change made a huge difference. The encoders now feel local and immediate, while the scope itself still has the final say on what value was actually set.

It was one of those cases where drawing a rotary knob was easy. Making it behave convincingly over a network connection was more "challenging".

[KungFuJosh]

I like your concept. However, from a design perspective, I think it would be better if everything were setup like widgets, rather than the section of rows from Setups to Misc.

Cool idea tho!

[EvgenyG]

A tablet version of the same would be great.

[CJSouthern]

I like your concept. However, from a design perspective, I think it would be better if everything were setup like widgets, rather than the section of rows from Setups to Misc.

Cool idea tho!

Thanks Josh,

Are you meaning, as in, "have the functionality contained in each of those individual rows contained in a separate object" so that the user can position it wherever they want? And/or have the ability to run it as a "window" so the PC can be used for other tasks at the same time?

For what it's worth, I kinda wanted it to act and look like a dedicated monitor plugged in to a scope with the appropriate firmware. I was concerned at how "busy" the screen could appear, so created the ability to make it "less busy". I'm toying with the idea of having the waveform displayed when there's room, but there are a few challenges that go with that.

[CJSouthern]

A tablet version of the same would be great.

Thanks - I agree. I toyed with the idea of writing it for a Raspberry Pi with the output sent to a dedicated touch screen.

My problem is that it's optimised for a 1920 x 1080 screen; I know some tablets can exceed that, but either way I suspect it would be challenging to include sufficient functionality on a smaller screen without introducing UI issues. I thought of using a 24" touch screen monitor too, but it's a bit too much of an investment to make at this stage.

[KungFuJosh]

Are you meaning, as in, "have the functionality contained in each of those individual rows contained in a separate object" so that the user can position it wherever they want? And/or have the ability to run it as a "window" so the PC can be used for other tasks at the same time?

That's generally the idea. It's functionally easier to use with a better workflow if everything is set as blocks (widgets). If I have to read individual lines in a big group of lines like it is now, then it's harder to find what I need.

This change will also make it possible to use it on smaller screens like tablets, or adapt to any screen size.

[CJSouthern]

Are you meaning, as in, "have the functionality contained in each of those individual rows contained in a separate object" so that the user can position it wherever they want? And/or have the ability to run it as a "window" so the PC can be used for other tasks at the same time?

That's generally the idea. It's functionally easier to use with a better workflow if everything is set as blocks (widgets). If I have to read individual lines in a big group of lines like it is now, then it's harder to find what I need.

This change will also make it possible to use it on smaller screens like tablets, or adapt to any screen size.

I hear what you're saying, but I don't see how the existing functionality could be put into widgets without either taking up even more screen real estate - or removing some of the functionality.

I've tried to optimise screen usage as much as I could (and as logically as I could); I just don't get how turning it into a widget could work; I'm trying to make the functionality accessible without having to dig through menus or perform additional actions.

eg If, for example, you had a channels widget it would either need to take up a lot of space to show everything - or be reduced to having to only deal with one channel at a time - which is kinda like the scope's actual interface is now which is what I'm trying to extend ... and then you'd still need additional widgets for timebase, triggering, cursors, measurements etc.

Am I missing something here?

[KungFuJosh]

Am I missing something here?

Planning.

For example, the ability to toggle what is visible or not.

However, the specific things I mentioned can easily be made widgets. You only need to decide how they function / interact.

Timebase could be a single small box, and then you decide if the button scrolls through the options, is a dropdown box, etc.

Trigger control could be a box with 3 small rows. It could also be part of the trigger box on the top.

Any of those lines from Setups to Misc could be a button that shows a popup of control options instead of a line taking up space on the screen.

You might want to look at how higher-end touchscreen focused scopes like the Magnova operate for ideas.

[CJSouthern]

Am I missing something here?

Planning.

For example, the ability to toggle what is visible or not.

However, the specific things I mentioned can easily be made widgets. You only need to decide how they function / interact.

Timebase could be a single small box, and then you decide if the button scrolls through the options, is a dropdown box, etc.

Trigger control could be a box with 3 small rows. It could also be part of the trigger box on the top.

Any of those lines from Setups to Misc could be a button that shows a popup of control options instead of a line taking up space on the screen.

You might want to look at how higher-end touchscreen focused scopes like the Magnova operate for ideas.

I thought I had included the ability to toggle what's visible or not; eg if one is primarily focused on changing channel sensitivity & timebase - with a bit of triggering adjustment thrown in for good measure - then every single quick action row can literally be turned off (per the screenshot above). All of the lines from the Setups to Misc ARE buttons that "pop open" the relevant controls.

Fundamentally, I want it to be a dedicated control surface where functionality is far more accessible than what it currently is through the scope's native menu; eg one click to invert any channel (and show visually that it is inverted) rather than have to click/touch that channel on the scope (if it's even still visible at the bottom considering other boxes may have scrolled it out of view) - scroll to the bottom of the channel menu that opens up (taking 3 goes to hit the 2px wide scroll bar, 1px from the right hand side of the menu) - toggle inverted on - then back out of the menu. Rinse and repeat for a lot of other stuff like channel labels all the way through measurements to entire setup states.

I think to do that with widgets would mean (a) one would still need a bunch of them (which would look messy) and if they were to still give access to the same functionality then one would have to start burying stuff - which would potentially obscure non-normal "gotcha" states (like an incorrect measurement because distortion is fooling a histogram into thinking it's at a peak because it's using the wrong detection mode ... but it's not visually obvious). Then one would also have to decide between things "popping out" on hover (which I think would be far more triggering for me than it would be for the scope) - or one would have to "go digging" to open stuff up - which, again, kinda defeats the purpose of the whole thing.

It's certainly trivially easy to make little panels that individually do various things - but I think that probably fits better with someone having a PC on a desk doing several things - including being able to tweak a sensitivity / timebase / run state on a scope on the network - but that's really a different usage direction.

Thanks for the Magnove head-up; I'll try to find someo online content and see if it gives me any ideas.

[EvgenyG]

A tablet version of the same would be great.

My problem is that it's optimised for a 1920 x 1080 screen; I know some tablets can exceed that, but either way I suspect it would be challenging to include sufficient functionality on a smaller screen without introducing UI issues. I thought of using a 24" touch screen monitor too, but it's a bit too much of an investment to make at this stage.

That is a real-world use case: sometimes I have a DUT sitting on my desk that occupies like half of it. It makes it difficult to reach out to the scope to change parameters and would be even more difficult to reach out to a touch screen or keyboard/mouse that just got tucked in between the screen and the DUT. If I had software running on a tablet, I could put it anywhere I have free space at that moment.

[CJSouthern]

A tablet version of the same would be great.

My problem is that it's optimised for a 1920 x 1080 screen; I know some tablets can exceed that, but either way I suspect it would be challenging to include sufficient functionality on a smaller screen without introducing UI issues. I thought of using a 24" touch screen monitor too, but it's a bit too much of an investment to make at this stage.

That is a real-world use case: sometimes I have a DUT sitting on my desk that occupies like half of it. It makes it difficult to reach out to the scope to change parameters and would be even more difficult to reach out to a touch screen or keyboard/mouse that just got tucked in between the screen and the DUT. If I had software running on a tablet, I could put it anywhere I have free space at that moment.

I know the feeling; my DUTs tend to sit in the middle of the bench and make it ackward to get to screens behind them.

I could connect to the PC via TeamViewer on my 13" Pro tablet, but I suspect it would probably be a lot better for monitoring than controlling. Maybe someone who's into app development might pickup the concept and run with it; I'm interested to know what kind of market there is for things like this given that SCPI exposes practically everything (at least on the Siglent lineup); I'm finding it extraordinarily powerful (once one has discovered it's quirks / bugs).

[Sorama]

Would your software also work on other siglent scopes like the sds2204 x plus (8 bit) ?

[CJSouthern]

Would your software also work on other siglent scopes like the sds2204 x plus (8 bit) ?

The present version has been developed specifically around the SDS800X HD family and its particular Standard Commands for Programmable Instruments (SCPI) behaviour, responses and menu/state handling. The SDS2204X Plus does have its own Siglent programming guide and uses the same general SCPI approach, so I’d expect a fair amount of overlap, but I wouldn’t assume command-for-command compatibility.

The fact that the SDS2204X Plus is 8-bit rather than 12-bit probably isn’t the important issue. The bigger questions are whether all the commands I use exist on that model, whether they return the same values, and whether things like setup files, measurements, cursors, references and screenshots behave the same way, etc.

So most likely a case of "very doable", but "someone would need to put the work into it". It probably wouldn’t take a huge amount of work, but it wouldn’t be practical to do it blind. One would really need access to one for testing and verification.

So I’d say the concept should certainly be portable to it, and quite possibly much of the code would carry straight across,

[CJSouthern]

Am I missing something here?

You might want to look at how higher-end touchscreen focused scopes like the Magnova operate for ideas.

As promised, I took a closer look at the Magnova (via a long online review) (I understand that you own one from reading other posts too -- lucky you!).

In summary ... nice scope - nice screen - I'm envious of the probes - and having interaction with it's creators here about it's design / features / improvements / bugs etc is nothing short of "next level" + "new benchmark" territory. I'd sell a kidney to be able to tap into that.

But having just said all that, as I see it, it's still constrained by much the same interface limitations as most other scopes (and certainly those at the affordable price point). The harsh reality is that most of the screen real estate remains reserved for the waveforms - so everything else has to be either summarised into the available remaining realestate - or buried in collapsing menus (no matter how nicely they're designed).

With my control panel it's really a case of "summarised info and structured menus in limited space - even on scopes like the Magnificent Magnova" vs "a 24 inch screen, 100% of which is dedicated to the interface where (a) a complete overview remains visible all the time (and outliers are flagged) and (b) it's much faster to get to / do things (which aids the workflow).

Case in point, I assume that to change channel info on the Magnova you'd need to tap the relevant channel soft key and then manipulate the relevant encoder. In contrast, with my control panel, ALL controls for ALL channels are ALWAYS a mouse movement away - including up to 12 encoders (sensitivity, offset, and deskew) x 4. I can even hold down the alt key and adjust the same control on all 4 channels simultaniously - or alt-double-click a swatch to turn off every other channel if I want to focus on a channel of interest ... or literally Ctrl+C -> Ctrl+V a configuration from one channel to every other channel.

Not trying to say it's for everyone (although having just said that, if one likes turning physical knows there's nothing to stop them doing that and just retaining the overview on the control panel) - but I'm finding it brutally efficient but - of course - at the expense of having it run on a dedicated 24" screen while it's operating.

[KungFuJosh]

My point wasn't to adopt the overall flow of it (even though I do love the workflow of the Magnova). My point was specifically about the few optional buttons you're using that expand into long rows and take up screen space. The way Magnova works with the popups and UI/UX in general is excellent.

If you took some inspiration from that for specifically those rows I mentioned previously, I think it would improve the interface. Which BTW is already looking better.

The big thing I would suggest is leaving the trigger controls active always in the top right corner of the screen where you already have trigger settings displayed. If I was designing it, I would integrate the trigger controls and trigger info into the same box to remove redundancy and improve the UI/UX. That's the biggest change I would make, and IMO it's not that significant.

Just my opinion here (FWIW, design is my day job); I won't be offended if you don't agree.

Thanks,
Josh

[CJSouthern]

The buttons you mention ("quick action row toggles") started out not being clickable but, of course, as functionality was added, the screen quickly became cluttered - so phase 2 made them collapsable.

Not long after that, I developed the "physical layout view" (with the timebase, delay, trigger level, and holdoff encoders on the right - and then the bunch of related buttons underneath them. And shortly after that, added the alt-physical view layout that moved the channel strips from being across the bottom (similar to how they are on the actual scope) to aligning them vertically next to the other encoders - so the controls that I'm using 95% of the time are all in the one place.

It was a hop, skip, and a jump from there to allow any swatch to be dragged to move the whole shooting match into the center; collapsing any quick action rows in the process (but restoring their remembered positions if moved back).

Reason I mention all this is that - for the most part - the quick action rows don't usually get used anymore once setup for the task is complete (with the possible exception of cursors);

- Measurements are assigned to buttons for quick access when needed - but once configured, remain in the measure strip across the bottom (which, incidentally, can be rotated vertically with an equivalent functions strip and or references strip (if enabled) by rolling the mouse wheel over any swatch at the bottom - a bit like a set of revolving number plates on a 007 car)

- Labels - much the same; typically assigned to channels before the job starts.

- States - again - chosen to setup the scope for particular presets before the job starts

- Setups - used even less often

- Misc - mostly just random / housekeeping stuff that's not used regularly (sync time / SCPI log / Rescan References (the SCPI commands aren't sufficient to track references properly) / Normalise warnings for the session etc).

So for the most part the rows are all in a collapsed state during normal operation (much like menus) - and get re-collapsed at the flick of a mouse by dragging a channel swatch.

Most of the functionality in the upper panels can be interacted with; it highlights on hover. My thinking was "since we need to display it anyway, why not"; it results in a little duplication but I thought it was more important to have things like trigger channel selection "where the action is".

My current philosophy is "try to add a lot of gestures so that things can be done quickly if the gesture is remembered" (and there is a help system and tool tips to assist with that) - but make it both consistent and optional so that it's still very usable with even the simplest gestures (single click to shift the focus or change a toggle - double-click to show/hide something etc) - and add additional personalisations in a global settings area (eg personally I like to roll the mouse wheel up to make a waveform bigger vertically or spread it out more horizontally- or hold both mouse buttons down to put a screenshot on the clipboard). There's also various built in boarder / control flashes / changes to give visual feedback as to what's happening so, for example, you know when a mouse button has been held down long enough to execute a guarded/destructive function like a reconfigure.

Currently adding functionality to ALT-Click controls like bandwidth to have it simultaniously change all currently enabled channels. Work in progress.

[KungFuJosh]

It sounds like it's developing nicely. I still recommend changing the trigger box to be more obviously functional (and not needing a separate control set). You already have the Display / Refs box on the other side looking more functional, so it will balance out nicely.

[CJSouthern]

Thanks. I'm not sure that I'm following you about changing the trigger control functionality though; if you're meaning in the upper panel then I can already change the source / coupling / noise reject from up there (will add level and holdoff when I get around to it) - but mostly I'm wanting to change between auto / normal / single - change the source - run/stop - or go to roll mode - in conjunction with changing the trigger level and sometimes the holdoff - so it made sense to me to have all those controls grouped in one place; and of course many are separate buttons on a scope for the same reason (convenience).

I mostly just use edge triggering day-to-day but I am planning to add more of the other modes so that part of the upper panel will probably get a lot more added - with more configurability - whereas the bottom controls will probably be fairly static (albeit with a bit of tuning eg, perhaps, just having the trigger source cycle through the available sources and save a few buttons).