<azonenberg>
Yeah we dont know whats causing it but the workaround of reverting to default preferences will at least make it not crash when this happens
<azonenberg>
But there's one of me and 149 open tickets against scopehal-apps. and another 261 against scopehal
<azonenberg>
So things will be moving slowly until we get more regular contributors :)
<dingwat>
dude this is great. spectrograms are pretty. Definitely gonna ask future equipment reps about support
<azonenberg>
dingwat: you can change the color ramp btw, right click on the channel name
<dingwat>
all I want so far is a little spinny thing when it's calculating stuff so I know my computer isn't frozen
<azonenberg>
Yeah there's an open request for that. at the same time though, we try to do as much as we can realtime with minimal latency so we dont need a waiting animation :p
<azonenberg>
but yeah if you like the spectrograms just wait until you're doign protocol decodes and stuff :D
<dingwat>
azonenberg: unfortunately, it doesn't seem like our fast scope isn't compatible
<dingwat>
or at least, I cannot determine the correct incantation to get ngscopeclient to connect
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #scopehal
<azonenberg>
dingwat: if it's a newer generation keysight, it's not supported yet. Nobody with one has been willing to put in the time to help write a driver
<azonenberg>
I don't have any accessible to dev against
<azonenberg>
If you're interested in building one and are comfortable in C++ I can walk you through the basics, but I can't do much of the legwork without actually having access to the scope
skipwich has quit [Quit: DISCONNECT]
<azonenberg>
dingwat: That is probably my single biggest wishlist WRT driver support, in fact
<azonenberg>
i just dont have any infiniiums on hand and nobody's offered to send me one
skipwich has joined #scopehal
<azonenberg>
i have a permanent dev scope from pico. i own lecroys, other devs have tek scopes plus they sent me a loaner for next week
<azonenberg>
siglent and rigol are all over the plaec among our users and devs
<azonenberg>
but for whatever reason we dont have a lot of keysight users and the one industry user i know with high end keysight scopes can't spare their $1M UXR as a dev platform (gee i wonder why)
<azonenberg>
they want it billable 24/7 :p
<azonenberg>
(I think most of their lower end scopes are tek mso5/6s. which is why we have a driver for those already)
<dingwat>
azonenberg: old gen tek
<dingwat>
azonenberg: MSO7000 series
<dingwat>
I wish we had an infiniium :)
<dingwat>
sorry, *MSO70000
Yamakaja_ has quit [Quit: Bye]
agg has quit [Ping timeout: 256 seconds]
agg has joined #scopehal
<azonenberg>
dingwat: oh. I have no idea about older gen teks WRT how similar their command set is to the newer ones
Yamakaja has joined #scopehal
Yamakaja has joined #scopehal
<azonenberg>
but if you can find a programming manual, you should be able to write a driver
bvernoux has joined #scopehal
<d1b2>
<vipqualitypost> i'm new to doing eye diagrams/patterns, are there any sort of special hardware requirements that I should keep in mind trying to take those types of measurements in ngscopeclient?
<d1b2>
<azonenberg> You mean on the PC side or on the instrument side?
<d1b2>
<azonenberg> On the instrument side, you need sufficient bandwidth. A good baseline is 1.5x the symbol rate to get out to the third harmonic of the data. For example, if you're looking at 1.25 Gbps data the fundamental is 625 MHz, third harmonic is 1.875 GHz, so a 2 GHz or higher scope would be a good choice
<d1b2>
<azonenberg> More sample rate and memory depth, and higher WFM/s PC interface rates, is helpful for getting more complete eyes in less time but doesn't affect the overall quality of results as much
<d1b2>
<johnsel> interestingly my settings file seems corrupt as well now @azonenberg
<d1b2>
<johnsel> oh no, it's the recently used list
<azonenberg>
huh what happened there?
<d1b2>
<johnsel> my mistake actually
<d1b2>
<johnsel> I ran ./src/ngscopeclient/ngscopeclient.exe instead of cd-ing to the folder
<d1b2>
<johnsel> so the relative paths were all messed up
<d1b2>
<johnsel> ideally we'd do something about that
<d1b2>
<johnsel> but meh
<d1b2>
<azonenberg> the recently used list should have all absolute paths?
<d1b2>
<johnsel> oh yes you are right
<d1b2>
<johnsel> I had 2 issues then, fonts were wrong and the recently used list error
<d1b2>
<johnsel> the latter still exists
<d1b2>
<johnsel> not sure what is wrong with it
<d1b2>
<johnsel> perhaps it's referring to a now deleted file?
<dingwat>
azonenberg: so our Tek scope calls out LXI "Class C" in the datasheet but other than that it's not entirely clear to me what all remote control options it has
<azonenberg>
dingwat: soo there's a bunch of layers to scope remote control protocols
<azonenberg>
on the bottom layer we have what we call a "SCPITransport" in libscopehal. this is basically a means of moving binary data bytes or ascii scpi commands to/from the scope
<azonenberg>
This transport can be anything from a rs232 port to USBTMC to GPIB to LXI VXI-11 over a TCP socket, LeCroy VICP over a TCP socket, or simply raw bytes over a TCP socket
<azonenberg>
We have support for pretty much all of the common transports already on Linux, although I think GPIB and USBTMC are currently linux only and don't yet have windows backends
<azonenberg>
Where the "driver" layer comes in is what's on top of that
<azonenberg>
going from high level abstractions like "turn on channel 2" or "display the contents of channel 1" to ascii commands
<dingwat>
the docs for this scope mention VXI-11 but not many details. But I would hope maybe it's similar enough to the mso5/6 scopes that it could work...
<azonenberg>
dingwat: VISA is NI's equivalent for our transport layer basically
<azonenberg>
if the scope supports vxi-11 you should be able to use our "lxi" transport to talk to it
<azonenberg>
at which point it's just a matter of either writing a new driver or extending the current mso4/5/6 driver to work with it
<dingwat>
there's a brief note in the help file "Tek LXI conforms to the LXI standard" ok so that's promising
<azonenberg>
Which you choose depends on how similar the architecture and command set is
<azonenberg>
if you skim the TektronixOscilloscope.cpp source file in libscopehal you should be able to see what commands it's sending and compare them to what the programming guide here has
<azonenberg>
if they look similar you might want to just try connecting using the "lxi" transport and see where it breaks
<azonenberg>
then add code to the driver to handle whatever the differences are lol
<d1b2>
<johnsel> @azonenberg I have been fighting with vkFFT for a while now, can you take a look and see if there's something I'm obviously doing wrong here?
<azonenberg>
Not at a glance but i'd need to spend some time to properly read it to see. Which i don't have right now, perhaps later today
<d1b2>
<johnsel> no problem, if you can take a look when you have time that'd be great, I just don't see what I'm doing wrong here
<d1b2>
<johnsel> all intermediate and output buffers stay empty
<d1b2>
<johnsel> or I'm not reading them out properly
<d1b2>
<johnsel> I wish I had vs studio so I could set a breakpoint and see the values
<d1b2>
<johnsel> but I guess that's a catch 22
<azonenberg>
@johnsel are you doing PrepareFor*Access() and MarkModifiedFrom*() properly?
<d1b2>
<johnsel> I may not, I've been copying from similar code
<d1b2>
<johnsel> I can play with that a bit
<azonenberg>
AcceleratorBuffer normally allocates separate CPU and GPU buffers and you have to explicitly tell it when you're changing on one side and using on the other
<azonenberg>
there's no explicit cache coherency between the twin buffers
<azonenberg>
no implicit*
<azonenberg>
you have to manage that yourself
<d1b2>
<johnsel> I see yeah that could very well be it since I'm porting only part of the code
<d1b2>
<johnsel> I'll look into it, thanks
bvernoux has quit [Quit: Leaving]
<d1b2>
<johnsel> No such luck
<d1b2>
<johnsel> I'm working on getting better traceability into the code paths though
<d1b2>
<johnsel> but if you can take a look when you have time that'd be appreciated
<d1b2>
<azonenberg> I'll see what I can do
<d1b2>
<azonenberg> right now my top priority schedule wise is the tek HSI demo scope that i only have for a week
<azonenberg>
can you have a look at whats going on with the windows CI failure here?
<azonenberg>
its complaining about an array bounds violation in code inlined from std::vector in the siglent driver
<azonenberg>
the line in question is just copy-assigning a std::vector
<azonenberg>
i dont see anything wrong with it at a glance
<dingwat>
azonenberg, balrog: if it helps, I saw that when building on one of my windows machines and not the other, so I was fairly confused
<azonenberg>
The surrounding code is weird and ugly and should probably be restructured
<azonenberg>
but i'm hesitant to touch it myself until i get a siglent scope on hand to regression test with
<dingwat>
and as far as I know they had the same install of msys2, same pull of scopehal, but the one that succeeded was win10, and the one that failed was win11
<d1b2>
<johnsel> could be build order/parallel build
<d1b2>
<johnsel> I've had some weirdness from that before
<azonenberg>
i was thinking difference in system headers between windows versions
<azonenberg>
anyway, I dont know windows at all
<azonenberg>
but please look into it someone :)
<dingwat>
but shouldn't everything be from msys2 and not from the os?
<d1b2>
<johnsel> also possible
<azonenberg>
there is also a macos CI failure that i'm ignoring because it appears FFTS related
<azonenberg>
so i'm just gonna say let's continue with our plan to deprecate the last vestiges of FFTS
<azonenberg>
i dont want to lift a finger to do anything with FFTS but get rid of it
<d1b2>
<johnsel> hehe
<d1b2>
<johnsel> yeah ideally you find the issue in my code, and I can continue
<d1b2>
<azonenberg> Well this guy is going to be keeping me somewhat busy soon
<d1b2>
<johnsel> but otherwise I'll investigate deeper myself
<dingwat>
_thicc boi_
<d1b2>
<azonenberg> I have it for the next week to play with Tek's new high performance API and integrate with scopehal
<d1b2>
<johnsel> what is it?
<d1b2>
<azonenberg> what's the API or the scope?
<d1b2>
<azonenberg> the scope is a 1 GHz MSO58
<dingwat>
azonenberg: tell me how you like it, because I want us to buy one
<d1b2>
<johnsel> oh nice, I can't open the image in browser so I can't see much
<d1b2>
<azonenberg> the API is protobuf over gRPC and appears to only be for waveform transport at a quick skim (still uses standard SCPI for control plane). The protobuf schema is not currently public and they provide a python blob for interfacing with it, although i'm sure we could RE it if we wanted
<d1b2>
<azonenberg> my plan is to have a python bridge server then scopehal native client for the near term
<d1b2>
<azonenberg> then possibly in the future get native gRPC client in scopehal
<d1b2>
<johnsel> is it over ssl?
<dingwat>
btw, if anyone knows if there's a converter out there for Keysight AutoProbe 1 to TekVPI, please let me know
<d1b2>
<azonenberg> That I do not know
<d1b2>
<johnsel> protobuf over gRPC is an interesting choice though
<d1b2>
<azonenberg> The scope has native 1000baseT but in theory should be compatible with 2.5GbE dongles over USB3
<d1b2>
<johnsel> I'm surprised they made you write Python though
<d1b2>
<azonenberg> i ordered one coming tomorrow
<d1b2>
<johnsel> or rather, that you let them
<d1b2>
<azonenberg> It's been a process to even get to this point 🙂
<d1b2>
<azonenberg> Tek is being friendly, we're taking what we can get
<d1b2>
<azonenberg> if we can get them to open up the proto spec down the road, great
<d1b2>
<azonenberg> My contact says he wanted to but was vetoed by someone over his head for the initial beta
<d1b2>
<johnsel> you don't write python in general though, right?
<d1b2>
<azonenberg> Nope. I was going to try and get @lainpants to help me lol
<dingwat>
kinda surprised the big vendors are being so friendly with you, because it seems like scopehal is gonna cannibalize license sales
<d1b2>
<johnsel> haha, well I offer myself as well for help
<d1b2>
<azonenberg> She's local and can do hands on debug so thats going to be the preferred option if she's available
<d1b2>
<azonenberg> Yep if she's too busy i'll poke you
<d1b2>
<azonenberg> yeah but if people stop buying their scopes because they want to use scopehal with somebody who's got better support...
<d1b2>
<azonenberg> more and more people i'm talking to are interested in using scopehal to the point they're telling sales reps that good PC interface capability is a selling point
<d1b2>
<johnsel> It's double-edged, people doing compliance testing will buy the trusted vendor packages anyway
<d1b2>
<azonenberg> that is something i want to keep hammering into the vendors, that there's demand for better APIs and remoting
<d1b2>
<azonenberg> and they can either provide the capabilities customers want or lose sales to someone who will
<dingwat>
true
<dingwat>
we'd still have to buy all the expensive shit for compliance testing for sure
<d1b2>
<johnsel> but that's also why they're being difficult in some respects
<d1b2>
<azonenberg> Yep. I am hoping to get precompliance testing packages on our sides though
<d1b2>
<azonenberg> even if not certified it will save time
<d1b2>
<azonenberg> thats a ways out though
<d1b2>
<johnsel> they know people want it, so they have to give in, but not give in more than they need to
<d1b2>
<johnsel> hence a blob
<d1b2>
<azonenberg> Yep lol
<d1b2>
<azonenberg> This is one of the reasons the scopehal license / plugin model is friendly to vendor blobs
<d1b2>
<azonenberg> I recognize its going to be a challenge to get vendors to fully open up everything
<d1b2>
<azonenberg> and i'd rather have blobs than no integration at all
<dingwat>
the last message i'll send to your keysight rep will be "your support sucks, we're buying tek. also you should improve support for scopehal" lmao
<d1b2>
<azonenberg> Lol
<d1b2>
<johnsel> true
<d1b2>
<azonenberg> well like i said, as of today with tek's HSI not officially released
<d1b2>
<azonenberg> lecroy is the winner for high performance scopes with good scopehal support
<d1b2>
<azonenberg> tek is trying to catch up
<d1b2>
<johnsel> I can throw up a ball w/ Keysight to get one of their scopes on loan, btw
<d1b2>
<azonenberg> (we've actually been playing with earlier iterations of this for a while back but weren't able to talk about it, now it's in open beta so i can be more free about what i say)
<d1b2>
<johnsel> Not sure if they're open to it but I have decent contact with daniel bogdanoff
<d1b2>
<johnsel> quite a while even, right?
<d1b2>
<azonenberg> yeah its been several months at least
<d1b2>
<azonenberg> but everyone involved has been super busy so its slow progress
<d1b2>
<azonenberg> i would love an infiniium driver
<d1b2>
<azonenberg> (i dont know how unified their command set is but i assume most of them are similar)
<d1b2>
<azonenberg> but i dont have the time to write one so i haven't pushed for a loaner
<d1b2>
<azonenberg> only reason i have this demo is tek was begging me to play with it more lol
<_whitenotifier-9>
[scopehal] azonenberg 1b23254 - AntikernelLabsTriggerCrossbar: clean up internal paths during destruction to prevent crash
<d1b2>
<azonenberg> And then with thunderscope on my plate plus my trigger crossbar stuff i have zero time for additional driver dev lol
<d1b2>
<azonenberg> (and scopehal core work)
<d1b2>
<johnsel> Yeah understandable
<d1b2>
<johnsel> You worked on another higher-speed interface for a vendor right?
<d1b2>
<johnsel> Was that R&S? Or?
<d1b2>
<azonenberg> There's this, Pico already has USB3 which is pretty good, then thunderscope is TBT3. R&S's highest end scopes have a SFP+ port that, last i heard, was not implemented on the FPGA side
<d1b2>
<azonenberg> its connected to the FPGA but nothing used it
<d1b2>
<azonenberg> AFAIK we've been pressuring them to implement the feature and there was discussion of even paying for development
<d1b2>
<azonenberg> if anything came of it, i wasn't in the loop
<d1b2>
<johnsel> Oh I might be misremembering then
<d1b2>
<azonenberg> you're probably thinking about me hinting about this
<d1b2>
<johnsel> Or it was a new scope driver
<d1b2>
<azonenberg> without being able to say it was tek
<d1b2>
<azonenberg> (at the time)
<d1b2>
<johnsel> well I think I'm confusing the beta driver you wrote for a scope pre-release
<d1b2>
<johnsel> that was it, iirc
<d1b2>
<azonenberg> there was also the new PicoVNA software
<d1b2>
<azonenberg> i was playing with that and doing driver integration prerelease
<d1b2>
<azonenberg> (also yes i know the latest PR broke the build i have a fix going up shortly)