<_whitenotifier-c>
[scopehal-apps] azonenberg 970425a - Added "delete" context menu item to history window. Fixes #343.
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #343: History view: allow older waveforms to be deleted without waiting for them to fall off the end of the buffer - https://github.com/glscopeclient/scopehal-apps/issues/343
Degi has joined #scopehal
electronic_eel_ is now known as electronic_eel
<azonenberg>
Just got tracking from Siglent for a SDS6204A dev unit
<azonenberg>
Other than their 12-bit variant (Asia market only) this is i think their current flagship scope
<azonenberg>
excited to see how it performs and if it's any snappier than the 2000x+
<azonenberg>
and just testing functionality and such
Stephie has quit [Ping timeout: 258 seconds]
<mxshift>
does glscopeclient have QSGMII decode?
Stephie has joined #scopehal
<azonenberg>
mxshift: Not yet, but we can do 1000baseX so it would be very easy to add
<azonenberg>
the only holdup is getting some test waveforms to work with, i could probably write the decode in an afternoon
<azonenberg>
arjen promised me some data then got busy w/ something
<mxshift>
I'll remind him. We're doing bringup of a QSGMII link today and someone noted that while we could probably see the signals on our 8GHz scope, we would need to decode them to understand anything about protocol failures.
<azonenberg>
mxshift: Great. Are they all gigabit or do you have any 10/100 in there too?
<azonenberg>
gigabit SGMII is identical to 1000baseX so all we'd need is a quick filter that would split one QSGMII lane out into four de-interleaved lanes, to which you can then apply the existing 1000baseX decode
<azonenberg>
If you get me a .scopesession with some test data, I could have that quick split decode written in an hour
<azonenberg>
writing a full SGMII decode as a derived class of the 1000baseX decode to support the repeated bytes in 10/100 mode would take a bit longer (and require test waveforms with a port set to 10 and 100mbit)
<azonenberg>
but still be quick
<mxshift>
QSGMII is 5Gbps
<azonenberg>
No i mean the streams within it
<azonenberg>
QSGMII is four SGMII lanes round-robin sharing a single SERDES, one 8b10b symbol from each in sequence
<mxshift>
Ah, this will be gigabit
<azonenberg>
with one control character swapped out in lane 0 so you can align to each phase
<azonenberg>
Ok, yeah then it's an hour of work max once i get a test waveform
<azonenberg>
I would like to eventually support 10/100 sgmii but that can come later
<mxshift>
Apparently we have the data but can't find a USB stick
<azonenberg>
What format is the data?
<azonenberg>
I can take raw CSV, agilent/keysight/rigol BIN, or (preferred) native scopesession files
<mxshift>
We don't have glscopeclient set up in the lab so this is whatever the scope's export is
<azonenberg>
what kind of scope?
<mxshift>
Tek I think
<azonenberg>
LeCroy .trc is notably not supported yet, but that's mostly because i ahven't put the time in. it's almost identical to the over-the-wire serialization format you use for downloading from the scope
<azonenberg>
IDK what tek can export
<azonenberg>
If it can do CSV that would be easiest i think
<azonenberg>
But native glscopeclient integration would be your best bet if it's a MSO6 or similar
<azonenberg>
They're not the fastest, but well supported
<mxshift>
Right now the goal is just to validate that SI isn't a problem and the patterns look reasonable. Getting you data is a "because we're here"
<azonenberg>
Makes sense
<mxshift>
Setting up glscopeclient is another day
<azonenberg>
well, when you do you'll probably start wondering how you got any work done without it :P
<mxshift>
One of our EEs is already using it some. Just not the ones at the main lab
<azonenberg>
ah cool
<azonenberg>
Definitely have him send me any feature requests, bug reports, etc that would make it more usable for you folks. You're like my exact target user (F/OSS friendly company doing high speed digital work)
<_whitenotifier-c>
[scopehal-apps] azonenberg 324ab4f - Initial work on markers. Markers can be created, and are destroyed when the parent waveform is destroyed. Displayed in history view, but not in waveform areas and cannot be interacted with.
<_whitenotifier-c>
[scopehal-apps] azonenberg 7928dd7 - Continued work on markers. Markers can now be displayed in timeline and waveform areas, dragged around, and renamed. Cannot be deleted or persisted to files yet.
<azonenberg>
@louis: around?
<azonenberg>
lain, @mubes: maybe you might have ideas on this
<azonenberg>
So, i'm trying to figure out how to make markers work logically in glscopeclient
<azonenberg>
The basic distinction is, a cursor represents a *relative* point in time
<azonenberg>
i.e. an offset from the start of whatever the waveform you are currently looking at is
<azonenberg>
a marker represents an *absolute* point in time
<azonenberg>
so you can mark a point on a waveform, acquire a new waveform
<azonenberg>
and the marker stays on the old one in history, and can be seen under the history view
<azonenberg>
make sense?
<azonenberg>
the idea is to be able to collect a bunch of waveforms during analysis and quickly find interesting points within old waveforms
<azonenberg>
(also ping: balrog)
<azonenberg>
Right now, the challenge i'm puzzling over is how to integrate this with waveform generation filters, like the step or prbs generation filters i use for SI testing
<azonenberg>
because those filters do not represent data from an actual measurement, currently they set the waveform timestamp to the time at which the filter was evaluated
<azonenberg>
which means every time you change anything on the filter, or refresh the filter graph for any reason
<azonenberg>
the timestamp changes
<azonenberg>
and any markers you put on them are lost forever
<azonenberg>
(there's no history for filters, as the filter graph exists outside of waveform history and is generally assumed to be idempotent - you can call the filter graph as much as you want and as long as the inputs are the same, output is the same)
<azonenberg>
(PRBS and noise generation are also touchy, as every time they're evaluated the output is different)
<azonenberg>
so even opening and closing the properties dialog can cause the waveform content to compeltely change
<azonenberg>
Also, if you click on a marker in the history view I want to make the marker scroll to be centered / visible in the view
<azonenberg>
but if you have multiple waveform groups open scrolled to different points in time etc, which one(s) do you zoom?
<azonenberg>
s/zoom/scroll/
<d1b2>
<louis> I'm around!
<d1b2>
<louis> I've been busy preparing for and then in CA for a conference
<d1b2>
<louis> One thought is, why not just make PRBS and noise deterministic from some seed? Seed can be an input param and picked randomly when you instantiate the filter (or not) and then changed when/if the user wants a different output
<azonenberg>
Yes, that is a valid consideration
<azonenberg>
I've been thinking of doing exactly that
<azonenberg>
Doesn't solve the timestamping issue though
<azonenberg>
(which is the more important near term problem)
<azonenberg>
For noise this isnt a problem because we can just pass through the timestamp of whatever we're adding the noise to
<azonenberg>
For file imports, we use the timestamp of the file
<azonenberg>
but for PRBS, step, and tone generation there are no inputs at all other than parameters
<azonenberg>
also, what do we do if you mix waveforms with different timestamps in the same group? like a synthesized step and a live scope capture
<azonenberg>
or an import and a live capture
<azonenberg>
right now the marker will disappear in some of the views, which is not optimal
<azonenberg>
but at the same time i don't want to be confusing about what point in time the marker is actually referring to