azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
<azonenberg> as far as unstable scpi stacks go, that's a global problem with just about everyone
<azonenberg> tek mso5/6 will hang for several seconds then ignore all commands for a while
<azonenberg> then recover (maybe the scpi stack reboots or something)
<azonenberg> when you give it anything evne slightly malformed
<azonenberg> or even a well formed command that at the wrong time
<azonenberg> like querying properties of a disabled channel
<azonenberg> lecroy's stack is super stable in comparison
<azonenberg> and it has a nice human readable error log too
<Stephanie> i managed to get my scope to crash every time you tried to read out too many points at a time for a bit
<Stephanie> but then it stopped doing that
<Stephanie> and the infuriating thing is i cant get it to crash again so i have no idea what the actual conditions are
<Stephanie> everything seems to be alright for now though
<_whitenotifier-5> [scopehal] RX14 forked the repository -
<_whitenotifier-5> [scopehal] RX14 opened pull request #415: Support recent CLHPP -
<Stephanie> there's a patch
<Stephanie> now to bed
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<Degi> I hope the rigol patch soon will prevent it crashing after a hundred acquisitions....
<_whitenotifier-5> [scopehal] azonenberg closed issue #412: Compile fails with recent opencl CLHPP -
<_whitenotifier-5> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-5> [scopehal] RX14 24f2ff5 - Support recent CLHPP
<_whitenotifier-5> [scopehal] azonenberg 712b616 - Merge pull request #415 from RX14/clhpp-fix Support recent CLHPP
<_whitenotifier-5> [scopehal] azonenberg closed pull request #415: Support recent CLHPP -
<_whitenotifier-5> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-5> [scopehal] azonenberg 0eebec2 - Removed cl.hpp exception define
<azonenberg> SMA test board now has a 4 GHz bandpass on it
<azonenberg> as a test
<monochroma> oooooo!
<monochroma> RF black magic
<azonenberg> Can you figure out how it works?
<monochroma> looks like an RC filter? capacitive coupling filter and stubs
<azonenberg> Not quite
<azonenberg> So the first stage is a hairpin bandpass filter. It's basically the classic "parallel coupled lines" filter but folded over on itself to form a 2D layout rather than a substantially 1D layout that's super long and skinny
<azonenberg> the idea is that each U resonates at the target frequency, and is coupled over half a wavelength to the next one
<azonenberg> sorry a quarter wavelength
<azonenberg> That already is a fairly decent bandpass for 4 GHz, but it also passes harmonics at 8, 12, 16, ...
<azonenberg> the three stages of stubs are tuned to 8, 12, and 16 GHz to notch out the harmonics
<azonenberg> so we only get the 4 GHz region
<monochroma> oic!
<azonenberg> And then past 16 GHz i didnt care because losses on oshpark pcb are too high for it to make a difference anyway :p
<monochroma> hehe
<azonenberg> I'm only going to be able to VNA this to 6 GHz but i'm gonna try and get derek from gnuradio to throw it on a higher spec VNA and see how the stubs work at suppressing the harmonics
<azonenberg> I chose 4 GHz as the passband because it was high enough frequency that it was going to produce tolerably small filters
<azonenberg> but low enough that i'd still have some room to see the stopband before my vna maxed out
<monochroma> heh
<azonenberg> With just the hairpin, the 8 GHz passband was almost as strong as the fundamental
<azonenberg> and 12/16 were just a mess, i'm not sure what happened there
<azonenberg> i think probably some other dimension of the structure - perhaps the spacing between hairpins - was resonating
<azonenberg> which makes sense considering that the 16 GHz notch stub at far right is about the same size as the gap across the U of the hairpin
Tost has joined #scopehal
<Degi> How much do the stubs capacitively load it at 4 GHz?
<Degi> Oh, it has like -6 dB at 4 GHz
<azonenberg> Yeah. That's mostly from the tiny capacitance i think
<azonenberg> I couldnt make them any closer on oshpark design rules
<azonenberg> the hairpin was like that originally
<azonenberg> the stubs dont make it any worse really
<Degi> Hm, I mean the 8/12/16 GHz stubs
<azonenberg> There's a small amount of insertion loss but not much
<azonenberg> more importantly that loss is pretty flat
<_whitenotifier-5> [scopehal] azonenberg opened issue #416: Add SMBus protocol decode -
<_whitenotifier-5> [scopehal] azonenberg labeled issue #416: Add SMBus protocol decode -
<_whitenotifier-5> [scopehal] azonenberg pushed 4 commits to master [+0/-0/±5]
<_whitenotifier-5> [scopehal] azonenberg ae4f58b - eSPI: Implemented parsing of Get OOB message type. See #407.
<_whitenotifier-5> [scopehal] azonenberg db6cb52 - Implemented merging of SMBus transactions. See #407.
<_whitenotifier-5> [scopehal] azonenberg e5480c3 - Implemented merging of get-status with get-virtual-wire packets. See #407.
<_whitenotifier-5> [scopehal] azonenberg c0c6f55 - eSPI: Added PC_AVAIL and NP_AVAIL bits to status column. See #407.
juli9610 has joined #scopehal
<_whitenotifier-5> [scopehal-apps] tomverbeure opened issue #315: SPDIF TOSLINK scope capture -
<_whitenotifier-5> [scopehal] azonenberg commented on issue #289: S/PDIF protocol decode -
<_whitenotifier-5> [scopehal-apps] azonenberg commented on issue #315: SPDIF TOSLINK scope capture -
<_whitenotifier-5> [scopehal-apps] azonenberg closed issue #315: SPDIF TOSLINK scope capture -
deanforbes_ has quit [Read error: Connection reset by peer]
kc8apf has quit [Read error: Connection reset by peer]
deanforbes_ has joined #scopehal
kc8apf has joined #scopehal
wbraun has quit [Ping timeout: 276 seconds]
wbraun has joined #scopehal
<d1b2> <mubes> Anyone who knows the SWD you know why the bits were slipped to align with the Target Reads rather than Host Writes? All the ARM documentation is Host-Write aligned and it's much more natural feeling. Here it is TargetAligned;
<d1b2> <mubes> ...and HostAligned;
<d1b2> <mubes> The host-alignment is a one line change and it was already in there and commented out, so it was obviously a concious decision to go this way, but personally I'd rather align with the ARM documentation, especially when I'm bug-hunting, which looks like this;
<d1b2> <mubes> It doesn't affect the decode, only the relative positioning of the decode onscreen.
<azonenberg> mubes: howabout making it configurable?
<azonenberg> add an enum parameter to the decode, make it default to host aligned
<azonenberg> i dont have strong feelings one way or the other though
<azonenberg> if you think it makes more sense to always be host aligned that works too
<d1b2> <mubes> I've never seen it shown target-aligned (although it's sampled at the rising edge in the middle of the bit time, obviously). I personally think it's confusing but just wondered if there were other arguments....whoever wrote this (you?) obviously considered making it host-aligned because the line to do it is there but commented out...for 'normal' protocols you'd obviously do it that way, but ARM are a rule until themselves 😕
<d1b2> <mubes> I'll do a patch
<azonenberg> yeah i probably just wasnt THAT familiar with the arm convention
<azonenberg> i'm pretty sure i wrote this decode
<d1b2> <mubes> fair enough. I'll move it to 'arm convention' as opposed to 'normal' then 🙂
<azonenberg> i'll be honest you're probably the first person to actually use the SWD decode seriously
<azonenberg> Wouldn't surprise me if you find other issues too
<azonenberg> But hey, glad to see it's useful :)
<d1b2> <mubes> Yeah, there are a couple of hiccups. Most serious outstanding one being that it doesn't recognise line resets
<d1b2> <mubes> ...but it sorts itself out in the end
<azonenberg> Feel free to send patches for any such fixes. it would be nice to recognize resets and maybe even decode the reset sequence as an event in the decode stream
<azonenberg> as upper layer decodes might want to know the link was reset
<d1b2> <mubes> So you get this, which is a bit messy;
<azonenberg> very likely i just never saw a reset in the test waveforms i wrote the decode from
<azonenberg> and completely missed it
<d1b2> <mubes> Oh, I'
<d1b2> <mubes> ve got no problem generating resets 🙂
<azonenberg> lol
<d1b2> <mubes> It's the other bloody stuff I can't get my head around
<azonenberg> Meanwhile, here I am deep enough in Intel specification hell that I'm trying to figure out how to report documentation errors
<azonenberg> i spent way too much time looking at the wrong figure
<azonenberg> because the documentation for a particular bus command references figure 37 when it should say figure 35
<azonenberg> so of course everything wasn't lining up
<d1b2> <mubes> At least at ARM there are eventually humans you can talk to who design the stuff. Intel, I'm not so sure.
<azonenberg> I have successfully reported errors in coresight manuals before
<d1b2> <mubes> AMD were great for easy access back in the day (29K bitslice stuff), but you had to constantly stop yourself pinging design authority and keep it for special occasions.
Tost has quit [Ping timeout: 240 seconds]
<azonenberg> When I was working on the GreenPak HDL toolchain back in the day
<azonenberg> I reported so many errors that eventually i had direct access to their datasheet engineers
<d1b2> <mubes> Ha ha, @zyp has just started a love affair with those chips
<d1b2> <mubes> ...he managed to wangle two onto our board
<azonenberg> I mean they're handy chips
juli9610 has quit [Quit: Nettalk6 -]
<d1b2> <mubes> for sure, I was impressed. The dinky linear regulators are great for the price
Stephanie is now known as Stephie
<_whitenotifier-5> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier-5> [scopehal] azonenberg b6e7607 - eSPI: Implemented wait states in response. Added parsing of Put I/O Write Short command. See #407.
<_whitenotifier-5> [scopehal] azonenberg 781cfca - eSPI: Added parsing of split completions. Can now merge I/O write completions with the original request. See #407.
<azonenberg> for something whose name implies it's just a variant of SPI
<azonenberg> eSPI is... quite complex
<azonenberg> and the best part is it's *not* even spi
<azonenberg> they have a 2-cycle bus turnaround between read and write
<azonenberg> which is a byte long in quad mode, but in x1 mode is only two bits long
<azonenberg> so a byte oriented spi parser can't read it :p