<d1b2>
<vegard_e> the picoscopes have decent support, right?
<d1b2>
<azonenberg> @vegard_e picoscope 6000 series is functional but doesnt have all of the advanced trigger types just because most of what i was doing didn't require them, it'd be easy to add
<d1b2>
<azonenberg> 6000e specifically
<d1b2>
<azonenberg> there is at least some support for the 3000s iirc but i dont have one personally
<d1b2>
<vegard_e> what about the 3000 series?
<d1b2>
<azonenberg> tl;dr its a nice architecture for the most part, the driver is fast and you can get excellent performance
<d1b2>
<azonenberg> but there is no api orthogonality
<d1b2>
<azonenberg> the is a separate libps2000a, libps3000a, etc for each familty
<d1b2>
<azonenberg> so we need a ton of new code in the bridge server for each new model
<d1b2>
<azonenberg> that is basically s/ps2000/ps3000/ lol
<d1b2>
<azonenberg> very slight method signature changes and feature set differences in some cases but for the most part it's copy paste with a few tiny changes
<d1b2>
<azonenberg> if you have a 3000 it will either work out of the box or be straightforward to get working
<d1b2>
<azonenberg> depending on the exact model
<d1b2>
<azonenberg> before the thunderscope, picoscope was my recommendation for people looking for the best performanc with ngscopeclient
<d1b2>
<vegard_e> we recently picked up one at work, not sure if we ended up with a 3204D or a 3404D, I haven't had time to play with it yet
<d1b2>
<azonenberg> yeah the 3000D is i think the one people were playing with
<d1b2>
<vegard_e> I'm on 75% paternity leave, so I'm not at the office much 🙂
<d1b2>
<azonenberg> thunderscope is now the best PC interface BW (i get 8 Gbps with it, vs about 2.5 for my picoscope 6824E)
<d1b2>
<azonenberg> but pico wins on analog bandwidth and number of channels on the high end. for now
<d1b2>
<azonenberg> they expect to compete in the higher end space eventually
<d1b2>
<vegard_e> I'll probably get a thunderscope for myself at some point
<d1b2>
<azonenberg> but 2.5 Gbps is still >>> what you get with literally anything else lol
<d1b2>
<azonenberg> my lecroys get a few hundred mbps
<d1b2>
<azonenberg> most entry level are single digit to low tens
<d1b2>
<vegard_e> yeah
<d1b2>
<vegard_e> I have a rigol mso5k, and so far I haven't found it worthwhile to use it with ngscopeclient
<d1b2>
<vegard_e> I still want that feature where I can do the entire capture setup on the scope itself, and just download and analyze in ngscopeclient afterwards 🙂
<d1b2>
<azonenberg> yeah a download mode has been requested, i'll get to it when i get to it
<d1b2>
<azonenberg> right now focus is bug fixing especially those that affect build or impact a lot of users or could cause data loss
<_whitenotifier-2>
[scopehal-apps] d235j 9f2d72b - Bump submodules and disable errors for -Wshadow due to YAML library on macOS Intel
_whitelogger has joined #scopehal
Degi has quit [Ping timeout: 276 seconds]
Degi has joined #scopehal
<d1b2>
<vegard_e> dropped by the office today just to play with the picoscope; it's a 3204D MSO, seems to work great with ngscopeclient
<d1b2>
<vegard_e> is there no way to remove a filter from the filter graph?
<d1b2>
<azonenberg> As of now, filters are reference counted and self-delete when the last user goes away
<d1b2>
<azonenberg> i.e. it's not in any waveform views, being used as an input to another block, etc
<d1b2>
<azonenberg> i plan to add a delete feature directly in the future, but this is nontrivial as the data structures are all backwards right now
<d1b2>
<azonenberg> tracking from sink to source
<d1b2>
<vegard_e> I noticed afterwards that some filters did go away, while others didn't
<d1b2>
<azonenberg> (yes there are some dangling refs to fix)
<d1b2>
<azonenberg> but basically, given a filter there is no way to know what is using it
<d1b2>
<azonenberg> so you can't delete it because there's no way to know what you have to disconnect it from
<d1b2>
<vegard_e> I also ran into an issue with the UI sometimes deadlocking while dragging views; attaching gdb indicated imgui was stuck waiting for some lock, but I didn't have time to dig into it
<d1b2>
<azonenberg> Switching from manual refcounting to std::shared_ptr (planned, we already do this in a lot of other stuff like instrument objects) will eliminate any potential for use-after-free crashes but is only half the puzzle since it doesnt keep any records about who is using the filter, just how many users there are
<d1b2>
<azonenberg> so you would know its not safe to delete, but not who you have to tell "hey this filter is being deleted set your input to null"
<d1b2>
<azonenberg> That's a v0.2 feature and probably one of the biggest UI wishlist items
<d1b2>
<azonenberg> please file a ticket with a backtrace, i was not aware of this one
<d1b2>
<vegard_e> I will once I have time to dig into it
<d1b2>
<azonenberg> (we've had locking bugs in the past but i thought we had fixed them)
<d1b2>
<azonenberg> but yay, glad it's working with the picoscope in general
<d1b2>
<azonenberg> the overall experience of using ngscopeclient with a fast scope like a picoscope or thunderscope compared to the "slideshow" experience with an entry level rigol/siglent is just a completely different game lol
<d1b2>
<azonenberg> like, we support the slow scopes because it's better than not working with them at all but it's just not the same