<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 ;)