<azonenberg>
proposed ultra minimalistic solder in probe
<lain>
looks nice
<Bird|otherbox>
btw: turned on some additional checks in cppcheck for now, going to return to clang-analyzer in a bit I think (need to figure out how to tailor the output a bit if nothing else)
<azonenberg>
Bird|otherbox: ok
<azonenberg>
lain: for scale the total distance from u.fl center pin to the tip of this probe *including resistors*
<azonenberg>
is slightly less than the distance from the AKL-PT1's first resistor to the tip of the needle
<Bird|otherbox>
also: food's about ready here, but when I get back from eating, mind if we have a bit of a style talk? (I'd like to turn clang-tidy on as well as it's a good neatness tool and does take some load off other static analyzers in chasing neatness around, but I suspect it'd be rather noisy atm)
<azonenberg>
We have a clang-format in the repo that ALMOST describes my preferred style
<azonenberg>
but not quite
<azonenberg>
i havent managed to make it exactly match up
<Bird|otherbox>
fair enough, makes sense -- I was speaking a bit higher level than what clang-format deals with though
<Bird|otherbox>
things like NULL vs 0 vs nullptr, expected auto usage, explicit on one-arg ctors, that sort of thing (mostly, what clang-tidy is after)
<azonenberg>
ah, ok
<azonenberg>
So... I generally use NULL for all pointer values
<azonenberg>
and i make very heavy use of auto since i have lots of long type names, iterators, etc
<Degi>
Maybe some kinda way to mount it would be nice, as not to exert too much force. And maybe putting the via inside the pad instead of besides it, since its gonna be hand soldered anyways
<azonenberg>
Degi: the intent is to kapton tape it to the DUT
<azonenberg>
as well as securing the coax for a short distance from the probe head
<Degi>
Ah neat
<azonenberg>
this is a first generation PoC and i expect to revise it a bit before i do a volume run
<Bird|otherbox>
azonenberg: definitely with you on auto :) I like it myself (although I generally don't use it to absorb declarator operators like & and * in order to keep the usage semantics of variables clear)
<Bird|otherbox>
odd that you use NULL still, nullptr is the way forward re: the null pointer value from what I've seen
<Bird|otherbox>
(if nothing else, nullptr doesn't depend on the preprocessor!)
<azonenberg>
Bird|otherbox: yeah but old C habits die hard :p
<azonenberg>
And NULL vs nullptr is one of those things that i've just never bothered trying to train myself out of because i couldn't really see a downside to the old way
<azonenberg>
meanwhile, auto + foreach loops are a massive improvement in both speed of typing and clarity when iterating over a STL container
<Bird|otherbox>
yeah, most of the NULL vs nullptr thing is trying to migrate away from the preprocessor, and also being able to diagnose goofiness with varargs and such
<azonenberg>
Bird|otherbox: lol. yes i keep style ones off
<azonenberg>
it gets loud
<Bird|otherbox>
noted!
<azonenberg>
performance and portability i usually keep on as those can be helpful
<Bird|otherbox>
yeah, also turned off the unusedFunction stuff since that seemed dubious
<Bird|otherbox>
better to leave that to more sophisticated tooling
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #298: LeCroyOscilloscope: enabling/disabling digital channels seems to give some kind of error - https://git.io/JUxO4
<_whitenotifier-f>
[scopehal] azonenberg opened issue #298: LeCroyOscilloscope: enabling/disabling digital channels seems to give some kind of error - https://git.io/JUxO4
<azonenberg>
aaaand grr
* azonenberg
stabs lecroy's inconsistent naming schemas with a passive probe
<azonenberg>
when configuring triggers, digital channels are called D0...D15
<azonenberg>
but when enabling/disabling in the LA config, it's app.LogicAnalyzer.Digital1.Digital0...Digital15
<azonenberg>
Tek's SCPI API isn't as orthogonal as i would like but it's much better than lecroy's
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUxc8
<_whitenotifier-f>
[scopehal] azonenberg 0c738e1 - LeCroyOscilloscope: fixed regression in digital channel naming. Fixes #298.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #298: LeCroyOscilloscope: enabling/disabling digital channels seems to give some kind of error - https://git.io/JUxO4
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUxcB
<azonenberg>
so architectural question for those of you who may or may not be familiar with the SD card protocol (awygle, monochroma, esden, balrog?)
<azonenberg>
i'm debating making 3 separate decodes... command bus, data bus, and then maybe something to combine them
<azonenberg>
does that make sense? from the parts of the spec i've looked at so far it seems like a pretty clean separation and they share nothing but the clock
<lain>
hmm
<lain>
right because CMD is used to send commands back and forth, but the data bus is only used for bulk data
<azonenberg>
exactly
<azonenberg>
So the question is if it makes sense to split them
<azonenberg>
this would also allow, for example, decoding *only* CMD
<lain>
hmm
<azonenberg>
if you only cared about addresses being fetched or something
<lain>
I think it makes sense as long as there's a way to associate a data packet with the corresponding command
<lain>
so you know "this block went to that address"
<azonenberg>
Yes, my thought was to have a secondary upper level protocol for that
<azonenberg>
that took the two streams and correlated them
<awygle>
Seems reasonable
<awygle>
Can't remember where command CRC comes back offhand
<awygle>
Think dat0
<azonenberg>
No, command responses come back on CMD
<awygle>
Probably not an issue tho either way
<azonenberg>
Command token is 2'b01, content, crc, 1'b1
<azonenberg>
response token is 2'b00, content with crc for some but not all commands, 1'b1
<azonenberg>
(figure 3-7 and 3-8 of simplified spec)
<azonenberg>
incidentally, the SD card simplified spec references, but doesn't give details (presumably this is only in the full spec) use of the SD bus as multi-drop
<azonenberg>
has anyone ever actually seen that in use rather than point to point?
<bluecmd[m]1>
azonenberg: Do you see the VCD/Ngspice waveform reading stuff live in scopehal or glscopeclient? I have been thinking about it and initially I thought of just copying the MockOscilloscope as discussed, but it seems a bit odd to add generic waveform parsing to a oscilloscope HAL library, no? Especially as a lot of functions would just be moot like triggers and such.
<azonenberg>
bluecmd[m]1: For non-interactive import, it makes sense to use the same MockOscilloscope class we use for loading saved waveforms
<azonenberg>
have a parser in glscopeclient and just push data into the scope
<azonenberg>
live streaming is a bit more of a gray area especially if you consider the potential for simulator control in the future
<azonenberg>
e.g. stopping the sim at a certain time step
<azonenberg>
Although having the parser in libscopehal might still make sense because you might want to do protocol decodes etc on a VCD in an offline test environment
<azonenberg>
i try to keep glscopeclient UI/rendering code only and keep the back end in scopehal/scopeprotocols
<azonenberg>
there may eventually be a refactoring splitting scopehal up more, i've thought about moving things like the s-parameter and IBIS parsers out to a new library "scopeutils" or similar. Still in the scopehal repo but not in libscopehal.so
<azonenberg>
and maybe even moving the core scope drivers out too, so libscopehal would be API base classes only and libscopedrivers would be all of the vendor specific stuff. No idea
<azonenberg>
at this stage of things, a VCD parser should probably live in scopehal
<_whitenotifier-f>
[scopehal] azonenberg opened issue #299: LeCroyOscilloscope: add A/B input mux selection for WaveMaster and other scopes with ProBuS+ProLink inputs - https://git.io/JUxPY
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #299: LeCroyOscilloscope: add A/B input mux selection for WaveMaster and other scopes with ProBuS+ProLink inputs - https://git.io/JUxPY
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #299: LeCroyOscilloscope: add A/B input mux selection for WaveMaster and other scopes with ProBuS+ProLink inputs - https://git.io/JUxPW
<bluecmd[m]1>
azonenberg: ack!
<bluecmd[m]1>
as for live data, I was thinking that the fake-oscilloscope can "trigger" when new simulation data has been written to the input file
<bluecmd[m]1>
which would allow you to either follow in realtime I guess, or you could just stop auto-triggering and you'd be frozen at the current state
_whitelogger has joined #scopehal
Katharina has joined #scopehal
Katharina has quit [Remote host closed the connection]
Katharina has joined #scopehal
Katharina has quit [Client Quit]
Katharina has joined #scopehal
juli965 has joined #scopehal
promach3 has quit [Quit: killed]
bluecmd[m]1 has quit [Quit: killed]
jevinskie[m] has quit [Quit: killed]
bluecmd[m] has joined #scopehal
maartenBE has quit [*.net *.split]
alexhw has quit [*.net *.split]
alexhw has joined #scopehal
Katharina has quit [Ping timeout: 260 seconds]
maartenBE has joined #scopehal
Katharina has joined #scopehal
jevinskie[m] has joined #scopehal
promach3 has joined #scopehal
azonenberg_work has quit [Ping timeout: 246 seconds]
azonenberg_work has joined #scopehal
Katharina has quit [Ping timeout: 244 seconds]
Katharina has joined #scopehal
Katharina has quit [Ping timeout: 240 seconds]
bvernoux has joined #scopehal
Katharina has joined #scopehal
<azonenberg>
bluecmd[m]: well the question is how we'd want that to interact with history
<azonenberg>
you dont want every sim timestep to be a new history event, that would result in exponentially growing ram usage :p
<azonenberg>
i think more like each entire sim is one history event makes more sense
<azonenberg>
so we might want to set up some modifications to the API to allow a single waveform to be mutable and send out notifications that it's been updated but isn't a new waveform object
<azonenberg>
right now once a scope triggers the waveform is mostly assumed unchanging
<azonenberg>
and you get an entirely new waveform next trigger
<electronic_eel>
azonenberg: about the akl-pt3 - it looks to me like the u.fl connector section is wider than the tip area of the akl-pt2. is this correct or just due to scaling of the pictures?
<azonenberg>
The AKL-PT2 tip area is 3mm wide due to the coplanar waveguide construction
<azonenberg>
The tip area of the AKL-PT3 is 2.5mm wide
<azonenberg>
and the U.FL area is 5.5 but i think i can go tighter
<electronic_eel>
hmm, I fear that if you want to probe lot's of signals from one ic and thus have many pt3 in close proximity, the width of the u.fl area will become a problem
<azonenberg>
The AKL-PT3 is not CPW, it's barely a transmission line at all. the longest electrical length between component footprints is 650 um
<azonenberg>
Yes. i may eventually add a short ~3mm wide GCPW area and move the u.fl further away
<electronic_eel>
maybe give the pt3 a bit of a tail too? like 2 or 3 cm more
<azonenberg>
Think of this like a concept artwork more so than something production ready
<azonenberg>
the concept being "how small can i make a solder in probe?
<azonenberg>
I think i can cut the edges of the PT3 closer to the u.fl too
<azonenberg>
the original PT3 concept also had micro coax soldered directly to the PCB
<azonenberg>
which remains an option
<electronic_eel>
hmm, so no connector at all? and the micro coax going to an sma on the pod/scope?
<azonenberg>
The original PT3 concept was for MEAD
<azonenberg>
i was proposing making an adapter that went into the LSHM on MEAD and had 8x u.fl sticking out the front
<azonenberg>
So you'd solder a u.fl to bare coax pigtail onto the pt3
<azonenberg>
the idea was to make the pt3 a $10 probe you could use a couple of times then throw out when the connector or tip area failed
<electronic_eel>
but why the u.fl (with it's few mating cycles) on the MEAD, where you are not that space constrained?
<electronic_eel>
I'd use sma on MEAD and go from there to micro coax
<azonenberg>
Two reasons
<azonenberg>
First, MEAD actually is space constrained, eight SMAs at reasonable pitch is HUGE compared to the pod size. my current input connector is MMCX
<azonenberg>
second, i have not found micro coax to anything but u.fl
<electronic_eel>
ok
<electronic_eel>
no mmcx to micro coax?
<azonenberg>
If you can find one i'll use it
<azonenberg>
all the mmcx pigtails i saw were to rg316 or rg188 or rg174 or something else in that size ballpark
<electronic_eel>
how good do you think will be a solder connection of micro coax to a flex pcb, I mean signal integrity wise?
<azonenberg>
my hope would be that it would be amazing. Especially if it was electrically close to the resistors so there wasn't much room for any mismatch to resonate
<azonenberg>
But the idea was also to experiment and find out
<azonenberg>
the u.fl i'm pretty confident in, i did a sonnet sim of the connector launch to add a ground cutout and match the impedance
<electronic_eel>
how would you design a solder pad for this?
<azonenberg>
and the connector + cable i'm looking at using are rated to 6 GHz
<azonenberg>
so the PT2 and PT3 have the same tip geometry, a 0.2mm wide signal contact and 1mm away a ground
<azonenberg>
on the top side of the pcb
<azonenberg>
the intent is for you to kapton tape the probe very close to the test point then use magnet wire, 30ga, or similar to run the last little bit to the test point
<electronic_eel>
I know
<azonenberg>
the bottom side of the pcb is nonconductive so it can overhang other components, traces, etc
<electronic_eel>
I meant the solder pad for the micro coax
<azonenberg>
Oh
<azonenberg>
Not a clue
<azonenberg>
i'd probably just use a copper trace the same width as the center conductor
<azonenberg>
then a bit further up have a ground pad
<electronic_eel>
Not a clue != my hope would be that it would be amazing
<azonenberg>
lol
<electronic_eel>
but you have sonnet
<azonenberg>
hope does not mean hope grounded in science :p
<azonenberg>
but i've never done a connectorless sma launch
<azonenberg>
I mean i could design a well matched launch footprint for arbitrary geometry
<azonenberg>
but knowing the best geometry to use for the coax would be the hard part
<azonenberg>
things like, do you SMT the ground shield? twist it up and solder on one side? split it and solder on both?
<azonenberg>
without a very accurate 3D EM model of the coax mechanical construction you can't sim that
<electronic_eel>
yeah, you have to strip the isolation and shield of the coax to be able to solder the center conductor. the problem is what happens with the impedance once you removed the spacer and shield around
<azonenberg>
well the pigtails i was looking at came prestripped. So that part would be repeatable
<azonenberg>
at that point i would hope for the best if i had a pad the same width as the center conductor that sonnet showed matched to 50 ohms
<azonenberg>
the additional capacitance of the center conductor would bring me down a little bit, i can't model that effect without a 3D solver
<azonenberg>
but at the frequencies i'm working with it would probably be fine
<azonenberg>
at 40 GHz not so much
<electronic_eel>
it would be cool to get rid of the u.fl, so the pt3 wouldn't be that much of a throwaway-thing
<azonenberg>
Yeah. I was concerned about both electrical and mechanical properties of the bare sma launch
<azonenberg>
and best case micro coax will still have u.fl at the OTHER end
<azonenberg>
but for about $5 you can get a u.fl to sma male adapter and semi permanently mount that
<azonenberg>
and have the sma eat most of the mating load
<electronic_eel>
wouldn't a u.fl to mmcx pigtail be better here? because then you can have the smaller mmcx on MEAD and not run into space problems there?
<azonenberg>
again, if i could find one
<azonenberg>
cables with u.fl male seem to not exist
<azonenberg>
all cables are female
<electronic_eel>
hrmpf, what are these cable manufacturers doing?
<azonenberg>
this is an adapter with a u.fl male connector on one side and sma male on the other. it looks like a sma terminator with a u.fl sticking out the end
<azonenberg>
(and a separate nut and body so you don't rotate the u.fl when tightening)
<azonenberg>
so basically the PT3 needs to mate to either that or a PCB with a SMT u.fl male on it
<azonenberg>
unless you can find some other alternative for <1mm diameter coax
<electronic_eel>
ok, so I understand why you put the u.fl on the pt3
<azonenberg>
I do not like u.fl but i so far have found no superior alternatives
<azonenberg>
if someone suggests one i'll use it
<azonenberg>
the intent was for the pt2 to be long lived but more expensive and bulkier and the p3 to be for when you are trying to throw dozens of test points on a DUT and need something cheap and small
<electronic_eel>
idea: have the u.fl connector on the pt3. make the pt3 a bit longer, add some flex without traces after the u.fl. then use a u.fl to sma pigtail and glue the pigtail to the pt3 part without the trace. so the u.fl connection doesn't get much mechanical wear
<azonenberg>
electronic_eel: I've already ordered the pt3 as is but that sounds like a possible option. I could then also make it with a u.fl to u.fl cable instead for use with a custom MEAD input board
<electronic_eel>
to connect that to MEAD you can use sma to mmcx connectors, so you don't need to replace the input board on MEAD ever so often
<azonenberg>
except that means sma as an intermediary
<azonenberg>
do you know how big 96 SMAs would be?
<azonenberg>
also expensive :p
<electronic_eel>
but it would look hellishly cool on the desk
<azonenberg>
lol
<azonenberg>
meanwhile i'm thinking of designing an 8-bit solder in probe at some point
<azonenberg>
that would go direct to the LSHM on MEAD
<electronic_eel>
I know it takes space but I think you'd place the MEADs around the dut and find some space for the smas
<azonenberg>
and give you eight solder in probe points on a single FFC. the jumpers from that to the DUT would be longer so SI wouldn't be as good but if you were looking at lower speed signals it'd probably be fine
<azonenberg>
and less clutter on the bench than eight coax's
<electronic_eel>
how would grounding for that work? one ground for each signal or one common ground point?
<azonenberg>
Might make both versions depending on relative speed
<azonenberg>
the initial version would probably be one ground on each end of the string of 8 as a compromise
<electronic_eel>
one problem I see with this is that you don't know the pitch of your dut and need different of these probe adapters depending on pitch
<electronic_eel>
oh, and the resistor size will obviously limit pitch
<azonenberg>
No. this is not intended for ganged installation
<azonenberg>
it's intended to be taped in the general vicinity of the dut and then have flywires coming off. potentially long ones
<azonenberg>
this would be intended for tens to maybe hundreds of mbps data rates max
<azonenberg>
not gigabit like the pt2/pt3
<azonenberg>
Things like looking at slow GPIOs
<electronic_eel>
but wouldn't that be more the realm of CONWAY?
<azonenberg>
Potentially yes. but we'd probably still want damping resistors at the tip to avoid reflections
<azonenberg>
even if the probe itself was high-z input
<azonenberg>
and i expect CONWAY will use the same LSHM connector to the probe body
<azonenberg>
anyway that won't happen until probably post maxwell-in-hand
<electronic_eel>
I think this is designing the input for CONWAY. how to properly get the signal in without distortion and so on
<electronic_eel>
the resistor as early as possible in the path is part of that
<azonenberg>
yeah but we cant rely on any kind of external probe
<azonenberg>
as a key goal for CONWAY is compatibility with 100 mil ribbon cables gonig to an arduino or pi or something
<azonenberg>
a small damping resistor can be allowed but not required
<electronic_eel>
I think we may want different input options for CONWAY. one with grabbers, which means the resistor is not really at the tip, and a solder in style which can have cool rf resistors near the tip
<azonenberg>
hmm
<azonenberg>
yeah i want to do more performance testing of MEAD before even thinking about CONWAY
<azonenberg>
i have a 4 GHz active diff probe coming soon which will be perfect for looking at SI on the LVDS lanes
<azonenberg>
(after the sff cable)
<azonenberg>
and i have that SFP+ test fixture
<azonenberg>
so i should be able to use a sma-to-mmcx adapter cable to connect the output of the SFP fixture directly to MEAD, giving me a ~150 mV p-p signal at 1.25 Gbps which is about the fastest i expect to be able to handle in MAXWELL
<azonenberg>
(best case w/ oversampling we get 5 Gsps and you need 3-4x to do CDR)
<electronic_eel>
yeah, that should allow you to properly characterize MEAD and the probes for it
<azonenberg>
That's the idea
<azonenberg>
Get as much testing as i can before the maxwell hardware shows up
<Katharina>
azonenberg: besides reals, bools and strings, do we need enums as properties?
<Katharina>
like, a choice property like "never, always, .."
<azonenberg>
Yes. And colors which i might not have a type defined for yet
<azonenberg>
but it should end up as a Gdk::Color and use the standard color chooser widget i use in the channel properties dialog
<azonenberg>
I want to allow configuring colors for all of the decode overlays to fit user preferences, color blindness, etc
<Katharina>
sounds good.
<azonenberg>
right now there are big tables i look up colors in but you can't modify them anywhere
<azonenberg>
as far as enums the first case i have in mind is allowing 24x24 or 48x48 toolbar icons depending on screen DPI
<azonenberg>
they'll be rendered at one of those sizes so an int input makes no sense'
<Katharina>
like IconStyle::Small|Large?
<azonenberg>
Something along those lines yeah
<azonenberg>
Look at how i did enums in the filter dialog
<azonenberg>
you can probably reuse a lot of that logic
<Katharina>
got it
<Katharina>
off topic: i did my first post-covid run and i went from doing half marathons to being a wreck after a mile
<azonenberg>
You made it a mile still? Sounds like you're recovering at least
<azonenberg>
that's still not *easy*
<Katharina>
yea, about 0.86 miles according to my phone, but i rounded up
<azonenberg>
monochroma: so i discovered something interesting and annoying about TRS's website
<azonenberg>
Just because something is listed there does not mean you can actually rent it
<azonenberg>
If they sell off stuff from inventory they don't always remove things from the site
<azonenberg>
Several of the probes and stuff i was interested in they had sold off
<sorear>
keeping product descriptions and manuals available until the heat death of the universe sounds like a good thing if they're marked as unavailable
<azonenberg>
sorear: no manuals
<azonenberg>
just item photo and link to ask for a quote
<azonenberg>
there's no way to know it's not actually available without contacting them
vup has quit [Quit: No Ping reply in 180 seconds.]
Katharina has quit [Read error: Connection reset by peer]
Katharina has joined #scopehal
vup has joined #scopehal
Katharina has quit [Client Quit]
<_whitenotifier-f>
[scopehal-apps] bvernoux commented on issue #92: Add support for "dense" waveform storage format (no explicit offset/len) to reduce size of analog captures - https://git.io/JUhfm
<_whitenotifier-f>
[scopehal-apps] bvernoux edited a comment on issue #92: Add support for "dense" waveform storage format (no explicit offset/len) to reduce size of analog captures - https://git.io/JUhfm
<electronic_eel>
azonenberg: IIRC you had a specific sma cable you recommended for the pt1 probes. going to do a digikey order soon. would you mind to post the part no? thanks
<electronic_eel>
the one I'm currently using is not flexible enough to be used with a probe holder
<azonenberg>
electronic_eel: i actually ended up not shipping a digikey one with the pro package. I shipped a minicircuits fl086-24sm+ which is a very nice 18 GHz cable but its a bit stiff
<electronic_eel>
do you know one that is a bit more flexible, but maybe not 18 ghz?
<azonenberg>
ok for hand use but probably not a positioner
<azonenberg>
How high are you gonna be using it?
<azonenberg>
my favorite low speed test lead is a special RG174 with TPR insulation instead of the usual whatever
<azonenberg>
I get it from CD International (cdint.com)
<electronic_eel>
my spectrum analyzer is max 3 ghz
<electronic_eel>
so that is about it freq wise
<azonenberg>
You lose about 2 dB at 3 GHz for a 3-foot cable with these cables
<azonenberg>
But they're super flexible
<azonenberg>
SASA-174TPR-3. you can also get them with BNC or N at one end
<electronic_eel>
the price for the cable looks reasonable, the shipping to Germany will probably be not :(
<electronic_eel>
do you know something similar that is available at Mouser or Digikey?
<azonenberg>
No. But there's so many cables this doesn't mean there isn't one
<azonenberg>
just that i haven't happened to buy it
<electronic_eel>
ok, then I'll go looking. just thought you might know something offhand
<azonenberg>
(back, phone)
<azonenberg>
My digikey cables have all been RG-316 which is stiffer than the 174TPR - but not as bad as the minicircuits ones
<azonenberg>
or semi-rigid which is, well, semirigid
<azonenberg>
Crystek Microwave semirigid from digikey is a very nice cable if that's what you want. But not really for hand probing, more for test fixtures etc