<d1b2>
<azonenberg> all protocol decodes should now be functional in ngscopeclient, however the pop-up protocol analyzer view you may be used to from glscopeclient with the table of packets is not currently available in ngscopeclient
<d1b2>
<azonenberg> that's probably my next todo item
<d1b2>
<azonenberg> also rendering for several "weird" waveform types (spectrograms, eye patterns, and FFT peaks i think are all that's left) isn't yet implemented
<d1b2>
<ehntoo> Heck yeah
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<azonenberg>
Random data point that probably doesn't mean anything: ngscopeclient is now 2/3 the size of glscopeclient, in terms of number of lines of source including whitespace and comments
<azonenberg>
I don't have a breakdown for how much of that was copied/ported from glscopeclient and how much is new
<azonenberg>
and of course the feature sets arent the same
<azonenberg>
ngscopeclient has all of the guis for instruments other than scopes, which glscopeclient is very light on
<azonenberg>
while glscopeclient has eye patterns, protocol analyzer, spectrograms, fft peaks, and of course scopesession load/save
<azonenberg>
and multiscope sync
<azonenberg>
I think ngscopeclient is going to become bigger quickly because of all the stuff we still have to add, but i also think the immediate mode nature of imgui actually leads to the code being more concise in a lot of cases
<azonenberg>
especially things like tree/list views in GTK get very bloated because you're constantly shuffling data between your internal data structures and the GTK version
<azonenberg>
while with imgui i can just emit rows directly from the internal representation without any translation
<azonenberg>
I also am pretty happy with the pace of progress and i think end of year or early 2023 is still a reasonable expectation for when most users should be able to switch over
<azonenberg>
maybe not 100% feature parity, but close enough
massi has joined #scopehal
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
massi has quit [Remote host closed the connection]
<bvernoux>
@azonenberg, I have just tried latest ngscopeclient with decoder it is amazing I was testing it on Rigol capture of WCH CH569 SerDes to decode 8b10b Hex
<bvernoux>
@azonenberg, the only issue is when we import bin(Rigol) with multi-channel inside the N channel are imported with same setting same color and cannot be separated
<monochroma>
bvernoux: off topic, but i just wanted to confirm the ch569 really only has a single SerDes pair with selectable Tx/Rx modes (since iirc you did the HydraUSB3?)
<bvernoux>
monochroma, unfortunately yes there is a single SerDes pair configurable as TX or RX
<bvernoux>
monochroma, It is why I plan to use it like a real-time trace for debug/trace purpose
<monochroma>
weird! havn't seen that before. wonder what the intended use case was
<bvernoux>
the use case is half duplex video I think over it
<monochroma>
something standardized or custom?
<bvernoux>
as it is very robust and amplified which can work to more than 100m with >600Mbps
<bvernoux>
It is custom of course as it is based on SATA for data
<azonenberg>
monochroma: yeah i helped him RE some of it, i recognized the line coding as sata instantly
<azonenberg>
but the upper layer is custom
<azonenberg>
bvernoux: So that is a general architectural issue which applies to glscopeclient too
<azonenberg>
color is a property of the channel, not the stream, and importer filters are considered to be one channel
<azonenberg>
i'm considering changing this
<bvernoux>
azonenberg, yes maybe just importe multi chan in same file like if they are different file
<azonenberg>
so the issue is just presentation
<azonenberg>
i want them to be visually grouped if it's things like real/imaginary of the same s-parameter dataset
<azonenberg>
also, right now the node color in the graph editor is the channel color
<azonenberg>
when you have multiple outputs, what is the node color?
<azonenberg>
the implementation is easy, the UI/UX is the hard part
<bvernoux>
I think just to have separate color for each channel will be enough
<bvernoux>
it is great to keep them grouped anyway as they are often linked...
<azonenberg>
well thats my point though
<azonenberg>
an import filter is a single filter instance
<azonenberg>
thus logically one channel
<azonenberg>
channels in the original acquisition map to streams of that channel
<azonenberg>
thus there's one color for them all
<azonenberg>
way back 6+ months ago, importers were implemented as a virtual oscilloscope with separate channels, and this allowed per channel coloring. but it didn't fit as well with the filter graph model because you had no way to provide parameters to the importer
<bvernoux>
ha ok that explain the difference
<azonenberg>
anyway, so the best way to solve this is to enable per stream colors. it's just not trivial to fit this into the existing GUI model while still preserving the visual connection between streams
<azonenberg>
maybe we can have a flag per class that says if you should have a constant or per stream color or something, idk
<bvernoux>
ha yes
<azonenberg>
Random interesting idea: black box with 50 ohm inputs and 3.3V 0.1" pin header outputs
<azonenberg>
containing a bunch of comparators and such
<azonenberg>
The idea is to allow you to use transmission line probes or active probes to feed into a saleae or similar LA that isn't optimized for low loading or weak signals
<azonenberg>
so you can use e.g. a bunch of PT5s to sniff some fast-ish bus but then feed it into MSO channels
<electronic_eel>
azonenberg: when your la input probe thing is usb powered i suggest to add a small mcu and an 8x dac to allow setting individual trigger levels
<azonenberg>
yes that was the idea
<azonenberg>
i was thinking it'd be self contained, just front panel LCD with some arrow buttons
<azonenberg>
but there might be an option for usb control in the future
<azonenberg>
i'd likely wire it up but not ship firmware to do that initially
<azonenberg>
you see what i'm going at here though?
<azonenberg>
wrt the pain of soldering little stub wires to a dut then hanging ez hooks and dupont wires off them
<azonenberg>
lots of connections to come loose
<electronic_eel>
i don't know if an lcd is necessary. would make it quite large and the box it comes in more complicated
<azonenberg>
it doesnt have to be big
<azonenberg>
little 1-2" diagonal thing
<electronic_eel>
an easy serial protocol to set the trigger level with a terminal program should be enough
<azonenberg>
yeah i mean this would basically be my MEAD logic pod but with LVCMOS33 instead of LVDS outputs
<azonenberg>
and probably lower bandwidth
<electronic_eel>
how would you connect the probes? 8 sma connectors?
<azonenberg>
no. small push on connector
<azonenberg>
probably SMPM for commonality with my other stuff
<azonenberg>
so you'd have 8x SMPM at one side (or even 16)
<azonenberg>
then a 2x8 or 2x16 header w/ signal and ground on the other
<electronic_eel>
ah, ok. but then you need smpm to smpm cables in addition to smpm to sma cables for your probes. iirc the cables were quite a substantial fraction of the costs for the probes
<azonenberg>
Correct
<azonenberg>
The issue with SMA on the output is that it's physically quite large and you need space to turn the nuts
<azonenberg>
this isn't something i'm going to start work on this week or anything. just musing about potential here
<electronic_eel>
yeah, they would take up some space. maybe two rows of 4 smas?
<azonenberg>
these are for <1 GHz BW applications, keep in mind
<azonenberg>
so we can get away with fairly cheap cable, it doesnt have to be the super fancy stuff
<bvernoux>
LA are often limited to less than 500MHz BW anyway
<azonenberg>
exactly
<bvernoux>
or even less than 200MHz
<bvernoux>
so 400Mbps
<azonenberg>
Which is why i'm saying we should be using cheapish cables
<electronic_eel>
are there cheap smpm to smpm cables available? when i looked briefly last time, all smpm stuff was quite expensive compared to sma
<bvernoux>
on my Rigol LA POD I'm using 600Mbps LVCMOS to LVDS
<azonenberg>
Yes, it is. but the probe has a SMPM termination regardless
<azonenberg>
There's potential for making, say, a MMCX version of the PT5 optimized for low cost
<bvernoux>
I have bought the last stock available in world ...
<bvernoux>
until there is something at end of 2023
<bvernoux>
I have 500 units
<bvernoux>
Each LA pod requires 16 units so it fast to use all the 500 units
<electronic_eel>
what was the reason to use smpm on the pt5 instead of mmcx?
<azonenberg>
MMCX is 6 GHz max
<azonenberg>
i'm using smpm on the av1 and other lower speed probes simply for commonality of cabling across the product line
<azonenberg>
i may well offer mmcx versions in the future
<azonenberg>
it would be a fairly small pcb change
<electronic_eel>
ah, ok. so if you don't need the max freq of the pt5 it could be a good option to save costs
<electronic_eel>
are smpm to mmcx cables a thing? then you could always use mmcx on the la input adapter
<azonenberg>
I mean, you can get any combo of cable and connector you want pretty much
<azonenberg>
but if you custom order they're $$$
<azonenberg>
also smpm and mmcx look similar enough i dont like mixing them
<azonenberg>
wrt potential for damage if you try to mate them
<azonenberg>
the mmcx will be fine, the smpm may not
<azonenberg>
one of the issues is for these tiny solder in applications you need really skinny high flex cable
<azonenberg>
but that's usually expensive mm-wave cable