00:19 <azonenberg> ok soooo we had some unexpected interruptions yesterday, but i'm gonna be hopefully assembling the updated MEAD pods today

00:19 <azonenberg> assembling the*

01:29 <azonenberg> MMCX input board done

01:29 <azonenberg> monochroma: also i finished soldering your sfp breakout. not tested though

01:29 <azonenberg> but you should be able to rework it if there's any issues

01:29 <azonenberg> visually looks fine

01:36 <monochroma> yay!

20:16 <azonenberg> So i ended up running out to a sar call last night while the MEAD board was cooling off after reflow

20:17 <azonenberg> still have to hand solder the sff shell and the SWD pin header but almost ready to fire it up and test

20:17 <azonenberg> the first known bug is that the opening on the front panel of the initial enclosure prototype is displaced vertically from where it should be

20:18 <azonenberg> there's space at the bottom and the top edge of the mmcx hits the opening

20:26 <Degi> Heh

20:31 <_whitenotifier-b> [scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JJkJz

20:31 <_whitenotifier-b> [scopehal-cmake] azonenberg e6951c8 - Updated submodules

20:32 <azonenberg> wbraun: per PM convo... first step is to grab the latest source from github and build

20:32 <azonenberg> are you going to be testing on linux or windows?

20:32 <azonenberg> linux is more stable/supported, windows is still mostly experimental

20:32 <wbraun> Linux.

20:33 <wbraun> How do the drivers work? I dont think linux supports all of the driver classes supported by the RTB2000, or is this over ethernet?

20:33 <azonenberg> So there's two layers between scopehal core and the instrument

20:34 <azonenberg> the first is the instrument driver, which converts API calls from scopehal into reads and writes over an abstract SCPI "transport"\

20:34 <azonenberg> second is the transport, which converts scpi data blocks into something the instrument understands

20:35 <azonenberg> Right now the supported transports are raw TCP, LXI VXI-11, LeCroy VICP, and USBTMC. Somebody is working on a GPIB transport but it's not merged yet, and we could easily write an RS232 one if there was demand

20:35 <azonenberg> Any transport and driver can be paired depending on the connectivity options available on your specific instrument

20:37 <azonenberg> So in your case you'd want to use driver "rs" and probably transport "tcp" assuming your scope was plugged into a LAN and using raw SCPI over TCP 5025 rather than LXI mode

20:39 <azonenberg> Build/setup instructions can be found in section 3 of https://www.antikernel.net/temp/glscopeclient-manual.pdf

20:40 <azonenberg> The R&S driver is in lib/scopehal/RohdeSchwarzOscilloscope.cpp. If you search "unimplemented" you'll see lots of APIs currently do nothing but print a warning and return a garbage value

20:40 <azonenberg> but it should at least allow you to connect to the instrument and view waveforms without touching any settings

20:47 <wbraun> Ok. I need to get my car smogged today, I will try this out this weekend

20:49 <azonenberg> Great. Assuming it works, we'd love PRs to get the driver fully feature complete so you can use it for remote control and such as well as just viewing data

20:50 <azonenberg> also if you have suggestions on signal processing/analysis features to make it more useful for power electronics, let me know

20:50 <azonenberg> right now the only thing we have is the ability to multiply a voltage and current waveform to get instantaneous power

20:50 <azonenberg> and a filter that derives a current waveform from a voltage waveform through a shunt resistor of known value

20:56 <Degi> Hmh would it be possible to efficiently make a thing where you enter a mathematical expression?

20:56 <Degi> Like with integrals and derivatives and cool stuff

21:03 <Degi> azonenberg: Do you use some kinda automated routing for big FPGA

21:12 <azonenberg> Degi: creating a filter graph from a math expression would be interesting but isnt a high priority right now

21:12 <azonenberg> and no i hand route everything

21:12 <azonenberg> i mean the kicad P&S has some interactive autorouting which is handy

21:12 <Degi> I mean things like ground and power vias could probably be automated

21:17 <azonenberg> until you start doing things like offset vias for routability

21:18 <Degi> Hm yeah. (At least for the package I'm interested in, it'll have dogboning with the same offset for all vias cuz jlc lol)

21:21 <azonenberg> Yeah on oshpark i will routinely use big/small offset vias on 1mm bgas

21:21 <azonenberg> because you just barely can't fit two signals per routing channel if they're even

21:21 <azonenberg> but if you squish the vias a bit, you can fit two in every other channel without squeezing the other channel below one

21:21 <azonenberg> so 50% fanout increase

21:31 <Degi> Whats a routing channel

21:44 <azonenberg> Degi: spaces available between balls/vias for escape traces

21:45 <azonenberg> i actually have a big google spreadsheet i made a while ago that calculates a lot of this for you... specify your min trace/space, via diameter, dimensions of the BGA array, ball diameter and pitch, etc and it calculates what percentage of the array you can fan out

21:45 <Degi> Oh neat

21:46 <azonenberg> Using both evenly spaced and offset vias

21:47 <azonenberg> this is approximate and doesn't allow for things like xilinx's sparse chevron design which has power/ground balls interspersed with io, but is good enough for a first order estimate

22:47 <_whitenotifier-b> [scopehal-docs] azonenberg pushed 1 commit to master [+1/-0/±14] https://git.io/JJkt4

22:47 <_whitenotifier-b> [scopehal-docs] azonenberg 168ee38 - Major restructuring of manual, changed from article to book class

23:20 <azonenberg> I think i'm going to put MAXWELL layout work on hold for a little while. Need to work on bringing up the hardware i already have lol