00:51 <d1b2> <dranonymous8117> @azonenberg Just wanted to let you know that I’ve worked on the 1553 decoder stuff and have a few ideas. It will probably be a bit before I’m ready to make a pull request.

00:56 <d1b2> <azonenberg> Sounds good, keep me posted

08:13 <_whitenotifier-4> [scopehal-apps] azonenberg closed issue #776: g_vkTransferQueue error when context menu spawns a new platform window - https://github.com/ngscopeclient/scopehal-apps/issues/776

08:14 <_whitenotifier-4> [scopehal-apps] azonenberg commented on issue #776: g_vkTransferQueue error when context menu spawns a new platform window - https://github.com/ngscopeclient/scopehal-apps/issues/776#issuecomment-2667866482

16:56 <_whitenotifier-4> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/f793ceb7d634...1ff6d5a8dbcd

16:56 <_whitenotifier-4> [scopehal-apps] azonenberg 1ff6d5a - Initial Y axis cursor support, incomplete. See #527.

22:01 <d1b2> <josHua> ok I'm about to do something deeply chaotic

22:04 <d1b2> <josHua> does ngscopeclient support Tek MSO44?

22:04 <d1b2> <josHua> I'm about to drive one over wireguard halfway across the country.

22:05 <d1b2> <david.rysk> I see support for MSO5 and MSO6; I suspect MSO4 uses the same protocol (it's in TektronixOscilloscope.cpp)

22:06 <d1b2> <josHua> this is gonna be slow if this works

22:32 <d1b2> <azonenberg> Never tested but probably works to some degree

22:32 <d1b2> <azonenberg> likely sample rate and memory depth settings won't work as it's not in the table of models it knows about

22:33 <d1b2> <azonenberg> (but could be easily added)

22:33 <d1b2> <josHua> it indeed did not know this

22:33 <d1b2> <azonenberg> i will warn you that the tek backend is generally a bit unstable, but it's on the scope side not ours

22:33 <d1b2> <azonenberg> i have had MSOs randomly lock up, bluescreen, or segfault while trying to drive them via scopehal

22:33 <d1b2> <azonenberg> or start returning gibberish to commands because their scpi stack is stateful across socket connections

22:33 <d1b2> <azonenberg> so if you close a socket due to a crash or network blip between sending a request and getting a reply

22:33 <d1b2> <azonenberg> you may get that reply to the next command you send it on a new socket

22:34 <d1b2> <azonenberg> yes it's that broken

22:34 <d1b2> <josHua> currently I am using their web VNC client across the world's slowest link, with someone driving locally, which seems to work

22:34 <d1b2> <azonenberg> i've been pushing them for a long time to fix it

22:35 <d1b2> <josHua> using ngscopeclient to get data over SCPI may not fly anyway just because of how unbelievably slow this link is