00:13 <d1b2> <chille0417> @azonenberg Too handle multiple devices of the same model at the same time, would you say the best option would be to run multiple instances of the bridging software?

01:35 <d1b2> <david.rysk> Honestly if we need to pull in a lub I’d be looking at this instead of libserialport https://github.com/wjwwood/serial

02:35 <d1b2> <azonenberg> if you're going the bridge route, yes

02:35 <d1b2> <azonenberg> one bridge = one instrument makes sense, as it allows a lot of flexibility for e.g. multiple ngscopeclient sessions doing different things

03:03 <_whitenotifier> [scopehal-apps] azonenberg pushed 5 commits to master [+12/-0/±5] https://github.com/ngscopeclient/scopehal-apps/compare/614a9e035cef...c36c921d1b41

03:03 <_whitenotifier> [scopehal-apps] mldulaney 42ad1e9 - More filter icons Signed-off-by: Mairi Savanna Dulaney <mairi@seattlebus.space>

03:03 <_whitenotifier> [scopehal-apps] mldulaney 0dcf159 - Add shark Signed-off-by: Mairi Savanna Dulaney <mairi@seattlebus.space>

03:03 <_whitenotifier> [scopehal-apps] mldulaney ededfde - flip shark export Signed-off-by: Mairi Savanna Dulaney <mairi@seattlebus.space>

03:03 <_whitenotifier> [scopehal-apps] ... and 2 more commits.

03:03 <_whitenotifier> [scopehal-apps] azonenberg closed pull request #767: Add some more icons - https://github.com/ngscopeclient/scopehal-apps/pull/767

16:43 <d1b2> <jescombe> Hi, have just rebuilt from latest master, and seeing a regression with the data from my Siglent SDS800X HD. Am just testing with the calibration output here, 10k sample depth at 10Ms/s. Looks like it has the expected amount of correct data, followed by the same amount of garbage?

16:43 <d1b2> <jescombe> https://cdn.discordapp.com/attachments/776941750291267595/1289628655018049587/siglent_new.png?ex=66f983c7&is=66f83247&hm=bc5489517a57a19a4b694779e7e83286440d8963b6a79e2c0fc2a5558ce2bfeb&

16:43 <d1b2> <jescombe> https://cdn.discordapp.com/attachments/776941750291267595/1289628655299072080/siglent_old.png?ex=66f983c7&is=66f83247&hm=7dd4aa2cf6d4f7534b745b35cbac053be847690d4c17ebbddb260649369a24cd&

16:44 <d1b2> <jescombe> I have a working build from 14th September, and just starting a git bisect to try and narrow down when it changed..

16:52 <d1b2> <fredzo_72653> Hi @jescombe that looks like a data width issue... Try and change the 8/16 bit parameter in driver settings maybe ?

16:56 <d1b2> <fredzo_72653> I ran into similar issue when removing rate-limiting on SCPI commands because the WAVEFORM:WIDTH command was ignored.

16:57 <d1b2> <fredzo_72653> @chille0417 are you working on this ? https://github.com/ngscopeclient/scopehal-apps/issues/754

16:58 <d1b2> <jescombe> @fredzo_72653 Thanks, will check that out...

17:59 <_whitenotifier> [scopehal-docs] fredzo closed pull request #89: Windows uart support via libserialport - https://github.com/ngscopeclient/scopehal-docs/pull/89

17:59 <_whitenotifier> [scopehal-apps] fredzo closed pull request #768: Windows uart support - https://github.com/ngscopeclient/scopehal-apps/pull/768

18:14 <d1b2> <azonenberg> @jescombe yeah equal length data + garbage implies you are trying to read 16 bit data and getting 8 bit data back from the scope

18:14 <d1b2> <azonenberg> There was a commit a few days ago that changed the rate limiting settings

18:14 <d1b2> <azonenberg> Maybe that was too optimistic and needs to be increased or rolled back entirely

18:15 <d1b2> <azonenberg> @fredzo_72653 your updated version of the xptools PR still pulls in libserialport despite using the native windows APIs

18:15 <d1b2> <azonenberg> that should be redundant, right?

18:20 <d1b2> <fredzo_72653> Oh yeah, forgot that one ! Let me fix that.

18:24 <d1b2> <fredzo_72653> Don't think this one was merged to upstream, was it ? But yeah that what I thought at first...

18:25 <d1b2> <fredzo_72653> Should be good now: https://github.com/ngscopeclient/xptools/pull/27 So you where right, it was not that much trouble to use native Windows API 😉 and that's one less dependency !

18:47 <d1b2> <chille0417> Not right now. So far I haven't done more than some research on how to do it.

19:02 <d1b2> <fredzo_72653> OK, I do have a RD6006 and was thinking maybe I would give it a try, I'll let you know what comes out of it.

19:09 <d1b2> <chille0417> Okay, cool, then we are at least three people in here having a RD* 🙃

20:44 <d1b2> <chille0417> I'm writing a bridge between scopehal and a Hantek 365B DMM. It has this weird relative mode. You can take a measurement, press the button to save the value, and then take another measurement that will be relative to the first value. I'm thinking about leaving this functionality out of the bridge. To me this sounds more like something thah should be done in ngscopeclient rather than on the hardware. What do you guys think?

20:45 <d1b2> <chille0417> I can see that this would be a useful function on a handheld DMM, just like the tare button on scale. But I don't understand why they have put this function into a USB DMM.

21:21 <d1b2> <azonenberg> My R&S meters have this feature, the intended purpose is to null out any frontend offset or something i think

21:22 <d1b2> <azonenberg> But yeah i think it makes more sense to build into scopehal as a filter chain instead of the driver

23:03 <d1b2> <azonenberg> @fredzo_72653 what's with the LogError "twingo" in the latest PR

23:03 <d1b2> <azonenberg> forgotten debug message? lol

23:23 <d1b2> <fredzo_72653> Absolutely ! 😅 Fixed !