14:28 <_whitenotifier-3> [scopehal-apps] tatjam starred scopehal-apps - https://github.com/tatjam

14:41 <_whitenotifier-3> [scopehal] tatjam forked the repository - https://github.com/tatjam

15:18 <_whitenotifier-3> [scopehal-apps] tatjam forked the repository - https://github.com/tatjam

15:35 <d1b2> <upupa.epops> Welp there we go, it builds :)

15:35 <d1b2> <upupa.epops> https://cdn.discordapp.com/attachments/776941750291267595/1184156586923536505/image.png?ex=658af2c2&is=65787dc2&hm=eecffcd7eb2fe16cfcf058274c636ad207d28972cc58d97749b0833c97e16144&

16:27 <d1b2> <upupa.epops> I'm going to go for the bridge approach to expose an SCPI from OWON's propietary stuff, here's the repo: https://github.com/tatjam/scopehal-owon-bridge I don't have the oscilloscope with me right now, but once I get to the lab I should be able to start working on it 😃

16:29 <d1b2> <upupa.epops> the official program does have an SCPI server but sadly it requires running the whole application, which can be resource intensive

20:04 <d1b2> <azonenberg> oh cool yeah we generally use bridges for anything that doesn't natively speak scpi. and i dont think we currently have any owon support at all

20:08 <d1b2> <upupa.epops> I wonder if other owon scopes use similar protocols, if that's the case maybe the bridge can be useful for the other models too (once made 😉)

20:09 <d1b2> <upupa.epops> the one I have uses some simple but propietary commands over USB

20:09 <d1b2> <upupa.epops> higher end models also have ethernet so maybe different protocol?

20:22 <d1b2> <azonenberg> As a general rule scope vendors tend to have common software stacks across similar models

20:22 <d1b2> <azonenberg> But how similar they are varies

20:23 <d1b2> <azonenberg> extreme examples: Pico has a completely separate SDK for each family, so our bridge has a ton of conditional logic to use different APIs (very close to 1:1 drop in equivalents for each other just with the scope family name in the function name, but there are subtle variations)

20:24 <d1b2> <azonenberg> on the flip side, Teledyne LeCroy scopes made 20 years ago mostly still work with our modern scopehal driver built for their currently shipping products

20:24 <d1b2> <azonenberg> (a few things changed but that's something i intend to add checks for in our driver to support friends who have those old scopes)

20:25 <d1b2> <azonenberg> in between you get scenarios like R&S, who had a pretty common software platform on all of their scopes then decided its time had come for a rewrite

20:25 <d1b2> <azonenberg> so the RTO6 and RTP (and presumably all of their future models under development) use a new software stack with a different command set