azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<azonenberg> dingwat: yes
<azonenberg> i unfortunately didnt get a chance to build out as much of the feature set as i wanted
<azonenberg> i've been super busy, the scope is in a box about to go back to them since they needed it for other stuff
<azonenberg> But basically we had trouble getting it to work reliably
Degi has quit [Ping timeout: 252 seconds]
Degi has joined #scopehal
<dingwat> Yeah :) I don’t think the dude responding to me knew that
azonenberg has quit [Ping timeout: 258 seconds]
azonenberg has joined #scopehal
bvernoux has joined #scopehal
<d1b2> <johnsel> Sorry I couldn’t be more help with it
<azonenberg> dingwat: anyway, at this stage i would not recommend using a tek for high speed pc interfaced applications
<azonenberg> their scpi stack is just too unstable
<azonenberg> we had the dev scope lock up and need power cycling multiple time
<d1b2> <david.rysk> which tek models have you worked with?
<azonenberg> we segfaulted the scope app once and had it go unresponsive to the point the touchscreen didnt do anything more times than i can count
<azonenberg> This dev scope was a 1 GHz MSO58
<azonenberg> but i've tested on a MSO64
<azonenberg> similar results
<dingwat> yeah, that's unfortunate. I'll let Dallas know that we're concerned about SCPI instability. Unfortunately I can't really push for something else, our move to Tek is to provide some consistency across sites
<d1b2> <david.rysk> wonder if it's worth trying to get them to fix their firmware
<dingwat> I think maybe I'll request DScope, or buy one for myself
<azonenberg> well if you get the scope we'll do our best to get scopehal working but its definitely the #1 problem with tek right now
<dingwat> I suspect a Thunderscope will be out of my budget
<azonenberg> the hardware is excellent
<d1b2> <johnsel> Did you get any further than I did with it eventually @azonenberg
<azonenberg> no i didnt have time to touch it
<azonenberg> i've been nonstop on other stuff
<azonenberg> i dont think i've touched scopehal code except to review and merge a PR in a month
<azonenberg> i have two pcbs sitting on my bench waiting for me to find time to assemble them
<azonenberg> and they've been there for almost two weeks
<azonenberg> i mopped and vacuumed the whole house except for the lab and one other room over the weekend for the first time all year lol
<azonenberg> (we had vacuumed more often of course but this was the first time we had had a chance to mop)
<azonenberg> I have a week off in august and am hoping to find time to catch up on stuff but the todo list on my phone has 52 open items so who knows if scopehal will get done in that time
<dingwat> is there a manchester decoder in scopehal? can't find it but maybe I'm lookin in the wrong menu?
<azonenberg> dingwat: No. There's an open todo, and we have a decode for 10baseT which is manchester
<azonenberg> but for a generic manchester decode its nontrivial because there's so many variations
<azonenberg> in particular most variants of manchester have some out of band signal like a too-long pulse or differential zero or something for denoting start of packet
<azonenberg> so the consensus at that time was that it made more sense to just write separate decodes for every variant
<azonenberg> Also i have some work on the probe stuff making progress although pcbway just rejected one of my assembly fixtures for being too small for their CNC machine lol
<azonenberg> so i need to just add a nonfunctional brick of aluminum at the bottom of the fixture to make it large enough to fit their minimum volume
<dingwat> azonenberg: ah gotcha. Perhaps someday I will attempt to write a DP AUX decoder
<azonenberg> There is an open ticket for that specifically
<dingwat> noice
<azonenberg> to my knowledge, nobody is actively working on it
<dingwat> I still haven't made a diff probe to logic analyzer bodge board :( that's what I really need to do, so I can capture a huge chunk of aux
<azonenberg> what do you mean, diff probe to LA?
<azonenberg> dp aux is 1 mbps you should be able to just use a pair of bog-standard r-c divider probes
<tnt> azonenberg: there is 720 Mbps aux channels now :)
<tnt> Although ... apparently that didn't last. It was introduced in DP 1.2 and deprecated in DP 1.3 ...
<azonenberg> lol
<dingwat> azonenberg: well, sure, doesn't have to be a diff probe, but needs a diff comparator in the path because the middle of the waveform wanders around too much to use a fixed logic analyzer threshold
<dingwat> tnt: yeah, nobody used it and they nuked it. Correct move IMO, unlike HDMI where all the features that were introduced and never used still linger around like that unopened coffin in your root cellar
<dingwat> Ethernet over HDMI?? Wow that's super cool I'm sure everyone will use that
<azonenberg> dingwat: i would use two single ended probes and a subtract filter in scopehal
<azonenberg> at least to start
<dingwat> azonenberg: https://i.imgur.com/1Bpscof.png
<dingwat> works fine, just need to decode. But ultimately this is something that would be more suited for a logic analyzer than a scope, gonna need a lot deeper capture than I can get with this scope
<azonenberg> dingwat: whats your max memory depth?
<azonenberg> both of my lecroys can do 128M points
<azonenberg> the picoscope will happily do a gigapoint or more
<dingwat> azonenberg: on this scope, I think 4Mpts
<dingwat> we're living in the dark ages over here :)
<dingwat> that's half channels too. So only 2Mpts if you have 4 channels. Keysight also never shows you the sample depth anywhere
<dingwat> I think my next test equipment purchase for myself will be a picoscope or dscope
<azonenberg> yeah i have so many instruments that come close to what i want
<azonenberg> none check all the box
<azonenberg> boxes*
<dingwat> i accidentally a ham radio license and it's hard not to spend money on radios :/
<azonenberg> thunderscope: highest PC interface bandwidth by a long shot, very limited analog performance
<azonenberg> picoscope 6000e: most channels (8), better but still limited analog performance (500 MHz, up to 5 Gsps but only on 2 channnels; dropping to 1.25 Gsps on all channels), fastest PC interface other than the thunderscope, very deep memory
<azonenberg> lecroy: highest sample rate(20 Gsps on the one scope with all channels active, 40 Gsps in 2 channel mode, big scope does 40 Gsps on all channels)
<azonenberg> best analog performance (4 GHz on the small one, 16 GHz on the big)
<azonenberg> shallowest memory (64M points on the 4 GHz in 4ch mode, 128M in 2ch mode, and i think 128M on the 16 GHz)
<azonenberg> the 16G can be expanded to 256M point memory but idk if i'll even bother since it cant offload the data fast enough
<azonenberg> it can only push a couple hundred Mbps over the pc interface
<azonenberg> where can i get lecroy's frontend and ADCs with the thunderscope processing pipeline and a 10G or 25G ethernet link to the PC? lol
<dingwat> just have to weld the Lecroy acquisition board to a PCIe 5x16 card, EZPZ
<d1b2> <abdull9274> chiming in. I have an SDRplay RSPdx and just recently discovered ngscopeclient. My first impulse was to see if ngscopeclient supports SoapySDR.
<tnt> dingwat: as a hack if you have a laptop on battery you can use one of those fx2 analyzer and connect gnd to the negative DP channel and the signal to the positive DP channel.
<d1b2> <azonenberg> As of now, the only backend we have for SDR stuff is UHD, and there's been no incentive to add more until we build more filters to actually do things with RF signals
<d1b2> <azonenberg> e.g. making a FFT that takes I/Q input rather than scalar
<d1b2> <246tnt> @azonenberg What Rb were you using when doing your GPSD comparison ?
<d1b2> <azonenberg> symmetricom sa.22c
<d1b2> <azonenberg> i need to respin the breakout to fix some mechanical issues around the footprint, i couldn't actually screw the breakout to the Rb like I planned
<d1b2> <246tnt> I was trying to reproduce the graph here comparing a FE-5680A (cheap ebay unit from like 10y ago) to a Trimble Thunderbolt (also probably from 10y ago). But I was getting quite a bit of noise on the Phase measurement.
<d1b2> <246tnt> Even when triggering on Rb and measuring the phase of the Rb the numbers would jump around quite a bit.
<d1b2> <azonenberg> How clean was the clock source of your scope?
<d1b2> <azonenberg> the lecroy was either using the rubidium or the internal double oven OCXO as the source, i forget which, for that test
<d1b2> <azonenberg> probably the OCXO
<d1b2> <azonenberg> Stability of the reference clocks is definitely important
<d1b2> <246tnt> Of the scope ? My scope doesn't take an external reference 😅
<d1b2> <azonenberg> yeah i would question how clean the internal timebase is then :p
<d1b2> <azonenberg> when you're looking for differences this small
<d1b2> <246tnt> Well it was jumping by not small amounts, I'll need to reproduce tomorrow.
<d1b2> <azonenberg> yeah if you can share some video of the dynamic behavior plus a screenshot of the filter graph setup i'll see if anything looks off
bvernoux has quit [Quit: Leaving]