skipwich has quit [Remote host closed the connection]
skipwich has joined #scopehal
Bird|ghosted has joined #scopehal
Bird|ub3rghosted has quit [Ping timeout: 256 seconds]
merbanan has quit [Remote host closed the connection]
merbanan has joined #scopehal
ALTracer has joined #scopehal
ALTracer has quit [Quit: Quit]
t4nk_freenode has joined #scopehal
cyborg_ar has quit [Ping timeout: 248 seconds]
t4nk_fn has quit [Ping timeout: 248 seconds]
cyborg_ar has joined #scopehal
t4nk_freenode is now known as t4nk_fn
<d1b2>
<elemecca> Hi all, I'm interested in adding support for the 1990s Tektronix TDS series oscilloscopes (TDS 4xx / 5xx / 6xx / 7xx) over GPIB.
<d1b2>
<elemecca> They're technically pre-SCPI, but they use a very SCPI-like command set.
<d1b2>
<elemecca> It looks like the commands and state are quite different from the existing MSO 4/5/6 TektronixOscilloscope driver.
<d1b2>
<elemecca> Should I just create a new driver class? What should I call it?
<d1b2>
<elemecca> I could call it TektronixTDSOscilloscope, but there are other scopes with the TDS name which have different command sets, or at least separate programming manuals: the TDS 3xx series, the TDS 2xx/10xx/20xx series, the TDS 30xx series, and the TDS 50xx series.
<d1b2>
<elemecca> Although I haven't read through the programming manuals for those series yet; it's possible that they're similar enough to handle with conditional checks based on the model.
<d1b2>
<azonenberg> So, as long as they understand *IDN? you dont have to do anything special in a driver
<d1b2>
<elemecca> Yeah, they're all 488.2-1987, so they have *IDN?
<d1b2>
<azonenberg> (if they do not, there's a boolean argument to the SCPIInstrument constructor that you can pass to make the base class not send *IDN? during initialization, at which point your driver is responsible for populating those fields as you see fit)
<d1b2>
<azonenberg> by default the base class will send *IDN? and parse the reply before your driver does anything
<d1b2>
<azonenberg> from then on, all commands are up to your driver
<d1b2>
<azonenberg> it does not in any way have to be scpi spec compliant
<d1b2>
<azonenberg> Generally speaking the decision of whether to use quirks mode in an existing driver or add a new driver class depends on how dramatic the changes in the API are
<d1b2>
<azonenberg> if the answer is "there is nothing in common except the company logo on the box" a new driver makes sense
<d1b2>
<azonenberg> I would say "tds4" or something might not be a bad name for the driver (internally TektronixTDS4Oscilloscope), then in the documentation you can list the models it's known to work with and ones that you think it probably works with but haven't tested
<d1b2>
<azonenberg> and then if someone wants to support a similar model with quirks modes in the future, we can cross that bridge when we come to it
<d1b2>
<azonenberg> because linux-gpib is GPL licensed so we keep any code touching it separate from the scopehal core
<d1b2>
<azonenberg> (this isn't a problem for scope driver code because it just is handed a SCPITransport object and doesn't care if the transport is from a plugin or not)
<d1b2>
<azonenberg> i.e. you don't have to GPL or plugin-ify your driver
<d1b2>
<azonenberg> but if you want it to work on windows or macos, you're going to have to figure out how to make a SCPITransport for GPIB on that platform and that's way beyond my expertise
<d1b2>
<elemecca> Would you be interested in a non-GPL GPIB implementation for Linux? The device driver modules are now in the upstream kernel, so the ioctl interface for GPIB devices is now public API and it should be pretty easy to write a SCPITransport implementation which talks directly to the kernel device without linking libgpib
<d1b2>
<azonenberg> yes, very much so. that would let us move the gpib transport back into the core and get rid of the linux-gpib based plugin
<d1b2>
<azonenberg> it's way too late to get it in v0.1 which is going to ship as soon as we fix some macos packaging issues
<d1b2>
<azonenberg> but it would be great to have for v0.2
<d1b2>
<elemecca> OK, I'll play around with that as well, and possibly a SCPITransport wrapper for NI-VISA for Windows.
<d1b2>
<elemecca> I might need to break or extend the SCPITransport abstraction for the TDS scopes I'm targeting - they seem to assume you can access the GPIB status byte for error recovery. I should be able to make something that works fine on the happy path with just a bidirectional character stream, but it will have problems with desyncing in the face of errors unless I can read the status byte and force certain commands to be sent at the start of a
<d1b2>
message.
<d1b2>
<elemecca> Looking through the existing TektronixOscilloscope driver, it looks like the MSO scopes speak the same protocol as the TDS scopes, but of course they have a bunch of commands that the TDS scopes don't support since they're 20 years newer.
<d1b2>
<elemecca> So I'll start out trying to add conditionals off the *IDN? model string to the existing class for now, and if there end up being way too many of them I'll break it out into its own class.
<d1b2>
<azonenberg> interesting. if we get to that poitn we can talk in more detail
<d1b2>
<elemecca> It looks like you have exactly the same desync problems with the MSO scopes but no GPIB signaling to fall back on, for what that's worth.
<d1b2>
<azonenberg> yes, tek's scpi implementatino is one of the most unstable i have encountered ever
<d1b2>
<azonenberg> i hate it
<d1b2>
<azonenberg> it's stateful across reconnects
<d1b2>
<azonenberg> like you can close the socket and reconnect and in some cases you get replies to a previous client's request
<d1b2>
<azonenberg> (if it crashed before the reply was sent)
<d1b2>
<azonenberg> their stack still pretends they're running over gpib
<d1b2>
<azonenberg> its a nightmare
<d1b2>
<azonenberg> i had a mso6 on loan from tek as a dev scope a year or so ago to play with their new high speed grpc interface before it was officially announced
<d1b2>
<azonenberg> it was so unstable and painful to work with i basically gave up and sent it back
<d1b2>
<elemecca> Huh, yeah, the older scopes that actually use GPIB have a handshake protocol in the programming manual for resetting the command parser on a new connection that's quite reliable, but it depends on GPIB-specific signalling. It sounds like they just didn't replace that when they moved to non-GPIB transports.
<d1b2>
<azonenberg> lol
<d1b2>
<azonenberg> interesting. i wonder if there is some way to do this over LXI and i just didn't know that was a thing
<d1b2>
<azonenberg> fwiw, LeCroy's VICP is basically gpib over raw tcp sockets with a custom binary protocol
<d1b2>
<azonenberg> they have header fields in the binary framing for GPIB EOI etc
<d1b2>
<azonenberg> but it's extremely stable and reliable IME
<d1b2>
<azonenberg> their stack resets on a new tcp connection and i've only crashed it once or twice total
<d1b2>
<azonenberg> i've bluescreened mso6s several times a day during driver dev
<d1b2>
<azonenberg> also VICP lets you pipelined-send multiple commands and then get replies to them in sequence without lockstepping req/resp
<d1b2>
<azonenberg> if you send two commands to a tek scope before the first reply comes back it'll just drop the second one and you hang waiting for a reply that's never going to come
<d1b2>
<azonenberg> if you ever try to send a query to e.g. a channel that's not turned on, it'll drop it silently
<d1b2>
<azonenberg> there's just so many broken error cases where it doesn't do the obvious right thing
<d1b2>
<elemecca> Huh. The TDS scopes don't do that. I've piplined my TDS784 like 8 commands deep before with no issues.
<d1b2>
<azonenberg> lol interesting. well the msos i was never able to pipeline successfully
<d1b2>
<azonenberg> i do it on other scopes all the time
<d1b2>
<azonenberg> in general the mso4/5/6 scpi stack is the least stable and performant stack i've seen from a big-name high end scope
<d1b2>
<azonenberg> stability wise it's worse than siglent's
<d1b2>
<azonenberg> although it is a little faster than siglent for waveform download usually
<d1b2>
<azonenberg> but it's still one of the worst performing of major scope vendors
<d1b2>
<azonenberg> like an order of magnitude lower wfm/s than lecroy at the same memory depth
<d1b2>
<azonenberg> i think ~60ish Mbps is the most i've ever got off a mso6 while my lecroy sda816zi-a i've pushed 800
<d1b2>
<elemecca> The TDS scopes can only do 8 Mbps, of course (because GPIB), but they can saturate that with waveform downloads.
<d1b2>
<azonenberg> yeah its one thing if the scope itself cant do any faster
<d1b2>
<azonenberg> but i'm talking about something with gig-e on it
<d1b2>
<azonenberg> the scpi stack is just garbage
<d1b2>
<elemecca> Yeah, that's wild.
<d1b2>
<azonenberg> now i'm not saying lecroy is free of sin
<d1b2>
<azonenberg> many of their more advanecd commands are only accessible via the VBS SCPI command
<d1b2>
<azonenberg> which runs a line of vbscript
<d1b2>
<azonenberg> which you can then use to poke properties of an OLE Automation object that is the "real" remoting API
<d1b2>
<azonenberg> the logic analyzer peripheral returns "waveforms" as ascii 1s and 0s, i forget if base64 coded or not, in an xml CDATA block along with some other xml metadata
<d1b2>
<azonenberg> instead of the binary format used by analog channels
<d1b2>
<azonenberg> but despite this cursedness it's reliable, stable, and (other than the LA which is usb2 attached and slow as hell) reasonably fast
<d1b2>
<macaba> Writing the SCPI implementation for TS.NET with minimal effort naturally yielded me the ability to pipeline loads of SCPI requests and get replies in sequence with no thought. I have to wonder what these scope vendors are doing that would require a fixed req-resp
<d1b2>
<azonenberg> pretending they are an 8051 with 2 kB of RAM running a scope from the 1970s with a gpib interface
<d1b2>
<macaba> Maybe a tiny size of receive buffer?
<d1b2>
<azonenberg> and yes, i agree
<d1b2>
<azonenberg> this is the natural way to do a socket based api
<d1b2>
<azonenberg> i dont understand how they are doing it
<d1b2>
<elemecca> To be slightly fair, Tek is pretending they're running on an m68k and speaking GPIB 1987 on a scope from the 90s.
<d1b2>
<elemecca> I have some GPIB instruments from the 70s. They're a lot less pleasant to work with.
<d1b2>
<azonenberg> lol
<d1b2>
<azonenberg> you're not helping their case :p
<d1b2>
<david.rysk> Why???????
<d1b2>
<azonenberg> because the codebase is probably directly descended from the firmware on that scope
<d1b2>
<azonenberg> why do you think lecroy scopes in 2025 are still activex based internally
<d1b2>
<azonenberg> it's the same XStream architecture they used when the things ran win2k / xp and had floppy drives
<d1b2>
<elemecca> Do we have anyone who has an MSO 4/5/6 and can test that platform?
<d1b2>
<elemecca> Ah, right, OK. The TDS series does the same thing as the MSOs that kills pipelining: it clears the output buffer at the start of each bus message received, so you can't pipeline queries. You can pipeline commands, but then you can't rely on the command's response to indicate when it's done and instead need to use one of the status polling mechanisms.
<d1b2>
<elemecca> You also can send multiple queries semicolon-separated in one message, but then you get all the responses semicolon-separated in a single message as well.
<d1b2>
<azonenberg> huh i tried semicolon separated in the MSOs iirc and it didnt work? i cant remember
<d1b2>
<azonenberg> anyway it's just generally cursed and slow and buggy :p
<d1b2>
<elemecca> I don't know how well the concept of messages maps to an LXI transport. In GPIB you can write arbitrarily long messages to the device (even interleaved with other bus traffic) and it doesn't consider the message ended until you either send an LF character or assert the GPIB EOI flag (or both).
<d1b2>
<elemecca> Heh, big chunks of the MSO 4/5/6 programmer manual are word-for-word identical to the TDS 400/500/600/700 programmer manual from 1997.
<d1b2>
<elemecca> So on the upside, I can almost certainly keep the TDS and MSO scopes in the same driver (because the MSO scopes talk like they're from 1999).
<d1b2>
<azonenberg> lol yay
<d1b2>
<azonenberg> yeah if you can just add quirks to turn off all the new features
<d1b2>
<azonenberg> it should be easy enough
<d1b2>
<azonenberg> making it stable and reliable might be harder :p
<d1b2>
<azonenberg> but nobody is actively maintaining that driver at all right now afaik
<d1b2>
<azonenberg> so if you wanna take it over that would be geeat