azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
Bird|otherbox has quit [Remote host closed the connection]
Bird|otherbox has joined #scopehal
<_whitenotifier> [scopehal] azonenberg opened issue #394: Add USB-PD CC pin protocol decode -
<_whitenotifier> [scopehal] azonenberg labeled issue #394: Add USB-PD CC pin protocol decode -
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
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
<azonenberg> maybe i'll do that tomorrow
bvernoux has joined #scopehal
juli966 has joined #scopehal
futarisIRCcloud has joined #scopehal
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #scopehal
Degi has quit [Quit: ZNC 1.7.5+deb4 -]
Degi has joined #scopehal
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_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
<azonenberg> (unless PD provides descriptors already?)
<azonenberg> We'll also want some kind of handshake to identify our specific device before applying power
<azonenberg> i figure you send some kind of message and it returns a 128-bit UUID
<azonenberg> if you see the right UUID, you know it wants +/- 7V power
<d1b2> <david.lenfesty> Closest thing to descriptors is a Manufacturer_Info message which gets you a 22-byte string to play around with
<d1b2> <david.lenfesty> I guess I'm not sure what if any settings we would need to change on the probe side
<azonenberg> Me neither :P
<azonenberg> The AKL-AD1 allows you to configure gain, in theory, but i don't ever expect to *do* this because linearity at lower gains suffers
<azonenberg> max gain has the flattest response
<azonenberg> if i want attenuation i'll add an external attenuator and still run the amp at max
<d1b2> <david.lenfesty> maybe the easiest thing would be to read/write strings to some defined registers?
<azonenberg> Strings and integers
<azonenberg> Let's define register 0 = string, probe model ID
<azonenberg> register 1 = string, probe serial number
<azonenberg> registers 2-15 reserved for future global (common to all probes) registers
<azonenberg> register 0x10 and up are model specific
<azonenberg> Sound good?
<d1b2> <david.lenfesty> yep
<d1b2> <david.lenfesty> just trying to figure out what I can fit into the 15-bit header and what needs to fit in data
<azonenberg> Is there a length field in the message format?
<d1b2> <david.lenfesty> you get no. of data objects, which is 32-bit aligned
<azonenberg> I'm thinking we will want to define a transport layer protocol that allows arbitrarily long messages
<d1b2> <david.lenfesty> yeah, if we want more than 24-byte strings we'll need that
<azonenberg> I want to be able to store s-parameters on the amp
<d1b2> <david.lenfesty> What's the longest you would want?
<azonenberg> in the extreme case? A 10K point Touchstone file off my VNA at max resolution is about 1.5 megabytes
<azonenberg> i'd use a full 32-bit field in the first message of a packet for the length
<azonenberg> as far as the Manufacturer_Info message, can we use that in some way to do an initial sanity check before dropping into our protocol?
<azonenberg> Do we want/need a VID/PID? i can probably get one from openmoko or something
<d1b2> <david.lenfesty> Yeah we need a VID
<d1b2> <david.lenfesty> I think it would just be easier to define another extra message w/ a bit in our VDM header
<azonenberg> What i meant was, before we start sending random messages we want *some* level of assurance we're talking to one of our probes
<azonenberg> (Just a VID or a PID too? never seen a VID used in isolation)
<d1b2> <david.lenfesty> VID is all that's defined in the VDM
<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
<azonenberg> Ok
<azonenberg> In other news, :(
<azonenberg> Good news - after de-embedding measured probe+amplifier response, i get a really nice eye
<azonenberg> bad news - there is a massive amount of wifi channel 11 in my measurement
<azonenberg> lain monochroma: ^
<monochroma> :O
<monochroma> is your AP on ch 11?
<azonenberg> Yeah
<azonenberg> It's either coming from the AP on the ceiling or the laptop a few feet away on the bench
<azonenberg> connected to said ap
<azonenberg> But this is a huge amount of interference. I think it's being picked up by the probe tip, after the resistors, and amplified
<monochroma> what's it like without the probe connected?
<azonenberg> Much less bad
<azonenberg> Peak at -63 dBm vs over -50 with tip connected
<monochroma> can play with foil tape around the amp
<azonenberg> I think it's coming in on the probe tip
<azonenberg> when i remove the tip from the amp it's less bad
<azonenberg> i do plan to shield the amp
<azonenberg> probably in the next pcb spin
<azonenberg> But that won't help if i have noise at the input connections
<monochroma> yeah
<azonenberg> Which is why i need to figure out how to improve noise immunity of the probe itself
<monochroma> have any lengths ~31.25mm long?
<azonenberg> Multiples thereof perhaps. Tip is ~200mm long i think?
<azonenberg> TSP vid on the AKL-PT1 just came out
<azonenberg> watching now
juli966 has quit [Quit: Nettalk6 -]
<lain> !
<d1b2> <Lambda> Nice! Pretty positive review
<azonenberg> Yeah. And I addressed the two issues he mentioned in the top comment
<azonenberg> One of which can be solved for $100 by buying the optional pogo tip :p
<azonenberg> the other is on deck to be fixed in the next pcb version