<xzcvczx>
almost makes me wonder if freenode did incite/request the spambots
lethalbit has joined #scopehal
<miek>
and i was just one week away from 15y on there :(
<azonenberg>
They brag about how many users they have
<azonenberg>
libera has been around for what, a week or two? and already has upwards of 11K users
<miek>
the other hilarious thing is that they keep talking about how they've saved everyone from the plan to destroy freenode!!
<miek>
when the new guy is literally the only danger to freenode
<monochroma>
what really sucks, is going to be all those channels that were kinda just barely hanging around from long ago, not much activity, but you could still find those people there. it's not going to be worth it for them to move those to other networks, so they will probably just disconnect from IRC completely :P
<xzcvczx>
the funny thing is irc which is like the tech nerds hangout, (always has always will be) they think they can come in and do a facebook style takeover and everyone will just be happy with it like IG/whatsapp etc but wrong crowd
<xzcvczx>
azonenberg: you said there was a discord? wheres the link for that?
<azonenberg>
1bitsquared. dont have the link handy
<azonenberg>
but it should be easy to google
<xzcvczx>
oh ok, i think i have them on twitch anyway
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+1/-0/±4] https://git.io/JGJCp
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JGJ2x
<_whitenotifier-3>
[scopehal] azonenberg bbf48ff - DemoOscilloscope: generate test waveforms in parallel
ericonr has quit [Ping timeout: 264 seconds]
ericonr has joined #scopehal
someone--else has joined #scopehal
someone--else has quit [Quit: Connection closed]
bvernoux has joined #scopehal
someone--else has joined #scopehal
someone--else has quit [Quit: Connection closed]
_whitelogger has joined #scopehal
sorear has quit [Ping timeout: 264 seconds]
elms has quit [Ping timeout: 264 seconds]
esden has quit [Ping timeout: 252 seconds]
JSharp has quit [Ping timeout: 264 seconds]
sorear has joined #scopehal
esden has joined #scopehal
elms has joined #scopehal
JSharp has joined #scopehal
esden has quit [Ping timeout: 264 seconds]
esden has joined #scopehal
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
someone--else has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
<azonenberg>
someone--else: so i made a couple of performance fixes yesterday that should help you a lot
<azonenberg>
1) the demo driver now multithreads waveform generation
<azonenberg>
2) it uses an LCG instead of mt19937 so the RNG is less heavy
<azonenberg>
3) the filter graph now runs in a background thread
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JGTO2
<_whitenotifier-3>
[scopehal-apps] azonenberg 87db57b - Updated submodules. Refactored filters test to handle new TestWaveformSource API
dang`r`us has joined #scopehal
<dang`r`us>
heya
<dang`r`us>
after a moderate amount of hacking I've successfully built scopehal + apps for apple m1, so that's nice. It even starts and shows me the scope picker (but then, GL errors). I'd like to make this a PR buuuuuttt as of now the port is a "bit" of a hack job. So, I'll probably launch a few questions here if that's ok :)
<azonenberg>
o/
<azonenberg>
How about you start with a PR that adds #ifdef's around all of the x86-isms so it will compile on non-x86?
<azonenberg>
That's something we can merge as is, i think there might even be a ticket for it already
<dang`r`us>
yeah, something like that. I've also needed to add a few apple-isms (and potentially homebrew-isms)
<dang`r`us>
zero experience with CMake so far and that'S where I did the most ugly hacking
<azonenberg>
That's a separate issue but also will be nice to have. Make it a different PR though
<dang`r`us>
quite a few dependencies seem to be ... stubborn.
<azonenberg>
Lol
<dang`r`us>
mostly, cpp-yaml pretty much made me admit defeat
<dang`r`us>
or was it called yaml-cpp
<azonenberg>
you mean yaml-cpp?
<azonenberg>
yeah
<azonenberg>
interesting, i wouldnt have expected that to be a problem
<azonenberg>
As far as GL errors, yeah - there's no compute shader support on any apple platform right now under opengl
<dang`r`us>
I could for the life of me not get the include to appear, even when it was successfully found (in various ways). But as I said, I have no idea what I'm doing when cmake.
<xzcvczx>
dang`r`us: did you build with glang or gcc?
<azonenberg>
Did you get OpenCL support working BTW?
<xzcvczx>
clang*
<azonenberg>
or at least compiled / detected?
<dang`r`us>
xzcvczx, clang; gcc wouldn't link because ABI conflicts with (I think) prebuilt gtkmm
<azonenberg>
If OpenCL is usable on M1 we can render with that probably
<dang`r`us>
I wasn't in the mood for a full custom build including all deps
<xzcvczx>
dang`r`us: i assume you had to add -mavx flag for it to build?
<dang`r`us>
I did hack OpenCL in *in some way*
<xzcvczx>
oh actually nvm that might be default now anyways
<azonenberg>
or should i say, replace compute shaders with opencl
<dang`r`us>
xzcvczx, I think I did not. let me search
<azonenberg>
xzcvczx: M1 is ARM not x86
<azonenberg>
so he'd have to remove all the avx stuff entirely
<azonenberg>
FFTS is bare bones, it doesnt even do windowing
<azonenberg>
i had to do that myself
<azonenberg>
But i'm guessing kissfft is slow and not vectorized
<dang`r`us>
likely
<azonenberg>
it looks like they support four independent fft's via vectorization
<azonenberg>
but not vectorization within a single fft
<dang`r`us>
anyway, I'm probably going to pair up with GyrosGeier (who sent me here) this weekend to clean up the port
<azonenberg>
Excellent
<xzcvczx>
i think i caught most of the BSD oddities but i will definitely keep an eye on any commits to see if they can be generalised
<dang`r`us>
from my pastebin, do you have any kind of estimate how much work is left to do (leaving out potential ffts time sinks) until I get something actually working?
<dang`r`us>
xzcvczx, there also seems to be at least one apple-ism, lemme grep
<azonenberg>
dang`r`us: To my knowledge, if you aren't using any of the filters that use FFTs (so basically FFT, spectrogram, channel emulation, de-embed, waterfall)
<azonenberg>
the only thing stopping it from working at this point is the rendering
<azonenberg>
Basically we just need to find something that replaces OpenGL compute shaders with a gpu compute api that's available on M1, and since we already use OpenCL that would probably be a good starting point
<azonenberg>
I'll experiment with that when I have time. No promises
<xzcvczx>
azonenberg: replace or addition?
<azonenberg>
It would be a parallel thing since lots of stuff doesnt have working CL but has GL
<azonenberg>
e.g. old ivy bridge intel gpus
<xzcvczx>
cool
* xzcvczx
gives azonenberg a cookie
<azonenberg>
(thinking of nobody in particular :P)
<azonenberg>
It would probably default to GL if GL_ARB_gpu_compute_shader is available, then fall back to CL if that's available
<azonenberg>
if neither, abort
<dang`r`us>
azonenberg, ok, so basically what's left to do is "fire up OpenCL properly"?
<azonenberg>
more like "port all of the compute shaders to OpenCL and add logic to call one version or the other"
<xzcvczx>
azonenberg: is opengl likely to be faster than opencl?
<dang`r`us>
aah, so opencl is just a dependency right now, but not fully integrated
<azonenberg>
We use CL for accelerating a couple of filters, if available
<azonenberg>
It's not even required
<dang`r`us>
got it
<azonenberg>
it falls back to software versions otherwise
<xzcvczx>
dang`r`us: >_< that one used to annoy me too (i used to be macos but they stuffed me with the 2018 mba)
<azonenberg>
GL compute is a critical requirement for waveform rendering
<azonenberg>
the actual rendering isn't using opengl polygons like a game or cad tool or whatever
<azonenberg>
it's actually a software rasterizer multithreaded on the GPU
<dang`r`us>
heh, fun times
<dang`r`us>
who needs triangles
<azonenberg>
custom tuned for rendering waveform data
<dang`r`us>
shadertoy sure doesn't
<azonenberg>
basically waht it does is run one gpu thread group per X coordinate in the image
<azonenberg>
then run N gpu threads per group, each one grabs a chunk of samples at that offset
<azonenberg>
so you can process say 32 samples in the same pixel in parallel
<dang`r`us>
(Neo voice) whoa
<dang`r`us>
that's a lot of threads
<azonenberg>
it interpolates the position, finds the min/max Y coordinate of the line segment crossing that pixel, then does alpha blended intensity grading
<azonenberg>
and finally writes it back
<azonenberg>
analog, digital, and histogram waveforms all use the same basic shader source concatenated in different ways with different #define's to activate different code paths
<azonenberg>
e.g. histogram fills under the curve, analog interpolates, digital doesn't
<azonenberg>
oh and then there's two different features that may or may not be present for a given waveform
<azonenberg>
it can be either sparse (samples are (x,y) pairs sorted by increasing X) or dense (samples are y coordinates only with X implied to range from 0...N-1)
<azonenberg>
and the GPU can support native 64-bit integer operations or not
<azonenberg>
in the latter case we do bignum math with multiple 32-bit operations to compute on 64-bit values
<azonenberg>
So one shader codebase can get compiled to i think 12 different possible binaries depending on system configuration and the particular data being rendered at that time
<dang`r`us>
nifty
<azonenberg>
We need all of that rewritten in OpenCL, and the code that dispatches the gpu compute added to have conditionals to invoke the CL or GL version
<azonenberg>
and ultimately the output of the CL kernel has to turn into a GL texture
<dang`r`us>
ok
<dang`r`us>
I have written shader stuff before
<dang`r`us>
and chart visualizations and stuff
<azonenberg>
Ultimately the whole rendering path consists of three passes
<dang`r`us>
it sounds doable
<azonenberg>
there's a Cairo software rendered underlay (background gradient, grid, and axes)
<dang`r`us>
(in other words imma just gonna find and replace gl compute function names with CL ones)
<azonenberg>
a Cairo software rendered overlay (cursors, protocol decodes)
<azonenberg>
and an OpenGL compute (or soon OpenCL) rendered waveform, or possibly several if you have digital overlays on an analog waveform
<azonenberg>
Each pass produces a texture which is finally composited into the visible viewport by a very simple shader based compositor
<azonenberg>
the Cairo textures just get alpha blended and displayed as is, the compute output is a fp32 monochrome texture which then gets tone mapped to RGB in the final fragment shader
<dang`r`us>
ok, prettyt straightforward
<dang`r`us>
+spelling
<azonenberg>
Yeah it's not complicated, although months of optimization and tuning went into making it fast
<azonenberg>
the architecture is straightforward though
<dang`r`us>
also, hmmmmmmmmmm
<dang`r`us>
I just zoned in on that "clFFT" thing in my log output
<azonenberg>
We use that already if OpenCL is present
<dang`r`us>
ah ok
<azonenberg>
But we can't use it exclusively because not all platforms we support have OpenCL support
<dang`r`us>
yeah exactly
<azonenberg>
except for the spectrogram filter which is currently FFTS only (it does a lot of small FFTs which i don't think would map well to GPU vs a few large ones)
<dang`r`us>
aye
<azonenberg>
all other filters that do FFTs will use clFFT instead of FFTS if available
<dang`r`us>
ok so it's just not detecting properly on my machine I guess
<azonenberg>
Or it's not installed etc. If it's there, it should be used
<azonenberg>
In any case, as long as it compiles there's enough FFTS that the core functionality should render. FFT isn't used to just display waveforms and do digital protocol decoding, eye patterns, CDR, etc
<dang`r`us>
it's part of the devkit but maybe didn't link right or w/e .. will investigate
<dang`r`us>
aye
<azonenberg>
So we can debug that independently
<dang`r`us>
yip yip
<dang`r`us>
one step at a tiiiiime
<azonenberg>
The main thing to get a minimum viable build on mac is the ifdefing avx optimizations which it sounds like you've done, and then the shader->opencl port
<azonenberg>
incidentally, even without GL compute, you should be able to use libscopehal and libscopeprotocols in headless mode
<dang`r`us>
any binary I can run to test that?
<azonenberg>
writing your own code that instantiates an Oscilloscope and a bunch of Filter objects
<azonenberg>
As of now, no
<azonenberg>
there's the usbcsv example which works offline from CSV import
<azonenberg>
but i dont know if there's any public test data you can use it with
<dang`r`us>
would probably require more C++ than I'm willing to commit right now then :D
<azonenberg>
Yeah, long term i want to have an example that does something simple
<dang`r`us>
I do have a scope so that's the least of my problems
<azonenberg>
like connecting to a scope, setting a trigger at 0V, and calculating the frequency of the signal applied to channel 1
<dang`r`us>
makes sense
<azonenberg>
and runs in headless console mode
<azonenberg>
The whole point of splitting libscopehal and libscopeprotocols out was to allow headless production test use cases etc
<azonenberg>
and/or complex scripted experiments for research
<dang`r`us>
headless would actually be quite interesting for my employer, I might propose carving out a chunk of my work time then
<dang`r`us>
we're a pure Rust shop though :D
<azonenberg>
you can set up triggers, build a custom filter graph, and compare say a protocol capture to expected data
<azonenberg>
by looking at actual i2c packets or 8b10b codewords or ethernet frames
<azonenberg>
Bindings for other languages would be worth looking into past v0.1. But not right away
<dang`r`us>
(and my C++ is mediocre at best; biggest involvement was a 3 year project with cocos2d-x ... I ported everything to smart pointers ... ugh, the memories)
<azonenberg>
also as a general note, the v0.x series has no ABI stability guarantee and while I generally try not to change semantics of existing APIs sometimes I add say new functions to a class that all derived classes must implement
<dang`r`us>
ericonr, always an option! I used bindgen to write a freebsd kernel driver in Rust for a customer which was surprisingly pleasant, given the huge api surface
<azonenberg>
there will be no formal ABI or API stability until v1.0
<azonenberg>
which is a minimum of a year out
<dang`r`us>
(and me never having done anything in terms of kernel dev OR freebsd before!)
<ericonr>
dang`r`us: huh, interesting
<azonenberg>
heck, we don't even have an official v0.1 binary release yet
<dang`r`us>
just saying that if I contribute test cases they probably won't be in C++
<dang`r`us>
ericonr, if you're interested in those things, definitely check out build-std
<azonenberg>
For v0.1 the goal is to hit a minimum useful deployment for windows and linux
<dang`r`us>
unstable as of now but very promising.
<azonenberg>
polishing what rough edges we can in the meantime
<ericonr>
dang`r`us: I'm more in the "complain about rust" than the "use rust happily" camp, rn :P
<dang`r`us>
I have a windows machine here too but the last few days were spent with way too much cursing at libusb, non-working llvm builds, and other stuff
<azonenberg>
Then for v0.2 the current plan is to focus on the existing drivers and protocol decodes with missing bits and finish them
* ericonr
has valid complaints about rust, though
<azonenberg>
e.g. MDIO supports clause 22 but not 45
<dang`r`us>
ericonr, what's your main gripe, out of curiosity?
<azonenberg>
the USB decodes don't do as much sanity checking as i'd like, for things like verifiyng DATA0 and DATA1 alternate, and doesn't support PCAP export
<azonenberg>
the Lecroy driver is missing a ton of triggers
<ericonr>
dang`r`us: most of my rust experience comes from doing distro work, and that's where it bothers me. The language is honestly awesome, but the ecosystem is really messy
<dang`r`us>
what's bothering you about cargo integration? (I'm asking these things because I might be able to nerd snipe people to fix)
<azonenberg>
ericonr: what i want is "rust++" :p
<dang`r`us>
ericonr, oh yeah, distro
<dang`r`us>
we have gotten a ball rolling there but right now it's not perfect
<azonenberg>
rust looks like a decent memory safe C replacement
<ericonr>
also a bunch of crates that automatically download and build C things statically instead of using system stuff
<azonenberg>
I want an equivalent that does everything C++ can but safer
<ericonr>
azonenberg: afaik Rust can do that? I thought that was where mozilla was plugging it into firefox
<dang`r`us>
azonenberg, Rust is definitely a lot more expressive than C, what I like is how composable its primitives are
<azonenberg>
ericonr: I'm talking things like multiple inheritance
<azonenberg>
not just interfaces, but actual code in both base classes
<dang`r`us>
you can usually wing these things with traits
<ericonr>
ah, fair
<azonenberg>
e.g. a Filter is a FlowGraphNode and an OscilloscopeChannel
<dang`r`us>
it's not the same for sure
<dang`r`us>
but inheritance is often messy anyway
<azonenberg>
and both of those have quite a few methods with default implementations
<azonenberg>
please collaborate to send a PR tagged for that issue
<dang`r`us>
will do!
<ericonr>
dang`r`us: and for example, projects that updated to a new libgit2-rs version and now build their own libgit2 version instead of using the system one (because libgit2-rs hardcodes ABI instead of using bindgen), leading to me having bigger executables for each one using libgit2
<dang`r`us>
I wouldn't claim Rust is perfect, that would be silly
<dang`r`us>
binary size can be annoying, yeah
<dang`r`us>
azonenberg, ok so roughly my plan would be 1. fork ffts, coordinating with GyrosGeier (he needs to patch it for Debian anyway) 2. proper AVX guards 3. BSD/Apple-isms 4. OpenCL
<azonenberg>
Yep
<azonenberg>
1-3 would enable headless use on non-x86
<azonenberg>
4 is only needed for the GUI
<dang`r`us>
re ffts ... ship patches with scopehal? or vendor it?
<dang`r`us>
or just use fork
<azonenberg>
I think the best option is to create a full fork on github
<dang`r`us>
ok
<azonenberg>
adopt it, do what we need to do
<azonenberg>
put all debian specific patching in there
<azonenberg>
as well as, eventually, arm64 neon/avx2/avx512 optimizations
<azonenberg>
Before you do that, look at all of the current forks of anthonix/ffts
<ericonr>
dang`r`us: but really, as a language/standard library my only complaints are os::c_char being u8 and i8 on different platforms and people not being aware of it, the eagerness with which people use .unwrap(), and the story around OOM
<azonenberg>
See what the status of them is, and if they have anything we'd want to use as a base
<azonenberg>
Or if we should just fork the original upstream
<ericonr>
dang`r`us: out of curiosity, where do you work that's moved to rust completely?
<dang`r`us>
ericonr, isn't C to blame for the c_char thing? otherwise ... unwrap needs to mostly diiieeeee asap, the question mark operator (combined with e.g. anyhow) makes it really not a question of ergonomics anymore
<dang`r`us>
been a random freelancer in all kinds of stuff before, used Rust only for personal art projects
<azonenberg>
I have to ask, are you guys partnered with Oxide Computer at all? :p
<dang`r`us>
but since I've now joined the cult full time I'll probably eventually replace our government with a Rust impl
<azonenberg>
that would make the perfect rust :p
<dang`r`us>
haven't heard about Oxide. But we're doing a -lot- of puns internally
<ericonr>
and yes, agreed on C being to blame, buuuut people use it in their libraries and only test builds for x86, then the crate breaks with arm/ppc/literally any other arch (see curses-rs iirc)
<ericonr>
can I say I hate that blog? I can't switch pages without it reloading and resetting my position
<dang`r`us>
yes, it'S terrible
<dang`r`us>
and even completely fake: if you noscript the site it's instantly all there
<dang`r`us>
check out the page source for horror
<dang`r`us>
huge asshole move.
<ericonr>
dang`r`us: so very unnecessary :/
<dang`r`us>
yeah, I understand a certain amount of Javascript hate but that's just uncalled for. And probably messes with screen readers etc
<ericonr>
dang`r`us: also damn, that's a very evil pitfall :/
<ericonr>
> (In C, the compiler will let you get away with murder, but the compiler doesn't purport to be a life saving device, either.) :D
<dang`r`us>
right?
<dang`r`us>
anyway, dinner time. I'll probably resurface properly on Saturday or so.
<ericonr>
bb
<dang`r`us>
o>
<GenTooMan>
hmm azonenberg have you only looked at analog D based devices for the differentially coupled amp? you have been designing (well differential coupled to eventually single).
<azonenberg>
GenTooMan: I've looked at a lot of parts, the AKL-AD1 prototype i originally built used a TI amplifier
<azonenberg>
LMH6401 i think
<Degi>
Huh, ADS54J60 has 10.4 ENOB at 720 MHz
<azonenberg>
Looks nice
<azonenberg>
but it's JESD204B so needs a beefy fpga to back it, and is probably expensive
<GenTooMan>
thank you for humouring me azonenberg I was looking at the LMHX401 devices actually and wondered if you had "incidentally" looked at them.
<azonenberg>
yeah it's $1035 at digikey with MOQ of an entire tray
<azonenberg>
GenTooMan: yeah i think at this point for my probe designs i've considered every halfway decent diff amp from adi, ti, and others
<azonenberg>
in other news, i figured out why i was randomly getting bad performance on my picoscope dropping down to usb2 speeds
<azonenberg>
Turns out my haswell i5's XHCI controller has some serious resource limits and can't handle more than a couple of superspeed deviecs plugged in at once
<azonenberg>
it was also causing strange issues with a SDR
<azonenberg>
to try and squeeze a bit more life out of that box I ordered a pcie x1 usb3 controller which will let me shift some of my devices to a separate usb root complex
<azonenberg>
But i need a new lab workstation
<azonenberg>
Which has been on the to-get list for months now but i keep having higher priority things to eat my budget
<GenTooMan>
azonenberg, no surprise you had really, as for the scope drop ouch but not a surprise either Intel products have had "issues" sadly for a while.
<azonenberg>
well this is like intel's first gen usb3 chispet
<azonenberg>
it's from 2014 or so
<azonenberg>
it was my first computer to even *have* usb3
<azonenberg>
its funny, the CPU and RAM are still reasonably adequate
<azonenberg>
and the old but high end quadro card is also pretty decent
<azonenberg>
My problem is that it's getting IO bound
<xzcvczx>
o_O this 2013 machine apparrently has usb3
<azonenberg>
between the single low-spec usb3 root complex and the limited pcie (one x16 that i forget if is gen 2 or 3, plus three gen2 x1 ports)
<azonenberg>
i can't get data on and off fast enough
<azonenberg>
It has a 10G NIC shoved into a pcie x1 slot running at only 2.5 Gbps for example
<GenTooMan>
nothing as bad as the 2011 nvidia AMD chip set I'm using
<Degi>
azonenberg: That thing costs 1000 $, I think even an ECP5 could interface to its 4 lane 5 Gbps mode...
<azonenberg>
but that's lower sample rate right?
<azonenberg>
that's only 20 Gbps
<azonenberg>
hmm
<azonenberg>
which might be enough actually
<azonenberg>
but yeah the adc is pricey
<azonenberg>
anyway, i'm not using it in my first designs
<Degi>
Ohh
<Degi>
It is 4 lanes per channel
<GenTooMan>
:D
<GenTooMan>
Like most ultra high speed converters getting the data off the chip itself is the biggest issue.
<GenTooMan>
The windows of this house are getting hosed by rain... pretty noisy.
<Degi>
Hmm, is it? I mean you can get a few hundred Gbps even with LVDS
<azonenberg>
well it's a combination of needing a lot of fast serdes lanes, and a lot of ddr to buffer it
bvernoux has quit [Quit: Leaving]
<GenTooMan>
eh these days getting something fast enough to handle those many channels in a cost effective manner is becoming a challenge.
<azonenberg>
Anyway, i think my next project in the scope series is going to be a single lane ZENNECK proof of concept
<azonenberg>
Small FPGA, a bit of DDR, 1G ethernet, four HMCAD1520s, and one front end
<azonenberg>
targeting 500 MHz BW
<azonenberg>
The idea being to validate the front end originally designed for BLONDEL at higher frequencies
<azonenberg>
and test interleaving of multiple HMCAD1520s etc
<azonenberg>
If that's successful I can think about building a full ZENNECK. Which I think would be a fairly respectable scope in its own right
* GenTooMan
writes the first model number in "digital" crayon "Z101"
<azonenberg>
I have yet to decide on the actual model number designations for the scopes, or if the internal code names will stick as final product names
<azonenberg>
On the probe side of things... the AKL-AD3 mechanical prototypes are printing now
<azonenberg>
amplifier board is done, pending design review before i order it
<azonenberg>
but i still have to design the flex for the probe tip area
<GenTooMan>
are you using KiCAD or something better?
<azonenberg>
Still kicad
<azonenberg>
and solvespace for mechanical
<azonenberg>
Designing complex flex PCBs with multiple bends in them is HARD
<azonenberg>
there's basically no tooling for it
<GenTooMan>
hmm I was thinking a python script to reverse generate a spice network based on the PCB layout might be a fun little project.
<azonenberg>
from what people tell me, even in the commercial space there's not a lot of good options at the midrange (altium/solidworks) level
<azonenberg>
the ultra high end tools from cadence etc probably can do it
<azonenberg>
but even then integration with mcad is probably hard
<azonenberg>
I think i'm going to end up designing the pcb outline by trial and error
<azonenberg>
print it out on paper, cut it out
<azonenberg>
and curve it around a 3d printed mechanical prototype
<azonenberg>
iterate as needed
<GenTooMan>
I fear you are correct in thinking their is no "easy" way for now.
<azonenberg>
i know roughly what i want the flex to be shaped like, but have no clue how to, given the board and probe geometry, design an outline of a flex pcb that will fit the shape i want
<azonenberg>
This mechanical outline is of course still very much a WIP and i expect a couple of iterations to get all of the ergonomic etc factors right
<azonenberg>
I'm thinking of trying to design the tail area to be dimensionally compatible with the lecroy wavelink probe positioners similar to how i made the AKL-PT1 fit the PMK ones
<azonenberg>
remains to be seen if that's doable, but i think it would be a nice goal
<GenTooMan>
for https://www.antikernel.net/temp/ad3-09.png do you plan to get that machined or cast using a rapid prototype mould then burn the material out and machine the brass afterward?
<azonenberg>
It's not going to be brass
<azonenberg>
The whole thing will be one piece SLS nylon
<azonenberg>
I'm relying specifically on the flexibility of the nylon for the jaw area
<GenTooMan>
SLS instead of SLA or FDM, OK that makes more sense, I'm using to people using FDM or SLA to make precision aluminium or brass cases for their projects.
<GenTooMan>
s/using/use"
<azonenberg>
Yeah I dont have a home printer
someone--else has quit [Quit: Connection closed]
<azonenberg>
All of my mechanical fab is outsourced unless it's something i can do by hand on a manual 3-axis mill. Which is almost nothing (I got it for PCB rework)
<azonenberg>
and i'm not going to pay someone to FDM a part for me
<azonenberg>
if i'm paying for the print i'm going to do SLS or MJF
<azonenberg>
The top part is just a shield can https://www.antikernel.net/temp/ad3-06.png and will be SLS'd out of shapeways nylon 12 which is their cheap entry level SLS plastic
<azonenberg>
The bottom part will use nylon 11 which is more expensive but flexible, since i'm using it as both a spring (when thin) and as the frame (when thick)