<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3gZC
<_whitenotifier-3>
[scopehal] azonenberg bda6ab2 - PicoOscilloscope: correctly position WIP trigger to midpoint of signal regardless of other configuration. Implemented trigger phase interpolation.
<azonenberg>
Ok so the pico driver got a lot more usable over the past few days
<azonenberg>
Fixed a bunch of crashes, incorrect offset calculation, and added trigger interpolation
<azonenberg>
Still have to add digital channel support, and all of the fancy triggers are still pending
<azonenberg>
But this is progress
<azonenberg>
oh and i have to do high res mode still
<azonenberg>
That will be nice, all of my other scopes are 8 bit only
<azonenberg>
so having the 10/12 bit mode even if lowish sample rate will be convenient
<noopwafel>
so I guess it's easy enough to also hack signal generator config into the scpi bridge
<azonenberg>
Yes. I have several scopes with siggens that i have to finish
<azonenberg>
right now there is basic siggen support in the libscopehal API under the FunctionGenerator class, which an instrument can inherit from as well as Oscilloscope
<azonenberg>
however there is no UI side support in glscopeclient to call any of those methods
<noopwafel>
so in the worst case I can stick a relay on the socket between the scpi bridge and scopehal
<azonenberg>
Sooo that's actually something i was thinking of doing
<azonenberg>
Having the bridge expose a *different* socket socket for the AWG
<azonenberg>
So you can use it from other code should you so desire
<azonenberg>
or have a separate picoscope siggen driver that would connect to it
<azonenberg>
that's one thing that bugs me about the combo instruments that have only one socket
<noopwafel>
that might be more elegant, and you can keep the global mutex
<azonenberg>
if you connect glscopeclient for example you can't have a test script talking to it
<azonenberg>
Exactly
<noopwafel>
since then you can also actually *reply* to things
<azonenberg>
They're logically separate instruments
<azonenberg>
I wish scopes would let you do that
<azonenberg>
but ~every scope i've seen has only one concurrent scpi connection allowed
<azonenberg>
They're still in the GPIB mindset
<azonenberg>
not thinking about it as a server
<azonenberg>
to me, an AWG and a scope are two services running on the same physical host
<azonenberg>
for that matter, the frontend and the acquisition subsystem are separate services to me
<azonenberg>
Hence why my bridge has separate control and data plane sockets
<d1b2>
<mubes> On Orbuculum there's only a single connection to the trace so we mux it out for clients to use. That's mostly one-way though, would be more difficult to do something bidirectional and keep proper control of resources. A 'proper' socket interface is much more flexible for the future though...
<d1b2>
<zyp> but the trace pipe from the hardware is still logically separate from the control plane
<d1b2>
<mubes> yup, should have mentioned that bit 🙂
<d1b2>
<mubes> Whats the trendy RPC mechanism the kids are all using nowadays? CoAP? AFAIK its nicely RESTFul. Provided you have a maximum of one controller at a time you could have multiple observers...would want to keep the data plane separate anyway!