<d1b2>
<louis> OK, that should be fixed? Want to make sure that still works right @MP ? (& also someone on windows)
<d1b2>
<louis> but no russh
<d1b2>
<louis> also, re garbage from the tek: the last time i was elbow deep in there doing the chunked transfer stuff I was wondering about trying to implement something that would attempt to recover by terminating and restarting the SCPI socket connection
<d1b2>
<louis> That is an unpursued avenue afaik as far as things to do for Tek (or in general) stability
<d1b2>
<louis> might be worth hacking up a quick python implementation of pulling data as fast as possible from the tek and then quickly iterate on various error recovery approaches and then when reached a happy place try to implement in scopehal
<d1b2>
<MP> yes feex it
<d1b2>
<MP> @louis first firmware upgrade the tek
<d1b2>
<louis> the specific thing you hit: yeah, probably requesting a very large CURV?, timing out waiting for it to get put into buffer, then that getting put into the buffer and coming out as random garbage when the driver queries max bandwidth at startup
<d1b2>
<louis> but that all is to say the basic issue is the seeming lack of any particular reliable behavior when making long-running queries of the tek 🙄
<monochroma>
are modern tek scopes still running linux + (iirc?) tcl/tk application ?
<azonenberg>
monochroma: the MSO5/6 can run either an ubuntu based locked down OS (afaik you dont have shell or any access to it, it just boots up and runs the GUI)
<azonenberg>
or if you pay extra you can get a second ssd with windows on it that runs basically the same GUI
<azonenberg>
but is wide open and lets you do whatever
<azonenberg>
i do not know any details about how the firmware is built under the hood gui toolkit wise
<azonenberg>
@louis: OK i'll merge once i get confirmation
<azonenberg>
@louis: and fundamentally tek's problem is that they have a single global scpi stack
<azonenberg>
vs one per socket
<azonenberg>
i.e. state does not fully clear when you disconnect and reconnect the socket
<azonenberg>
the best option i can think of for recovery s sending a sequence of commands and looking for replies
<azonenberg>
the trick is, you need to avoid the trap of sending *IDN? (wait, read garbage)
<azonenberg>
*IDN? (wait, read garbage)
<azonenberg>
*IDN? (get reply to first query)
<azonenberg>
now you think you're synced but in fact have two more IDN replies to go
<azonenberg>
so you will probably want to alternate IDN with some other command that returns a known/predictable value
<azonenberg>
in such a way that the replies have low autocorrelation
<azonenberg>
i.e. given any subset of the reply string, you can uniquely determine where you are in it
<azonenberg>
then you know how many bytes to discard to achieve full sync
<azonenberg>
it's doable but i never put in the work b/c tek fixing their firmware is the proper solution :p
<azonenberg>
a hypothetical option would be alternating IDN with querying channel enable state but instead of A/B it'd be 1A/1B 2A/2B 3A/3B etc
<azonenberg>
also hard to reproduce reliably for testing
massi has joined #scopehal
bvernoux has joined #scopehal
bvernoux has quit [Client Quit]
bvernoux has joined #scopehal
massi has quit [Remote host closed the connection]
<d1b2>
<MP> @azonenberg per the NDA they wanted us to sign
<d1b2>
<MP> they are fixing it by throwing away SCPI
<d1b2>
<david.rysk> And replacing it with... something proprietary?
<azonenberg>
I mean if its a custom protocol that still has all the same bugs and instability its not any better :p
<d1b2>
<MP> @david.rysk they mentioned to us it was https://grpc.io
<d1b2>
<david.rysk> that's an RPC framework that you use to build implementations on top of
<d1b2>
<david.rysk> so yeah sounds like a custom protocol
<d1b2>
<david.rysk> built on top of gRPC
<azonenberg>
and are they *removing* scpi or adding this as a parallel, alternate API?
<d1b2>
<MP> parallel
<azonenberg>
ah, ok that makes more sense
<d1b2>
<MP> @azonenberg parallel and alternate
<d1b2>
<MP> fairly sure for their desktop client
<d1b2>
<david.rysk> not sure why they don't want to work with the standards bodies though... probably because they want it now
<azonenberg>
my big complaint though is that if it shares the same backend it will be just as bad
<azonenberg>
So for example, if i try to query a property of a channel that's off
<azonenberg>
is it going to return a nice error code, or is it going to hang for 5 seconds and stop responding to traffic? :p
<d1b2>
<MP> @david.rysk if you have a problem and you work with the standards bodies - now you have 17 problems, and 8 committees to investigate the investigation of considering investigating 25 problems, none of those problems related to the original problem 😛
<d1b2>
<david.rysk> isn't HiSLIP supposed to be the replacement? 😛
<azonenberg>
AFAIK hislip is just an alternative to LXI
<azonenberg>
in terms of being a transport layer that scpi lives on top of
<azonenberg>
i have nothing against SCPI as an upper layer protocol, it's bad implementations of it that i dislike
<azonenberg>
things that are single threaded and maintain state across connections, for example
<azonenberg>
if I start downloading a waveform from a scope and my connection is interrupted
<azonenberg>
and i reconnect
<azonenberg>
and you continue spitting waveform data at me before i get a word in edgewise
<azonenberg>
that is not good
<azonenberg>
in fact, ideally i should be able to have multiple concurrent connections to a scope
<azonenberg>
especially if it has features like a function generator
<azonenberg>
i should be able to open one socket to talk to the generator and another to talk to the scope, and the fact that they're co-located in the same chassis should be irrelevant
bvernoux has quit [Read error: Connection reset by peer]