<azonenberg>
also interesting: it appears lecroy's i2c protocol decoder borks hard on transactions that are just cut off and don't end properly
<azonenberg>
while the scopehal one can still decode partial transactions
<Bird|otherbox>
so, got the stuff merged and committed as a new local branch
<Bird|otherbox>
now, how do I turn that into a pull request?
<azonenberg>
Bird|otherbox: do you have a fork on your github account yet?
<azonenberg>
if not, make one
<azonenberg>
then push the branch to your fork
<azonenberg>
then send a PR from that fork to the upstream version
<Bird|otherbox>
OK, makes sense
<azonenberg>
Also if you see a fork in the road, stop and pick it up so nobody runs over it and gets a flat tire :P
<azonenberg>
(jokes aside, i have literally seen dining forks lying on the street. no idea how they got there. Nice metal too, not plastic)
<azonenberg>
Bird|otherbox: (make sure your PR is aimed at ui-dev, not master, on upstream)
<azonenberg>
How does the ui-dev stuff look? have you built and played around with it much yet?
<Bird|otherbox>
it compiles and runs, the prefs dialog doesn't go away nicely on close unfortunately, still have the test widgets in there too (no real prefs yet)
<_whitenotifier-f>
[scopehal-apps] tarunik forked the repository - https://git.io/JUgq6
<azonenberg>
Bird|otherbox: Ok. So definitely not ready to merge yet
<azonenberg>
also is the prefs dialog currently modal or modeless? i'm trying to move towards dialogs being modeless as much as i can so they don't block waveform updates and rendering
<Bird|otherbox>
I'm not sure, I'd have to look at that
<azonenberg>
trigger properties is currently modal and i have a ticket open to fix that
<Bird|otherbox>
my current goal's to get the branch sorted out WRT the submodule changes and get that pushed everywhere, then we can start doing real work :)
<azonenberg>
Yeah
<azonenberg>
Agreed
<azonenberg>
and just generally up to date with all of the other changes from the past few months if any affect it
<Bird|otherbox>
since I'll be sending a PR over for the changes, do you want me to do all the branch juggling in one PR BTW, so that the new gui-dev just shows up in place of the old one?
<azonenberg>
Yeah
<azonenberg>
the desired end state is a gui-dev PR i can just pull in over the current gui-dev branch that brings it to the point of building against current master
<Bird|otherbox>
rightyo
<azonenberg>
Once that's done, can you look at scopehal-apps:#143? it appears that you can use relative paths in submodules
<azonenberg>
such that a) forks work properly as long as you fork all of the applicable repos and b) you can clone over both https and ssh so anonymous clones work properly
<azonenberg>
But i want someone to actually set up a test environment with forks of every repo, verify cloning over both https and ssh works, etc
<azonenberg>
then send PRs to make the relevant gitmodules changes to master
<azonenberg>
This includes both the submodule of scopehal in scopehal-apps, and the ones for logtools, xptools, and graphwidget in scopehal. I think it's only those four
<_whitenotifier-f>
[scopehal-apps] tarunik opened pull request #181: Migrate the gui-dev branch over to the new submodule format - https://git.io/JUgmk
<azonenberg>
Hmm, merging this is going to be a pain because of the way github handles branching
<Bird|otherbox>
yeah, you may have to trash the gui-dev branch and then pull the PR in sadly
<azonenberg>
Can you close this PR and send a new one to gui-dev-new?
<azonenberg>
(which doesnt yet exist)
<Bird|otherbox>
sure
<azonenberg>
I'll create it
<Bird|otherbox>
don't worry about creating it on your end?
<Bird|otherbox>
(unless you have to)
<azonenberg>
Not sure if you can send a PR to a nonexistent branch on github
<_whitenotifier-f>
[scopehal-apps] tarunik closed pull request #181: Migrate the gui-dev branch over to the new submodule format - https://git.io/JUgmk
<_whitenotifier-f>
[scopehal-apps] azonenberg created branch gui-dev-new - https://git.io/JvExD
<azonenberg>
So send a PR against that
<_whitenotifier-f>
[scopehal-apps] tarunik commented on pull request #181: Migrate the gui-dev branch over to the new submodule format - https://git.io/JUgmE
<azonenberg>
If it was me, i'd just force push. But i'm not confident enough in your merge yet that i want to blow away the old branch
<azonenberg>
By putting it in a new one we can diff things and sanity check before doing anything permanent
<_whitenotifier-f>
[scopehal-apps] tarunik opened pull request #182: Migrate the gui-dev changes to a gui-dev-new branch. - https://git.io/JUgm2
<azonenberg>
If a diff of gui-dev-new against gui-dev looks good, then I can replace it i think
<_whitenotifier-f>
[scopehal-apps] tarunik edited pull request #182: Migrate the gui-dev changes to a gui-dev-new branch. - https://git.io/JUgm2
_whitelogger has joined #scopehal
LeoBodnar has joined #scopehal
kc8apf has joined #scopehal
wbraun has joined #scopehal
florolf has joined #scopehal
NeroTHz has joined #scopehal
Degi has joined #scopehal
azonenberg_work has joined #scopehal
electronic_eel has joined #scopehal
maartenBE has joined #scopehal
anuejn has joined #scopehal
alexhw has joined #scopehal
vup has joined #scopehal
promach3 has joined #scopehal
sorear has joined #scopehal
lukego has joined #scopehal
Bird|otherbox has joined #scopehal
apo has joined #scopehal
smkz has joined #scopehal
gruetzkopf has joined #scopehal
elms has joined #scopehal
laintoo has joined #scopehal
monochroma has joined #scopehal
tnt has joined #scopehal
jn__ has joined #scopehal
lain has joined #scopehal
gurki has joined #scopehal
_whitenotifier-f has joined #scopehal
azonenberg has joined #scopehal
pepijndevos has joined #scopehal
StM_ has joined #scopehal
Stary has joined #scopehal
kbeckmann has joined #scopehal
agg has joined #scopehal
Ekho has joined #scopehal
noopwafel has joined #scopehal
balrog has joined #scopehal
miek has joined #scopehal
Error_404 has joined #scopehal
Kliment has joined #scopehal
asy_ has joined #scopehal
yourfate has joined #scopehal
bluezinc has joined #scopehal
futarisIRCcloud has joined #scopehal
deltab has joined #scopehal
Implant has joined #scopehal
awygle has joined #scopehal
_whitelogger has joined #scopehal
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #scopehal
electronic_eel_ has joined #scopehal
electronic_eel has quit [Ping timeout: 272 seconds]
_whitelogger has joined #scopehal
<_whitenotifier-f>
[scopehal] bvernoux forked the repository - https://git.io/JUgZD
<_whitenotifier-f>
[scopehal-apps] bvernoux forked the repository - https://git.io/JUgZD
<_whitenotifier-f>
[scopehal] bvernoux opened pull request #263: Replace usleep(..) by std::this_thread::sleep_for(std::chrono::microseconds(..)) see PR #262 - https://git.io/JUgnW
<_whitenotifier-f>
[scopehal-apps] bvernoux opened pull request #183: Fix .git modules with correct url - https://git.io/JUgnR
<_whitenotifier-f>
[scopehal] bvernoux commented on issue #262: Issue to build the actual code with MSYS2 / MINGW64 related to usleep (Impact multiple files SignalGeneratorOscilloscope.cpp...) - https://git.io/JUgnw
<_whitenotifier-f>
[scopehal] bvernoux edited a comment on issue #262: Issue to build the actual code with MSYS2 / MINGW64 related to usleep (Impact multiple files SignalGeneratorOscilloscope.cpp...) - https://git.io/JUgnw
electronic_eel_ is now known as electronic_eel
m4ssi has joined #scopehal
<NeroTHz>
azonenberg, regarding the differential-to-single-ended thing from yesterday
<NeroTHz>
looks like that was a rat race coupler
<NeroTHz>
ring is 6/4ths of a wavelength
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on pull request #183: Fix .git modules with correct url - https://git.io/JUg0r
<azonenberg>
yeah this is for a clock so i guess they didnt care about harmonics and just wanted the fundamental though. On the other hand, i guess integer harmonics would still work well on a rat race?
<NeroTHz>
indeed, the integer harmonics can still work
<NeroTHz>
well only the odd ones I think
<azonenberg>
which is all you need for a squarewave right?
<NeroTHz>
the even ones see 180 degrees turned into 360, so a side-effect is that all even harmonics get turned into commmon-mode, all odd harmonics into differential mode
<azonenberg>
so basically if you want to convert a single ended clock signal of a known, constant frequency to differential this circuit should actually work extremely well for that
<NeroTHz>
yes. But I suspect that those high-speed clocks aren´t square but I´m not sure
<azonenberg>
well i mean its not like most serdes etc get too many harmonics out if they're working close to their limit
<azonenberg>
You do get really nice open eyes using a modern fpga serdes for 1000base-X though :p
<NeroTHz>
sure :p
<azonenberg>
NeroTHz: also i did some pre-PCB experiments on my latest sonnet model of the probe. On my 4 GHz scope, looking at a 40ps (aka "infinitely fast" as far as the scope frontend is concenred) risetime pulse
<azonenberg>
applying the simulated s-parameters only took 10ps off the rise time
<azonenberg>
the signal looked beautiful, and quite a lot nicer than doing channel emulation with the actual measured s-parameters for either the kickstarter version (significantly slower edges) or the last prototype (fast edges but huge overshoot from the ~3 GHz peaking)
<azonenberg>
So here's hoping reality gets even somewhat close to that :p
<azonenberg>
i'm a little scared because this is my first use of a distributed element filter in a design
<NeroTHz>
they really aren´t as hard as they seem, esp if they aren´t super-high-Q
<azonenberg>
Yeah for this one low Q is actually a feature not a bug
<azonenberg>
I had trouble getting the Q *down* to where I needed at first lol
<NeroTHz>
I´ve made an 8-pole 50 MHz filter at 2.4 GHz at one point, which required a few iterations to compensate for etching effects, but even me as a (at the time) masters student could do it in a few design sittings
<azonenberg>
You probably also had formal training in EE
<azonenberg>
rather than a computer science degree and... two? EE classes total
<azonenberg>
and a bunch of independent study that clearly is missing important bits here and there
<azonenberg>
(for example i've never properly studied diffeq)
<azonenberg>
Every once in a while my having not studied certain things bites me
<azonenberg>
Like when I was trying to build the CTLE filter without knowing a pole from a zero if it bit me on the nose
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #263: Replace usleep(..) by std::this_thread::sleep_for(std::chrono::microseconds(..)) see PR #262 - https://git.io/JUgnW
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±6] https://git.io/JUguJ
<_whitenotifier-f>
[scopehal] bvernoux 776cedd - Replace usleep(..) by std::this_thread::sleep_for(std::chrono::microseconds(..)) see PR #262
<_whitenotifier-f>
[scopehal] azonenberg a6d02e8 - Merge pull request #263 from bvernoux/usleep_changes Replace usleep(..) by std::this_thread::sleep_for(std::chrono::microseconds(..)) see PR #262
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #184: When loading a save file, the view sometimes has a weird negative offset putting the view off to the left of the data - https://git.io/JUggb
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #184: When loading a save file, the view sometimes has a weird negative offset putting the view off to the left of the data - https://git.io/JUggb
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±4] https://git.io/JUgak
<_whitenotifier-f>
[scopehal] azonenberg f2ee813 - Initial implementation of I2C EEPROM protocol decode. No protocol analyzer support yet, just basic decode. Fixes #37.
<azonenberg>
bvernoux: how's the windows stuff going?
<bvernoux>
still need to fix stuff in other repo
<bvernoux>
then after the usleep
<bvernoux>
there an other error where ffts is not found ...
<bvernoux>
strange
<azonenberg>
Yeah we've had issues with ffts's installation. There's been talk of importing it as a submodule or something and integrating it under our build
<bvernoux>
It seems Katharina has come back
<bvernoux>
I hope she feel better after COVID ...
<azonenberg>
Yeah she's commenting on issues again which is a good sign
<azonenberg>
I know she was hospitalized, even in the ICU, for a little while. Last i heard she said she was trying to recover her strength and focusing on getting back to work
<azonenberg>
and that we shouldn't expect any contributions for a while
<bvernoux>
yes I imagine
<azonenberg>
But if she's following the github she clearly hasnt lost interest so i'm hopeful she'll be back when she's ready
<azonenberg>
Also i am thinking of making a small change to the MEAD enclosure design
<azonenberg>
the bottom will stay basically as is
<azonenberg>
but for the front i want to remove the engraving
<azonenberg>
then add a lexan overlay that covers the LCD and has printing on it
<azonenberg>
this will provide better protection for the LCD and also allow higher resolution text than engraving
<bvernoux>
let post photo when MEAD will be assembled ;)
<azonenberg>
The PCBs are assembled already, did you not see?
<azonenberg>
25 of them are in the DHL network somewhere between shenzhen and me ETA monday
<azonenberg>
i have one prototype enclosure i'm going to fit test them against, probably tune a bit, then make 25 of the final rev
<azonenberg>
I still need to make the input connector boards. The ones in my lab will get 8x MMCX coax connectors and the ones going to Germany will get a custom flex PCB that connects to their DUT
<azonenberg>
The MMCX board is designed but needs slight tuning, the flex board is not designed yet
<bvernoux>
yes I have seen that photo
<bvernoux>
I want to see all ;)
<bvernoux>
that board is very clean anyway
<bvernoux>
it is done at PCBWay ?
<azonenberg>
Multech
<azonenberg>
I've had very bad experiences with pcbway
<azonenberg>
Not using them again
<azonenberg>
I had like 30% yield on a run of 500 flex boards
<azonenberg>
If you can't make my design, fine - tell me during CAM review and i'll make it more manufacturable
<azonenberg>
Don't make it and then have 2/3 of the boards not work
<electronic_eel>
did they send you the broken boards without telling you?
<azonenberg>
They sent me all of the boards with no testing
<miek>
out of interest, what went wrong? we had a bunch of issues on an old work project where the flex adhesive was bubbling during reflow
<azonenberg>
these were solder in ancestors of what will eventually become the AKL-PT2, my solder in flex probe
<azonenberg>
The tip castellations were completely cut off, there was copper on the top and bottom and all of the via plating was routed away
<azonenberg>
only about a third of them actually had connectivity from top to bottom
<azonenberg>
I freely admit that the castellation vias were pretty small, so it needed tight tolerance on the board edge
<electronic_eel>
wow, no testing. are non-100%-flying probes tested boards still a thing? even the cheapest jlcpcb offer has 100% testing
<miek>
ugh
<azonenberg>
but this should have been caught during design review
<azonenberg>
The fact that they took my money for a batch of boards where 2/3 of them didn't work, and i had no idea which ones, is unacceptable
<azonenberg>
meanwhile multech has caught tiny errors in my boards like a slightly not-square outline where the bottom right corner was 50um right of the top right
<azonenberg>
so they clearly do a thorough cam review
<azonenberg>
and they do good testing too, you get microsections and impedance test reports and they even send you the specimens if you don't trust their measurements
<azonenberg>
I've spot checked a few and their data looks good
<_whitenotifier-f>
[scopehal-docs] azonenberg opened issue #18: Replace all screenshots with new toolbar icons and dark theme - https://git.io/JUg5k
<azonenberg>
electronic_eel: Yes, they are still a thing :p
<electronic_eel>
multech doesn't have an online quote calculator, even for the more common options. I don't like that, because it is hard to get a feeling which options are expensive and which are cheap
<azonenberg>
electronic_eel: Yes, you have to go through a rep. But you can get very quick responses
<azonenberg>
I just send a skype IM to betty and hear back in minutes during normal hours
<azonenberg>
so i can ask "how much to add one layer of blind vias"
<azonenberg>
and get a number
<azonenberg>
a lot of fabs wont give you that without a full quote. Which is annoying if you want to know what's expensive
<azonenberg>
BEFORE you've done the design
<electronic_eel>
yes, exactly
<azonenberg>
i'll routinely just message her something like "about how much for 5 pieces of 100x150 mm 4 layer FR408HR with ENIG, filled via in pad, and impedance control" and get a number pretty quickly
<electronic_eel>
ok, this sounds reasonable
<azonenberg>
And she generally has pretty good english (written at least, we've never done voice/video calls)
<azonenberg>
i've never had significant issues with language barriers
<azonenberg>
She's been my main rep for years, i was with Andy for a while but he left the company ~5 yrs ago
<azonenberg>
and betty has handled my account since then
<azonenberg>
So far every other fab i've worked with has either had worse quality, cost a lot more, or in some cases both
<azonenberg>
and i keep coming back to them lol
<azonenberg>
The only other fab i actively use is oshpark, which is expensive for big stuff but great for small things because they don't charge NRE
<electronic_eel>
I once had a problem with jlc. they had a question about my design. the english was ok, but the problem was that the person emailing with me was not the engineer, but some sales/support rep that did translating and had low knowledge of pcb manufacturing. so the meaning of the questions / answers was lost in translation
<azonenberg>
and FR408HR is a nice low loss material, and has an Er almost identical to RO4350B
<azonenberg>
Multech's engineering normally sends over an EQ sheet as an excel file with clear english descriptions of questions/issues
<azonenberg>
and screenshots of the CAM software showing potential problem sites
<azonenberg>
To give you an idea of how well they handle such stuff, i caught them making a mistake with impedance control once
<azonenberg>
the proposed trace geometry was way off what i had calculated in sonnet, but rather than silently making the board wrong they sent me an EQ sheet asking me to accept the changes
<azonenberg>
I said "no way, something is wrong"
<azonenberg>
sent them a screenshot of my sonnet sim with calculated geometry, then they replied back apologizing and saying they hadn't noticed there was no soldermask on the line
<azonenberg>
and gave a new suggested geometry that was like 10 um off of mine
<azonenberg>
No hard feelings, no silently making broken boards
<azonenberg>
identify the issue, figure out which one of us made the mistake, then fix it and move on
<bvernoux>
azonenberg, yes they seems great
<bvernoux>
but I hate to ask all from Email they seems to do not have online things for PCB
<azonenberg>
yeah all of my contact with them is over skype
<bvernoux>
what is nice JLCPCB or PCBWAY is you validate all without contacting them
<bvernoux>
but yes you can have issue ;)
<bvernoux>
JLCPCB are very serious anyway for ultra cheap PCB