azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
sam210723 has quit [Read error: Connection reset by peer]
sam210723 has joined #scopehal
apo has quit [Quit: apo]
apo has joined #scopehal
Stephanie has joined #scopehal
Stephie has quit [Ping timeout: 260 seconds]
Tost has joined #scopehal
apo has quit [Quit: apo]
apo has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
bvernoux has joined #scopehal
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #scopehal
<azonenberg> Score! Just arranged a refurb lecroy RP4030, their high offset power rail probe
<azonenberg> for over $1K under MSRP
<monochroma> :O
<azonenberg> $2845 MSRP, $1991 refurb price, then i had a bit of trade-in credit left over from the HDO9204
<azonenberg> so i paid $1599 plus tax and shipping which came out to about $1770
<azonenberg> It comes with solder-in tips as well as MCX and U.FL leads
<azonenberg> So i'm probably going to start putting MCX and U.FL test points on my boards for power rail monitoring
<bvernoux> ha great
<bvernoux> DO you remember the BNC to SMA PN you are using ?
<bvernoux> Does it is => 1868-1192-ND‎
<bvernoux> Rosenberger
<bvernoux> ‎ => 32K151-S00L5 ‎
<bvernoux> as it is only 10GHz
<bvernoux> I have found an other one
<bvernoux> 314-1192-ND‎
<bvernoux> Mueller Electric Co
<bvernoux> ‎BU-P4289‎
<bvernoux> which is up to 12.5GHz
<bvernoux> 12.4GHz ;)
<bvernoux> which is less expensive than Rosenberger
<azonenberg> I believe I'm using that 10 GHz rosenberger
<azonenberg> realistically, the highest BW i've seen anyone use BNC for is 8 GHz
<bvernoux> yes ;)
<bvernoux> it was mainly the other one is cheaper
<bvernoux> but I do not know if it is robust like rosenberger ...
Tost has quit [Ping timeout: 246 seconds]
maartenBE has quit [Ping timeout: 240 seconds]
maartenBE has joined #scopehal
m4ssi has joined #scopehal
m4ssi has quit [Client Quit]
<azonenberg> Care package from Digilent came in
<d1b2> <mubes> That was quick! Siglent mso codes arrived too.
<azonenberg> Excellent
<azonenberg> everything working? did you figure out how to feed inputs to it?
bvernoux has quit [Quit: Leaving]
Tost has joined #scopehal
bvernoux has joined #scopehal
<bvernoux> woo crazy auction
<bvernoux> 1471 ETH !!
<d1b2> <mubes> Yeah, I've got a bodgeboard that will give me signals and they'll get a real digital adaptor to us sometime next which time it will hopefully all be done and ready for test.
<azonenberg> Excellent
<d1b2> <mubes> They also provided SENT and MANCH codes so will fold the triggers in for those too...if I've got to do a full test it might as well be on the whole thing.
<azonenberg> Great
<azonenberg> We need to write trigger classes for those protocols
<azonenberg> but you should be able to figure out how to do that
<azonenberg> the only thing to be aware of is that in scopehal/scopehal.cpp there's one line to register the new trigger class in the table
<d1b2> <mubes> Yeah, I'm getting a feel for how it all holds together.
<azonenberg> on that note, right now trigger settings are not saved to .scopesession files
<azonenberg> that has been on my agenda for a while, along with some other tweaks to the file format
<azonenberg> but i've been too busy w/ other stuff to touch it
<azonenberg> Is the code reasonably easy to learn your way around? At some point i really want more developer documentation
<azonenberg> there isn't much of that at the moment, just the comments. all of the formal documentation is end user focused
<d1b2> <mubes> I had a cursory look at the scpi for the other scopes too and I suspect it's quite different (probably different provenance)....once this is done we might need to borrow one of those from somewhere for a week or two....but that is later.
<azonenberg> Yeah once we have proven results on the SDS2000X+ series, we should be able to arrange for testing and/or loaner hardware for other instruments
<d1b2> <mubes> I think moving things into directories might help a lot (scope drivers, triggers etc) cos that makes it easier to see what to finch from, but if it fragments too much it doesn't really help.
<azonenberg> Yeah that might be worth looking into at some point. Is the overall object model reasonable though?
<d1b2> <mubes> For developers I personally prefer small markup files in each directory to say what they're for.
<azonenberg> it took me a while to come up with this trigger model but it seems decent so far
<azonenberg> also i forget if i mentioned but I have some test waveforms for MIL-STD-1553 now
<azonenberg> i have one more decode to bang out that i need for $dayjob before i can get to that
<d1b2> <mubes> Haven't grokked enough of it to criticise, but I can work on one part reasonably independently, which implies the inter-module coupling isn't too bad.
<d1b2> <mubes> I can generate MANCH easily enough but will have to dig around to see if I've got any real SENT sources.
<azonenberg> Yes, keeping the codebase modular was a big design goal
<azonenberg> glscopeclient is not nearly as modular as i'd like
<azonenberg> it needs a major refactoring but i havent had the time to plan it out yet
<azonenberg> libscopehal is much nicer to work on in that regard
<d1b2> <mubes> Close to putting Orb to one side for a week or two (which I need to do to get perspective back) so that'll be a good chance to get this done.
<azonenberg> BTW, we need a manchester decode in libscopehal
<azonenberg> So if you're going to make some manchester test waveforms for trigger testing, and have some time, maybe write a decode too?
<azonenberg> the hard part with manchester will be figuring out how to do sync
<azonenberg> Maybe look at how siglent's UI does it? and google around, see if you can find docs from lecroy/tek/keysight
<azonenberg> I'm not saying blindly copy them, but learn from their design
<azonenberg> Same thing with SENT. It's been on my list of decodes to write for a while, but i haven't actually done it because i haven't had any signal sources
<azonenberg> so if you find something, or rig up a bitbanged signal source, now we'll have test data for a decode
<d1b2> <mubes> Manch is pretty easy to create using Arm SWO.
<azonenberg> I was gonna use 10baseT
<azonenberg> i have waveforms for that already
<azonenberg> in fact i have a working manchester decode as part of the 10baseT decode already
<d1b2> <mubes> Or coded infrared etc. Yeah there are loads of sources at different speeds.
<azonenberg> the only thing stopping me from pulling it out into its own filter is figuring out how to do sync
<azonenberg> the implementation in the 10baseT decode i think actually relies on differential voltage
<azonenberg> it works on the analog waveforms and going from differential zero to significant amplitude is the sync
<d1b2> <mubes> The sync mechanism is pretty independent of the signalling afaik. I'll look how the scope does it as a starting point.
<azonenberg> well *bit* sync is well defined
<azonenberg> *byte* sync is not
<azonenberg> especially if there's noise at the start of the packet
<_whitenotifier-5> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier-5> [scopehal] azonenberg e0b8547 - Continued work on eSPI decode
<_whitenotifier-5> [scopehal] azonenberg 552411f - Continued work on eSPI decode. Now works on raw signals instead of base SPI bus because eSPI needs weird 2-SCK cycle bus turnaround instead of something sane. See #407.
<_whitenotifier-5> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-5> [scopehal] azonenberg 8f60651 - eSPI: correctly detect x1 vs x4 mode via heuristics. See #407.
<d1b2> <mubes> Scopehal saves me real-world time already....had a clashing bit where I was changing drive on the wrong edge, but couldn't easily see where in the protocol. Scopehal made that rather easy to find;
<d1b2> <mubes> ('scuse the probing)
<azonenberg> Nice
<azonenberg> And yes, one of the things i want to make easy in general is finding things like CRC errors in upper layer protocols
<azonenberg> then drilling down to find the PHY layer problem causing it
<d1b2> <mubes> Yes, I already saw what happens when you add a MEMAP to this....very handy
<azonenberg> BTW, longer term i plan to support integrating FPGA based logic analyzer IP cores with external scopes and trigger cascading
<azonenberg> so you can do full-system debug of on an off chip stuff
<azonenberg> most of the ground work is there already
<d1b2> <mubes> Well, I'm figuring we'll bolt the digital channels of Orb into this pretty soon.
<azonenberg> remind me, what is orb again?
<d1b2> <mubes> CORTEX Debug and Trace
<d1b2> <mubes> (FPGA Based)
<azonenberg> oh, nice
<azonenberg> Yeah, i'm all for developing more complex system level debug tools
<d1b2> <mubes> but @zyp got enthusiastic and added some digital I/o too
<azonenberg> e.g. being able to build something on top of the mem-ap decoder to be able to go all the way up to register names/fields rather than just raw pointers
<azonenberg> maybe using SVDs if available
<azonenberg> so you can debug programming algorithms by seeing what flash registers they poke
<d1b2> <mubes> yep, or down to corrolated analog signals or across to s/w trace outputs
<azonenberg> Yep
<azonenberg> Exactly
<azonenberg> Or have a protocol error inside FPGA logic triggering an analog scope looking at phy-layer signals
<azonenberg> to find the source of a corrupted data bit
<azonenberg> There's lots of potential
<d1b2> <mubes> yup. The only issue with all of this is that very quickly you end up with a lot of data flying around
<azonenberg> And this is why my lab is wired for 10GbE everywhere :p