azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-cmake, https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal | Logs: https://freenode.irclog.whitequark.org/scopehal
_whitelogger has joined #scopehal
maartenBE has quit [Ping timeout: 250 seconds]
maartenBE has joined #scopehal
m4ssi has joined #scopehal
andres2 has joined #scopehal
<andres2> Hello there. It's me again (I came here a couple of days ago to get an intro to scopehal)
<andres2> I am working on completing the Rigol implementation
<andres2> It works quite well. Now I am trying to understand the protocol decoders (I took I2C as a reference to hopefully add CAN protocol)
<andres2> azonenberg Is it possible to use two threshold channels as inputs to a serial decoder?
_whitelogger has joined #scopehal
<azonenberg> andres2: yes, in fact that's normally how you'd do it
<azonenberg> down the road i plan to add some UI glue so that when you pass analog inputs to a decoder, it will create a 50% threshold channel for you automatically
<azonenberg> which you can then tune the threshold of if you want
<azonenberg> but for nowm you have to do the type conversion explicitly
<andres2> I see. just to be clear, I tried to add I2C filter from the gui with two thresholds and I had the option disabled
<andres2> When you say that's normally how you'd do it you mean in the code or the ui?
<azonenberg> andres: when you right clicked to add the trace
<azonenberg> what did you right click on?
<azonenberg> the context menus are strongly typed
<azonenberg> it grays out decoders that are not valid for what you right clicked on
<azonenberg> if you right click on the analog waveform and not the digital overlay, it won't let you see decoders that expect digital inputs
<azonenberg> andres2: *
<azonenberg> So you need to right click on one of the threshold traces to see the i2c filter
<azonenberg> Make sense? This isn't quite as intuitive as i originally wanted apparently :)
<azonenberg> (it doesn't help that i don't have any end user documentation yet... any interest in helping to write a user manual?)
<andres2> Oh, I thought the context menu was the same for the entire screen, ok I see.
<andres2> I don't recall where I clicked actually, I'll try later
<azonenberg> no everything is highly sensitive to exactly what you right clicked on
<azonenberg> analog waveform, decode overlay, horizontal axis, vertical axis, etc all do different things
<azonenberg> for example if you left click on the Y axis you set the trigger point, if you click and drag the X axis you shift the horizontal position of the waveform display
<azonenberg> (there is currently no UI for setting horizontal trigger offset within the capture)
<azonenberg> If you're doing a multi-layer protocol decode like USB, you have to right click on each of the previous layers when adding the decode for the next one up
<azonenberg> eventually there will be scripted actions that bring up an entire multilayer decode stack straight from analog signals, but that's not there yet
<azonenberg> internally, the whole decode architecture is a filter graph and right now that is very explicit
<azonenberg> To be more specific, when you right click on a waveform it will gray out any decoder that doesn't report that the selected waveform is valid for its first input
<azonenberg> since some decoders, like "AC couple" which just measures and removes a DC bias on a waveform by subtracting the average, don't even take any configuration options from the user so they are created instantly with no configuration dialog
<azonenberg> Again, this should probably be documented better (well, it should be documented AT ALL)
<andres2> azonenberg: FYI, my scope doesn't respond / responds with "command error" if the commands are sent too quickly, so I implemented a bool return for the zero-return-data commands and a break in receiption if "command error" is received. Would you mind taking a look at a patch before I submit a PR?
<andres2> I'll create my fork in a couple of hours
<azonenberg> Sure. I'm about to leave for $dayjob (it's 7am where i am) so i'll be on the road and AFK for a bit
<azonenberg> i'll be on azonenberg_work in 2-3 hours and join this chan when i get to the office
<azonenberg> I fully expect that as we add support for more hardware, we'll find assumptions that initially turned out to not be valid that will require changes to the APIs
<azonenberg> like i said, i did all initial development on LeCroy gear because it was all i had
m4ssi has quit [Remote host closed the connection]
bvernoux has joined #scopehal
<azonenberg> bvernoux: fyi, i plan to do another respin of my probes in probably early January
<azonenberg> with actual controlled impedance
<bvernoux> ha great
<azonenberg> and a bit more field solver work to model the tips
<bvernoux> do you have found some new hint to have even better probe ?
<azonenberg> i did some early testing vs the low-end Pico probe
<azonenberg> need to poke more, but i think it's better than i thought it was
<bvernoux> ha great and the comparison ?
<azonenberg> I'll do more analysis when i get a chance
<azonenberg> i dont have final results, waiting on some more hardware to come in
<azonenberg> the Pico probes have a superb pogo pin tip
<azonenberg> i want to see if i can replicate something like that
<bvernoux> ha great
<azonenberg> maybe even use exactly that tip
<bvernoux> yes we can buy just their pogo pin IIRC
<bvernoux> for something like 10USD
<azonenberg> yeah just have to figure out how to mount it and work out a ground better than what i have now
<azonenberg> I also found that pico and lecroy OEM the same probe holders lol
<bvernoux> hehe nice
<azonenberg> one is blue and one is black and the brand mark is different, but they're IDENTICAL
<azonenberg> right down to tooling marks on the injection molding die
<bvernoux> On my side I have not done more test on my Auburn Tech 12GHz Probes
<azonenberg> literally they are the same part off the same production line
<bvernoux> as I need a good PCB Test Fixture
<bvernoux> yes same fab just different sticker
<bvernoux> what a shame for such big companies
<bvernoux> I'm planning to build a 20GHz generator ;)
<azonenberg> Nice
<bvernoux> based on latest TI chipset which is amazing
<azonenberg> and well, i thought that they would be "basically the same thing"
<azonenberg> but that pico's would be an independently made clone
<azonenberg> but no, they actually came from the same factory lol
<bvernoux> very interesting
<bvernoux> for my sig generator it will be based on lmx2594 but adapted to lmx2595
<bvernoux> based on Harmon Instruments testpcb-lmx2594
<bvernoux> it can be built cheaply with some samples
<bvernoux> as anyway I do not plan to sell such board it is mainly for my own use to have a Sig Generator (nice sweep) from 10MHz up to 20GHz
<azonenberg> how flat do you think you can get?
<bvernoux> like Harmon Instruments version ;)
<bvernoux> but up to 20GHz ;)
<bvernoux> probably using flexpcb
<bvernoux> as they are very nice for freq > 10GHz
<bvernoux> anyway traces will be ultra short as all is done in the chipset
<azonenberg> Thoughts on flex + stiffener for a transmission line probe?
<azonenberg> nvm misunderstood what you were saying
<bvernoux> yes it definitely required stiffener
<bvernoux> the idea is to use flex because it has very nice Er vs FR4
<azonenberg> My tentative plan is to use FR408HR for the handheld probe
<bvernoux> like seen on Harmon Instruments VNA tests
<azonenberg> i'm also going to re-engineer the probe enclosure
<bvernoux> ha nice
<azonenberg> instead of a clamshell it'll be a single 3d printed piece with a cavity inside it
<bvernoux> with something with aluminium ?
<azonenberg> material TBD
<azonenberg> still thinking plastic for now but metal connecting to a shield is plausible
<azonenberg> Shapeways offers SLM aluminum alloy
<bvernoux> but IIRC they are very expensive today
<azonenberg> it's like SLS, but fully liquefies the metal so you don't get as much voids as SLS
<bvernoux> compared to "plastic"
<azonenberg> Yes, it will cost more
<azonenberg> But for a premium quality probe, might be worth it
<bvernoux> yes to be compared with cheap plastic case ;)
<bvernoux> if you are interested by Harmon LMX2594 https://gitlab.com/harmoninstruments/testpcb-lmx2594.git
<bvernoux> there is some nice measurements
<bvernoux> ferrite bead are really better than resistor for output power in dBm
<bvernoux> with a gain of about +5dBm
<bvernoux> gain linearity over frequency is not amazing but can be compensated by a good sw table
<bvernoux> in order to generate a very nice sweep freq from 10MHz to 15GHz (or even 20GHz with LMX2595)
<bvernoux> cool lmx2594 vs lmx2595 have exactly same pinout ;)
bvernoux has quit [Quit: Leaving]