<_whitenotifier>
[scopehal-sigrok-bridge] 602p 2419d09 - Use correct channel for trigger offset; fix bugs with trigger source and offset selection on DSLogic
<_whitenotifier>
[scopehal-pico-bridge] azonenberg 7851a72 - Don't print warning message if we request an invalid timebase because too many channels are enabled. Just hide it from the list.
<_whitenotifier>
[scopehal-apps] azonenberg 88e6e72 - Refresh timebase properties dialog when channels are added/removed, in case set of valid sample rates/depths changed as a result
<_whitenotifier>
[scopehal] azonenberg 0691350 - Fixed typos in copyright line
<azonenberg>
@louis: ok so i merged your PR and also fixed a typo in the copyright lines (you had 2022- instead of 2012-2022)
<azonenberg>
Going to start porting the digilent and pico drivers over to this model shortly
<azonenberg>
at that point i think the control plane refactoring will be pretty solid
<azonenberg>
then we can turn our attention to data plane, we need to make the waveform data protocol more consistent across the bridges and also figure out the fine points of the flow control scheme
<_whitenotifier>
[scopehal-docs] azonenberg 66194b5 - Documented digital-to-NRZ and digital-to-PAM4 filters. Added skeleton descriptions for a lot of filters.
bvernoux has joined #scopehal
<Degi>
azonenberg: re channels: Isn't that exposed in the API where you can get if a channel is active or not? (And that should be read from the scope at startup IIRC)
<azonenberg>
Degi: what is not exposed is whether it's a usb or standalone scope
<Degi>
I see
<azonenberg>
the theory is, a usb scope should start up with some reasonable default channel set
<azonenberg>
as they have no memory between uses of what's going on
<azonenberg>
a standalone scope should start up with the currently active channel set unless there are no channels active
<azonenberg>
in which case it should enable some default set
<Degi>
Hmm
<Degi>
If the USB scopes have no memory, then either none or all channels will be active (at least that is my guess)
<azonenberg>
Default is normally none i think
<Degi>
Hmm, then we could check for none and activate some default set maybe
<azonenberg>
yes, i guess that is one option
<azonenberg>
("all analog" is probably a reasonable default in that scenario)
<Degi>
Maybe storing configuration between sessions could be nice
<azonenberg>
although we'd have to figure out what to do with a LA
<azonenberg>
I dont like th eidea of storing config
<azonenberg>
because often when i disconnect and reconnect to an instrument it's because i'm doing something totally different from last time
<Degi>
Another idea: Sample every channel and only enable channels with > 10 % FSR RMS readings or so
<azonenberg>
i dont like that idea at all
<Degi>
Yeah, a bit unpredictable
<azonenberg>
your dut might just be off or something
<azonenberg>
yeah
<Degi>
Hmm, though storing config as an option could be nice, so that I don't have to re-enter IP address and everything each time (maybe it is there and I didn't see it)
<Degi>
(Like as an option in the drop down or so)
<azonenberg>
oh
<azonenberg>
you just mean locatio nof the scope
<Degi>
Hmm, I thought also channels etc. could be nice but location would be a good start
<azonenberg>
file | recent instruments
<Degi>
Oh nice, thanks!
<azonenberg>
it stores the ... 10? most recently used
<azonenberg>
(I have 7 including all the digilent gear and the demo scope simulator, i might need to up that limit soon lol)
<Degi>
Maybe add a config option xD
<azonenberg>
I've been adding a lot of content to the docs lately on filters and such but i should go through and document a bunch of the recently added menu items and such too
<azonenberg>
the docs are definitely lagging the actual feature set by a fair bit
<azonenberg>
I wonder how far we are from breaking 200 pages (currently 191)
<azonenberg>
although many of those 191 are empty headings for filters that are not fully documented and just have a sentence or so of text
<Degi>
I wonder if a HTML documentation generated from the tex could be useful, like with collapsible sections and stuff
<azonenberg>
once we have content we can always reformat it
<azonenberg>
getting the text is the hard part for now
<azonenberg>
Ok great i have a call in a few minutes and will review it after that
<azonenberg>
I refactored the Digilent driver to use RemoteBridgeOscilloscope last night but did not have time to do Pico
<azonenberg>
that's on my agenda for tonight
<azonenberg>
In the meantime, if you're looking for something to do i suggest starting to work on unifying the data plane side of the bridge
<azonenberg>
Think about how we can handle various kinds of data (raw ADC codes, fp32/fp64, sparse/dense MSO samples)
<azonenberg>
so we'll probably have to add a type field
<azonenberg>
i want to do that unification first, then flow control on top of it
<tnt>
azonenberg: have you ever simulated high speed lanes on flat flex ? I'm wondering how doable it'd be to have pcie (2.0 or 3.0) on flex from oshpark ?
<azonenberg>
tnt: The AKL-PT2 did ~6 GHz BW on oshpark flex in prototyping although i moved to a chinese fab for volume
<azonenberg>
it was limited by losses due to length of the flex, that was the -3 dB BW
<azonenberg>
for digital data especially with good equalization, a foot or so should be very viable out to gen3 speeds and maybe even gen4
<azonenberg>
assuming you don't have a ton of loss elsewhere in the system
<tnt>
azonenberg: oh good to know. It'd be way less than a foot, maybe 15 cm max, it's mostly to extricate the lanes from the underside of a motherboard. The classic "riser cables" that use a bunch of coax is not flexible enough to make a 90 deg angle.
<Degi>
Gen 2 works with flat band cables (at least when aluminium shielded, though not sure if that is necessary since I changed two parameters during my test and thus I'm not sure what was the cause)
<Degi>
(Gen 3 might too, didn't try)
<Degi>
(The second parameter was a disconnected line of one side of a differential pair, it still worked but with a lot of errors and thus at a reduced rate, even compared to Gen 1 speeds)
<_whitenotifier>
[scopehal] 602p fae959b - Silence unused parameter warning now that digital threshold is device-wide
<_whitenotifier>
[scopehal] azonenberg 7382c8c - Merge pull request #570 from 602p/dslabs Support first-sample offset in digital waveforms for DSLogic devices