<azonenberg>
shield-digital: oh, so one other feature i didn't mention. Still a WIP, it works but requires a lot of manual setup on the scopes since i don't have all of the commands scripted yet
<azonenberg>
You can connect to more than one instrument at once
<azonenberg>
if you sync the refclks and daisy chain trigger in/out, and properly calibrate for cable propagation delay between the units, you can do acquisitions on arbitrarily many scopes
<azonenberg>
They do not need to have the same sample rate or bit depth or number of channels
<azonenberg>
also, if you have an instrument like a logic analyzer that does RLE, you do not need samples to be constant duration or directly adjacent
<azonenberg>
every sample object internally stores a length and start time. This is needed so protocol decoders etc can have non-monotonic outputs
<azonenberg>
Eventually i plan to support user-transparent resampling, but for now most 2-input analog filters (like subtracting one voltage from another for pseudo differential inputs) require the same sample rate on the inputs
<azonenberg>
Anything that works with a clock actually sweeps through the data signal and lines up with the clock edges, so the clock and data do not need to have the same sample rate
<azonenberg>
and anything that works on upper level protocol packets makes no assumptions about sample rate as that's no longer meaningful
<azonenberg>
Down the road when i build my own acquisition hardware you will be able to configure PLL dividers for each ADC individually, as well as trigger offset *per channel*
<azonenberg>
So for example you will be able to record slow I2C traffic to a variable attenuator at 50 Msps with a very long record length, then right as the gain setting takes effect record a short window of 10 Gsps data on the input and output to see ringing as the taps change
<azonenberg>
I don't think anyone currently makes a scope capable of this
<azonenberg>
and yet it's such a simple thing to build
<_whitenotifier-3>
[scopehal-docs] azonenberg pushed 1 commit to master [+2/-0/±0] https://git.io/Jv8Ym
<_whitenotifier-3>
[scopehal-docs] azonenberg 3279cb3 - Initial skeleton of manual with some compilation instructions
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #53: Allow display name of waveform groups to be changed - https://git.io/Jv8Yy
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #53: Allow display name of waveform groups to be changed - https://git.io/Jv8Yy
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #53: Allow display name of waveform groups to be changed - https://git.io/Jv8Yy
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/Jv8sT
<_whitenotifier-3>
[scopehal-apps] azonenberg 2cd7357 - Timeline: can now use mouse wheel to zoom, rather than just on waveform area
<_whitenotifier-3>
[scopehal-apps] azonenberg 9d39259 - Added TODO for future driver support
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #54: Allow changing channel vertical offset by dragging Y axis timeline in WaveformArea - https://git.io/Jv8sC
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #54: Allow changing channel vertical offset by dragging Y axis timeline in WaveformArea - https://git.io/Jv8sC
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #54: Allow changing channel vertical offset by dragging Y axis timeline in WaveformArea - https://git.io/Jv8sC
<_whitenotifier-3>
[scopehal-apps] azonenberg edited issue #54: Allow changing channel vertical offset by dragging Y axis scale in WaveformArea - https://git.io/Jv8sC
<_whitenotifier-3>
[scopehal-docs] azonenberg pushed 1 commit to master [+2/-0/±2] https://git.io/Jv8sM
<_whitenotifier-3>
[scopehal-docs] azonenberg f1cc7ad - Began writing user manual. Added some high level overview screenshots.
<_whitenotifier-3>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jv8Z6
<_whitenotifier-3>
[scopehal-docs] azonenberg 7b2f270 - Added skeleton to manual for protocol decodes. No actual content yet.
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #27: Write some end-user documentation!! - https://git.io/Jv8ZM
<_whitenotifier-3>
[scopehal-cmake] azonenberg pushed 1 commit to master [+1/-0/±5] https://git.io/Jv8ZS
<_whitenotifier-3>
[scopehal-cmake] azonenberg 2266253 - Updated submodules, added docs repo, removed some content from readme that belongs in the manual
bvernoux has joined #scopehal
<shield-digital>
azonenberg: also a feature that sounds incredible. Have you thought about doing a PCIe card for the initial version of the hardware?
shield-digital has quit [Remote host closed the connection]
<bvernoux>
azonenberg, do you have seen my latest version of Probe Test Board v0.4 ?
<monochroma>
shield-digital: likely the hardware will be 10gig ethernet interfaced instead of PCIe
<azonenberg>
shield-digital: yeah probably not pcie. I run a decentralized lab with multiple workstations and having the ability to move around and still talk to equipment is critical for me
<azonenberg>
You can always run a direct-attach cable from a 10g nic to the board
<azonenberg>
everything will also have 1g for lower b/w transfer to cheaper hardware like a laptop
<azonenberg>
The first version with the HMCAD1520 or similar will probably be 1G only
<azonenberg>
since that will allow use of a cheap FPGA like an artix7 ftg256
<lain>
ah so you are considering an hmcad15xx part :D
<azonenberg>
lain: My plan is to build at least three generation
<lain>
it's funny, ever since hmcad was still a thing made my Arctic Silicon Devices (before Hittite and now Analog Devices acquisitions), back in like 2007, I knew it'd be perfect for a scope
<lain>
when rigol introduced their 1000Z series
<lain>
I'm pretty sure they used an hmcad1511
<azonenberg>
First gen will be low cost, low bandwidth. I'm thinking 2x HMACD1520 fed to a total of 8 inputs, artix7, then gig-e to the outside world. Probably a few hyperrams for buffering?
<lain>
overclocked a bit, and they time-interleaved some for higher sample rate iirc
<azonenberg>
option of DNPing one of the ADCs to reduce cost
<azonenberg>
so on one extreme you can get 8 channels, 12 bit, 160 Msps
<azonenberg>
on the opposite extreme 2 channels, 8 bit, 1 Gsps
<lain>
yep
<azonenberg>
each ADC will be individually configurable so you may have different sample rate on one half vs the other. This will be a good test for scopehal's variable rate support
<azonenberg>
I might also go further and have the PLL clocks to each individually configurable
<azonenberg>
so you have the option of doing slow, say 10 Msps, capture on one ADC for deep memory of i2c/uart and then faster on the other
<azonenberg>
Since that's also a feature i want to debug before moving to higher end acq hardware to
<azonenberg>
too*
<azonenberg>
and design a good UI for changing multiple timebases and keeping track of which timebase stuff is on
<azonenberg>
It will also have features like trigger in/out and refclk input that are normally reserved for much higher end hardware
<azonenberg>
No market segmentation here, i'm going to build the best scope i can with a low-cost BOM
<azonenberg>
oh i forgot the 1520 also has a 14-bit 105 Msps mode
<monochroma>
if it doesn't have software locked out features, is it /really/ a scope?
<azonenberg>
Lol
<azonenberg>
oh, and the scope will be 50 ohm input only
<azonenberg>
You're expected to use transmission line probes or active probes, no support for those godawful 1M capacitive nightmares :p
<azonenberg>
(and will have SMA inputs rather than BNC to prevent someone from being stupid with a 1M probe)
<azonenberg>
i figure i can make a low bandwidth high impedance probe, like 5K ohm input impedance or something, which will be a good enough substitute for a high-Z probe in most applications when you don't need to go fast
<sorear>
I have many questions about the economics of $$$ ADCs
<azonenberg>
Speaking of probes, DHL says as of 10 minutes ago my probe boards cleared customs in LA
<azonenberg>
ETA still says Thursday but i think they'll get here mon or tues
<monochroma>
yay
<azonenberg>
So by midweek one way or another, I should have some preliminary eye patterns and VNA traces for them
<azonenberg>
out to 2-3 GHz at least. If they look good i'll have to figure out how the heck to see if they're good as far into the X-band as i think they are :p
<azonenberg>
Oh, so you know how i unified protocol decodes and math functions in scopehal?
<azonenberg>
what if i fold measurements into there too, to allow better trending
<azonenberg>
a measurement is simply a protocol decoder that outputs an analog waveform *and* a scalar
<azonenberg>
(typically the average of that waveform across the entire capture)
<azonenberg>
Then you get automatic trending of every measurement by virtue of also being a filter you can apply to a signal
<azonenberg>
then summarization
<azonenberg>
Because right now i have only one trendable measurement, period of a signal, and that is a completely separate implementation I made just because i needed it NOW
<azonenberg>
So it obviously won't scale to do it that way
<azonenberg>
The other thing i have to do to fix things properly is add proper unit support rather than just assuming everything X is ps and Y is volts
<monochroma>
that sounds useful
<azonenberg>
at some point i also want to add long term trending support, one point per acquisition
<azonenberg>
displaying graphs that span seconds to minutes or more. But i'm not yet sure how that will fit into the object model which right now assumes everything comes from a single capture
<monochroma>
azonenberg: also, re scope card, would be interesting to make it dual form factor, standard barrel jack power+ethernet port for stand alone use, and a card edge connector to plug into a backplane for MARBLEWALRUS style use
<azonenberg>
Hmmmm maybe later on? definitely not the first iteration which will just be for experimenting
<azonenberg>
seeing as we dont even have the next-gen marblewalrus architecture defined yet
<azonenberg>
oh, so here's another protocol decode i haven't seen anywhere
<azonenberg>
Volts to amps given resistance
<azonenberg>
i.e. you take a measurement on a low-side shunt, or a differential measurement on a high side shunt
<azonenberg>
input the resistance and it prints out the current
<azonenberg>
(that's already on the wishlist)
<monochroma>
oooo
<azonenberg>
Poor man's current probe, lol
<azonenberg>
if you dont have a fancy rogowski coil probe or something, but have a low valued resistor handy
<azonenberg>
Or if you want to measure on a PSU that has an integrated shunt for an ina226 or something
<monochroma>
those are nice, i worked with a PMC carrier card that had those with DMM probe ports (that standard DMM probes would slide into)
<azonenberg>
yeah i was just looking at how pricey lecroy current probes were
<azonenberg>
and realizing how nice it would be if i could just throw a cheap passive probe across a shunt
<adamgreig>
azonenberg: i do that a bunch with my normal scopes, set the channel to 'amps'
<adamgreig>
and the probe attenuation to whatever number is the resistance (or 1/)
<adamgreig>
scope happily reports current in amps, correctly scaled
<adamgreig>
siglent, keysight etc
<azonenberg>
interesting. Yeah i dont know how to do that on a lecroy without using a current probe
<azonenberg>
probably doable
<azonenberg>
either way scopehal should be able to do it too
<adamgreig>
on the keysight i have to tape over the probe ID pin to stop it hard-setting it to volts
<azonenberg>
lol
<adamgreig>
it happily lets you change units and attenuation on inputs that aren't autodetected, but if the scope id pin works then it locks them, sigh
<azonenberg>
I see that makes sense
<azonenberg>
anyway, right now i'm working on #89. Plan is to have a Unit class that has a PrettyPrint function for converting a value to a strnig with appropriate SI prefixes
<adamgreig>
it does and i have no shortage of kapton tape lying around so whatever, but it was a bit annoying until i worked out why it wasn't letting me change it
<azonenberg>
e.g. kohms, mA, etc
<adamgreig>
adding keysight support to scopehal remains on my todo list if no one beats me to it fwiw, i would find it very useful but don't yet strictly need it, so..
<azonenberg>
This will replace FloatMeasurement::GetValueAsString() and becomes a more key part of the system
<azonenberg>
also being used for printing x/y axis channel labels etc
<azonenberg>
Anybody here working on anything scopehal related at the moment?
<azonenberg>
adamgreig: btw did you look at the manual draft i linked earlier? thoughts?
<adamgreig>
i saw your tweet but did not click through yet, i will have a look
<adamgreig>
meta thought is that i prefer writing markdown and using pandoc to render to latex these days
<adamgreig>
you can stick raw latex in wherever you want, but for the bulk of the prose you can do markdown, which i find nicer
<adamgreig>
pandoc does a great job of managing it
<adamgreig>
latex is fine too though, whatever :P
<azonenberg>
we can always reformat, having *some documentation* was the priority for me :p
<azonenberg>
lots of sections are blank but i at least wanted to get the outline done at a high level
<azonenberg>
and some introductory getting-started text
<adamgreig>
for sure
<adamgreig>
other nits, latex renders `--debug` as an em dash, so you want \texttt or something, or just backticks in markdown :p
<azonenberg>
File a ticket on scopehal-docs? not a priority but worth fixing. I threw that together in one ~4 hour sprint last night
<azonenberg>
so its not exactly polished yet
<adamgreig>
sure
<adamgreig>
huh, fun, i hadn't really noticed this before reading the manual but glscopeclient has a lot in common with the data acquisition display software i wrote at work
<azonenberg>
oh? in terms of being a filter graph?
<azonenberg>
(at some point i want to expose some kind of editor UI that makes this more explicit)
<adamgreig>
trying to find a screenshot that i can share that would demonstrate, but yea
<adamgreig>
that and the lots of groups, adjustable layouts for them, views into other groups, statistics over selected regions, bla bla
<azonenberg>
I am amazed developers of "actual" scope UIs don't do it like this
<azonenberg>
it seems like a pretty logical architecture
<adamgreig>
it is if you have a mouse and keyboard
<azonenberg>
Fair point
<adamgreig>
but i guess a lot of older/lower-end scope uis are really predated on not having that
<azonenberg>
and more modern ones assume touchscreen so big chunky buttons etc
<azonenberg>
My general design goal for glscopeclient is to keep the clean, context-based UI look/feel of lecroy MAUI (minimal explicit UI elements, touch things to interact with them, menus and dialogs appear as needed and then go away)
<azonenberg>
But optimizing for a large HD display with a mouse/keyboard rather than a small touchscreen
<adamgreig>
yep, it makes a huge amount of sense
<adamgreig>
manual looks good from a quick read, i remain totally convinced by combining maths and protocol decoders into one unified thing like that
<azonenberg>
What do you think of folding in measurements too?
<azonenberg>
a measurement is simply a protocol decode that outputs a scalar alongside a vector
<adamgreig>
what is the vector? the scalar value over the same time as the input?
<azonenberg>
yes
<azonenberg>
so you can view, say, risetime as a function of time on a signal
<adamgreig>
one thing i like from my software is i can draw a region and take measurements inside it
<azonenberg>
or frequency vs time
<azonenberg>
File a ticket and i'll try to come up with a way to support bounding measurements
<azonenberg>
In fact, maybe i won't even have the decode output a scalar at all
<azonenberg>
The native output will JUST be a vector, with one sample per input sample, per UI, per rising edge, or whatever other thing it measures
<adamgreig>
and the measurements box will average that vector over its length?
<azonenberg>
then there will be a summarization operator you can apply to view average, min/max/stdev, etc
<adamgreig>
yea makes sense
<azonenberg>
With arbitrary bounds defaulting to the entire trace
<azonenberg>
So that way everything is natively a transformation operator that turns one or more waveforms and zero or more configuration options into a waveform
<azonenberg>
And you can then extract properties from said waveform arbitrarily
<adamgreig>
and the only non-waveform output is an actual display widget or whatever
<adamgreig>
a sink in the filter graph
<azonenberg>
well it will be in the library
<azonenberg>
So you can do ATE type applications that find, say, average risetime of a squarewave
<adamgreig>
does the ATE use case still use glscopeclient?
<azonenberg>
No. Everything is in libscopehal/scopeprotocols/scopemeasurements, glscopeclient itself is just a UI for interacting with the library
<azonenberg>
you can run all of the filter graph stuff in headless mode
<azonenberg>
just write your own C++ application to itneract with it
<adamgreig>
sounds lovely up until "C++" :P
<adamgreig>
can do some bindings one day i guess
<azonenberg>
BTW this means that i will probably be merging libscopeprotocols and scopemeasurements into one at some point
<azonenberg>
since there will no longer be a meaningful difference
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±13] https://git.io/Jv8rP
<_whitenotifier-3>
[scopehal] azonenberg 7af2190 - Initial implementation of Unit class (see #89). Not fully integrated everywhere yet.
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/Jv8rM
<_whitenotifier-3>
[scopehal-apps] azonenberg a9c9b93 - Initial integration of new Unit class for Y axis units on traces