03:39 <_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±8] https://git.io/Jf1em

03:40 <_whitenotifier-f> [starshipraider] azonenberg fb9bdf7 - Finished initial plane layout on MEAD, added soldermask apertures over RF traces, tweaks to shield routing

03:40 <azonenberg> ok i think at this point the main MEAD board is ready for signoff review. will probably make a few tiny adjustments during review like adding layer-change stitching caps

03:40 <azonenberg> at least by the connector where i change the reference from 2V5 (on the board) to ground (by the cable)

03:51 <azonenberg> https://www.antikernel.net/temp/mead-layout17.png

05:07 <tverbeure> I was looking into GPIB. The Linux kernel driver and utilities are working fine (I can talk to the Tek 420A that UPS dropped off at my door this evening).

05:07 <tverbeure> However, those utilities are using a library that comes with it that is GPL licensed.

05:08 <tverbeure> Are there any options here, other than writing a stand-alone GPIB to TCP/IP bridge utility?

05:09 <azonenberg> Writing a non-GPL client for the linux kernel device, just like you did for USBTMC?

05:41 <tverbeure> The user mode code is very convoluted. Doesn't seem nearly as straightforward as usbtmc.

05:42 <tverbeure> Ultimately, I'm not super interested in GPIB, but in getting a Tek scope to work. But the only way to get there cheaply is with a very old Tek scope (the 420A is from 1995), which means: GPIB.

05:43 <tverbeure> I compared the Tek programmers manual of the 420A and later models: they're almost word-for-word identical, so whatever works for the 420A should work on much later models too.

05:44 <azonenberg> If there wasn't a global pandemic going on i have a late 1990s tek with 10baseT at the lab at work

05:44 <azonenberg> we retired it from service when i sold them my WaveSurfer 3034, but it never got tossed

05:44 <azonenberg> But i don't expect to have access to it for months

05:44 <tverbeure> We have much later versions at work too, but those are at somebody else's house. :-)

05:45 <azonenberg> Re GPIB, there is always the option of writing a GPL'd plugin in a standalone module

05:45 <azonenberg> glscopeclient has the ability to load plugins including scope drivers or transports at run time

05:45 <tverbeure> Any examples?

05:46 <azonenberg> the only one in existence right now is one with a decode for a client-proprietary protocol unfortunately, but i can explain it easily enough

05:46 <azonenberg> anyway that shouldn't contaminate the glscopeclient core codebase if we had a gpl'd plugin for this

05:46 <azonenberg> However, as a matter of policy, GPL'd code should not be built by default

05:46 <azonenberg> there will need to be an explicit cmake option for building gpl'd plugins that needs to be turned on

05:46 <azonenberg> In order to keep the default glscopeclient/scopehal distribution permissively licensed

05:47 <azonenberg> The source for the plugin will be still BSD although the compiled binary would be GPL

05:47 <tverbeure> This looks promising: https://michael.siegenthaler.us/projects/software/gpib

05:47 <azonenberg> as far as plugins go, just for general information

05:47 <azonenberg> see scopehal.cpp:110 InitializePlugins()

05:48 <azonenberg> basically it looks in /usr/lib/scopehal/plugins, /usr/local/lib/scopehal/plugins, and ~/.scopehal/plugins for so's

05:48 <azonenberg> dlopens them and calls PluginInit()

05:48 <azonenberg> which then registers the transports, filters, etc in the same way you would from libscopehal or libscopeprotocols

05:48 <tverbeure> Ok. I'll check it out later. My preference right now would be a TCP/IP to GPIB server.

05:48 <azonenberg> Yes

05:48 <azonenberg> then we could use the existing tcp transport

05:49 <_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jf1JP

05:49 <_whitenotifier-f> [starshipraider] azonenberg 8777962 - Major revamp of left side comparator area. Moved terminating resistors to top side, changed reference plane for diffpairs from 2V5 to ground. Still have to do this on right side.

05:50 <azonenberg> note that PluginInit needs to be extern "C" linkage

05:50 <azonenberg> since i don't search for the mangled name when calling it

05:50 <tverbeure> Better not to forget that!

05:50 <azonenberg> no arguments or return value, it just calls the registration functions

05:50 <azonenberg> Lol

05:59 <azonenberg> Well I'm off to sleep. Made lots of progress on the MEAD logic head but still finding things to tweak before the signoff review

05:59 <azonenberg> Gonna try and get that ordered asap, hopefully tomorrow, then i can turn my attention to fine tuning the probe more

16:11 <_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±7] https://git.io/Jf107

16:11 <_whitenotifier-f> [starshipraider] azonenberg f644704 - Updated LA pod with right side compoarators ref'd to ground, other layout tweaks to right side comparator block

16:14 <azonenberg> ok i think i'm finally happy with it, gonna do review after work tonight

16:19 <azonenberg> 100% of the RF signals are now ref'd to ground and we have stitching vias when i switch from one ground to another

19:09 <miek> lol, i have just learned that agilent called the rackmount version of this scope the "pancake form factor"

19:13 <Degi> hahaha

19:20 <miek> 'hamsterPresent = 1;' uh..

20:26 <azonenberg> hamsters in your scope?

20:36 <miek> possibly! also, apparently hamsters don't fit in the pancake form factor

21:42 <electronic_eel> maybe the hamsters power the scope with their wheel?

22:05 <azonenberg> ooh

22:05 <azonenberg> i like that idea

22:05 <azonenberg> makes sense why it wouldnt fit in a pancake

22:05 <azonenberg> they just have little tubes in there but can't fit the wheel