electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
<azonenberg>
Hmmm so i'm wondering if maybe it would make sense to, before starting work on the AKL-AD3
<azonenberg>
make a usb power version of the AKL-AD1 first
<azonenberg>
Since at this point i'm reasonably happy with it. It's not *perfect* but i think it's good enough for a first iteration differential probe
<azonenberg>
the main improvement i want to make at this point is an EMI shielded enclosure
<azonenberg>
And if i'm respinning the AD1 with shielding, it seems logical to test out the usb power in the same board rev
<azonenberg>
The other thing i can start work on soonish is a silicone mold for casting around the AKL-PD1 so it's nice and rubberized like the PT2 will b
<azonenberg>
be*
<azonenberg>
If we then build a standalone 12V based power conversion module for the probes, I might actually be able to start thinking about a production run of the AD1
<azonenberg>
That might end up being the next project I take to completion after the PT2 (which is hopefully going to be doing small run production in march and ramping up in april)
<azonenberg>
I feel like even if it's pretty imperfect, an open hardware active diff probe would sell a few units
<azonenberg>
So far it looks like the AD1 amplifier is pretty good but response of the PD1 tip may need to be tuned. I still haven't VNA tested the PD1 yet so that's probably next on my to-do list
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JtVqY
<_whitenotifier>
[scopehal] azonenberg 10068a3 - FFTFilter: fixed improper management of OpenCL handles during creation
<d1b2>
<david.lenfesty> okay I'm at the point where I think I need to start considering the protocol in our vendor messages
<d1b2>
<david.lenfesty> Basically the only constraint is we get 0-6 32-bit data objects to work with, and 15 bits of a header to do whatever we want with.
<d1b2>
<david.lenfesty> There are structured VDM headers w/ more constraints and stuff but I don't see an advantage to those
<azonenberg>
So i guess the first thing we'll want is framing to return an arbitrarily long string (possibly several messages in length)
<azonenberg>
(string or block of binary data)
<azonenberg>
This will be used by the scope to query model number, serial number, maybe even a touchstone file with calibrated response data
<d1b2>
<david.lenfesty> we get 15 bits "free" address for our protocol
<d1b2>
<david.lenfesty> I was thinking use 8 for the register address
<d1b2>
<david.lenfesty> 1 for r/w
<azonenberg>
Sounds good
<azonenberg>
then maybe one bit for start or continuation
<azonenberg>
if start, we have header data in the body
<d1b2>
<david.lenfesty> 1 for the UUID idea (If that bit isn't set and there isn't exactly the correct UUID)
<azonenberg>
a VID/PID is probably enough. i didnt realize that PD used them
<d1b2>
<david.lenfesty> man I'm bad at wording things right now
<d1b2>
<david.lenfesty> I think they're only used in messages associated with vendor data
<d1b2>
<david.lenfesty> like the vendor-specific messages and vendor info
<d1b2>
<david.lenfesty> sorry edited that to say "like the vendor-specific messages and device info"
<azonenberg>
What i mean is
<azonenberg>
we have a means to send an initial vendor info message to the probe
<azonenberg>
verify it's one of our probes
<azonenberg>
then proceed from there
<azonenberg>
I figured we'd have a register that stored a 'requested power voltage' level somewhere
<azonenberg>
and we'd check that had the right value before turning it on
<d1b2>
<david.lenfesty> Took another look at Manufacturer_Info, on second thought yes it is better to use that vs. going straight to VDM.
<d1b2>
<david.lenfesty> Specifically that means the host sends a Get_Manufacturer_Info message and the probe responds w/ Manufacturer_Info, that has VID, PID, and a string we can do whatever with
<d1b2>
<david.lenfesty> probably returning the probe model no. is the best for that string
<azonenberg>
Yeah
<azonenberg>
Then once we've done that we'll drop into our VDM protocol
<azonenberg>
query the full serial numbers etc
<azonenberg>
figure out the actual voltages the probe wants
<d1b2>
<david.lenfesty> requested voltage should probably be register 2 then?
<d1b2>
<david.lenfesty> because we're going to want that for every probe
<azonenberg>
Yeah. Say have that be one 32-bit field, with two 16-bit ints in it
<azonenberg>
for requested positive and negative supply voltages
<azonenberg>
in millivolts, unsigned
<d1b2>
<david.lenfesty> Probably easiest just to support 32-bit ints and strings
<azonenberg>
for now, every probe must report 0x1b58 for both
<d1b2>
<david.lenfesty> and how those are packed is up to the register
<azonenberg>
yeah that was my thoguht
<azonenberg>
i just mean in this particular register
<azonenberg>
it'll be two uint16s with positive and negative voltages
<d1b2>
<david.lenfesty> yeah that's what I was assuming, just clarifying
<azonenberg>
How about before we drop down into code
<azonenberg>
you start writing up a spec for this?
<azonenberg>
sketch it out in markdown under doc/ on the starshipraider repo
<d1b2>
<david.lenfesty> 👍
<d1b2>
<david.lenfesty> I'll still keep it in my FW branch