06:27 <azonenberg> Ooook so, i want the ability to export stuff from a glscopeclient session to external formats

06:27 <azonenberg> csv, vcd, touchstone, etc

06:27 <azonenberg> this gets tricky because not all data is compatible with all formats

06:28 <azonenberg> e.g. it doesn't make sense to export analog data to VCD, or logic analyzer traces to WAV, or anything but s-parameters to touchstone

06:28 <azonenberg> The actual file creation is trivial but the UI side is not

06:28 <azonenberg> anyone have thoughts about what the UX for exporting data should look like?

06:28 <azonenberg> do you do it from the file menu or waveform context menu or a filter graph block or what?

06:28 <azonenberg> how do you select the format and which signals you want to export?

06:29 <azonenberg> how does the UI prevent you from choosing incompatible channels?

06:35 <azonenberg> and how do we do this all without excessive numbers of clicks and wizards etc if at all possible?

06:35 <azonenberg> And how do we handle situations in which the channels being exported don't all have the same sample rate / interval, phase offset, etc?

06:37 <azonenberg> The scopehal native file format handles this fine but most common external interchange formats do not

07:00 <azonenberg> lain, dannas, noopwafel, mubes: ideas?

07:02 <azonenberg> (ping again because discord bridge is dumb: @dannas @noopwafel @mubes)

07:07 <d1b2> <dannas> @azonenberg As a user I would expect to find the export option under the File menu. That's where it is located in my word processor, and some editors. If you have several different kind of traces/waveforms/channels (not quite sure what the terminology is here) then maybe you could display a selection subwidget in a dialog and have the options for file format change based on the type).

07:07 <azonenberg> I'm wondering if it might make sense to be file|export then have a wizard pop up

07:08 <azonenberg> actually better idea

07:08 <azonenberg> file|export then a file *browser* pops up, you select the file name

07:08 <azonenberg> then based on the chosen file format it then pops up a wizard to let you configure what you want to export, only showing channels compatible with the selected format

07:08 <d1b2> <dannas> Exporting a waveform is something you would do less often so it makes sense to tuck it away in the menu bar and not have it accessible from a context menu via the mouse.

07:10 <azonenberg> yeah

07:10 <d1b2> <dannas> How many different formats are you expecting to be able to export to?

07:11 <azonenberg> off the top of my head... CSV for anything, VCD for digital, WAV for analog, touchstone for s-parameter

07:11 <azonenberg> probably raw fp32 for a single analog channel

07:12 <azonenberg> anyway the challenge is also about how to handle losing information... for example, if you look at a LeCroy scope with four channels, each channel will have a different trigger phase value

07:12 <d1b2> <dannas> Ok, so atleast not an overwhelming number of different file formats.

07:12 <azonenberg> which means the samples are actually from slightly different timestamps

07:12 <azonenberg> the ADC clocks are phase aligned but have a small shift relative to each other

07:12 <azonenberg> if i export more than one channel to CSV, I lose that sub-sample timing information

07:13 <d1b2> <dannas> Oh my. I can understand drifts to due to cables, but do you have to take the ADC drift into account as well?

07:13 <azonenberg> When doing some of my more sensitive measurements i have actually seen errors if i didn't account for that

07:13 <azonenberg> it's not drift

07:14 <azonenberg> i think it's a static phase shift due to internal propagation delays or something?

07:14 <d1b2> <dannas> checks clock. Time to start $dayjob

07:15 <azonenberg> https://github.com/azonenberg/scopehal-testdata/blob/master/Networking/10Gbase-R_data/scope_1_metadata.yml

07:15 <azonenberg> note the "trigphase" values, those are femtosecond offsets

07:15 <azonenberg> in this case there's only one channel and the timestamps are different for each trigger event, at +6 and +11 ps

07:16 <azonenberg> here https://github.com/azonenberg/scopehal-testdata/blob/master/Networking/100Base-TX_data/scope_1_metadata.yml there's two channels

07:16 <azonenberg> one has an offset of 107.136 ps and the other 115.328 ps

07:16 <d1b2> <dannas> @azonenberg I'll have to read up a bit more about how that works to be of any help. But at least you had a "rubber duck" for a few minutes. 🙂

07:18 <d1b2> <dannas> When I said drift I mean the time taken for the signal to travel (the propagation delay). I need to read up on terminology as well.

19:09 <d1b2> <mubes> @azonenberg you asked a whole set of questions back there. I would be inclined to have a dialog with selectors per channel, called up by a menu or shortcut key. Selectors dynamically become available, or not, depending on rules you've got about which channels are compatible. You could also have a 'make persistent' clickbox that runs the export after every sample, or on some keypress or something. Maintain a list of 'canned' exports for configs

19:09 <d1b2> that have previously been set up.

19:09 <azonenberg> yeah then you also have to do things like channel mapping

19:09 <azonenberg> e.g when exporting to WAV which channel is left and right

19:10 <azonenberg> when exporting to touchstone which is which path (this can be default populated heuristically, but you might want to export say a math function on s-parameters)

19:10 <azonenberg> for example, you might be measuring a 10x probe on a VNA and it shows loss of -20 dB

19:10 <azonenberg> but if you have the scope set to 10x attenuation, you want it normalized to 0 dB

19:10 <azonenberg> so you can set the trigger level, etc with the 10x scaling factor applied

19:11 <azonenberg> then do the de-embed just to flatten the frequency response rather than correcting for the gain

19:11 <azonenberg> so i want to be able to do that kind of edits to s-params in glscopeclient then export to touchstone

19:11 <azonenberg> but now you have a filter graph with sparams applied and it has to know you want e.g. s21 mag to be the math function while s21 angle came right from the vna, etc

19:11 <azonenberg> or if you are doing a de-embed of a cable or fixture you might be applying that to the raw vna s-params then saving that

19:12 <azonenberg> or, in another possible scenario, you might be measuring or importing 4-port sparams

19:12 <azonenberg> and exporting mixed mode differential sparams as a .s2p

19:12 <azonenberg> that is very much a use case i intend for my probe work

19:12 <azonenberg> or in my case a .s3p in, .s2p out

19:12 <azonenberg> so diff-to-single mixed mode

20:17 <Degi> Kinda unrelated to all this discussion, but once we talked about TDC, especially for trigger interpolation. Maybe we can just use a carry chain inside of an FPGA? They can easily get to < 100 ps (maybe even < 10 on the faster FPGAs?) and are basically no effort, though probably have higher jitter than a dedicated solution

20:24 <azonenberg> Yes, that's an option. For now though, on scopes without a hardware TDC

20:24 <azonenberg> I just do manual software interpolation of the zero crossing

20:24 <azonenberg> (at least in the drivers i write)

20:25 <Degi> Nice

21:35 <d1b2> <mubes> Given the amount of config needed for an export I think that lends itself to the argument for being able to 'can' them for later....otherwise it's a lot of setup for graphs etc. That's already a bit of a pain for digital decode of a set of analogue channels etc.