<azonenberg>
The preferences dialog is blocking #43, #72, #86, #121, #131, #132, #159
<azonenberg>
Bird|otherbox: Any ETA on the about dialog, btw? Think you can have it done today/tomorrow?
<Bird|otherbox>
I can see what I can do :)
<azonenberg>
The other big infrastructure task we have is proper installation. This is #141/142. But it's not a short term priority because i dont think we're at the point that installing systemwide makes sense. The tool isn't mature enough yet
<azonenberg>
Then there's a bunch of big ticket items like a gui filter graph editor that will be a ton more work
<azonenberg>
and a bunch of stuff that depends on new APIs not yet added to scopehal
<_whitenotifier-f>
[scopehal-apps] tarunik edited a comment on issue #175: Add "about" dialog - https://git.io/JUMKn
<_whitenotifier-f>
[scopehal] azonenberg opened issue #281: Figure out some means of shortening filter names so they don't grow out of control - https://git.io/JUM66
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #281: Figure out some means of shortening filter names so they don't grow out of control - https://git.io/JUM66
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #281: Figure out some means of shortening filter names so they don't grow out of control - https://git.io/JUM66
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #179: Add write queueing to transports for better handling of high-latency instruments - https://git.io/JUMiB
<azonenberg>
ook so actually before i get to the rest of the spectrum view stuff i have some easy yaks to shave
<azonenberg>
also my lab tech is coming tonight to solder pin headers on all of the MEAD boards
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUMyL
<_whitenotifier-f>
[scopehal-apps] azonenberg ceeaaf5 - Improved rendering of sparse traces with fine timescales
<Bird|otherbox>
I ask because git-describe is generally what you implement "give me the version of this git project" in terms of, and it has some fairly fancy footwork inside it to derive version numbers based on tags
Degi has quit [Ping timeout: 272 seconds]
gurki has quit [Ping timeout: 246 seconds]
gurki has joined #scopehal
Degi has joined #scopehal
<Bird|otherbox>
also: git hashes aside, I have the about box moooostly done (as a modal). only problem is that the text in the credits sub-box doesn't display? (it seems to be there, but isn't)
<azonenberg>
Bird|otherbox: did you not call show_all()?
<azonenberg>
(and yeah modal for about is fine)
Kliment has quit [Ping timeout: 264 seconds]
<Bird|otherbox>
azonenberg: the license sub-box works fine without that
<azonenberg>
Interesting. As a general rule though show_all() is needed in gtk 3.x to make sure all child widgets are visible
<Bird|otherbox>
no-change in behavior with a show_all() right before the run()
<azonenberg>
Huh
<azonenberg>
Push your code somewhere i can see and i'll have a look?
<azonenberg>
you probably have something like white text on a white background or similar because of a missing setting in the theming css
<azonenberg>
We've had several of those over the last few months as we started using a new widget that didn't have settings in the theme
<azonenberg>
the inspector allows you to type in custom CSS (overriding the normal application theme). Poke around a bit and see if you can find what's wrong
<azonenberg>
Unfortunately the GTK theme schema (in terms of what properties and class names etc are available) is not super well documented, i normally use existing theme files as a reference
<Bird|otherbox>
yeah, that was my guess when I saw it as well
Kliment has joined #scopehal
_whitelogger has joined #scopehal
Nero_ has joined #scopehal
NeroTHz has quit [Ping timeout: 260 seconds]
<azonenberg>
Bird|otherbox: The inspector should help you narrow down the cause. Let me know if you cant figure it out
<Bird|otherbox>
yeah, it's CSS -- I figured out a hacky workaround by giving the about box a name but there's probably a better way to handle it
<bvernoux>
at least the one we have refactored so far
<bvernoux>
to write portable C/C++ code
<bvernoux>
here it is more C++
<_whitenotifier-f>
[scopehal-apps] bvernoux forked the repository - https://git.io/JUgZD
<bvernoux>
ok understood the issue ;)
<bvernoux>
it was my repo scopehal which was obsolete
<azonenberg>
Yeah now that we're using relative paths, if you work out of your scopehal-apps the submodule references your scopehal
<azonenberg>
not upstream
<bvernoux>
azonenberg, maybe it will be simpler to remove those submodules ?
<azonenberg>
So you have to keep your fork in sync
<bvernoux>
what is the advantage ?
<azonenberg>
Some of them, like logtools, are used in other projects
<bvernoux>
ha ok
<azonenberg>
scopehal and scopehal-apps could potentially be merged, we had 3 repos originally
<bvernoux>
but scopehal not really
<azonenberg>
But that would be a MAJOR project to migate
<azonenberg>
migrate*
<azonenberg>
and e.g. wireshark + libpcap are separate repos i think
<bvernoux>
also scopehal-docs.git
<bvernoux>
I do not see the point to have a submodule for that
<bvernoux>
as it is linked to scopehal-apps
<bvernoux>
I ask that because it take lot of time and energy to resync all submodules each time ;)
<bvernoux>
and if someone forgot there is very strange things which happen like rebuilding obsolete submodule with new code ;)
<bvernoux>
for log, graphwidget and xptools it is better to keep them as submodule
<bvernoux>
the most critical I think it scopehal itself
<bvernoux>
as it change at same time as scopehal-apps all is linked all the time especially during dev
<bvernoux>
the aim is to have a more "fluid" workflow for contributors ...
<bvernoux>
(like me)
<azonenberg>
Yeah
<azonenberg>
I think merging is probably a good long term solution but it will be a lot of work and is not a short term priority. in particular merging them causes github to randomly open and close tickets due to "fixes #3" commit messages referencing tickets from the other repo
<bvernoux>
I have just understood the drawback of submodule ../ ;)
<bvernoux>
So I have forked all modules else I cannot clone the repo ;)
<bvernoux>
if I want to be a contributor with my own fork
<azonenberg>
Yeah
<bvernoux>
Are you sure BLONDEL and DUDDELL have a place when we check what we can have with Rigol ... ?
<bvernoux>
I see the spec it is ADC up to 1GSPS 8bits (in best case 12bits 500MSPS)
<bvernoux>
BLONDEL is interesting for the 12bits ADC mode anyway
<bvernoux>
DUDDELL is clearly less interesting on paper 250MHz BW with 1GSPS ADC (8bits)
<bvernoux>
we have that with a Rigol scope for less than 1KUSD now
<bvernoux>
with a screen and everything (of course it is not open source)
<bvernoux>
I also suspect Rigol will present a 12bits Oscilloscope ;)
<bvernoux>
as they have no any
<miek>
bvernoux: i tend to just keep a clone of the upstream and do a `git remote add mine <url>`; `git push mine <branch>` for any changes to each repo
<bvernoux>
miek, so far my workflow is more tu update my fork with upstream
<azonenberg>
Anyway, at this point i conclude that the v1.2 probe is my best probe yet, and it outperforms everything i have except the 921
<azonenberg>
And it's closer to the 921 than I thought
<bvernoux>
if you want to improve it you shall design a filter ;)
<bvernoux>
an active filter ;)
<bvernoux>
or maybe change the tip
<azonenberg>
Shortening the tip will move the resonance higher
<azonenberg>
Or using a shorter socket
<azonenberg>
Adding a resistor to ground - if i can keep it purely resistive with minimal L/C - should damp out the resonance at the cost of higher DC loading
<bvernoux>
yes will be interesting to see the results with other tip (they shall be compatible with actual design too)
<azonenberg_work>
So it seems like the socket i currently use for grounds will also fit the tips
<azonenberg_work>
and it's quite a bit shorter
<azonenberg_work>
That should shift the tip resonance even higher up
<bvernoux>
On my side I have received some cheap sma/male/male cable 15cm ;)
<bvernoux>
will test them with the VNA to check how they are ;)
<bvernoux>
anyway they will be used for NFC so it is not a big deal is they are not good after 1.5GHz ;)
<miek>
use connector savers :p
<bvernoux>
the only impact is towards their impedance ;)
<miek>
in my experience the cheap cables do just fine up to high frequencies, but the connectors are almost always out of spec
<azonenberg_work>
So the proposed new tip socket is 1.32mm shorter than what i have now
<azonenberg>
Which will bring the tip stub from roughly 8.5 down to 7.2 mm
<azonenberg>
That should shift the tip resonance roughly 500 MHz up from where it isn ow
<bvernoux>
yes it is a good idea to switch the resonance outside 6Ghz window if possible ;)
<bvernoux>
RF stuff are full of tricks like that ;)
<bvernoux>
I will say about 637MHz ;)
<azonenberg_work>
I think i can also remove the mitering where the tip socket goes to the resistor array
<azonenberg_work>
that should cut off another 0.4mm or so
<azonenberg_work>
I might actually try sanding down the tip of a v1.2 probe and testing this right now lol
<azonenberg_work>
well like, later today
<azonenberg_work>
I think i have enough parts to do it
<bvernoux>
yes very interesting to see if that will move the resonance ;)
<bvernoux>
without other bad effect ;)
<azonenberg_work>
I mean it definitely will move it, the question is by how much, and how good the response will look after
<bvernoux>
body is smaller but maybe also the tip is smaller vs previous tip ?
<azonenberg_work>
Same tip
<azonenberg_work>
Just a less deep socket
<bvernoux>
ha ok
<bvernoux>
the great stuf is it is same size just smaller
<bvernoux>
you will need to cut the PCB ;)
<bvernoux>
but if the performance are really better it is a good deal
<azonenberg_work>
I'm debating whether i want to try sanding down a PCB or just send a new board design out to oshpark. I wanted to make some other tweaks to the tip layout too probably
<azonenberg_work>
I also have to shorten the filter
<azonenberg_work>
the current filter is meant to null out the resonance of the longer tip
<azonenberg_work>
that will be tricky to rework
<bvernoux>
it will be great to test same type as the 921
<bvernoux>
Yes I imagine you will probably need to change again the resistors/placement ...
maartenBE has quit [Ping timeout: 272 seconds]
maartenBE has joined #scopehal
<azonenberg>
Ok so it looks like the "sticking out" part of the probe tip is 3.21 mm long (at 209 pix/mm in that photo), then the old socket is 4.72 vs new is 3.38 mm long, then there's 0.35 mm of stub between the back of the footprint and the resistors
<azonenberg>
So all told, the current tip is 3.21 + 4.72 + 0.35 = 8.28 mm long
<azonenberg>
from resistor to point
<azonenberg>
and the new, assuming i can shorten the miter a little bit, is 3.21 + 3.38 + say 0.15 mm = 6.74
<azonenberg>
Also BTW there is going to be about 0.15 dB/GHz of loss from the FR408 + ENIG on the test fixture that we can subtract from our measurements
<azonenberg>
I did not de-embed the fixture
<azonenberg>
That actually explains a good chunk of the sub 2 GHz loss i'm seeing compared to simulation
<azonenberg>
Red is simplified netlist model of current probe, blue is with shortened tip. Pink and cyan are my probe and the Pico 921
<azonenberg>
this is S11 so ideally we'd see a flat line at about -1.7 dB from the DC loading of the resistor
<azonenberg>
This model is using a tip length based on actual measurements from the resistor to the point of the tip, and assumes uniform impedance the whole way. Actual impedance is not uniform, the socket and the tip are different
<azonenberg>
I'm going to try and tune the sim later today to get a closer fit
<azonenberg>
oh wait i forgot to model the length of the resistor body. so actual stub is 0.7 from socket to resistor
<azonenberg>
also derp i modeled the Er of the tip wrong too. it's air dielectric