<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)
<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>
<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