azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
_whitelogger has joined #scopehal
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #scopehal
juli965 has quit [Quit: Nettalk6 -]
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±8]
<_whitenotifier-f> [starshipraider] azonenberg fb9bdf7 - Finished initial plane layout on MEAD, added soldermask apertures over RF traces, tweaks to shield routing
<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
<azonenberg> at least by the connector where i change the reference from 2V5 (on the board) to ground (by the cable)
Kliment_ is now known as Kliment
tverbeure has joined #scopehal
<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).
<tverbeure> However, those utilities are using a library that comes with it that is GPL licensed.
<tverbeure> Are there any options here, other than writing a stand-alone GPIB to TCP/IP bridge utility?
<azonenberg> Writing a non-GPL client for the linux kernel device, just like you did for USBTMC?
<tverbeure> The user mode code is very convoluted. Doesn't seem nearly as straightforward as usbtmc.
<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.
<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.
<azonenberg> If there wasn't a global pandemic going on i have a late 1990s tek with 10baseT at the lab at work
<azonenberg> we retired it from service when i sold them my WaveSurfer 3034, but it never got tossed
<azonenberg> But i don't expect to have access to it for months
<tverbeure> We have much later versions at work too, but those are at somebody else's house. :-)
<azonenberg> Re GPIB, there is always the option of writing a GPL'd plugin in a standalone module
<azonenberg> glscopeclient has the ability to load plugins including scope drivers or transports at run time
<tverbeure> Any examples?
<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
<azonenberg> anyway that shouldn't contaminate the glscopeclient core codebase if we had a gpl'd plugin for this
<azonenberg> However, as a matter of policy, GPL'd code should not be built by default
<azonenberg> there will need to be an explicit cmake option for building gpl'd plugins that needs to be turned on
<azonenberg> In order to keep the default glscopeclient/scopehal distribution permissively licensed
<azonenberg> The source for the plugin will be still BSD although the compiled binary would be GPL
<azonenberg> as far as plugins go, just for general information
<azonenberg> see scopehal.cpp:110 InitializePlugins()
<azonenberg> basically it looks in /usr/lib/scopehal/plugins, /usr/local/lib/scopehal/plugins, and ~/.scopehal/plugins for so's
<azonenberg> dlopens them and calls PluginInit()
<azonenberg> which then registers the transports, filters, etc in the same way you would from libscopehal or libscopeprotocols
<tverbeure> Ok. I'll check it out later. My preference right now would be a TCP/IP to GPIB server.
<azonenberg> Yes
<azonenberg> then we could use the existing tcp transport
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1]
<_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.
<azonenberg> note that PluginInit needs to be extern "C" linkage
<azonenberg> since i don't search for the mangled name when calling it
<tverbeure> Better not to forget that!
<azonenberg> no arguments or return value, it just calls the registration functions
<azonenberg> Lol
<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
<azonenberg> Gonna try and get that ordered asap, hopefully tomorrow, then i can turn my attention to fine tuning the probe more
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
juli965 has joined #scopehal
futarisIRCcloud has joined #scopehal
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±7]
<_whitenotifier-f> [starshipraider] azonenberg f644704 - Updated LA pod with right side compoarators ref'd to ground, other layout tweaks to right side comparator block
<azonenberg> ok i think i'm finally happy with it, gonna do review after work tonight
<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
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #scopehal
tverbeure2 has joined #scopehal
tverbeure has quit [Ping timeout: 246 seconds]
<miek> lol, i have just learned that agilent called the rackmount version of this scope the "pancake form factor"
<Degi> hahaha
<miek> 'hamsterPresent = 1;' uh..
<azonenberg> hamsters in your scope?
<miek> possibly! also, apparently hamsters don't fit in the pancake form factor
<electronic_eel> maybe the hamsters power the scope with their wheel?
<azonenberg> ooh
<azonenberg> i like that idea
<azonenberg> makes sense why it wouldnt fit in a pancake
<azonenberg> they just have little tubes in there but can't fit the wheel
balrog has quit [Quit: Bye]