<azonenberg>
Made good progress today assembling MEAD pods but ran out of the little plastic spacers I use for the input boards
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
<_whitenotifier-a>
[scopehal] bvernoux synchronize pull request #481: Add support of PicoScope3000 MSO (16chan option) - https://git.io/Js0o0
bvernoux has quit [Quit: Leaving]
<Degi>
Does anybody know if the sideband wires of SFF-8087 are good for transmitting a 100 MHz reference clock?
<azonenberg>
Degi: Hmm
<Degi>
Though I guess otherwise a few € ref clock on the board won't be too bad
<azonenberg>
Single ended or differential? and what's on the other sideband signals?
<Degi>
Differential, maybe 12 V DC or just ground.
<Degi>
Maybe I²C
<azonenberg>
i am not a fan of the idea, they're probably not controlled impedance or routed with any level of SI and mind. You could probably make it work but jitter might be a problem, as would EMC
<azonenberg>
in mind*
<Degi>
Hm okay, then local refclk and SFF-8088 is probably better anyways for external use.
<azonenberg>
8087 is still reasonable if you need i2c and other slow stuff
<azonenberg>
but local refclk is probably a good idea
<azonenberg>
Or use one of the high speed pairs of course
<Degi>
Not really I think, just the high speed pairs should be fine.
<Degi>
Though I need all 8 pairs already
<azonenberg>
On a related note, i'm about halfway done with final assembly of the first batch of MEAD pods
<Degi>
I wonder how feasible it is to transmit stuff in common mode on them
<Degi>
Nice!
<azonenberg>
Discovered one more thing I have to do
<azonenberg>
The 3D printed prototype enclosure had nice square corners
<azonenberg>
The CNC milled one has rounded corners due to the cutter radius
<azonenberg>
The PCB has square corners and fairly tight clearances
<azonenberg>
so i have to sand two of the corners for it to fit
<azonenberg>
just taking a mm or so off the very corner where the mounting screw is
<Degi>
Oh okay, a thing for the next revision xD
<azonenberg>
next rev would probably include mechanical improvements too
<azonenberg>
as far as making the pod a lot smaller
<Degi>
Neat
<Degi>
Do you usually sand under water or some solvent to prevent dust?
<azonenberg>
It depends. In this particular case I did it dry because the area was so small
<azonenberg>
I have done wet sanding too
<Stephie>
I got a used NI VirtualBench today (basically scope+logic analyzer+sig gen+dc psu+5.5digit DMM in a tiny box accessible over tcp)
<Stephie>
would people be interested in a scopehal frotnend for it?
<Stephie>
i assume just the scope and logic analyzer part would fit
<azonenberg>
Sure, why not
<azonenberg>
We do have multimeter support too
<Stephie>
oh neat
<azonenberg>
signal gen and power supply as well in the API however no GUI for them yet
<azonenberg>
this is going to get important for multifunction instruments like, for example, the AWG integrated on a lot of lower end oscilloscopes
<Stephie>
i wasnt sure of the extent of scopehal's API/scope
<Stephie>
yeah
<Stephie>
this device has like, *everything*
<Stephie>
even digital IO
<Stephie>
so it'd be a good testcase
<azonenberg>
basically libscopehal is intended to be a VISA replacement
<Stephie>
thats awesome
<azonenberg>
then libscopeprotocols is for all of the postprocessing once you have a waveform and want to make sense of it
<Stephie>
has there been GPIB backends that talk to old gear such as my 34401A then?
<azonenberg>
and glscopeclient is primarily the frontend for oscilloscope-type instrments but i think it is going to start expanding to other stuff too
<Stephie>
neat
<azonenberg>
in particular because as of now, most multunfciton instruments only have a single scpi interface
<azonenberg>
so you cannot run glscopeclient talking to the DSO and some other tool to talk to the arb
<azonenberg>
you have to run everything through one app
<Stephie>
i'd be interested in looking into a bunch of that work
<azonenberg>
while it's plausible we could make a bridge that muxed requests from multiple clients, or exposed each virtual instrument as a separate socket
<azonenberg>
that does not currently exist
<azonenberg>
so all users of a given instrment need to be in the same process
<Stephie>
for this decide, it's like the picoscope that its accessible over the network, and iirc your architecture there was to have another server running and translating protocols?
<azonenberg>
unless the instrument itself supports multiple concurrent sessions
<Stephie>
for this one, I'd really like to support concurrent sessions
<azonenberg>
That was what i did for the pico API, yes. mainly because it was a third party binary blob
<Stephie>
ahh right
<azonenberg>
and i didnt want to require all libscopehal builders to compile against it
<azonenberg>
also i wanted network transparency
<Stephie>
i didnt realise that used an external library
<azonenberg>
for GPIB the eaisest option would be to implement a new SCPITransport based class for gpib
<Stephie>
and not a custom proto impl
<azonenberg>
This had been planned from the start, but i dont have any gpib stuff handy i can implement it against
<azonenberg>
There is an open ticket for it
<azonenberg>
As far as multiple clients to the virtualbench, does it support that natively?
<Stephie>
nope
<azonenberg>
can you have e.g. two visa sessions open to it at once on different sockets?
<azonenberg>
ah ok
<Stephie>
i planned to support multi-session in the sidecar "communicator" daemon
<Stephie>
since each instrument is largely seperate, it shouldn't be too hard?
<azonenberg>
So, in that case i think the best first implementation is going to be to implement a libscopehal driver for it which will give you a single session
<Stephie>
counting the LA and scope as the same instrument sicne they have the same timebase
<Stephie>
(i think)
<azonenberg>
The next bit is going to be making a *single* separate daemon for network transparency of an arbitrary scopehal instrument
<azonenberg>
Which will be helpful for, say, network transparency of a USBTMC attached device
<azonenberg>
We would then think about adding multi-client support at that layer
<Stephie>
yeah that'd be useful for my lab too, since then I could use my GPIB instruments connected to my headless lab PC with the PCI GPIB card from my laptop
<azonenberg>
That would be a much cleaner and more reusable architecture IMO
<azonenberg>
Exactly
<azonenberg>
the only reason i didn't do this with pico is their binary blob SDK
<Stephie>
i understand now
<azonenberg>
if the usb protocol was documented i'd have done it that way instead
<Stephie>
i'm gonna have to work out the same with this scope
<azonenberg>
So yeah unless you need multiclient or network transparency in the immediate future
<azonenberg>
i think this is the best strategy
<Stephie>
i am assuming that since it supports both USB and TCP/IP that the protocols for both are largely similar
<Stephie>
since most sane devs would choose that
<azonenberg>
as far as the long term future of the project and being clean and modular
<Stephie>
but i could be wrong
<azonenberg>
is it SCPI?
<Stephie>
unlikely
<azonenberg>
well, have fun in that case. I would suggest starting with the TCP protocol
<azonenberg>
SCPISocketTransport does have raw read/write methods which let you use it for non SCPI endpoints
<Stephie>
yeah, thats where i was gonna start
<Stephie>
unless it pops up as a generic USB class, that's where i was gonna start
<azonenberg>
Makes sense
<Stephie>
unfortunately it's wifi-only, no LAN
<azonenberg>
o_O that is annoying
<Stephie>
yeah
<Stephie>
it's weird
<azonenberg>
meanwhile i'm all in on wired networking
* azonenberg
looks up at cable tray full of fiber
<Stephie>
it even has an internal unpopulated pad for a enternet phy and port
<azonenberg>
Intereresting
<Stephie>
but the footprint isnt capable of being mounted with the case on
<Stephie>
it's, weird
<azonenberg>
wonder if you could bodge one on and if the firmware would pick it up :p
<azonenberg>
Anyway I've had my hands full with work, getting ready for the baby, and finishing assembly of the MEAD pods but that's coming along nicely
<azonenberg>
and i hope to get back to scopehal work in a couple of days
<Stephie>
not a clue, i hardly dare myself to
<Stephie>
yeah, i'll start off with reversing the protocol myself
<Stephie>
after that i'll come back and work out what to do with that
<Stephie>
since any first impl of a RE'd protocol will be complete garbage i dont mind scrapping
<azonenberg>
Makes sense
<azonenberg>
Incidentally we still need someone to RE the usb3 saleae logic protocol and write a driver for that
<azonenberg>
and/or write an open source firmware we can load onto it
<azonenberg>
because afaik they come up in usb bootloader mode and need firmware every boot
<azonenberg>
and a fully open firmware would eliminate the need to have the saleae software installed to get the blob from
<azonenberg>
Not a super near term priority but on the wishlist
<Stephie>
i dont think custom FW is gonna be feasable for this instrument :P
<azonenberg>
Yeah but it's self contained if it's wifi based
<azonenberg>
a lot of usb headless stuff has no /minimal flash
<azonenberg>
and requires a blob to be downloaded every time you power it up
<Stephie>
yeah
<azonenberg>
which poses distribution problems
<Stephie>
i heard this device is self-contained enough that you plug it in and it presents the desktop software as a flash drive
<Stephie>
so, the other way around haha
<azonenberg>
lol
<Stephie>
means probably a windows VM required to do firmware updates but oh well
<Stephie>
worth it
<azonenberg>
meanwhile my main scopes actually run native windows lol
<Stephie>
lol
<Stephie>
oof
<azonenberg>
One of them is a skylake i5 the other is a core2quad because it's much older. when i upgrade that one the new cpu board will probably be a xeon
<Stephie>
i know eric bogatin uses his scope as his main PC
<azonenberg>
Lol
<Stephie>
i mean, i would
<azonenberg>
He probably also has a lecroy labmaster or one of those other monsters lol
<Stephie>
they're powerful as heck and have good IO :P
<Stephie>
yeah he does
<azonenberg>
i mean he does SI stuff for lecroy
<azonenberg>
i'm sure he can get any scope he wants from them :p
<Stephie>
yep
<azonenberg>
meanwhile here i am scrimping and saving to buy my SDA off ebay lol
<azonenberg>
although to be fair if I asked *pico* for a scope they'd probably send me anything :p
<Stephie>
meanwhile i'm eyeing up a mid 80s HP 20ghz sampling scope boat anchor as the only affordable option
<azonenberg>
Yeah this SDA was definitely not cheap. But for the stuff I do i needed a realtime scope
<Stephie>
yeah, realtime ones are a lot more useful
<azonenberg>
I do want to improve sampling scope support in glscopeclient though
<azonenberg>
For example, right now it is theoretically possible to create a scope where an eye pattern is the native output
<Stephie>
if i amnage to get one of these scopes working i'd want to run glscopeclient on it i suspect
<azonenberg>
but there is no way to save it to disk
<azonenberg>
right now only analog and digital waveforms have defined serialization formats
<azonenberg>
(since filter output is not serialized, only the configuration, and output is lazily evaluated as needed)
<azonenberg>
I have a bunch of infrastructure stuff i want to work on probably for v0.2
<azonenberg>
Like memory traces and the ability to do math across history rather than just the current point in time
<Stephie>
todo list always gets longer...
<azonenberg>
to, say, subtract the value of a waveform from its value last trigger
<azonenberg>
And I want to get v0.1 out the door this summer