<electronic_eel>
but wouldn't it be nice to also have something like the probe sockets for gnd, just in case there is some problem and you want to make sure it is not bad gnd connection?
<azonenberg>
I can solder something up if necessary
<azonenberg>
it's bare copper
<azonenberg>
well silver plated
<electronic_eel>
ok, so no soldermask on top
<azonenberg>
there will be selective soldermask to prevent flow out onto the CPWs from connectors etc
<azonenberg>
but small rectangles here and there, not flood fill
<azonenberg>
re grounds/tips, my standard accessory kit will most likely be an 890-800-000 solid tip plus maybe a few spares, an 018-291-103 ground blade, an 890-400-800 Z-ground, an 890-400-808 flex ground
<azonenberg>
https://www.antikernel.net/temp/IMG_20200226_191441.jpg and here's the Z-ground in use. The tip needle here is a Pico tip that is longer and has more inductance than the PMK tips I plan to use in the long term
<azonenberg>
as a result i will have to move the ground lead a bit to keep the tip and ground coplanar, but i'm respinning the probe PCB for the new tip socket anyway
<azonenberg>
the oshpark characterization board you see here is microstrip based, not CPW, which makes getting a good ground for the probe a little bit harder. It also predates me having Sonnet so the connectors are poorly matched and i'm having problems as a result
<electronic_eel>
looking forward to a probe that a) doesn't cost k$ and b) has some proper grounding accessories available
<azonenberg>
and, to top it off, has SOLT and TRL standards embedded on it
<azonenberg>
so i can de-embed the SMAs and CPW and get a measurement that's effectively only the probe itself
<electronic_eel>
yeah, that was what I thought when I saw the 3d render you posted before
<azonenberg>
Down the road i will definitely be making a high impedance active probe as well
<azonenberg>
not necessarily super high bandwidth, but since my scopes will be 50 ohm input *only*
<azonenberg>
you need some way to probe i2c and other slow stuff with pullups
<azonenberg>
So i might go backwards and use cheap active probes out to 100 MHz or so, then go passive out to the GHz :D
<azonenberg>
dont get me wrong, the transmission line probe will work fine down to DC, it just presents a fair bit of loading for something with a weak pullup
<azonenberg>
Re pricing yeah i am expecting the bom for the finished probe to be sub $50 in moderate volume
<electronic_eel>
wouldn't a differential probe for fast serial lines be more useful than a active low-freq probe?
<azonenberg>
I'm going to build one of those too
<azonenberg>
Lol
<azonenberg>
One thing at a time
<electronic_eel>
I'd expect everyone to have some cheap scope with passive 1M probes which would be enough for slow stuff
<azonenberg>
yes but my eventual goal is to make it so you don't need anyone elese's scope :p
<electronic_eel>
it just needs an interface that can be connected by scopehal
<azonenberg>
anyway in general my thought is to have 3 tiers of pricing: hobbyist/student (no support, must either prove student status via .edu email or sign a "i swear not to use this commercially, at least for now" doc)
<miek>
do you know how PMK are to deal with for small orders yet? i'm in need of accessories for old agilent/hp probes i've picked up and they look compatible :)
<azonenberg>
small business (default, we'll provide some assistance with integration/setup)
<azonenberg>
and pro (individually serialized with NIST-traceable 2-port s-parameters provided both as printed charts and downloadable files)
<azonenberg>
i think this is the best compromise from a "from each according to his ability, to each according to his needs" perspective lol
<azonenberg>
Design files will of course be open
<azonenberg>
the value-add service from the higher price tiers is support and cal
<electronic_eel>
do you plan to build them yourself, like solder the tip holders and smas and stuff, or do you plan oursourcing that?
<azonenberg>
For the first 50-100 i will probably have my tech do them in house
<azonenberg>
if there's enough demand i'll re-evaluate
<azonenberg>
re PMK, i spoke to a sales rep on the phone friday morning and she forwarded me to their US distributor
<electronic_eel>
sounds reasonable. how about order handling, shipping, international shipping with customs,... - do you plan to use some service like crowdsupply for that?
<azonenberg>
who has not yet got back to me
<azonenberg>
they sounded willing to deal with me but I don't have any details past that
<azonenberg>
For low volume i'll again do it myself. lain/monochroma have more experience actually selling widgets and i may use their company as a distributor, they apparently have an online store set up already for some of their gizmos
<azonenberg>
so they have the logistics mostly figured out afaik
<azonenberg>
btw the pricing tiers will also apply to my scopes and other test equipment as i branch into that
<azonenberg>
scopehal itself will of course always remain free and compatible with both my products and third party hardware, although i may consider selling support contracts and integration/protocol-decode-development-as-a-service if there's demand
<azonenberg>
All of the hardware products will also be fully OSH with full kicad files on github, so anybody can go build one themself. The value of buying from me is i'd get volume pricing and so even with my cut, it would likely be cheaper than building it yourself
<electronic_eel>
at work we hired several different open source maintainers to do custom addons or similar for us and this was nearly always a very good experience. so this could work out well for you and the customers
<azonenberg>
Yeah. One of the big priorities to enable that is plugin protocol decoders
<azonenberg>
I don't want to maintain a private fork of scopehal for each customer who has some in-house protocol they're making a decode for
<azonenberg>
i already have a consulting client where i'd like to use scopehal to debug their board, but they don't want the decode to go back into mainline
<electronic_eel>
re decoders: have you thought about a way to integrate sigrok as a plugin or library? they have some nice decoders
<azonenberg>
so if i can just have a private repo for the decode, build it, and stick it in /usr/share/scopehal/plugins/ i'm golden
<azonenberg>
I'm open to the possibility of someone making a shim for it, as long as it's clear the resulting binaries would end up as GPL
<azonenberg>
it needs to not be built by default and might even be a plugin in a separate repo
<azonenberg>
My biggest fear is having someone integrate scopehal into a product then get hit by a GPL lawsuit
<electronic_eel>
sigrok is gpl, so I don't see a license problem there
<azonenberg>
yes, the point is that if you link sigrok stuff into scopehal the whole system is now contaminated with GPL
<azonenberg>
this needs to be impossible to do by accident
<azonenberg>
having a separate scopehal-plugins-gpl repo or something, not part of the scopehal-cmake setup, would meet that requirement
<azonenberg>
That being said, sigrok in general seems to be targeting low speed type stuff, i2c sensors, etc. Which, while it does overlap with my goals for scopehal, isn't the main effort
<azonenberg>
My big push is on the high end doing SI work, high speed serial, etc
<azonenberg>
and the low end stuff is just along for the ride
<azonenberg>
(Not that i won't accept patches for someone making a 24c eeprom decoder etc, in fact there's already a ticket for that)
<electronic_eel>
I think it would be nice to have it all in one software. And integrating sigrok seems like a nice way to get that without too much effort
<azonenberg>
Yes
<azonenberg>
If you want to look into how you could integrate my object model with their stuff by all means
<azonenberg>
like i said i'm not opposed to it, i just want to make sure you can't accidentally GPL your whole product
<azonenberg>
sigrok drivers would be nice to have support for as well, to e.g capture from a saleae logic
<azonenberg>
But i think plugin support in general is a prereq for this
<azonenberg>
so perhaps that should be your priority?
<electronic_eel>
unfortunately I won't have time to work on this in the near future, already commited to help whitequark with Glasgow
<azonenberg>
ah
<azonenberg>
tentative thought: look for plugins in the glscopeclient binary directory (this will likely require retooling the cmake config to drop all bins and libs in a common directory rather than following the source tree layout)
<azonenberg>
~/.scopehal/plugins/
<azonenberg>
and /usr/share/scopehal/plugins/
<azonenberg>
and maybe /usr/local/share/scopehal/plugins/
<azonenberg>
at this point libscopeprotocols will just become one of N possible plugins
<electronic_eel>
wouldn't that be /usr/lib/scopehal/plugins/?
<electronic_eel>
like because .so files?
<electronic_eel>
or how would plugins link in?
<azonenberg>
Hmm yeah that would make more sense i guess
<azonenberg>
yes they will be so's
<azonenberg>
you'll have one exported function you call to register all of the protocol decoders
<azonenberg>
drivers as plugins will require some refactoring to create drivers by name, right now glscopeclient has a big if/else string matching tree
<azonenberg>
protocol decodes and measurements use dynamic creation by string names registered in a global table
<azonenberg>
drivers need to do this too, just havent implemented it yet
<_whitenotifier-3>
[scopehal] azonenberg opened issue #99: Create dynamic creation table for scope drivers and SCPI transports - https://git.io/JvrCl
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #99: Create dynamic creation table for scope drivers and SCPI transports - https://git.io/JvrCl
<_whitenotifier-3>
[scopehal] azonenberg edited issue #99: Create dynamic creation table for scope drivers and SCPI transports (depends on #68, #71, #72) - https://git.io/JvrCl
<monochroma>
i'm not impressed with what i saw of sigrok decoders, this probably varies from decoder to decoder but their JTAG one is borderline unusable
<awygle>
Why immersion silver?
<awygle>
I continue to think GPL paranoia is overblown. It'd only matter if you were selling software derived from scopehal+sigrok, not if you were using scopehal to debug a commercial board.