05:32 <d1b2> <j4cbo> now I know where Nordic gets the inspiration for their packages

11:56 <Degi> Somebody sometime did testing on the S parameters of an ordinary SMA connector on a PCB edge, right? Who was that / are the results somewhere online?

14:20 <azonenberg> Degi: details depend greatly on the specific layout in question

14:20 <azonenberg> and pcb material, etc

14:22 <Degi> I remember that somebody did tests with this specific connector https://www.renhotecrf.com/wp-content/uploads/2019/01/27-4.jpg and it was kinda bad already at 2 GHz, not sure what the PCB layout was but I think the problem was the connector itself having a large inductance compared to fancier variants

14:22 <Degi> How is the thing called where you plug a SFF-8087 cable into? I somehow cant find it on mouser or digikey

14:23 <azonenberg> i just looked for sff-8087 connectors, idk lol

14:23 <azonenberg> And i did testing of a samtec connector that looked exactly like that

14:23 <azonenberg> i had issues with it being very sensitive to pcb layout and bottom side grounding

14:23 <azonenberg> the amphenol connector i now use doesnt care nearly as much because it's a coplanar launch

14:24 <Degi> Ah, so when the PCB layout is good they actually perform well? nice

14:25 <azonenberg> The samtec one performs much better with good pcb layout. it tops out at something like 12 ghz and the amphenol goes to 26.5

14:25 <azonenberg> (per specs)

14:25 <azonenberg> but i couldnt reliably simulate the samtec one and the amphenol one behaves like the sims suggest

14:25 <azonenberg> so i switched

14:25 <azonenberg> i'd rather pay more for a connector i can trust than get a cheap one that ruins my signal if i look at it funny

14:26 <Degi> Hmm yes... Especially when you cant simulate it and considering that respins cost money too

14:27 <azonenberg> Exactly

14:27 <azonenberg> i spent many hours on the phone w/ sonnet support and multiple pcb spins testing

14:27 <azonenberg> we never did figure out what was going on at the launch, i think you need a full 3D EM solver to model it

14:28 <azonenberg> The amphenol one is easy to simulate reliably with a 2D launch into CPWG

14:29 <Degi> Hmm, probably... Maybe if I ever find the motivation to work with OpenEMS

14:31 <azonenberg> Well a 3D model would also involve having detailed info about the internal 3D structure of the connector (by RE probably)

14:31 <azonenberg> Because samtec gives out HFSS models but they're a) in a proprietary format and b) encrypted

14:32 <Degi> Sanding it down layer by layer

14:35 <azonenberg> Yes, that is a valid strategy

14:35 <azonenberg> i would probably have just cast it in epoxy and sawn it in half

14:35 <azonenberg> then assumed the barrel was rotationally symmetric

14:35 <azonenberg> But it would have had to be done carefully because the center contact is BeCu and Be dust is... not nice

14:40 <azonenberg> also... I'm tabling probe work for a few days

14:40 <azonenberg> I dont think there is anything left i can do until the new scope comes in

14:41 <Degi> No worries, it was just a random idea.

14:42 <Degi> If anybody has problems finding SFF-8087 and SFF-8643 receptacles: Search for Mini-SAS or Mini-SAS-HD (because for some reason they dont show up when searching for the number)

14:44 <azonenberg> Well, this means I have time to work on the picoscope driver and a few other things in the meantime

14:44 <Degi> nice ^^

14:45 <azonenberg> pico wants me to put together a little demo video for some of their customers of glscopeclient and the picoscope 6000 series

14:45 <azonenberg> so i want to get the trigger logic debugged first

14:45 <azonenberg> then maybe do something looking at usb or something? idk, have to figure out a good demo

14:51 <azonenberg> oh, so the other thing i want to do is update my nvidia drivers and reboot

14:51 <azonenberg> (since there's kernel updates to do too)

14:51 <azonenberg> to see if that has any impact on my weird opencl issues

17:47 <azonenberg> ok back after lots of pain dealing with broken grub :p

17:48 <azonenberg> opencl issues are still here with latest driver

18:00 <_whitenotifier-4> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±7] https://git.io/JqCpI

18:00 <_whitenotifier-4> [scopehal] azonenberg d3ebea6 - Added UsesCLFFT() method. A few more minor OpenCL cleanups. Fixes #395.

18:01 <_whitenotifier-4> [scopehal] azonenberg closed issue #395: Crash when using OpenCL FFTs and more than one FFT is active - https://git.io/JtVWS

18:01 <_whitenotifier-4> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JqCpG

18:01 <_whitenotifier-4> [scopehal-apps] azonenberg 6286f81 - OscilloscopeWindow: updated filter scheduler to avoid concurrently computing two clFFT operations. Workaround for suspected thread safety issue in either clFFT or NVIDIA OpenCL driver

18:02 <azonenberg> This appears to work around the bug although i still don't have a root cause so i'm not happy

18:05 <azonenberg> Sooo now i can take care of a few things around the house then get back to work on the Pico driver

23:31 <azonenberg> New record, lol. 335 WFM/s with glscopeclient

23:31 <azonenberg> 1M points @ 5 Gsps from my picoscope on a single channel

23:31 <azonenberg> Not sure if that was a fluke, i havent been able to sustain it that high

23:33 <azonenberg> but i'm averaging about 1.9 Gbps of streaming bandwidth. 1M points * 16 bit is 16 Mbits, so with 1900 Mbps bandwidth that should give me an average of about 120 WFM/s

23:34 <azonenberg> Which is more along the lines of what i am seeing

23:34 <azonenberg> but the average is all over the place, probably due to OS jitter at both sides of the link

23:34 <azonenberg> i only average time for ten waveforms right now