azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://freenode.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
<azonenberg> So I got the SMPM bullet puller tool the other day
<azonenberg> it's expensive but it works *perfectly*
<azonenberg> and does exactly what it should
<azonenberg> I'm going to try to design my probes to not require the end user have one
<azonenberg> by using full detent and smooth bore connectors in such a way that the bullets should in theory remain attached all the time
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #scopehal
wbraun_ has joined #scopehal
wbraun has quit [Ping timeout: 245 seconds]
wbraun_ is now known as wbraun
_whitenotifier-5 has quit [Ping timeout: 245 seconds]
Tost has joined #scopehal
d1b23 has joined #scopehal
d1b2 has quit [Read error: Connection reset by peer]
d1b23 is now known as d1b2
<Degi> What is a bullet here?
<azonenberg> Degi: SMPM connectors are normally made in the male configuration only
<azonenberg> which is to say, a shell with a pin in the middle
<azonenberg> to mate two of them, you place a little pill-shaped coupler between them with two female ends
<azonenberg> called a bullet
<Degi> Ah yes
<azonenberg> And removing them without damage is hard
<azonenberg> There's basically two options
<Degi> Yeah, it looks quite intricate
<azonenberg> the first is grabbing the bullet with pliers about the center line
<azonenberg> but they're normally rounded enough that the pliers are likely to slip
<azonenberg> which results in pinching the contacts at the end
<Degi> yes...
<azonenberg> in my early testing, i had about a 50% survival rate for bullets removed this way
<Degi> oh
<azonenberg> half the time the pliers slipped, the rest of the time it worked :p
<Degi> welp
<azonenberg> anyway the second option is a dedicated puller tool which inserts a conical tip into the open end of the connector
<Degi> Even if it worked, didnt it get deformed a little?
<azonenberg> No, because i was grabbing the solid body between the open "leaves"
<azonenberg> then a larger cylindrical shell slides over the outside
<Degi> ah yes
<azonenberg> so it's providing a clean pulling motion down the axis of the connector, no pinching of the body, and no way for it to slide
<azonenberg> They work perfectly, they just cost like $300 because it's such a specialized tool
<Degi> So basically it jams the outer pins between an outer cylinder and an inner cone?
<azonenberg> Yeah
<azonenberg> the two parts are spring attached together like a LA micro clip
<azonenberg> so you squeeze the plunger to open and release to close
<Degi> Neat
<azonenberg> anyway, SMPM male connectors come in two varieties
<azonenberg> "smooth bore" and "full detent"
<azonenberg> the latter having much higher unmating force
<azonenberg> my intent is to design the differential probes with a mix of smooth and full detent connectors such that the bullets always stay attached to the FD connectors, which can be treated as if they were just female connectors
<azonenberg> and thus an end user won't ever need a bullet puller
<Degi> Neat
<azonenberg> For prototyping though, i need one because I need to be able to mate a test adapter to it for connecting to the VNA etc
<azonenberg> and that has a female connector too
<azonenberg> so i have to add and remove bullets
<d1b2> <theorbtwo> I always wonder how hard it would be to 3d print or otherwise manufacture such things cheaply at the location of need ... and almost always come to the conclusion that it would be very hard.
<Degi> What is some jtag cable that works fine on linux?
<d1b2> <zyp> anything ftdi-based?
<azonenberg> Yeah i mostly use either my own homebrewed ones or digilent HS1/HS2
<azonenberg> theorbtwo: 3D printing lacks the mechanical strength
<azonenberg> it would be straightforward to make on a lathe probably
juli9610 has joined #scopehal
bvernoux has joined #scopehal
<bvernoux> azonenberg, hello I'm tempted to buy a LibreVNA to check the performance
<bvernoux> latest update even add harmonic mixing to go up to 8GHz(with performance decreased ...)
<bvernoux> The only things I'm not too happy with LibreVNA is the Dynamic range after 3GHz ...
<azonenberg> interesting. not familiar with it
<bvernoux> it is less than -60dBm
<bvernoux> anyway up to 3.5GHz (calibrated) it is more than -100dBm
<bvernoux> I do not know if the version sold on Aliexpress have same performance ...
<bvernoux> like we can see Dynamic range is lower than -50dBm near 6GHz ...
<bvernoux> -60dBm in fact ...
<bvernoux> it is -70dBm in fact as on right it is Phase in ° ;)
<bvernoux> so it is not so bad but to be on par with my HP VNA or even PicoScope VNA it will be nice to have -90dBm or -100dBm up to 6GHz+ (with more linear dynamic range)
<bvernoux> What is nice is the software App for LibreVNA is very nice and there is SCPI commands ...
<bvernoux> and it is ultra fast Full S2P 10kpoints in less than 1s !!
<bvernoux> when my HP VNA requires more than 40s(using raw calibrated data) for 1601pts full S2P...
<bvernoux> something nice for a Pro VNA will be to have native Ethernet as there is only USB today to drive it
<azonenberg> Yeah
<bvernoux> So far my major issue with my HP VNA is it is quite slow and limited to max 6GHz and very loud and doing a SOLT calibration is clearly a long process (limited by memory too as I cannot store more than 6 Full S2P calibration)
<miek> as a workaround you could do the correction offline with scikit-rf
_whitenotifier-3 has joined #scopehal
<_whitenotifier-3> [scopehal] azonenberg opened issue #419: SPI flash: add support for 4-byte addressing - https://git.io/JOKhP
<_whitenotifier-3> [scopehal] azonenberg labeled issue #419: SPI flash: add support for 4-byte addressing - https://git.io/JOKhP
<bvernoux> miek, all is already integrated in PC LibreVNA tools
<bvernoux> miek, it also support de-embedding which is nice ...
<_whitenotifier-3> [scopehal] azonenberg opened issue #420: eSPI: implement "Put Virtual Wire" packet type - https://git.io/JO6fJ
<_whitenotifier-3> [scopehal] azonenberg assigned issue #420: eSPI: implement "Put Virtual Wire" packet type - https://git.io/JO6fJ
<_whitenotifier-3> [scopehal] azonenberg labeled issue #420: eSPI: implement "Put Virtual Wire" packet type - https://git.io/JO6fJ
<_whitenotifier-3> [scopehal] azonenberg labeled issue #421: SPI flash: Add RPMC support for Winbond parts - https://git.io/JO6JB
<_whitenotifier-3> [scopehal] azonenberg opened issue #421: SPI flash: Add RPMC support for Winbond parts - https://git.io/JO6JB
Tost has quit [Ping timeout: 240 seconds]
Tost has joined #scopehal
<azonenberg> Hmmmmm
<azonenberg> i might have to start thinking about moving away from gtk tree views for the protocol analyzer at some point
<azonenberg> With some of my current large captures, gtk_tree_store_set_value() is the main consumer of CPU time
<azonenberg> oh isnt THIS lovely
<_whitenotifier-3> [scopehal-apps] azonenberg opened issue #316: Protocol analyzer is extremely slow with a lot of elements - https://git.io/JO6RX
<_whitenotifier-3> [scopehal-apps] azonenberg labeled issue #316: Protocol analyzer is extremely slow with a lot of elements - https://git.io/JO6RX
<_whitenotifier-3> [scopehal-apps] azonenberg labeled issue #316: Protocol analyzer is extremely slow with a lot of elements - https://git.io/JO6RX
<azonenberg> So it turns out that my decode is super fast
<azonenberg> and the gtk tree view is horifically slow
<azonenberg> more precisely the tree *store* is slow
<azonenberg> So i think if i make a new class derived from Gtk::TreeStore I'll be able to make this vastly more efficient
<bvernoux> You should definitely switch to ImGui for such stuff
<bvernoux> Gtk is slow and ugly
<bvernoux> Check SDRPlusPlus if you want to be convinced that OpenGL + Dear ImGUI is a must have
<azonenberg> A complete UI rewrite is not a trivial proposition
<bvernoux> it can be done in multiple step to avoid breaking all and keeping Gtk ...
<bvernoux> on the screen which are already OpenGL you can easily integrate Dear ImGUI as it is designed for that
<bvernoux> screen/window
<azonenberg> The waveform rendering is already pretty much all GL based
<bvernoux> yes it is why such part do not need to be rewritten
<bvernoux> I speak mainly about ugly GTK stuff
<bvernoux> and with that TreeStore and other issues everywhere in Gtk
<bvernoux> KiCad have also tons of issues with Gtk ...
<bvernoux> for multiplatform it is a real mess
<bvernoux> I think solution is clearly a mix with OpenGL/Dear ImGUI
<bvernoux> a Qt is more and more bloated and anyway does not bring anything interesting for realtime stuff required in glscopeclient
<bvernoux> Example protocol analyzer slowness
<bvernoux> Dear ImGUI have ultra fast opengl gadget for that
<bvernoux> which are designed to be fast and realtime
<bvernoux> which is not the case for Gtk ...
<azonenberg> yeah qt is a nightmare, its not even in question
<azonenberg> kicad is mostly wxwidgets
<azonenberg> if there is gtk stuff it's used via wx
<bvernoux> wxwidgets is same bloated things as gtk ...
<azonenberg> Anyway, so far it looks like the actual treeview widget is probably fine
<azonenberg> the problem is actually the back end treestore data structure
<azonenberg> But yes it's very likely we will have to move the protocol analyzer to a custom widget
<azonenberg> long term i expect that will be needed anyway to support more complex layouts
<azonenberg> that aren't strictly column based
<azonenberg> near term though, i need to get my work done
<bvernoux> yes for that ImGUI is a must have
<azonenberg> which means minimally invasive problems to eliminate the O(n^2) problem
<bvernoux> their listview are already totally amazing
<azonenberg> minimally invasive fixes*
<bvernoux> the aim of gtk or other gui is not to provide performance anyway ...
<bvernoux> It is why I think Dear ImGui is a must have for that as it is designed for high performance
<bvernoux> and not limited by CPU as all run in OpenGL(GFXCard) ...
<bvernoux> So UI does not slow down everything like it is the case with all standard GUI stuff like gtk, wxwidgets ...
<azonenberg> Well there's some other stuff that has to be worked on too
<azonenberg> like the protocol decode overlays
<azonenberg> in the waveform area
<azonenberg> right now they're composited in OpenGL but the little boxes are drawn on the CPU
<bvernoux> Immediate mode rendering is a must have also for lot of stuff to simplify things and memory management ...
<azonenberg> and it doesn't scale well
<bvernoux> Yes it is why I think such little things drawn with the CPU (gtk ...) could be replaced step by step by pure OpenGL with ImGui
<bvernoux> So at end all will scale very well and all will be OpenGL either natively or mixed with ImGui gadgets ...
<azonenberg> I'd be more inclined to do it pure opengl in compute shaders
<azonenberg> or similar
<azonenberg> and then possibly use something like imgui for the protocol analyzer
<bvernoux> You would like to rewrite what has been done in Dear ImGUI in that case ?
<azonenberg> but keep GTK for all of the things like channel configuration dialogs where performance isnt critical
<azonenberg> We're not making a normal ui with buttons and stuff. it's totally specialized
<bvernoux> as they have solved the issue to add text, cursors, listview, gadget with Vertex... in OpenGL
<azonenberg> i doubt there will be much reusable code
<azonenberg> for the list/tree view maybe
<azonenberg> but for waveform rendering it's so different from everything else
<azonenberg> Text is not a performance bottleneck for the most part
<bvernoux> I speak about common things like text, graph, list/tree
<azonenberg> we can keep that software rendered
<azonenberg> there's not enough of it to matter
<bvernoux> of course for specific stuff it shall be done manually ...
<bvernoux> The problem is text scale in bitmap is awfull
<bvernoux> check Dear ImGui demo you will understand
<miek> it's nice to have something that looks native too, for the normal widgets / file management / etc
<bvernoux> you can zoom text and everything and all is smooth and look nice
<bvernoux> the most amazing is docking stuff too
<bvernoux> I say that as glscopeclient is more and more complex everyday and it will be harder and harder to refactor it ...
<bvernoux> Even some guys in KiCad Team was thinking to replace some parts with Dear ImGui
<bvernoux> for KiCad 7 or more
<bvernoux> as they see the GUI is bloated and very hard to maintain
<azonenberg> Before we even think about any API changes, the glscopeclient frontend needs a lot of refactoring and cleanup
<azonenberg> the backend is nice and clean and modular
<azonenberg> the frontend is... not
<bvernoux> Yes it is why I think you shall not wait too long to start to think to switch things to ImGui
<bvernoux> step by step it is fully compatible without breaking all
<azonenberg> you misunderstand, we need to clean up the architecture first
<azonenberg> before we think about anything else
<bvernoux> ha yes
<bvernoux> but it is not the same things
<bvernoux> I speak more about the Gui here and context menu mainly things done in Gtk today which are slow and ugly
<bvernoux> the ListView/Tree is a good example
<miek> it's one class that's probably easily fixable and it's .. not ugly?
<azonenberg> GTK4 is already working on architectural improvements for that AFAIk
<azonenberg> but near term i have to fix the tree model using GTK3
<azonenberg> even debian 11 won't be using gtk4 as standard yet
bvernoux has quit [Quit: Leaving]
juli9610 has quit [Quit: Nettalk6 - www.ntalk.de]
Tost has quit [Ping timeout: 240 seconds]