<azonenberg>
We might need to do a lower level capture
<azonenberg>
are you familiar with Wireshark? If you can send us a pcap of the traffic between the scope and your computer it might shed some light on things. I suspect there's a very subtle format change they may have made
<azonenberg>
that isn't jumping out at me here
<azonenberg>
the other thing you can try doing is attaching a debugger and breaking at SiglentSCPIOscilloscope.cpp:1441 (or adding print statements there) and see what the values of len, getLength, and hdSizeWorkaround are
<Guest98>
I'm sorry. I don't know Wireshark.
<Guest98>
All users using sds2000x plus will have the same symptoms.
<Guest98>
I don't speak English as my first language, but I use an automatic translator, so I may not be able to deliver the language.
<Guest98>
Please understand.
<azonenberg>
What is your preferred language? We may have someone here who can help you better
<Guest98>
I am Korean. ^^
<azonenberg>
Hmm, I don't think we have any Korean speakers here off the top of my head. I know we have a lot of folks from across north america and europe
<azonenberg>
anyway, if you are able to install https://www.wireshark.org/ and record the traffic between your computer and the scope, then upload the .pcap or .pcapng file, it may help
<azonenberg>
otherwise, you may be stuck until we can find someone having the same problem. I don't have any Siglent scopes in my lab (the only Siglent hardware I have is a SSG5060X-V) so I am unable to test
<Guest98>
I can send you sds2000x plus if you allow.
<Guest98>
You can take a long, slow look.
<Guest98>
Another question, is there an average view in fft?
<azonenberg>
I don't have the time myself. We have several Siglent users in the channel though and some are probably going to update to the new firmware soon
<azonenberg>
as far as FFT goes, not currently. It would probably be implemented as an "average over time" block that you could apply to any channel, including but not limited to an FFT
<azonenberg>
That's a good idea, but does not exist right now
<azonenberg>
the closest we have is a moving average block that averages adjacent samples within a single sweep
<azonenberg>
I just filed a feature request ticket for it, see link above. No promises it will happen soon as I have a lot of other things to get to
<azonenberg>
but it's on the list
<Guest98>
Thank you! <3
<azonenberg>
Anyway, you are using 10M point memory depth
<azonenberg>
correct?
<azonenberg>
Because looking at the pcap I see the scope sending #9005000000 in response to the request for channel 1's data. So it's only sending 5 million bytes of data
<Guest98>
Yes, I will change it to 100k.
<azonenberg>
Change it to much less
<azonenberg>
like a few hundred samples
<azonenberg>
So it's easy to manually look at the captured data and see what it's doing
<azonenberg>
And does it work with 100K or is it failing in the same way?
<Guest98>
I'll be back in an hour.
<Guest98>
Both 10k and 100k fail.
<azonenberg>
I feel like this really needs a developer to be hands-on with a scope
<azonenberg>
But I'm way too busy to do it myself
Guest98 has quit [Ping timeout: 252 seconds]
<azonenberg>
louis: so yet another wrinkle to content with WRT cursors and in progress updates
<azonenberg>
during the filter graph execution, we have a mutex that locks access to waveform data, because filters may or may not reallocate their output buffer during execution
<azonenberg>
in order to avoid slowing down rendering, we need to do a try-lock on this mutex and consider what happens if we fail to get it
<azonenberg>
(meaning, we are unable to read waveform data this frame because it's being modified)
<_whitenotifier-7>
[scopehal-apps] azonenberg 0183e38 - WaveformArea: tooltip now includes sample depth/rate information
<_whitenotifier-7>
[scopehal-apps] azonenberg ddf340c - Initial rendering of trigger level arrow. Always in white, not channel color yet.
<_whitenotifier-7>
[scopehal-apps] azonenberg 393d08a - Added trigger arrow dragging to set level
Guest98 has joined #scopehal
<Guest98>
I'm back.
<Guest98>
Please let me know if you need any data.
<azonenberg>
Guest98: Nothing is super obvious. Unfortunately I think I've done as much as I can
<azonenberg>
i'll put the word out to other Siglent scope users
<azonenberg>
hopefully one of them can help debug
<azonenberg>
in the meantime, file an issue on github and upload anything you think might be helpful there
<azonenberg>
including these pcaps
<Guest98>
Thank you. Very!
<Guest98>
Have a Good day.
Guest98 has quit [Quit: Client closed]
massi has joined #scopehal
smudge-the-cat has joined #scopehal
smudge-the-cat has left #scopehal [#scopehal]
smudge-the-cat has joined #scopehal
smudge-the-cat has left #scopehal [#scopehal]
<d1b2>
<Badr> Hi there! I just ran across this awesome project, always hoped I had access to such a tool. Is there any doc. to run the glscopeclient on macOS (MacBook Pro M1 here)? I couldn't find any mention of macOS in the PDF doc.
bvernoux has joined #scopehal
<azonenberg>
badr: There's no docs because it's not currently possible. There is an ongoing active porting effort to get it working on M1 macos
<azonenberg>
as of today, it will compile and run up to the point that you try to display a waveform, then fail to create a plot because the rendering requires OpenGL 4.3 and MacOS only supports 4.1
<d1b2>
<Badr> Ah too bad. Thanks for the feedback! Let me know if I can help with the testing.
<azonenberg>
lain is working on a rewrite of the renderer which uses Vulkan instead of OpenGL, which (through MoltenVK) can run on macOS
<azonenberg>
we are hoping to have that merged some time this week
<azonenberg>
at that point it may work, or we may run into additional portability issues. We don't know yet
<d1b2>
<Badr> Looking forward to it!
<azonenberg>
We are also in the process of a complete rewrite of the frontend GUI code using a new UI toolkit that is faster and should work better on Windows
<azonenberg>
The new frontend (working name is "ngscopeclient" but we're planning to use this as an excuse to work with some marketing/branding people to invent a more catchy name) is incomplete, and cannot display waveforms anywhere yet
<azonenberg>
but the functionality it does have runs pretty much flawlessly on macOS (it's pure Vulkan, no OpenGL)
<azonenberg>
The new frontend adds a bunch of new features, like the ability to have multiple top level windows or tabs with waveforms in them, as well as ability to control RF signal generators and power supplies and other instrument types glscopeclient doesn't have UIs for
<azonenberg>
We are hoping to drop the new renderer into it in the next week or two and have it usable for minimum scope remote display, but it can't yet save/load files or run any of the complex signal analysis tools in glscopeclient
<azonenberg>
that is still weeks to months out
<azonenberg>
But it should be significantly faster and more capable once it's done
<d1b2>
<Badr> Awesome. Thanks for all the work, this is really a missing piece of software 🙂
<azonenberg>
Yeah the closest competition is sigrok and at this point it's like comparing one of those ride-on toy cars for toddlers to a ferrari
<azonenberg>
sneak peek at the new UI if you're curious
<d1b2>
<Badr> 😍
<d1b2>
<Badr> Looking good
<azonenberg>
We will likely get the existing UI at least somewhat working on macOS in the immediate future, but there will likely be rough edges that will go unfixed for a long time, if not forever
<miek>
i don't think it's necessary to insult another project to sell the features of this one..
<azonenberg>
since nobody is actively working on the new frontend
<azonenberg>
miek: my point is, we're solving very different problems
<azonenberg>
sigrok is intended to decode a huge range of low speed protocols
<azonenberg>
it does that reasonably well
<azonenberg>
but it can't do much else
<azonenberg>
if you want to debug a string of WS2812 LEDs it's not a bad choice, in fact there is no scopehal decode for them at the moment
<azonenberg>
its analog capabilities are practically nonexistent
<azonenberg>
sorry i meant, since nobody is actively working on the old frontend*
<miek>
i know the differences, but "it's a toy for kids" isn't the same as "it solves very different problems"
<azonenberg>
It generally does feel underpowered and very limiting though
<azonenberg>
i was not impressed when i played with it last
<miek>
i think that's because you're most interested in the problems it isn't solving though :p
<azonenberg>
it supports every $5 logic analyzer under the sun
<azonenberg>
and as far as i can tell not much else
<d1b2>
<Badr> It supports remote view of oscilloscopes but the functionalities are basic. Live capture from my Rigol DS1054Z over TCP
<azonenberg>
Yeah. in general sigrok feels like a tool that might be effectively used in, say, a first robotics club
<azonenberg>
but is unlikely to see significant adoption in industry
<d1b2>
<xabean> pipe wrench v.s. needle nose vice grips would be a better comparison. Tools that have similar function/purpose, but vastly different application use cases because of their design.
<d1b2>
<xabean> you can use one in place of the other, but it's gonna be a painful experience outside of its intended application space
<_whitenotifier-7>
[scopehal] azonenberg 492ad25 - Refactoring: GetChannelBandwidthLimit() now returns an unsigned int, to be consistent with SetChannelBandwidthLimit() and GetChannelBandwidthLimiters()
<_whitenotifier-7>
[scopehal-apps] azonenberg 6865124 - Don't allow changing of coupling when an active probe is connected
<azonenberg>
Ok so that's channel properties, we can adjust trigger level but not horizontal position
<azonenberg>
multiscope should in theory work as i copied most of that code straight from glscopeclient, but there's no sync wizard yet so you get whatever alignment you had at connection time
<azonenberg>
i guess next on the list is timebase settings
massi has quit [Remote host closed the connection]
<d1b2>
<louis> azonenberg: do we already have some way I don't know of to select a subset of a waveform?
<azonenberg>
you mean to run filters on a window of a waveform or something?
<d1b2>
<louis> yeah
<d1b2>
<louis> I was going to add a window filter
<azonenberg>
no, that has been on the wishlist for a while. the easiest way to implement it would be a filter to extract a window of a waveform, probably coupled with some GUI sugar that lets you drag the start/end points vs having to type them in as parameters
<d1b2>
<louis> yeah that was my plan
<azonenberg>
i never actually built it because i had no urgent need
<d1b2>
<louis> i was going to do that plus a waveform that combines two non-overlapping waveforms to make it easy to get some data to test sparse waveform handling
<d1b2>
<louis> slash to avoid running analyses on a 100MPt waveform when I only care about a 200kPt block
<azonenberg>
what do you mean combines. you mean it turns two waveforms with a gap between them into a single sparse waveform with a void in the middle?
<azonenberg>
yeah i could see that potentially being useful
<azonenberg>
the nice thing about the extract filter is that you can set triggerPhase to the beginning of the window
<azonenberg>
and then still make it uniform
<azonenberg>
so you can just do a block memcpy of the sample data etc
<azonenberg>
(assuming the input waveform is itself uniform)
<_whitenotifier-7>
[scopehal-apps] azonenberg f230b75 - ChannelPropertiesDialog: dispaly proper units on bandwidth values
<_whitenotifier-7>
[scopehal-apps] azonenberg 3251ea7 - WaveformArea: avoid using last frame's value (or, worse yet, uninitialized) for m_ymid. Fixes weird jittering when dragging windows as well as rare hang during first frame when displaying a new WaveformArea.
<azonenberg>
bvernoux: 3251ea7 should fix that hang you observed
<azonenberg>
tl;dr it was a coordinate being initialized one funciton call *after* we used it for the first time
<azonenberg>
which led to both visdual artifacts from using last frame's value in rendering (problematic when moving the window)
<bvernoux>
ha yes great
<azonenberg>
and also to a potential hang on the first frame if the uninitialized value happened to be really big
<azonenberg>
it wasn't strictly a hang, it would have eventually resolved
<azonenberg>
but it could have taken hours or days for the loop to end :p
<azonenberg>
(and then worked flawlessly after that)
<azonenberg>
There appears to be one more hang when you start triggering, likely a mutex deadlock i have to troubleshoot
<azonenberg>
it's inconsistent but does happen after a fairly short time
<azonenberg>
hmmm when you have a window titlebar over the timeline
<azonenberg>
it seems like the timeline steals the focus for drags through other windows. that's not good
<d1b2>
<Mughees> A question about statistics display. It continuously calculates the average, max and minimum. If filters input parameters change on the fly, the past values are still used to calculate the averages. Maximum and Minimum values remain the same as with previous parameters settings which feels a bit bad. Is there a way to reset statistics calculation upon parameter change?
<azonenberg>
There is a "clear sweeps" button on the toolbar that refreshes history
<azonenberg>
We don't currently have a way to clear stats when a filter is reconfigured but that's a good idea, i've wanted to do that for a while
<azonenberg>
file a ticket and i'll work on it in a bit
<d1b2>
<Mughees> Sure will do
<d1b2>
<Mughees> today
<azonenberg>
in general i want a way for filters to propagate change notifications downstream
<azonenberg>
or channels, for that matter
<azonenberg>
so that e.g. an eye pattern will clear if you adjust volts/div on the input signal
<d1b2>
<karlp> fwwi, thw font or whatever in the pdf generation from tex means that the code snippets and shell snippets can't be copied/pasted directly, they result in extra spaces all over the place.
<azonenberg>
Yes that is a known issue we want to work on
<azonenberg>
there's already a ticket filed for it
bvernoux has quit [Read error: Connection reset by peer]
<d1b2>
<karlp> so, after rebooting and rebuilding clean today, it runs "properly" without aborting, but.. is the current state of master meant to be "good" ? or have things broken as part of the ng effort?
<d1b2>
<karlp> is there a tag I should go back to if I want to explore the demo, and use it as a base for adding a new driver?
<d1b2>
<karlp> because right now, clicking "fullscreen" locks me in fullscreen, and never comes back, , which is workable, not world breaking,
<d1b2>
<karlp> but middle clicking, which.. zoomed all the way out? mymachine was then hard hung, and I had to power cycle to get back.
<azonenberg>
Master is always intended to be usable
<d1b2>
<karlp> I'm currently at a39c2aae1 which is ~two days ago.
<azonenberg>
ngscopeclient is incomplete but should not crash or hand and certainly not take out the whole machine
<azonenberg>
or hang*
<d1b2>
<karlp> I'm only uising the glscopeclient right now anyway, that was my expectation that it should still be "fine"
<azonenberg>
Yes
<azonenberg>
it should be fully operational
<azonenberg>
Fullscreen has known bugs on windows, probably best not to use, however the expected failure is simply that some dialogs act funny
<azonenberg>
it shouldn't get stuck fullscreened
<d1b2>
<karlp> this is on fedora36
<d1b2>
<karlp> so, wayland+ipewire I guess.
<azonenberg>
fullscreen on linux should work normally. that said, we have not done a lot of testing on wayland vs X
<azonenberg>
so that is slightly uncharted territory
<d1b2>
<karlp> I don't really need fullscreen, that's kinda just me clicking things in the UI 🙂 the power cycle hang is much more of an issue for me 🙂
<d1b2>
<karlp> I'm trying it again with logging and debug, we shall see.
<azonenberg>
Middle click is supposed to auto-fit so the viewport encompasses the entirety of the active waveform
<azonenberg>
(if on the plot area)
<d1b2>
<karlp> (I take it the same bug about the spaces in code snippets also applies to -- vs "dash" stuff right?)
<azonenberg>
or, if on the Y axis of a filter block, autofit the Y axis scale
<azonenberg>
Yes. We need to overhaul the code snippet rendering to make it copyable
<azonenberg>
anyway i just tested with the demo scope and it does exactly that on my debian/X11 box
<azonenberg>
The new Vulkan renderer should be landing in glscopeclient in the next day or two, we can see if that changes anything
<d1b2>
<karlp> ok with logging and --debug I get an abort instead of a hang.
<azonenberg>
abort? interesting. is there a displayed error message?
<d1b2>
<karlp> "exactly that" you see it hang too?
<azonenberg>
no
<azonenberg>
i see normal behavior, it zooms to fit
<d1b2>
<karlp> well it zooms, but then it aborts just afterwards.
<d1b2>
<karlp> last boot, without --debug and -l blah.log it just hung the entire system
<d1b2>
<karlp> it crashes for me when the window loses focus,
<d1b2>
<karlp> alt-tab, or mouse click elsewhere.
<azonenberg>
hmmmmm
<azonenberg>
it's dying in gtk_gl_area_draw()
<azonenberg>
but not within our own code
<azonenberg>
Gut feeling is that this is either some subtle, slightly invalid OpenGL thing we're doing that your driver doesn't like, or it's a driver installation/configuration problem
<azonenberg>
good news is, whatever it is, the offending code is not going to exist/be called in ngscopeclient which is all vulkan
<azonenberg>
and thanks to the Khronos validation layer, I have very high confidence that we're not making illegal/malformed Vulkan API calls, reading/writing GPU memory out of bounds, etc in ngscopeclient
<azonenberg>
with the OpenGL renderer, i have no idea
<azonenberg>
the debug/validation is not nearly as well developed
<d1b2>
<karlp> so... shelve any plans i had for working on a scope driver then 🙂 wait for ngscopeclient?
<azonenberg>
The backend is the same
<azonenberg>
my one suggestion is to see if you can try it under X instead of Wayland
<d1b2>
<karlp> here's me trying to give into the inevitable, let wayland do it's thing, and you want to go back to X? but also forwards to vulkan, throwing out opengl? 🙂 sure, the suggestion is reasonable. the world we live in is by all acounts not...
<azonenberg>
I mean near term, prior to the vulkan transition
<azonenberg>
just so you can get started on the driver and such
<azonenberg>
the backend is exactly the same, swapping glscopeclient for ngscopeclient on the front end changes nothing about what you do in libscopehal.so
<d1b2>
<karlp> meh, turns out I was already on xorg, because of complexity studio hellholes, get "same" crash on wayland, just with a trivbially different stack trace: https://paste.centos.org/view/6c221ba3
<d1b2>
<karlp> ok, out of this sort of play time again tonight. will revist again later...
<d1b2>
<karlp> I also tried latest latest master, 3251ea75302 as well, no change.
<azonenberg>
ok yeah i'm not sure then. See what happens then lain's new renderer lands in a day or two. in glscopeclient this will be using vulkan for everything until the waveforms are rasterized as textures
<azonenberg>
and then the final texture compositing will happen in opengl
<azonenberg>
a day or two after that, we should have an all-vulkan pipeline based on the same shader in ngscopeclient that will hopefully avoid your issue
<azonenberg>
you won't have access to a lot of the more advanced glscopeclient features, for example there is no way to create filters or protocol decodes yet
<azonenberg>
and you can't save or load files
<azonenberg>
But for the purpose of creating an instrument driver, it should be sufficient
<azonenberg>
mughees: is your "time outside level" filter intended to report the total, integrated time per waveform?
<azonenberg>
not the duration of each pulse?
<azonenberg>
Maybe tweak the documentation to make that a little more clear
<azonenberg>
the screenshot seems to imply it's measuring the total but my first impression on reading the text was that it was reporting the duration of each pulse