azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<azonenberg> does it use the older ps6000* api not the 6000a?
<azonenberg> (I need to merge the 3000 PR from bvernoux, havent had time to review it - been super busy)
<d1b2> <TiltMeSenpai> yeah it uses the older ps6000 api
<d1b2> <TiltMeSenpai> I have it kinda mostly working but trying to configure timebase things just makes it crash
<d1b2> <TiltMeSenpai> does glscopeclient have things to deal with 10x probes btw
<azonenberg> you need to set the attenuation manually with pico right now
<azonenberg> via channel properties
<azonenberg> there is an id ring detector and the most recent APIs, at least for 6000a, let you trigger a callback when a probe is mated
<azonenberg> but we havent implemented that yet
<azonenberg> unsure if available on the other platforms
<d1b2> <TiltMeSenpai> the 6404d doesn't have any sort of probe identification 😦
<azonenberg> ok so i guess thats a feature they added in E
<azonenberg> so for your D you'll need to explicitly set the attenuation and coupling by hand when you start a new session
<d1b2> <TiltMeSenpai> is that something in the GUI or do I have to send SCPI commands
bgamari has quit [Ping timeout: 260 seconds]
bgamari has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<azonenberg> TiltMeSenpai: double click the channel name, it's in the properties box along with all the other stuff
<d1b2> <TiltMeSenpai> side note: goddamn the picoscope probes are nice
<d1b2> <TiltMeSenpai> they come with pogo pin tips and stuff
<azonenberg> ah yeah probably the same PMK design they use for the transmission line probes like the TA061
<azonenberg> i dont remember if lecroy's passive probes come with pogo tips, i dont have them installed if they do
<azonenberg> but they do have a nice selection of accessories
<azonenberg> i dont actually think i've ever used the stock probes for my picoscope
<_whitenotifier-7> [scopehal-pico-bridge] TiltMeSenpai forked the repository - https://github.com/TiltMeSenpai
<_whitenotifier-7> [stm32-cpp] azonenberg pushed 1 commit to master [+4/-0/±5] https://github.com/azonenberg/stm32-cpp/compare/9b18a4d67730...ad92f983c1c5
<_whitenotifier-7> [stm32-cpp] azonenberg ad92f98 - Initial support for STM32H7 OCTOSPIM
bvernoux has joined #scopehal
Bird|ghosted has quit [Ping timeout: 272 seconds]
Bird|otherbox has joined #scopehal
lain has quit [Ping timeout: 244 seconds]
lain has joined #scopehal
Bird|otherbox has quit [Ping timeout: 260 seconds]
Bird|otherbox has joined #scopehal
Bird|otherbox has quit [Ping timeout: 272 seconds]
Bird|otherbox has joined #scopehal
Bird|otherbox has quit [Ping timeout: 240 seconds]
Bird|otherbox has joined #scopehal
<d1b2> <TiltMeSenpai> btw, do you want me to hold on merging the legacy picoscope 6k support until it's done or start a WIP pull request now
<d1b2> <TiltMeSenpai> current problems are trying to open the timebase settings causes a crash in glscopeclient and I just realized that the 6404d also has an AWG that I'll need to port
<azonenberg> So we do not support full arb in libscopehal yet. that is pending as i now have several instruments with AWG capability i need to implement
<azonenberg> but the canned function generator waveforms should be available
<azonenberg> as far as the 6k stuff, start a PR now so we can track it
<azonenberg> but expect you will need to update and fix conflicts
<azonenberg> Especially given that there is a pending PR from bvernoux for 3000 series support in line ahead of you
<azonenberg> so you'll likely have to make some minor updates to build cleanly against that
<d1b2> <TiltMeSenpai> cool, sounds good, I'll start that when I get home today
<d1b2> <TiltMeSenpai> oh also glscopeclient thinks I have a logic analyzer pod attached to my 6404, which doesn't have logic analyzer pods at all. That's gonna be a fun one to figure out
<azonenberg> That may be a clientside driver issue in libscopehal. i dont know if it knows about picoscopes without MSO pods yet
<azonenberg> i dont remember if we advertisie # pods in the protocol
<azonenberg> or if thats hardcoded clientside based on model number
<d1b2> <TiltMeSenpai> is it worth starting to refactor the picoscope bridge away from else-if statements since we'll have 6000a, 3000a, 6000 and 3000 support? (bvernoux might already have done some of that idk)
<azonenberg> Yes. that needs to happen. we also need to rename ps6000d to something more generic
<azonenberg> as the original plan was one app per API but now we unified that
<bvernoux> yes next step is to rename ps6000d to picod or something like that
<bvernoux> I'm waiting the merge when azonenberg will have time to push more things
<azonenberg> I've been crazy busy but hopefully will review this weekend
<bvernoux> I have found only 1 strange issue with actual PR
<bvernoux> If we change a channel zoom in live sometimes it stop to refresh
<bvernoux> I suspect it is because there is too much update per click
<bvernoux> I suspect exactly the same appears on PicoScope 6000 too
<bvernoux> Events clearly need a cleanup to avoid 100 times updates per second
<bvernoux> IIRC there was a proposal about that as it is an issue in glscopeclient
<bvernoux> Like to limit events to the scope to something like max 20/s configurable ...
<azonenberg> Rate limiting i dont think is the solution. it's probably a race condition
<azonenberg> the fix is to add a mux there
<azonenberg> mutex*
d1b2 has quit [Remote host closed the connection]
bvernoux has quit [Quit: Leaving]
<_whitenotifier-7> [scopehal-pico-bridge] TiltMeSenpai opened pull request #21: Add preliminary support for Pico 6000A/B/C/D - https://github.com/glscopeclient/scopehal-pico-bridge/pull/21