ok so the MHO98 logic analyzer is. not good. at all.

and the protocol decoders are basically not useful, i can see why they haven't bothered implementing even 10 of them (they only decode what's exactly on screen, like on the lower end models)

it's best understood as "logic analyzer attachment to orient you for where you want to see your analog traces" more so than a "logic analyzer" per se in any meaningful sense of the term

i was kinda hoping that it would be a useful option and... i think it will be for me (i have an application for it next week), but only barely, and that's really disappointing. probably the first thing that made me unambiguously unhappy with the scope so far

i assume you can still grab the data for use with a third party frontend, but that's sort of defeating the purpose of an oscilloscope as a complete self-contained instrument (which is what i expect from mine)

@whitequark It’s amazing just how much oscilloscope capabilities are limited solely by the firmware GUI front-end. And of course vendors will never create an extensible one to solve this problem (unless the scope has Windows, or its name is National Instruments), otherwise nobody will buy the high-end models.

@whitequark If all you wanted was a scope and a logic analazer (not counting the convenience of having them combined), I'm guessing you need to aim quite a bit higher to get something comparable to something like an LA5032?

@slaeshjag no i specifically want them combined. if i just wanted an LA i have the glasgow

@niconiconi _does_ rigol even have a higher end model with a non-awful protocol decoder?..

i would describe the MHO98 'logic analyzer' as 'a tool suitable for understading the relationship of the digital signals to analog signals at a glance, and perhaps reading the digital signals slightly faster and more reliably than you could do by tapping the screen with a pencil'

it is not 'a logic analyzer' or 'useful for reading the values off digital buses'

i believe knife enthusiasts invented the term 'knife shaped object' for this exact circumstance

@whitequark

@niconiconi Yes exactly

@whitequark I'm a knife shaped object

@Lynx nice.

@niconiconi @whitequark and this is why ngscopeclient exists, although I wouldn't expect great performance downloading data from a Rigol as historically that has been one of their biggest weaknesses.

(Now that we've got packaging/installation figured out for all major OSes, and we've fixed the performance bug on intel iGPU, can i convince you to give it another try?)

@azonenberg @niconiconi yes... but it has to be on the MHO98 :P

(there's a non-24k-gold-nameplate series it's basically identical to which can be used as reference, and i'm entirely willing to donate time on my scope as per usual)

@azonenberg @niconiconi to be clear this isn't just me being fickle; I think the TCP/IP implementation of the DS1000 series is probably too far gone to coax anything of value out of it for me, but the MHO900 series is built on a Rockchip platform that has as much power as my smartphone and I see no god damn reason it cannot be performant enough

@azonenberg @niconiconi (and then the DS1000 becomes a gift for someone else or just a secondary shop scope for low-end tasks, haven't decided yet; it is quite heavy in comparison to the tablet-weight MHO98, and i really like upgrading to physically lighter equipment...)

@whitequark all I can think of is nirvana's heart-shaped box which feels like the perfect place to keep a knife shaped object

@whitequark @niconiconi The only potential reason is "their firmware / architecture was not designed with this in mind or they didn't care about remoting performance".

As someone who's looked at a lot of SCPI implementations and scope architectures, they vary widely in how performant they are for this use case.

And it's not just high/low end stuff (although low end scopes are more likely to be slow either due to underpowered hardware or underpaid firmware engineers not putting in the effort to optimize).

The Tek MSO5/6 series for example is a midrange to high end scope by almost any definitions, and yet its SCPI performance is worse than some scopes from Teledyne LeCroy that cost half as much. And it's also one of the most cursed, braindead SCPI implementations ever featuring such joyful features as "global protocol state that's stateful across socket disconnect/reconnects so if a client drops due to a network issue the next client to connect might get data that had been intended for them".

@azonenberg @niconiconi there is so much random... crap... lying around in the firmware that it would probably be trivial to interface to the kintex inside, lmao.

@whitequark @azonenberg @niconiconi I have seen something like this in commercial radio gear, which may have great baseline performance and build, but have very mid he support for digital waveform compared to open source software implementations. That said, it is reflected in pricing, e.g: $900 for consumer hw + OSS; $3000 for commercial hw; $30k for military hw.

@whitequark @niconiconi As long as the interface between the kintex and the rockchip isn't like 115200 8N1 UART or something... from some of the scopes I've looked at you'd think that was how they worked because of how slow they worked lol.

(Which kintex out of curiosity?)

@azonenberg @niconiconi i think it's pcie? i see some xillybus stuff, some pcie references in scripts

@azonenberg @whitequark @niconiconi I assume some SCPI implementations still assume you're going to boop the device over GPIB from BASIC on your HP computer, because of course

@recursive @whitequark @niconiconi most scpi stacks are based on the gpib model still. This can but does not always imply being slow and crufty.

LeCroy VICP is literally GPIB over TCP complete with bits in the header for EOI. But it works very well, it's fast, and even supports pipelining multiple requests/replies.

@azonenberg @whitequark @niconiconi eevblog forum users claim it's a Shanghai Fudan Microelectronics clone / technology-transfer fpga, not a kintex!

@r @azonenberg @niconiconi i only looked at the bitfile, not the actual device

tech transfer?