azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 256 seconds]
someone-else has quit [Quit: Connection closed]
<_whitenotifier-8> [scopehal] azonenberg commented on issue #322: Add support for units defined in terms of other units - https://github.com/azonenberg/scopehal/issues/322#issuecomment-1010626742
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
Bird|otherbox has joined #scopehal
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 240 seconds]
nelgau has joined #scopehal
lain has quit [*.net *.split]
Bird|ghosted has quit [*.net *.split]
nelgau has quit [Ping timeout: 240 seconds]
lain has joined #scopehal
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 256 seconds]
bvernoux has joined #scopehal
massi has joined #scopehal
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 256 seconds]
massi_ has joined #scopehal
massi has quit [Ping timeout: 256 seconds]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 240 seconds]
nelgau has joined #scopehal
massi_ has quit [Ping timeout: 256 seconds]
massi has joined #scopehal
nelgau has quit [Remote host closed the connection]
balrog has quit [Quit: Bye]
balrog has joined #scopehal
nelgau has joined #scopehal
massi has quit [Remote host closed the connection]
nelgau has quit [Ping timeout: 256 seconds]
miek has quit [*.net *.split]
elms has quit [*.net *.split]
welterde has quit [*.net *.split]
Ekho has quit [*.net *.split]
florolf has quit [*.net *.split]
Fridtjof has quit [*.net *.split]
esden has quit [*.net *.split]
Yamakaja has quit [*.net *.split]
_florent_ has quit [*.net *.split]
monochroma has quit [*.net *.split]
tnt has quit [*.net *.split]
GyrosGeier has quit [*.net *.split]
ericonr has quit [*.net *.split]
bgamari_ has quit [*.net *.split]
Stary has quit [*.net *.split]
mxshift has quit [*.net *.split]
lethalbit has quit [*.net *.split]
electronic_eel has quit [*.net *.split]
vup has quit [*.net *.split]
Stephie has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
sorear has quit [*.net *.split]
agg has quit [*.net *.split]
asy_ has quit [*.net *.split]
azonenberg has quit [*.net *.split]
d1b2 has quit [*.net *.split]
Kliment has quit [*.net *.split]
bvernoux has quit [*.net *.split]
balrog has quit [*.net *.split]
Bird|otherbox has quit [*.net *.split]
Degi has quit [*.net *.split]
Ekho- has joined #scopehal
elms has joined #scopehal
welterde has joined #scopehal
balrog has joined #scopehal
bvernoux has joined #scopehal
Degi has joined #scopehal
monochroma has joined #scopehal
tnt has joined #scopehal
esden has joined #scopehal
_florent_ has joined #scopehal
florolf has joined #scopehal
Yamakaja has joined #scopehal
Fridtjof has joined #scopehal
GyrosGeier has joined #scopehal
Stary has joined #scopehal
Stephie has joined #scopehal
bgamari_ has joined #scopehal
lethalbit has joined #scopehal
Bird|otherbox has joined #scopehal
vup has joined #scopehal
electronic_eel has joined #scopehal
d1b2 has joined #scopehal
agg has joined #scopehal
Kliment has joined #scopehal
kbeckmann has joined #scopehal
sorear has joined #scopehal
azonenberg has joined #scopehal
asy_ has joined #scopehal
mxshift has joined #scopehal
ericonr has joined #scopehal
miek has joined #scopehal
<d1b2> <dannas> Weird. The SDS1104x-e is supposed to send waveforms with a header and a trailer. When I started experimenting with the scope I did see the header/trailer but now they aren't sent. The whole response is the bytes that makes up the waveforms. Which is much better for me. I'm just curious why I see this change.
<azonenberg> dannas: there is probably a config setting somewhere
<azonenberg> try power cycling the scope and/or hitting the front panel default setup button if there is one
<d1b2> <dannas> Yes, just gotta figure out what it is. I thought it was related to the CHDR command but looks like that doesn't make a difference.
<azonenberg> also, having headers is usually a good thing on slower scopes / high latency connections
<d1b2> <dannas> Hm, I did hack the scope a few weeks back to get 200MHz bandwidth. I wonder if the header stopped coming after that.
<azonenberg> as it eliminates the need to poll the scope for settings
<azonenberg> having to send additional polling commands slows things down
<azonenberg> can you revert the hack?
<d1b2> <dannas> The header only provides the length of data and the channel, so not much use here for eliminating config roundtrips
<azonenberg> it's important to test with scopes in stock config
<azonenberg> but yes, also test with pwned ones as i suspect many of our users will have them :p
<d1b2> <dannas> @mokomull offered a while back to test code. Maybe he has a non-pwned one.
<d1b2> <dannas> 4WFM/s with 7k mem depth and four channels
<d1b2> <dannas> <1WFM/s with 7M depth.
<d1b2> <dannas> That looks rougly in order with what is reported for the 2xxx series in the manual
<d1b2> <dannas> @azonenberg I'll add the header/non-header WF? to my list of things to investigate.
<d1b2> <dannas> @azonenberg This is probably a silly question: But given that this scope probably can only retrieve 1-5 waveforms per sec: Doesn't that limit it for certain kind of measurements? Don't you need like thousands of waveforms per sec to do eye diagrams or provide statistics of signals to make sure you find glitches?
<d1b2> <dannas> I guess any scope is gonna spend most of it's time in a "dead state" between triggering signals. So even if you have 1000s of waveforms captured per sec you still have a low probability of catches glitches.
<azonenberg> Yes, that's one of the advantages of having good glitch triggering on the scope and also of having high streaming BW
<azonenberg> you can somewhat make up for it by having deep memory
<azonenberg> as far as eye diagrams you can get a decent eye with just a few million *points*
<azonenberg> which can be either one deep memory waveform or a few shallower ones
<azonenberg> But the ability to do more complex clientside analysis and have improved glitch catching is one of many reasons why the scopes I'm building will have 10GbE or 40GbE interfaces
<d1b2> <dannas> Hm, I wonder if the existing driver supports segmented captures (or what the terminology is). Where you can trigger multiple times on a waveform without having to record the uninterresting samples in between.
<d1b2> <dannas> I think they're called sequenced captures on the Siglent scope.
<d1b2> <dannas> I guess segmented memory is the term I'm referring to.
<d1b2> <dannas> checks the glscopeclient manual for waveform/s for other scope brands
<azonenberg> Re segmented capture, several of the current drivers support downloading segmented capture (each segment is exposed to the API as a separate waveform, since they're logically separate trigger events)
<azonenberg> however there are currently no APIs to configure segmented memory
<azonenberg> so you have to set it up on the scope
<azonenberg> this is an open ticket that has been low priority for a while
<d1b2> <mokomull> I do have a stock one 🙂
<d1b2> <dannas> @azonenberg We'll see if I get to segmented captures one day.
<azonenberg> Sounds good. Definitely far from the highest priority
<azonenberg> I'm still busy playing catch-up with other things i've promised various people I'd do, and haven't had time to do much core glscopeclient dev in a month or two
<d1b2> <dannas> @mokomull Great! The code is a bit in flux at the moment. Will clean it up and push in a day or two.
<azonenberg> i have time to review/merge PRs and fix quick obvious segfaults etc
<azonenberg> But not to do major dev myself
<d1b2> <mokomull> sounds good, I don't think I'll have any time until the weekend anyway
<azonenberg> Hopefully I can start closing out the ongoing projects and spend more time on it in a few weeks
<d1b2> <dannas> @azonenberg That means less rebasing of scophal for me 🙂
<azonenberg> lol
<azonenberg> Fair point
<azonenberg> Longer term I really want to find another core/GUI developer though (or several)
<azonenberg> As much as I love and appreciate people developing and maintaining drivers
<azonenberg> there's more to the project than drivers
<d1b2> <dannas> @azonenberg I guess you might attract electronics/firmware people who needs support for a scope or a specific decode functionality. The GUI/desktop expertise might be a slightly different subset of people.
<azonenberg> Yeah exactly
<d1b2> <dannas> But isn't that how it goes? A few core devs and a most contributors providing drivers. The Linux kernel model.
<azonenberg> "a few" != 1
<azonenberg> And there's not a ton of overlap unfortunately. but really what i think has made the project so successful so far is that I'm both a scope user and a ui dev
<azonenberg> i.e. I know what i want out of a scope
<d1b2> <dannas> Do you have anything in particular that you want to achieve with glscopeclient? Polish or more substantial UI changes?
<azonenberg> i mean there's hundreds of open tickets :P
<azonenberg> if i had to pick one small, self contained, highish priority task for a UI dev to work on it would be a facelift and feature upgrade of the filter graph editor
<d1b2> <dannas> 111 open tickets.
<azonenberg> it has some segfaults I never found/fixed
<azonenberg> the paths between blocks are drawn ugly and square and overlap removal is not as good as it should be
<azonenberg> you cannot create new filters (this will require coordination with the UI as currently you cannot have a channel/filter with no loads, so if you make a filter it has to have a WaveformArea associated with it or it will get garbage collected because nothing is using its output)
<d1b2> <dannas> I saw a tweet about how you wanted to adjust the layout algorithm of the filter graph
<azonenberg> the filter graph tile positions are not saved in scopesession files so any work you do on beautifying the layout is lost when you close the project
<d1b2> <dannas> For me: I'm mostly interrested in experimenting with the serial decoding. The decoding is so limited on the siglent scope. I do have a DSLogic Pro logic analyzer but it's so often that I want to correlate measurements on 12-24V signals with serial decoding and I'd really love to be able to do it all in one program.
<d1b2> <dannas> Having support for both DSLogic and Siglent would be great. I think I saw an open ticket for the DSLogic somehwer in the scopehal-app issue tracker.
Ekho- is now known as Ekho
<azonenberg> Yes there is an open ticket. glscopeclient does support multi instrument capture however as of now the multi-instrument sync support only works with two analog channels
<azonenberg> I would more than welcome a PR allowing a LA and scope to be synced via the same system though
<azonenberg> you'd probably need the analog scope to be the primary and have trigger out on that driving an input on the LA
<azonenberg> and have the LA be secondary
<azonenberg> (unless the dslogic has trigger out in which case it can be primary)
<d1b2> <dannas> So many things to do and so little time. I need to amortize the cost of the time investment I put into learning scopehal, so I guess I'll have to just keep going for a while 🙂
<d1b2> <dannas> Time's up for today. Heavy raining outside. In January. That's insane. I hope when I wake up it is snowing instead. 160cm expected on a mountain top nearby.
bvernoux has quit [Quit: Leaving]
<azonenberg> dannas: is that not normal where you are?
<azonenberg> out here in the PNW, our winter is mostly rain. we get snow 1-2 times a year