azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<_whitenotifier-b> [scopehal] penguin42 commented on issue #803: Rigol: Floating point exception - https://github.com/ngscopeclient/scopehal/issues/803#issuecomment-1820051658
<_whitenotifier-b> [scopehal] azonenberg commented on issue #803: Rigol: Floating point exception - https://github.com/ngscopeclient/scopehal/issues/803#issuecomment-1820056849
<_whitenotifier-b> [scopehal] azonenberg commented on issue #803: Rigol: Floating point exception - https://github.com/ngscopeclient/scopehal/issues/803#issuecomment-1820061316
<_whitenotifier-b> [scopehal] penguin42 commented on issue #803: Rigol: Floating point exception - https://github.com/ngscopeclient/scopehal/issues/803#issuecomment-1820089268
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
veegee has quit [Read error: Connection reset by peer]
veegee has joined #scopehal
veegee has quit [Quit: Textual IRC Client: www.textualapp.com]
<d1b2> <hansemro> Running scopehal-apps 45d255de8795bf5cf62054145907fcb5a022a104 with Siglent SDS2204X+ without major issues.
<azonenberg> Thanks
<d1b2> <hansemro> Siglent confirmed a bug with :WAVeform:WIDTh where the command fails if it ends with a semicolon. Example: :WAV:WIDTH WORD;
<azonenberg> interesting. were we sending semicolons in our driver?
<d1b2> <hansemro> No, but this bug made it impossible for me to test the following multi-command submission: :TRIG:MODE AUTO;:ACQ:RES 8Bits;:WAV:WIDTH BYTE;:TRIG:MODE STOP
<azonenberg> ah, ok
<azonenberg> Are they planning to fix it?
<d1b2> <hansemro> Yes, will be fixed in the next update (in a few months apparently)
<azonenberg> Great
<_whitenotifier-b> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/45d255de8795...2ce02e14213f
<_whitenotifier-b> [scopehal-apps] azonenberg 2ce02e1 - Added graceful degradation path if dialog or instrument isn't usable offline yet
<d1b2> <hansemro> Contacted someone with a scope on 1.3.9R6 and was able to confirm that the hdSizeWorkaround is still required.
<d1b2> <azonenberg> Great. so we've confirmed the exact firmware versions that are and are not impacted?
<d1b2> <azonenberg> Perfect. So just remove the TODO comment and we're golden
<d1b2> <hansemro> Any versions older than 1.3.9R6 are affected since they use the packet count in the header whereas newer versions use size in bytes
<d1b2> <azonenberg> You're not writing fun code until you have drivers with comments like "see support case XYZ" or ugly workarounds with checks for particular firmware versions :p
<d1b2> <hansemro> Force trigger is not supposed to re-arm the trigger, is it?
<d1b2> <azonenberg> Force trigger should be an instant, single shot trigger
<d1b2> <azonenberg> i.e. the same as "normal" but without waiting for an edge on your trigger source
<d1b2> <azonenberg> sorry i mean same as "single"
<d1b2> <hansemro> On Siglent, once triggered, it gets re-armed. Might be a bug
<d1b2> <azonenberg> Yes. Force should be a one shot trigger only
<d1b2> <azonenberg> File a ticket and investigate when you have time?
<d1b2> <hansemro> Sure
<d1b2> <azonenberg> Anyway, i feel like we're making good progress towards the goal of a first official stable release next summer
<d1b2> <azonenberg> (if not sooner)
<d1b2> <hansemro> Reminds me, I should seriously get started on docs again.
<d1b2> <azonenberg> i plan to set up a dev call some time in early December where we can talk over more concrete plans for what's missing for that
<d1b2> <azonenberg> Yes, docs are the single biggest item for sure
<d1b2> <azonenberg> Doesn't matter how good the code is if nobody can figure out how to run it
<d1b2> <hansemro> Should we have a checklist on the issue tracker for doc coverage for filters? How should we organize what needs work and who is in charge?
<d1b2> <azonenberg> A checklist would probably be good to have. As well as making a pass through the overall application and finding every major feature, dialog, etc. that has no docs
<d1b2> <hansemro> Here is a script that I used to generate a sample checklist: https://gist.github.com/hansemro/a770402c0657e2c37033373094b38015
<d1b2> <azonenberg> In general there's three categories of filter docs right now
<d1b2> <azonenberg> there's "nothing", "a sentence or two but not much", and "largely complete"
<d1b2> <azonenberg> most of the "largely complete" still need a QA pass to do things like replacing glscopeclient screenshots with ngscopeclient, checking for anything that might have changed since the docs were written, etc
<d1b2> <hansemro> Yes, screenshots and changes in operation should be updated, but I think a checklist could still be useful for tracking overall completion.
<d1b2> <azonenberg> my point is, make a checklist with an entry for every filter and just have statuses for each
<d1b2> <azonenberg> one for "docs written" one for "final qa pass" or something
<d1b2> <hansemro> Yes, okay
<d1b2> <hansemro> It will take a bit longer to prepare issue posts for each one, but MRs can target a specific one, so alright
<d1b2> <azonenberg> Yeah no rush. But this definitely needs to happen and if you're up for doing it, great
<_whitenotifier-b> [scopehal] hansemro opened issue #820: Siglent: Initial force trigger results in continous single trigger operation - https://github.com/ngscopeclient/scopehal/issues/820
<_whitenotifier-b> [scopehal] hansemro opened issue #821: Siglent: Improve SetADCMode reliability under slow/unstable network connection - https://github.com/ngscopeclient/scopehal/issues/821
<_whitenotifier-b> [scopehal] azonenberg commented on issue #821: Siglent: Improve SetADCMode reliability under slow/unstable network connection - https://github.com/ngscopeclient/scopehal/issues/821#issuecomment-1820637205
<_whitenotifier-b> [scopehal] azonenberg commented on issue #821: Siglent: Improve SetADCMode reliability under slow/unstable network connection - https://github.com/ngscopeclient/scopehal/issues/821#issuecomment-1820639515
<_whitenotifier-b> [scopehal] hansemro commented on issue #821: Siglent: Improve SetADCMode reliability under slow/unstable network connection - https://github.com/ngscopeclient/scopehal/issues/821#issuecomment-1820651793
mxshift has quit [Ping timeout: 246 seconds]
mxshift has joined #scopehal
veegee has joined #scopehal
<d1b2> <hansemro> @azonenberg If the scope is armed while trying to change ADC mode, does the scope re-arm itself here? https://github.com/ngscopeclient/scopehal/blob/10899c0f58e6111d8c8ea528a8a1ea0863bcb43c/scopehal/SiglentSCPIOscilloscope.cpp#L3306-L3310
_whitelogger_ has joined #scopehal
_whitelogger has quit [Remote host closed the connection]
<d1b2> <hansemro> I might just ask Siglent support and see if this is the expected behavior.
<d1b2> <hansemro> Anyhow, I found a better workaround for setting ADC resolution and waveform data width by shifting commands around and using command query (to flush commands and as delays): https://github.com/hansemro/scopehal/commit/01e9da900a8240ac16523454a36c540c52da9f21
<d1b2> <hansemro> Looking to test a bit more sending out a PR
<azonenberg> Ok sounds good keep me posted
<azonenberg> What do you folks think of naming for filters that do averaging in the "Z axis" vs the "X axis"?
<azonenberg> in other words, smoothing of multiple consecutive acquisitions rather than within one waveform
<azonenberg> "waveform average" vs "average" or what?