<electronic_eel>
I think azonenberg thinks about the case of a scope vendor taking scopehal and selling it with their scopes.
<electronic_eel>
then the GPL could become a problem. Search for "Patrick McHardy" to get a feeling how much of a problem the GPL can become when one developer goes over to the dark side
<electronic_eel>
So I think having a clear and explicit border between BSD and GPL is a good idea
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
<bvernoux>
It seems to be excellent for the price stay tuned
<bvernoux>
anyway today is the last day for their "crowd-founding"
bvernoux has quit [Quit: Leaving]
_whitelogger has joined #scopehal
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
electronic_eel has quit [Ping timeout: 255 seconds]
electronic_eel has joined #scopehal
<azonenberg>
awygle: yes that is exactly the intent
<azonenberg>
I want to allow e.g. tek to ship a scopehal decoder on their hardware
<azonenberg>
That said yes i agree sigrok decoders are of questionable quality
<azonenberg>
Re immersion silver, because nickel is a poor conductor at RF
<azonenberg>
So ENIG is an awful material for an unmasked transmission line
<azonenberg>
and masked lines have less predictable properties due to soldermask Er and thickness being not well controlled
<sorear>
I am surprised nickel is usable at all for signals
<azonenberg>
well, at lower frequencies most of your signal is in the copper
<azonenberg>
and the plating is only on exposed stuff not soldermask
<azonenberg>
so normally you only go through the nickel layer in the Z axis on solder pads and it's NBD
<azonenberg>
Once skin depth is s.t. most of your signal is in the nickel layer it falls apart on un-masked traces
<azonenberg>
Anyway, now that i'm back from sar training i'm gonna try and finish the probe characterization board today, then do the LA bit-merging filter
<azonenberg>
I'd like to add a lot more LA support stuff eventually including things like enums
<azonenberg>
and the ability to save info like channel radixes in settings files, so you can reload glscopeclient later on and have addresses showing as hex, states as enums, etc
<azonenberg>
So here's a question for the channel: What is the best way to identify "the same computer" in save files?
<azonenberg>
basically if you load a save on the machine it was created on, i want to prompt the user if they want to automatically reconnect to the instrument
<azonenberg>
On a different machine, assume they just want to view data
<azonenberg>
i think the best way to balance privacy and functionality is to save a UUID in ~/.scopehal or similar, that is only used by scopehal and has no relationship to the mac address or anything else
<sorear>
"the same computer" is an ill-defined concept because the kind of people we're targeting theseus machines all the time
<apo>
that's the first time I've seen that being used as a verb
<sorear>
I wonder if it would make more sense to use the instrument serial number, and offer to connect to the instrument used to generate the save if it's still available
<apo>
sorear: theseus machines would probably still have the same data, though
<apo>
so a uuid stored in ~/ would be perfect for this
<azonenberg>
well it gets hard when you are connecting via USB or rs232 or something to something like an ILA
<azonenberg>
not everything will necessarily have unique serial numbers
<azonenberg>
basically, how do i even know if the instrument in question is still there?
<azonenberg>
Should i always attempt to connect, and if i can connect then prompt if you want to reconfigure the instrument to match the setup in the save file or use the settings currently on the instrument?
<apo>
that might fuck with serial devices
<azonenberg>
That was my concern
<azonenberg>
but i feel like prompting to reconnect every time you load a save is likely to be annoying
<apo>
you could try and match stuff? Save... most/all of the metadata for whatever you have as /dev/ttyUSB0 and find something that matches?
<azonenberg>
match what?
<azonenberg>
my thought was, if you are on the same computer then attempt to reconnect by default, if successful prompt if you want to reconfigure the scope or not
<azonenberg>
if you cannot reconnect, start in offline mode
<azonenberg>
Right now there is no file load support only, saves are write only (and it's metadata only, no waveforms yet)
<sorear>
I would split this up
<azonenberg>
but these are design issues that have to be figured out before we build the loader
<sorear>
have configuration data in ~/.config/scopehal with the non-probeable instruments that exist
<azonenberg>
what i want to avoid is a huge wizard every time you load a file
<sorear>
do NOT probe anything automatically that might be destructive
<azonenberg>
i guess uart is the main thing to not probe
<sorear>
hold on I didn't fully think that through
<azonenberg>
Connecting over SCPI and sending a *IDN? should be safe
<apo>
match everything! :p vid/pid for USB, stuff like what's produced by udevadm info...
<azonenberg>
right now since the majority of stuff is done via sockets
<azonenberg>
i guess what i'll do is attempt to auto reconnect to any SCPISocketTransport in the save file?
<sorear>
I don't think it makes sense to have information about nonprobeable devices in "trace" save files ("workspace" saves might be different, idk)
<azonenberg>
and if successful prompt to reconfigure or not?
<azonenberg>
if unsuccessful just start in offline mode
<azonenberg>
sorear: there are no trace-only saves, at least for now
<azonenberg>
there are workspace or workspace+waveform
<apo>
probably highly connection specific
<azonenberg>
there will be support for CSV or similar export of waveforms but not loadable
<apo>
ethernet stuff, just try to connect
<apo>
USB, try to find matching devices
<azonenberg>
well seeing as we dont yet have usb support
<azonenberg>
i'll hold off on that for a bit :P
<apo>
aww =P
<azonenberg>
The other thing that has to happen is dynamic instantiation of Oscilloscope and SCPITransport objects based on connection strings
<azonenberg>
right now this is all in glscopeclient/main.cpp
<apo>
... not that it matters, my scope is slow as fuck with every connection :)
<azonenberg>
but if i save the connection string in a save file that code path wont be hit
<azonenberg>
as it's not a command line arg
<azonenberg>
So i need to move that logic into scopehal proper and use a dynamic creation table like i do for protocol decodes already
<azonenberg>
but like i mentioned on friday there are a number of dependencies to do that, like making the lecroy and siglent drivers use SCPITransport properly
<azonenberg>
In general there are two main use cases for loading saves: continuing experiments in progress (possibly after someone else used the scope for something unrelated in the meantime)
<azonenberg>
and analyzing results of previous experiments
<azonenberg>
So i want the UX for both to be smooth and streamlined
<azonenberg>
without more popups etc than strictly necessary
<apo>
how about having a button "Connect to same device"
<azonenberg>
where?
<apo>
first time you click it, it asks you "Same device/IP..." / "Different..."
<apo>
and then remembers that
<apo>
No idea, I don't know your GUI =P
<azonenberg>
As of *right now* the only way to use glscopeclient is to pass a scope (or multiple scope) connection strings on the command line
<azonenberg>
There is no connection dialog
<apo>
whereever you get when you load a save file
<azonenberg>
If you run with no scopes, it gives you an empty, useless top level window you can't do anything with
<azonenberg>
There is a file load dialog that is just a standard OS file picker
<azonenberg>
but when you click open, it doesn't actually DO anything yet
<sorear>
if this tool is going to have a large independent library of protocol decoders, people are going to want to use it with simulation output
<azonenberg>
sorear: yes, there will probably be a VCD import feature at some point
<azonenberg>
anyway, going back to the reconnection side
<azonenberg>
When you go file | load [layout|waveforms|layout and waveforms]
<azonenberg>
should there be a checkbox for "reconnect to instruments and load settings" or similar?
<azonenberg>
i think gtk lets you customize the file picker dialog a bit
<azonenberg>
well more precisely, you can put a file picker widget in a custom dialog with arbitrary controls in it
<azonenberg>
but you can also add boolean choices to the dialog easily
<azonenberg>
in that case we can make it an explicit user decision and not have to worry about any kind of autodetection
<apo>
azonenberg: I think you want a radio button
<apo>
(Do nothing, reconnect, reconnect but change path/IP)
<azonenberg>
the latter would require a fair bit of additional coding so i think i'll only have the first 2 to start
<azonenberg>
but i like the idea
<apo>
fair enough
<apo>
whatever you call the thing that transports are on top of could give you a vector of things that might change
<apo>
something for IP + port, device entry, stuff like that
<awygle>
on a coplanar waveguide most of the signal is between the traces
<awygle>
i feel like i read a thing about enig for this purpose...
<sorear>
virtually all of the energy is between the traces, but the current is in the traces, and the current is what causes resistive losses
<awygle>
mm
<awygle>
yeah you're right
<awygle>
metal losses are higher
<awygle>
it's just a question of what losses dominate i guess, and whether you need to care
<lain>
skin effect pulls the current to the faces, so some of the energy will concentrate at the top where the nickel is
<lain>
yeah, E-field concentrates strongly at sharp points
<lain>
how sharp the trace geometry is on a real board is debatable, but it's important to consider for sure :3
<sorear>
nickel is ferromagnetic so the skin effect will be two orders of magnitude thinner than copper…?
<azonenberg>
well its not just sharp points, it's the fact that the coupling is edge wide
<azonenberg>
sorear: more current in less metal = even worse
<lain>
now that we have these 5 GHz scopes we should actually order some test boards that are otherwise identical with test microstrips and the same stackup, but one with silver, other with ENIG
<azonenberg>
i'll ask betty if that's doable
<lain>
I might be mis-remembering, but I think most of the microwave equipment teardowns I've seen show gold-colored microstrip traces exposed in the inner workings... hmm...
<azonenberg>
yes i have seen that too. Which makes me wonder if that gold is over Ni or something else
<azonenberg>
e.g. NiPdAu
<azonenberg>
or EPIG (electroless palladium + immersion gold, nickel free
<lain>
For example, for the microstrip circuits, very little difference in conductor loss was apparent between the unplated (bare-copper) and ENIG circuits though about 2 GHz, although the higher losses of the ENIG circuit became more noticeable above that frequency. Compared to the bare copper circuit, the microstrip with ENIG measured about 0.25 dB higher in loss at 10 GHz, increasing to more than 0.5 dB higher
<lain>
at 40 GHz. The loss difference between GCPW circuits using bare copper conductors and using ENIG finish are even more dramatic, with about 0.5 dB more loss at 10 GHz and greater than 1 dB more loss at 40 GHz. The measurements clearly show the frequency dependence at higher frequencies but also how a particular circuit type can also contribute to the impact that a plated finish can have on a circuit.
<lain>
"""
<lain>
I wonder if at very high frequencies, the skin depth is confined to the gold and skips the nickel entirely?
<azonenberg>
at extremely high? very likely
<azonenberg>
also immersion silver is a win over bare copper btw
<azonenberg>
because silver is a better conductor than copper
<azonenberg>
So while the magnitude of the gain is frequency dependent, you will actually see less loss than unplated conductors
<azonenberg>
this is the presentation from rogers (oh and sonnet, lol) that blog post references
<azonenberg>
i wonder if sonnet has some way to model plating? i know they have some tricks to do plating on top of a trace but sidewalls i'm less sure of
<sorear>
the problem with that theory is that the E/B field are strongest immediately outside the active conductor
<sorear>
so if the current is flowing in the gold the field is strongest in the nickel, and then you have eddy currents? in the nickel to worry about
<azonenberg>
20 mins in roughly
<azonenberg>
this is also using 5 mil spacing and 8 mil dielectric. so a fair bit of the field in the substrate
<azonenberg>
as opposed to the ultra narrow GCPWs i've been using
<azonenberg>
where almost all coupling is in plane
<azonenberg>
in that chart they show about 0.5 dB of loss due to enig @ 10 GHz, closer to 1 dB at 20-25 GHz and up
<azonenberg>
that's per inch apparently
<azonenberg>
22:50 immersion silver and OSP are indistinguishable from bare copper for all intents and purposes, loss wise
<azonenberg>
note also soldermask losses are quite bad
<azonenberg>
and apparently soldermask is hygroscopic and when humid you get more loss
<azonenberg>
so unmasked immersion silver plated GCPW is definitely looking like the best for probes and low loss / sensitive stuff
<azonenberg>
still have to miter the trace width changes
<azonenberg>
but i think it's otherwise done
<azonenberg>
oh and lots of stitching vias
<lain>
:D
<azonenberg>
see, this is the kind of board where top level ground flood is OK
<azonenberg>
because every trace on the board is intentionally a CPW, and every signal pad was carefully optimized for a specific clearance value to maintain impedance
<lain>
yep
<azonenberg>
the probe connectors are 175 μm ground clearance, the SMA center pads are 150 μm, and the general signal traces are 100 μm
<azonenberg>
What do you think of those probe connectors for characterization btw?
<azonenberg>
just a big ground flood on either side for the ground blade to touch
<azonenberg>
then the center contact will mate directly with the probe
<azonenberg>
i think we should be able to get fairly repeatable measurements with it
<_whitenotifier-3>
[scopehal-apps] antikerneldev opened issue #78: Support more LeCroy trigger sources - https://git.io/JvoT9
<monochroma>
hmmm
<monochroma>
actually that isn't part of apps is it... that's in scopehal
<_whitenotifier-3>
[scopehal-apps] antikerneldev commented on issue #78: Support more LeCroy trigger sources - https://git.io/JvoTF
<_whitenotifier-3>
[scopehal-apps] antikerneldev closed issue #78: Support more LeCroy trigger sources - https://git.io/JvoT9
<_whitenotifier-3>
[scopehal-apps] antikerneldev edited a comment on issue #78: Support more LeCroy trigger sources - https://git.io/JvoTF
<_whitenotifier-3>
[scopehal] antikerneldev opened issue #100: Add more LeCroy trigger sources - https://git.io/JvoTA
<azonenberg>
we need apps support for UI of more advanced trigger stuff
<azonenberg>
as well as API support to even be what those triggers are
<azonenberg>
this isnt lecroy specific, this is in general more than edge trigger
<apo>
I2C Trigger :p
<electronic_eel>
apo: rf trigger, when the power between freq x and y rises above z dbm
<monochroma>
azonenberg: hmm so what do you want me to do with the issue then?