<azonenberg>
Degi: The characterization board lives under starshipraider right now which is where i've put most of the random accessory stuff like probes
<azonenberg>
I have yet to decide if i'm going to put the whole scope under there or make its own repo. starshipraider was originally intended to be a purely digital project but it may be turning into an umbrella project for multiple pieces of hardware
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
_whitelogger has joined #scopehal
<azonenberg>
So, trying to figure out where to look for plugins
<azonenberg>
so far i have... glscopeclient binary directory
<azonenberg>
~/.scopehal/plugins/
<azonenberg>
/usr/lib/scopehal/plugins/
<azonenberg>
/usr/local/lib/scopehal/plugins/
<azonenberg>
(obviously will need improvement when we start thinking about windows support)
<azonenberg>
so i think i have plugin support working
<azonenberg>
I just need to actually build a plugin to test that it works :p
<monochroma>
:D
<_whitenotifier-3>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±5] https://git.io/JvMYc
<_whitenotifier-3>
[scopehal] azonenberg c31ff30 - Refactoring: moved AddDecoderClass into ProtocolDecoder.h
<_whitenotifier-3>
[scopehal] azonenberg 4ad0463 - scopehal: initial plugin support
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvMYW
<_whitenotifier-3>
[scopehal-apps] azonenberg closed issue #16: Add some kind of plugin interface for loading new protocol decoders and measurements from additional libraries - https://git.io/JvEt7
<_whitenotifier-3>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JvMYl
<_whitenotifier-3>
[scopehal-cmake] azonenberg 93863c1 - Updated submodules for plugin support
<azonenberg>
Going to test this a bit more thoroughly by writing a protocol decoder in a plugin that does something nontrivial
<azonenberg>
So far it looks goo though
<azonenberg>
good*
_whitelogger has joined #scopehal
lain has quit [Ping timeout: 268 seconds]
lain has joined #scopehal
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tnt>
Is there a new format for the scope connection ?
<tnt>
nm, figured it out.
<tnt>
I tried saving session and it just crashes/hangs.
<tnt>
Ah, got it ... it hangs there because it tries to query the coupling (and other config I guess) from the 'EX' channel where this is not supported.
<tnt>
If I remove the EX channel all together from the driver, it works.
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
<azonenberg>
tnt: look at the lecroy driver
<azonenberg>
don't remove the external trigger channel, but make it return default values
<miek>
also, i still want external trigger! :p
<tnt>
Sure, I wasn't suggesting it was a proper fix, I just wanted to make sure that was indeed the issue :p
<azonenberg>
Yeah. I had the lecroy driver crash for the exact same reason when i first implemented file save
<azonenberg>
basically the problem is that ext trig normally has mostly the same AFE as a signal input with a few small changes
<azonenberg>
but sometimes not all of the commands work the same way
<azonenberg>
e.g. no ac coupling support
<azonenberg>
it makes sense to treat it as a channel most of the time
<monochroma>
azonenberg: are you able to view your ext input as a channel like on ours?
<azonenberg>
No
<azonenberg>
that option doesnt exist on my scope
<azonenberg>
your DDAs are weird
<azonenberg>
i mean its a useful debug capability to know what your trigger looks like, dont get me wrong
<azonenberg>
but it's odd
<azonenberg>
Not something i've ever seen before
<monochroma>
yeah, that's what i was curious about, how common that was
<azonenberg>
Very unusual. Probably won't be adding scopehal support for that checkbox unless you think there's a good reason?
<azonenberg>
if you really need it you can rdp into the scope and click it :p
<monochroma>
yeah that's what i usually do
<tnt>
The 1000X from keysight actually have a ext input that you can dispay on screen and even use as general purpose input for serial decode and stuff.
<azonenberg>
Nice
<azonenberg>
Yeah that's the sort of reason i wanted ext to be considered a channel
bvernoux has joined #scopehal
<tnt>
azonenberg: that screenshot isn't usb 2.0 it's just random data to test the ice40 IOs.
<azonenberg>
ah ok
<azonenberg>
my point stands though, i'd love for someone to write a usb 2.0 decoder :p
<tnt>
Hehe, yeah. I don't even know if in usb 2.0 the bus stays in high-speed mode all the time or does it transition at each packet ?
<azonenberg>
It transitions i think. there's a "chirp" of 32 bits at high speed to provide time for CDR lock iirc
<azonenberg>
then flatlines in between
<azonenberg>
3.0 moves to a sane full duplex design which is 8b/10b code with continuous idles between each frame
<azonenberg>
its funny, usb 2.x was like the last holdout of the half duplex I/O buses
<azonenberg>
(i2c doesnt count, i mean peripheral buses)
<azonenberg>
half duplex is a nightmare and needs to die :p
<azonenberg>
Now we just need DDRx to move to source synchronous full duplex, or better yet high speed serial with clock recovery
<azonenberg>
having the sstl lines stupidly tightly matched and changing direction each read really feels like a relic from the past. like, ATA-133 -> SATA happened decades ago
<azonenberg>
PCI -> PCIe
<azonenberg>
why has ram stubbornly resisted this?
<azonenberg>
what i dream is a scalable DRAM I/O interface that can range from a tiny chip with power, ground, one tx diffpair, and one rx diffpair all the way up to something competitive with hybrid memory cube
<azonenberg>
same protocol, different number of lanes
<azonenberg>
so you can hang one lane off of some small soc or a whole bunch off of a big GPU etc
<tnt>
GDDR6 is 18Gbps per pin already
<bvernoux>
per pins probably means differential ;)
<bvernoux>
but anyway it is impressing and challenging for PCB routing ...
<tnt>
nope
<tnt>
AFAIT it's still single ended
<bvernoux>
single ended i/o ?
<bvernoux>
woo
<bvernoux>
I was thinking it was diff now
<Degi>
Ah yes, RAM kind adoes that
<bvernoux>
especially for noise ...
<Degi>
I mean as long as the chip is real close
<azonenberg>
yeah GDDRx is ridiculous
<Degi>
I think why RAM has no serial with clock recovery is cause DDR parallel interfaces are cheaper
<azonenberg>
Degi: i know, and i dont like it
<azonenberg>
they make the controller nightmarishly complex in order to keep the actual dram chips cheap
<Degi>
Yeh
<azonenberg>
heck, slap some pam4 serdes ip's on there for ram :p
<bvernoux>
Enhancing ADC resolution by oversampling
<bvernoux>
PicoScope use that
<bvernoux>
Some high end ADC do that internally ...
<bvernoux>
It is done on AirSpy SDR# also
<azonenberg>
yeah lecroy has the same thing, they call it ERES (extended resolution) mode
<bvernoux>
it is not new anyway but very nice to have
<Degi>
Hm a TDR should be possible with less components than FREESAMPLE since you only need one comparator since you know when the pulse is sent
<azonenberg>
i built a tdr using this exact sampling architecture
<bvernoux>
anyone know if Tektronix 11801B TDR are good ?
<azonenberg>
freesample is basically that RX stage plus a more precise delay line (adding the HMC856 vs using the LMK04806's 25ps taps)
<azonenberg>
and a trigger/cdr circuit
<bvernoux>
they are pretty old but affordable
<azonenberg>
which is entirely redundant if you know when the pulse was sent
<bvernoux>
used ones of course ;)
<Degi>
Huh that'd be useful for PCIe analysis and maybe radar stuff
<Degi>
Why can octopart search comparators by "natural thermal resistance" and wh
<bvernoux>
One of the best for my use case is Tektronix MDO4104-6 Oscilloscope Mixed Domain ;)
<bvernoux>
A must have to mix Oscilloscope with Spectrum Analyzer(6GHz)
<Degi>
Hm is it possible to use a spectrum analyzer similar to a sampling scope?
<Degi>
Like if you had a sufficiently stable clock and IQ data, it should be possible to transform that into a time domain signal, as long as you have a repetitive time domain signal...
<azonenberg>
you'd need phase lock to the signal somehow
<azonenberg>
not likely to be practical i think
<Degi>
Shouldn't it be sufficient to have a sufficiently stable oscillator?
<Degi>
Hm on the other hand, mixers have some harmonic generation etc.
<miek>
i guess it's similar to time domain modes on VNAs?
bvernoux has quit [Quit: Leaving]
LeoBodnar has quit [Ping timeout: 246 seconds]
futarisIRCcloud has quit [Ping timeout: 246 seconds]