<d1b2>
<mubes> Well, I'm hoping I haven't :-) backups are optimised for being made quickly rather than restored quickly, so I won't know everything is good until tomorrow, but fingers crossed that all I've lost is time. There are three backup layers so I'm pretty certain that even in the worst case I have lost much (touch wood).
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
<GenTooMan>
interesting the lecroy code appears to be similar to the siglent code in terms of messing with digital channels.
<azonenberg>
GenTooMan: it's the other way around
<azonenberg>
the siglent driver was copied from the lecroy driver
<azonenberg>
because the two share a lot of commonalities
<azonenberg>
AFAIK digital channel support in the siglent driver is incomplete or nonfunctional at this time
<azonenberg>
although mubes is working on it
<GenTooMan>
well either way they "are similar" I'm not sure if it's a compliment or not being copied in this case.
<GenTooMan>
still this is going to be an annoying task as Siglent did their best to do as little as possible in terms of support.
<GenTooMan>
more accurately put the SCPI support which is kind of heh.
<azonenberg>
Siglent is actually being quite helpful, we're in email contact with them and i've had a nice phone chat with one of their folks
<azonenberg>
Siglent and lecroy have collaborated on several lower end desgns
<azonenberg>
which is why the command set is similar
<GenTooMan>
hmm that's cool it's rare the any company works with any other company. I guess I've become to pessimistic these days.
<azonenberg>
We've been collaborating with Pico and Digilent too
<azonenberg>
both of whom have sent free hardware to me for the express purpose of writing libscopehal drivers
<GenTooMan>
I saw someone syncing 2 scopes in a video using scopehal which is an interesting application. I can see a company interested in allowing their system to have increased support. It is beneficial to the company and the customer in the long run.
<azonenberg>
was it a lecroy and a tek? that was probably me :p
<azonenberg>
It should in theory scale to >2 although i haven't tried with more yet
<GenTooMan>
still a useful application, people seldom examine things with enough detail because they limit themselves to what they they think they have.
<azonenberg>
but yes, i have a lot of fun plans
<azonenberg>
in particular, combining on-fpga LAs with off chip scopes
<azonenberg>
there is no tool that can do that right now afaik
<GenTooMan>
as long as you have a passion for what you do go for it.
<GenTooMan>
still I won't be able to finish 1104X-E support before the weekend LOL
<GenTooMan>
I would like to know how to see if the MSO inputs have been added to a SDS1???X-E
<xzcvczx>
azonenberg: with the csv import will if the first line is numeric does it also use the first line for naming? or does that mean that its decided they are non-numeric?
<azonenberg>
If the first row is non-numeric it's used as headers
<azonenberg>
If numeric it's assumed to be data
<azonenberg>
Timestamps must be in seconds, not sample numbers, and must be in the leftmost column
<_whitenotifier-3>
[scopehal-docs] azonenberg opened issue #25: Document CSV import format - https://git.io/JOyYn
<xzcvczx>
azonenberg: yeah, the waveform is named based on the first line of the csv though, so i am not sure if its picked that up as the header line
<xzcvczx>
azonenberg: also this has a good chance of stuffing me over, should the opengl context be version 4,3 or is 4,2 sufficient for the context?
<xzcvczx>
is there any doc for writing protocol decoders or just look at existing and learn?
<d1b2>
<mubes> @GenTooMan do you mean how to see if the digital inputs are provisioned? That would normally be the job of the missing *OPT? command. You may be able to perform a function that implies the channels are not provisioned such as requesting a wave set and getting no response. Siglent are being very helpful at the moment and tbh I don't think I've met a scope yet that doesn't have 'issues' of one form or another with its SCPI implementation.
juli9610 has joined #scopehal
<_whitenotifier-3>
[scopehal-apps] xzcvczx commented on issue #277: glscopeclient fails to run on Fedora under Wayland due to GLEW init failure - https://git.io/JOyXW
<_whitenotifier-3>
[scopehal-apps] xzcvczx commented on issue #212: glscopeclient requires GL 4.2 even though we don't need most 4.2 features - https://git.io/JOyXa
sam210723 has joined #scopehal
Tost has joined #scopehal
<Degi>
Would it be possible to add python support to glscopeclient / the underlying libraries?
<Degi>
I want it because scopehal has a generic SCPIOscilloscope which all oscilloscopes implement in a standardized way
<GenTooMan>
Degi, 1 the SCPIOscilloscope class inherits from Oscilloscope and SCPIDevice. I believe the only thing SCPIOscilloscope can do is identify the device connected to. It supports no other functionality.
<Degi>
Oh, are the voids just implemented directly in the cpp file... I see
<Degi>
Hmm, though in the header file for example RigolOscilloscope implements SCPIOscilloscope
<GenTooMan>
look at the difference between SCPIOscilloscope.h and RigolOscilloscope.h class definitions the latter has a significant number of additional virtual functions.
<Degi>
yes
<Degi>
So uhh how exactly does glscopeclient interface to it... Afaik all oscilloscope classes implement the same set of functions
<GenTooMan>
it identifies the scope based on vendor then recasts itself accordingly. Each scope only implements a limited set of SCPI commands, inter and intra vendor implementations are different as well.
<Degi>
Hmm, though the implemented functions are all the same, right? Just some return nothing or a zero value / empty array when they're called and the scope doesn't support it
<GenTooMan>
why would one need a inherited class per scope then?
<GenTooMan>
or vendor in this case
<Degi>
Hm, at first I thought there was a standard class with a list of every fuction, but apparently its structured a bit differently...
<miek>
yeah, there is - it's in Oscilloscope.h
<Degi>
But still, they all seemingly have the same interface... though I'm not sure how exactly the programming works, like if you have a "SCPIOscilloscope scope;" and then initialize it with a scope, then how can you access its members which are not defined in SCPIOscilloscope.h?
<Degi>
Ah
<Degi>
Yes so essentially the idea being that you can use the interface that Oscilloscope.h provides in python instead of using the SCPI package and having to write everything yourself
<GenTooMan>
each vendor has a small bit of not implementing stuff. For example with "siglent" the "*OPT?" command is not implemented, and just returns an error.
<GenTooMan>
err returns no error.
<Degi>
Yes and scopehal standardizes the interface
<Degi>
Basically with AcquireData you get a scope trace which is the same for all scopes
<Degi>
Instead of having to deal with stuff like some rigols needing to have the amplitude multiplied by 8 and others not
<GenTooMan>
implementing a python API is a different topic all together. :D
<Degi>
Well, like python bindings for the C++ API
<GenTooMan>
I don't see the people who have written things changing the C++ API however other projects seem to do the latter enough that the python API becomes mournfully mutable.
<Degi>
I mean the C++ API might still be arbitrarily changed till a 1.0 release but I think that should be expected
* GenTooMan
is examining the mapping of channel #'s currently.
<GenTooMan>
it's not entirely generic how things operate. For example you have analogue, trigger and digital channels. so channels 1-4 could be 2 analogue 1 trigger and 1 digital channel (example only).
<GenTooMan>
external trigger I meant :D
<Degi>
I mean isn't that still generic, analog, trigger and digital channels should still behave the same across different scopes...
<Degi>
Apparenty boost python can be used for that... I might have a go at it sometime in the future
<miek>
i hear good things about pybind11
<Degi>
Neat, looks similar to Boost and has builtin documentation support
<Degi>
Yeah, it looks very nice...
<GenTooMan>
well hmm as I was saying about the SCPI implementations ... they create a bit of head scratching sometimes.
<Degi>
Yes, the head was scratched during development of scopehal, it doesn't need to be redundantly scratched if you want to use a scope in python...
<GenTooMan>
actually I am looking to get siglent SDS1XXX working
<GenTooMan>
only SDS2XXX and SDS5XXX are implemented.
<Degi>
Nice
sam210723_ has joined #scopehal
sam210723 has quit [Ping timeout: 240 seconds]
<azonenberg>
xzcvczx: there is not currently any developer facing documentation other than the doxygen comments
<xzcvczx>
azonenberg: ok, thank you
<azonenberg>
the basic idea for writing a decode/math function is to create a new class derived from Filter or PacketDecoder (depending on whether you want to implement the protocol analyzer interface or not)
<azonenberg>
add a line to scopehal.cpp to register the decoder in the global table
<xzcvczx>
yeah i saw that
<xzcvczx>
is there a known issue with the cursor giving incorrect voltages on waveforms?
<azonenberg>
No
<azonenberg>
it should be working correctly
<azonenberg>
Degi: and yes, Oscilloscope is the virtual base class for everything
<Degi>
Neat
<azonenberg>
New private/protected members are often added to various scope drivers to aid in implementation
<azonenberg>
but the public API of each derived class is the same
<azonenberg>
SCPIOscilloscope is a helper class for an oscilloscope that uses SCPI, it's possible in principle to use the Oscilloscope class directly to talk to a non-SCPI instrument
<azonenberg>
the only thing SCPIOscilloscope does is provide a constructor that takes a SCPITransport and parses the *IDN? response
<azonenberg>
the public API is the same
<azonenberg>
There have been some rumblings in the past about creating scripting bindings
<azonenberg>
I'm not entirely opposed to it, but i think we should wait until the project is a bit more mature first
<azonenberg>
GenTooMan: as far as channel numbers go, convention is to have analog first because that keeps the channel indexes the same as the front panel channel numbers
<azonenberg>
after that digital and trigger indexing is up to the driver
<azonenberg>
there is a type field in the channel that lets you query what it is
<azonenberg>
xzcvczx: very interesting
<azonenberg>
can you save a scopesession w/ waveform data and the cursor at the offending spot then uploaded it somewhere i can see?
<azonenberg>
GenTooMan: the main purpose of the different scope classes is translating the Oscilloscope API to SCPI commands
<xzcvczx>
save layout and waveforms?
<azonenberg>
xzcvczx: yes
<azonenberg>
then upload the .scopesession and _data directory
<azonenberg>
it's a similar model to audacity, the .scopesession itself is just metadata w/ no data
<xzcvczx>
btw its reproducible on pretty much any incline in the wave form
<azonenberg>
yeah it's likely an interpolation or rendering bug, i'll have to have a closer look
<azonenberg>
GenTooMan: because no two scopes use the same commands to, say, download waveforms or set trigger levels
<azonenberg>
so the driver classes abstract that away to a common C++ API
<azonenberg>
and yes i expect the C++ API to be changing up to and not including a 1.0 release
<azonenberg>
from there on a breaking change will probably require a new major version
<azonenberg>
So one of the things keeping me from declaring v1.0 is being somewhat confident the Oscilloscope API won't be changing too much anymorre
<GenTooMan>
PS good morning :D
<Degi>
Yeah I guess bindings don't make too much sense till then, especially as I don't have an immediate need and could hack together a python rigol interface for what I need but for the future (after 1.0) it'd be neat
<azonenberg>
Yeah
<azonenberg>
In the near term I want to start making a list of goals for a v0.1 and v1.0 milestone
<Degi>
Oh, there is no 0.1 yet?
<azonenberg>
No. The current stuff says 0.1 in the header comments because i had to call it something
<azonenberg>
but realistically it's pre-0.1 development
<azonenberg>
among other blockers, 0.1 will require functional install packages for windows and linux
<xzcvczx>
azonenberg: i included the original data file as well, you can ignore channel 2, that was just noise
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #318: Incorrect cursor behavior on sharp changes in waveform - https://git.io/JOSrB
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #318: Incorrect cursor behavior on sharp changes in waveform - https://git.io/JOSrB
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #318: Incorrect cursor behavior on sharp changes in waveform - https://git.io/JOSrB
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #318: Incorrect cursor behavior on sharp changes in waveform - https://git.io/JOSr0
<azonenberg>
xzcvczx: ok. i'll have a look. also the other thing i see is that it appears the channel names came from sample data somehow
<xzcvczx>
yeah it took the first line
<azonenberg>
yeah thats a bug too
<azonenberg>
i suspect it has to do with the spaces
<xzcvczx>
the other question i had was the huge number of GS/s it claims
<azonenberg>
So that's an artifact of how the sample rate is displayed
<xzcvczx>
there was 100kS/s and its over the right amount of time in the waveform
<xzcvczx>
ah ok
<azonenberg>
Internally, scopehal stores each waveform as a timebase resolution unit in femtoseconds
<azonenberg>
then each sample has a start time and length measured in multiples of that unit
<azonenberg>
for a typical scope capture timebase unit = period of ADC clock
<azonenberg>
then start time is 0....N-1 and length is 1
<azonenberg>
this common case is known as "dense packed" internally and allows some optimizations in rendering and decoding
<xzcvczx>
ah k that makes sense
<azonenberg>
but the code does not require this because data can be irregularly sampled in some situations, like the output of a math function measuring rise time of each edge in a digital signal
<azonenberg>
With CSV import, the importer does not know a priori what the input sample rate is and has to assume it was irregularly sampled
<azonenberg>
So it sets the timebase to 1fs and puts each sample at the exact time the CSV says it was at
<azonenberg>
with duration equal to the delay before the next sample
<azonenberg>
the rendering code sees a 1fs timebase and reports that you are using a 1 Ps/s scope
<azonenberg>
Eventually it would probably be possible to add some logic to make a histogram of sample delays in the CSV import and if they're all very close to the same value, round a bit in postprocessing
<Degi>
Hm, maybe just calc mean and stddev
<azonenberg>
Yeah. I'm not saying it cant be done
<Degi>
Maybe an optional field to specify sample rate if its an input channel...
<azonenberg>
but it would have to be done as a postprocessing operation once the whole dataset is loaded
<azonenberg>
i've never seen any actual scope do this
<azonenberg>
specify sample rate i mean
<azonenberg>
it can be done in post
<Degi>
oh
<azonenberg>
i just havent put the time in as there was never a good reason
<xzcvczx>
or just run through the data once to see whether its regular
<azonenberg>
Yeah well once everything is loaded i've got timestmps in memory
<azonenberg>
no need to touch the file again
<xzcvczx>
although i guess when you have 192GB ram thats less of an issue
<azonenberg>
It's not wasting memory
<azonenberg>
each sample is still only stored once
<xzcvczx>
haha yeah i know
<xzcvczx>
but IF you get up to stupid size csv files
<azonenberg>
it's just that instead of timebase=50ps and offsets 0,1,2 it's timebase=1fs and offsets=0, 50000, 100000...
<azonenberg>
The waveform is stored in ram after importing anyway
<xzcvczx>
ah ok
<Degi>
Does the data file store the timebase value?
<azonenberg>
The native scopehal waveform object stores the following
<azonenberg>
time scale (the timebase resolution unit)
<azonenberg>
start time of the waveform (time_t)
<azonenberg>
64-bit offset from that second to the actual start of the waveform, femtosecond resolution (since time_t is only 1 sec accuracy)
<azonenberg>
trigger phase (a static offset from nominal time 0 to the first sample clock edge, most commonly used for when you have an analog trigger that's got <1 sample resolution but also used in some instruments to deskew channels etc)
<azonenberg>
the dense packed flag i mentioned previously
<azonenberg>
then a vector of int64 start times for each sample, in timebase units
<azonenberg>
a vector of int64 durations for each sample, in timebase units (must be stored separately because e.g. protocol decode waveforms often have gaps between the end of one sample and start of the next)
<azonenberg>
and a vector of sample data itself, whose type depends on the waveform
<azonenberg>
for digital it's bools, for analog it's float32 volts, for protocol data it's arbitrary class type
<Degi>
Ahh, protocol decodes produce a waveform
<azonenberg>
Yes. The API is completely unified
* xzcvczx
is a big fan of the threshold feature
<azonenberg>
protocol decodes, math functions, and measurements are all one and the same
<xzcvczx>
feature/math function
<azonenberg>
the term "filter" is used internally to refer to all of the above
<Degi>
Neat
<azonenberg>
as it's the classical DSP/multimedia filter pipeline architecture
<azonenberg>
the unified api makes it a lot cleaner and also enables all kinds of interesting special cases
<azonenberg>
like a protocol analyzer that outputs i2c samples as the native waveform type
<Degi>
Hmm, 32 bit float is enough for analog sample?
<azonenberg>
or a sampling scope that outputs eye patterns
<Degi>
Hmm yes that makes sense
<azonenberg>
(eye pattern is a special waveform type with more members since it's not a 1D array of samples, all of the others use this same basic format though)
<azonenberg>
and yes, float32 has enough resolution for anything i've encountered to date
<azonenberg>
anyway, the downside of this is increased ram usage for analog waveforms as you store offset/duration for each sample
<Degi>
Hm well, 23 bit fraction is probably enough for most ADCs
<azonenberg>
if the waveform is not dense packed, you also spend more time copying duration/offset each time the filter executes and may need to use a less efficient processing implementation
<azonenberg>
But the flexibility seemed worth it
<azonenberg>
Generally we write all decodes assuming arbitrary irregular sampling rate then if it's too slow, special case parts of the loop for dense packed
<azonenberg>
there's helper functions in the filter class that do things like sampling one channel on rising edge of another
<azonenberg>
that make no assumptions about sample rate
<Degi>
I guess having multiple waveform types with compatible interfaces to save on RAM wouldn't be worth it? Like you could have a dense sample and if some filter requests times and offsets generate it on the fly
<azonenberg>
that would add way too much complexity
<azonenberg>
some math functions like "subtract" do assume, for now at least, that the inputs are sampled at the same timebase
<azonenberg>
but all of the protocol stuff does not
<azonenberg>
i might want to add improvements for that though because the common case of having two different instruments w/ diff sample rate means you can't do math between them without manually resampling
<azonenberg>
which works but is an extra step
<Degi>
If the subtract filter wouldn't assume that, would it need to sin x/x interpolate each input and then make an output at another sample rate based on that?
<azonenberg>
Yes
<azonenberg>
it would probably pick the higher resolution timebase as the output
<azonenberg>
then interpolate one of the inputs to match the other
<Degi>
Yes thats what I just thought too... That would be neat for interoperability
<Degi>
Do any scopes on the market support different sample rates at the same time?
<_whitenotifier-3>
[scopehal] azonenberg opened issue #424: CSV files with no header parse first line as channel names - https://git.io/JOS6M
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #424: CSV files with no header parse first line as channel names - https://git.io/JOS6M
<azonenberg>
Not to my knowledge. The picoscope 6824E is capable in hardware AFAIK
<azonenberg>
but not in firmware
<azonenberg>
it has two halves each with a 1.25/2.5/5 Gsps ADC, very similar architecture to BLONDEL except faster
<azonenberg>
and 4 channels per half
<azonenberg>
right now both halves have to use the same timebase config
<azonenberg>
but i believe this is an api/firmware limit and not a silicon one
<azonenberg>
as they're two physically separate ADCs
<azonenberg>
i havent looked at the clock tree layout on the PCB thoguh
<Degi>
Hm, aren't lower sample rates most of the time accomplished by downsampling in FPGA / firmware? (Like for sample rates below 1.25 GS/s in this case)
<azonenberg>
Very possible, yes. I havent looked into that either
<xzcvczx>
azonenberg: is there any reason WaveFormArea.cpp claims to require version 4.2 as opposed to 4.3 due to 'compute shaders'?
<azonenberg>
but for example you cannot have a 6824E use one 5 Gsps single channel
<azonenberg>
and four 1.25 Gsps channels on the other half
<azonenberg>
this would be nice to do though
<azonenberg>
xzcvczx: GL_ARB_compute_shader became core in GL 4.3
<azonenberg>
4.2 + GL_ARB_compute_shader might work. I haven't had time to do any testing to see
<xzcvczx>
azonenberg: it does
<azonenberg>
right now i just check for 4.3 as i was not aware at the time i wrote that code of any 4.2-only hardware
<xzcvczx>
thats what i am running it on with ivy bridge
<azonenberg>
everythign i had seen with compute shaders was 4.3+
<azonenberg>
File a ticket and include a glxinfo dump
<azonenberg>
(against scopehal-apps)
<azonenberg>
and i'll have a look at it
<d1b2>
<theorbtwo> Comment out the check amd see if it runs anyway?
<azonenberg>
If i drop the min version from 4.3 to 4.2 i have to make sure i check for every extension i use that's core in 4.3
<azonenberg>
so i have to make sure i know exactly what those are
<azonenberg>
interesting to hear it runs on a GPU that old though
<azonenberg>
i did not know ivy bridge had compute shader support
<azonenberg>
i thought they added that in skylake
<xzcvczx>
mesa made it possible
<xzcvczx>
in v17
<azonenberg>
is it software emulated or actual hardware?
<xzcvczx>
i dont actually know, i only found out about it at all due to an unatrributed note on wikipedia
<xzcvczx>
but the performance isn't terrible with the stuff i sent
<azonenberg>
well hey, if it works
<xzcvczx>
unattributed/unreferenced
<azonenberg>
even slow is better than nonfunctional
<Degi>
A scope would be nice with realtime protocol decode, RF downconversion etc. so you need less sample memory
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #381: Rigol MSO5000: Horizontal scale (timebase) and Vertical scale are wrong - https://git.io/JI47A
<Degi>
Huh wow, there is spin-transfer torque DDR3 RAM... Neat, spin-polarized currents
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #381: Rigol MSO5000: Horizontal scale (timebase) and Vertical scale are wrong - https://git.io/JI47A
<Degi>
Oh no
<azonenberg>
(That's an old ticket, i just tagged it)
<azonenberg>
unsure if still valid but it's now marked as blocking v0.1 release
<azonenberg>
As of now 28 of the 160 tickets filed against scopehal are scheduled for v0.1
<d1b2>
<theorbtwo> Would suggest downgrading not new enough opengl to a warning, and die horribly upon actually using a missing extension?
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #204: Commission a logo/icon - https://git.io/JOSDm
<Degi>
Yess, very much agreed on renaming glscopeclient
<azonenberg>
theorbtwo: so the issue is that compute shaders are used by literally the entire core of the rendering engine
<azonenberg>
as are most of the other things
<d1b2>
<theorbtwo> The question is "to what", of course.
<azonenberg>
So the very first frame rendered after startup will hit that problem
<xzcvczx>
azonenberg: well ivy bridge for example is only missing stencil texturing
<azonenberg>
hence why i just die during startup
<xzcvczx>
so please dont use that :)
<Degi>
Is it possible to print out a console message if that happens?
<azonenberg>
I dont think we use that, so in that case dropping to 4.2 is totally doable, we just have to do a better job of checking for the actual extensions used
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #303: glscopeclient chrome not drawn after changing applications - https://git.io/JOSD6
<xzcvczx>
thats 4.3
<_whitenotifier-3>
[scopehal-apps] azonenberg edited a comment on issue #303: glscopeclient chrome not drawn after changing applications - https://git.io/JOSD6
<xzcvczx>
4.2 my card supports
<d1b2>
<theorbtwo> Can I suggest that "gl" in the name is probably less important then getting the oscillo back in scope?
<Degi>
"UltiScopeClient 9000"
<azonenberg>
Lol
<azonenberg>
Ok... And 29 of the 100 open tickets against scopehal-apps are now tagged for the v0.1 release
<xzcvczx>
azonenberg: thats why i was questioning about that bug
<d1b2>
<theorbtwo> USUI, the universal oscilloscope user interface?
<azonenberg>
It has to be pronounceable
<monochroma>
MysterySignalTheatre3000
<d1b2>
<theorbtwo> Usui is pronounceable, but unfortunately sounds like a gun.
<Degi>
SOUI, S Oscilloscope UI (choose first letter to taste)
<Degi>
(Well, its more than a UI)
<d1b2>
<theorbtwo> "Frontend" is where I would describe it in most software parlance, but "front" is the other end on a scope.
<Degi>
I mean for one there is the front where you plug cables and for two there is the front of the display
<d1b2>
<zyp> I tend to prefer non-descriptive names -- descriptive names has this thing about not being all that descriptive once the project eventually changes scope
<xzcvczx>
nice pun there zyp
<GenTooMan>
@mubes I finally found a way to determine if the MSO digital inputs are available on an SDS1???X-E unfortunately I also found a bug in Siglents firmware at the same time, it doesn't affect the SCPI interface but it does mess with the scope screen.
<GenTooMan>
Oh and never issue MENU OFF for the SDS1???X-E series it stops the normal user interface from working
<GenTooMan>
only way to fix it is to force power down the scope.
<Degi>
Always?
<GenTooMan>
I tried it 3 times
<GenTooMan>
very consistent
<Degi>
I mean like from most menus? Like didn't they test it at all before publishing the current firmware?
<GenTooMan>
oh let me be very specific you can't do anything with the scope from it's face, period, you also can't power it off from the front. It appears to disable the entire scope user interface.
<GenTooMan>
the only way to reset it is unplug it.
<Degi>
Lol
<Degi>
Good thing my rigol has a hard power switch on the front
<GenTooMan>
I was never a fan of soft switches, and I am still learning the wisdom of a hard switch.
<xzcvczx>
azonenberg: btw apparently llvmpipe can do compute shaders
<d1b2>
<mubes> @GenTooMan Good find...what's the trick, I'll try it on the 2000X+. You will find many interesting ways to crash the scope to Big Red Switch....60% of the job of writing these drivers seems to be avoiding tickling the code.
<Degi>
The MSO5000 rigols crash after a hundred or two acquisitions but apparently next month there will be a firmware update
<azonenberg>
degi: if new firmware fixes that
<Degi>
Hopefully...
<azonenberg>
we should check the version in *IDN? and warn if you're using old fw
<azonenberg>
These are the two tickets related to that optimization
<azonenberg>
Both tagged for the v0.1 release but i haven't had a chance to touch them yet
<_whitenotifier-3>
[scopehal] azonenberg opened issue #425: CSV import: allow waveforms to be dense packed if all samples are equidistant - https://git.io/JO9fe
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #425: CSV import: allow waveforms to be dense packed if all samples are equidistant - https://git.io/JO9fe
<azonenberg>
also just filed a ticket for dense packing imported CSV data like we discussed earlier
<_whitenotifier-3>
[scopehal] azonenberg commented on issue #425: CSV import: allow waveforms to be dense packed if all samples are equidistant - https://git.io/JO9fc
<xzcvczx>
nice
<xzcvczx>
damn annoying people demanding features huh :P
<Degi>
Anyways, I can't figure out how to find out the max bandwidth
<d1b2>
<TiltMeSenpai> what happens if you set the bandwidth to a not installed option
<Degi>
I have all options installed though
<Degi>
But yes, if somebody could find that out, would be great
<xzcvczx>
i do wonder what the internal communication looked like at rigol when people worked out all the hacks to enable all the locked features
<d1b2>
<TiltMeSenpai> yeah same, also mine is currently packed for moving so
<GenTooMan>
@mubes you issue "DI:SW ON" then "DI:SW?" to see if it's on, if it's off then the digital option is not installed, the side affect I've yet to get around as it forces the Digital menu active. It seems the SCPI command bypasses the functionality of the "Digital" key, where as it should be using the functionality of the Digital key.
<d1b2>
<mubes> Seems to work in the same way on the 2000X+ too.
<d1b2>
<mubes> Officially :DIGITAL:SW... isn't a valid command on the 2000X+
<d1b2>
<mubes> Yes, that's the other protocol for the other set of scopes....but there's obviously some overlap
<azonenberg>
Well that's why i'm saying, if there are commands that work but arent in the manual we should reach out to siglent
<azonenberg>
Since we have this contact, let's make use of it
<azonenberg>
If it was just an oversight that they forgot to document it, then great
<azonenberg>
fix the manual
<GenTooMan>
@mubes they say it's for the 1000X and 2000X as well, they have a different set of commands listed in the digital interface section for those apparently.
<GenTooMan>
@mubes perhaps "DGST ON" and then "DGST?" to see if it's on would work on the 1000X and 2000X units?
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JO9tU
<_whitenotifier-3>
[scopehal] azonenberg 04bb711 - MockOscilloscope: don't treat lines containing a minus sign as header rows. Fixes #424.
<_whitenotifier-3>
[scopehal] azonenberg closed issue #424: CSV files with no header parse first line as channel names - https://git.io/JOS6M
<xzcvczx>
ah lol dang - character
<xzcvczx>
thanks azonenberg
<GenTooMan>
xzcvczx, you get caught by a negative thing again?
<azonenberg>
xzcvczx: yeah this is the kind of thing i expect to see a lot as we start working with data from more sources
<azonenberg>
GenTooMan: the CSV importer checks if the first row of a CSV file is numeric to decide whether to treat it as a header or as sample values
<azonenberg>
it was incorrectly treating a minus sign as not being numeric
* GenTooMan
responds with "ouch".
<azonenberg>
so if you have a negative value on the first sample it would be imported as a header and your channel would be called -1.234
<azonenberg>
rather than "CH1", "CH2", etc
<Degi>
lol
<d1b2>
<mubes> [ In other news, GLScopeClient compiles and runs on Ubuntu 21.04 ]
<azonenberg>
mubes: :)
<d1b2>
<mubes> ...which is my new daily driver, having murdered the last one
<xzcvczx>
azonenberg: were you saying you run debian ?stretch? earlier?
<azonenberg>
xzcvczx: I run stable, so buster
<Degi>
Hmm, I wonder how hard its to make an Arch AUR package, might have a go
<xzcvczx>
azonenberg: do you use backports or is stable enough for you?
<azonenberg>
if you want to work on it, tag any progress commits with that ticket
<azonenberg>
i would start with making "make install" work properly though
<azonenberg>
the big blocker for that is proper data file resolution
<Degi>
oh
<azonenberg>
so that we can find shaders, toolbar icons, etc in the right spot
<Degi>
Yes thats kinda necessary, though otherwise I could install it with cp
<azonenberg>
there's a bunch of tickets for that
<Degi>
oh
<azonenberg>
right now it assumes everything is in the glscopeclient binary directory and it chdir's to that
<azonenberg>
which is not ideal and also means opening relative paths on the command line as arguments fails
<azonenberg>
because cwd at startup time is ignored
<Degi>
Yeah... A bit suboptimal. I guess it could be put into some random folder and then ln'd to
<azonenberg>
well the proper solution is to add the path search tool
<azonenberg>
so you pass in a relative path and it will search the current dir, /usr/share/scopehal, etc
<Degi>
yes that'd be good
<azonenberg>
Somebody just has to actually build it. and make it work on windows and *nix
<azonenberg>
Packaging, and the prerequisites like path resolution, is one of the biggest blockers to a formal v0.1 release
<xzcvczx>
azonenberg: is the intention also to make it so that you dont need to specify the plugins in scopeprotocols.cpp? so userdirs can be a thing?
<azonenberg>
xzcvczx: binary plugins are already supported
<xzcvczx>
oh ok
<azonenberg>
you have to register them the same way but you do it in an exported function of your own .so
<azonenberg>
then put it in one of a few predefined locations
<Degi>
Neat
<azonenberg>
i've done this already for making non-releasable protocol decodes for proprietary customer protocols
<azonenberg>
(which is why i originally built it)
<Degi>
Is this one of the reasons you chose a BSD3 license? Such as to reach widerspread adoption since some companies probably don't want to release their protocols?
<azonenberg>
Yes. Also to enable integration w/ vendor firmware
<azonenberg>
e.g. if siglent wanted to ship scopehal decodes in their custom UI, or vice versa
<azonenberg>
it might be possible to do w/ LGPL but it would be easy to cause problems
<Degi>
Hm yes makes sense
<azonenberg>
My goal is to displace VISA and custom scripts poking SCPI commands as the dominant API for programmable instrumentation
<azonenberg>
this means being friendly to proprietary code which unfortunately isn't going away any time soon
<Degi>
Does VISA have a common interface across scopes?
<azonenberg>
AFAIK no
<xzcvczx>
well its a beautiful tool so far
<azonenberg>
not this nice, at least
<Degi>
I find it very good that scopehal combines everything, like other, more efficient forms of transport can be used too (as I guess will be in BLONDEL etc.)
<azonenberg>
Exactly. I expect all of my custom instruments will be using two separate sockets over 10/40GbE
<azonenberg>
i'm prototyping this interface in the pico bridge
<azonenberg>
using one socket for scpi control plane commands and another for binary data
<Degi>
Oh, 40 gig on blondel would be dope, could do realtime sampling
<azonenberg>
i may or may not keep the exact same API for my own stuff, but they will be architecturally similar
<azonenberg>
blondel will get 10G
<azonenberg>
40 is expensive and needs more serdes
<Degi>
Well Ok
<Degi>
(Unless you use DAC cables... lol)
<azonenberg>
well the other issue is most people, me included, have very limited 40G capability
<azonenberg>
i have four total switch ports
<azonenberg>
i dont want to use them lightly
<azonenberg>
I have 10G all over the place
<azonenberg>
and 40G to 10G breakout cables are expensive
<Degi>
Hm, though for P2P it would be fine since 40G PCIe cards are like only 25 bucks
<azonenberg>
also right now we are a long ways from having the software performance to actually keep up with 40GbE
<azonenberg>
even the ~2 Gbps the picoscope driver pushes is already hard to keep up with at times
<Degi>
Hmmh yes
<Degi>
Even SIMD has its limits... Though my CPU can do like 60 GFLOPs as I found out today...
<azonenberg>
Well that's where GPUs come in
<azonenberg>
i'm already pushing FIR filters and de-embeds to OpenCL when possible
<Degi>
Hm yes
<Degi>
Hmm, if the 4.2 thing gets implemented, I think I wanna try how good it performs on my laptop
<xzcvczx>
Degi: which graphics card you got? (and what os)?
<Degi>
On my desktop i5675C CPU, GTX980, Arch Linux
<Degi>
(On my laptop the CPU is from the generation before, also arch linux, no dedicated GPU)
<xzcvczx>
Degi: you can probably force it to run on your laptop
<Degi>
Yes, well, just removing the check
<xzcvczx>
i can on my i7-35xx
<xzcvczx>
with no dedicated
<Degi>
OK nice, my laptop is some 4xxx
<xzcvczx>
mesa added support for compute shaders
<azonenberg>
Yeah i'll play with setting the version to 4.2 + GL_ARB_compute_shader shortly
<Degi>
(Though I don't have an actual usecase for my laptop, not even for my desktop till Rigol gets it working)
<Degi>
Hm, I mean if azonenberg wants to fix it shortly, I think I'll wait for that... I wanna have a closer look in the next days anyways to look at the rigol issue with timescale
<Degi>
(or end of next month, when new FW is out)
<xzcvczx>
azonenberg: is there any formats other than csv that are supported by both sigrok and scopehal?
<azonenberg>
Not to my knowledge. scopehal also does not currently have CSV *export* format
<azonenberg>
there's an open ticket for that
<xzcvczx>
ah k, all good currently just trying to get something out of sr into scopehal
<xzcvczx>
as scopehal is much prettier
<_whitenotifier-3>
[scopehal] azonenberg opened issue #426: CSV import: if no header with timestamp, use file modification time as timestamp for history view - https://git.io/JO9sr
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #426: CSV import: if no header with timestamp, use file modification time as timestamp for history view - https://git.io/JO9sr
<xzcvczx>
the (import) csv must contain time in coloumn 1 eh?
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JO9GL
<_whitenotifier-3>
[scopehal] azonenberg 27c30c7 - MockOscilloscope: added NormalizeTimebases() function to detect uniformly sampled data and apply dense packing. Fixes #425.
<_whitenotifier-3>
[scopehal] azonenberg closed issue #425: CSV import: allow waveforms to be dense packed if all samples are equidistant - https://git.io/JO9fe
<azonenberg>
Correct. The CSV format needs to be documented at some point, i think i filed a ticket against scopehal-docs for that already
<azonenberg>
but in short, format is:
<azonenberg>
any blank lines or comment lines starting with # at the start of the file are ignored
<azonenberg>
first non-blank/comment line is header if it contains any characters other than whitespace, commas, digits, or minus signs
<azonenberg>
leftmost column is time in seconds
<azonenberg>
subsequent columns are either 1/0 for digital samples or analog values in volts
<xzcvczx>
ok i need to figure out why sigrok is just giving all 0's for time
<azonenberg>
right now digital samples are converted to analog and have to be thresholded, i will in the future detect '1' and '0' and convert to digital
<azonenberg>
there's an open ticket for that
<azonenberg>
ok hmmmm
<azonenberg>
degi, xzcvczx: it appears our minimum right now is 4.2 not 4.3
<_whitenotifier-3>
[scopehal-apps] azonenberg 2afc795 - Updated shaders to use GLSL version 4.2.0 + extensions rather than 4.3.0, allowing us to run on some OpenGL 4.2 implementations such as Mesa on Ivy Bridge integrated graphics. See #212.
<azonenberg>
xzcvczx: no, i want you to pull latest code and see if it runs as-is :D
<xzcvczx>
ok i will do
<azonenberg>
It should also show correct channel names CH1, CH2 if you re-import the CSV
<azonenberg>
and correct sample rate
<azonenberg>
however the cursor bug is still present
<azonenberg>
i can reproduce but havent touched it yet
<xzcvczx>
ok cool, good to know its not just something broken because of my old ass graphics card
<xzcvczx>
(building now btw)
<xzcvczx>
do you disable a bunch of warnings or are you a very good clean coder?
<azonenberg>
I actually turn on a bunch of extra warnings
<_whitenotifier-3>
[scopehal] miek opened pull request #427: Implement SetAttenuation for AgilentOscilloscope - https://git.io/JO9nE
<azonenberg>
i generally have a zero tolerance policy for them even at high warning levels. there's one or two in the current code for example the MIPI decode ignores some ECC values
<azonenberg>
but that's something i am keeping because there actually is a missing feature for checking that ECC
<azonenberg>
and the warning is a reminder that the code isn't done :p
<xzcvczx>
fair enough
<azonenberg>
but yeah i do -Wall -Wextra -Wuninitialized -Wshadow -Wunsafe-loop-optimizations -Wpedantic -Wcast-align -Wwrite-strings -Wmissing-declarations -Wvla
<xzcvczx>
wow very thorough
<azonenberg>
we're in the process of setting up static analysis but that's still being cleaned up a bit to be more integrated into the build chain
<azonenberg>
it's slow enough it's not on by default
<azonenberg>
you have to do -DANALYZE at cmake time
<xzcvczx>
what are you using for static?
<azonenberg>
cppcheck and clang-analyzer
<xzcvczx>
okay
<azonenberg>
eventual plan is to have that run automatically as part of CI builds
<azonenberg>
We have github CI builds already but they're underutilized. the unit test infrastructure is also almost nonexistent, i think there's two test cases so far
<_whitenotifier-3>
[scopehal] miek edited issue #405: Crash with pure virtual called during destructor when oscilloscope object is destroyed - https://git.io/JOeZZ
<xzcvczx>
thank you miek
<azonenberg>
Hmmmm
<azonenberg>
*very* interesting little bug here
<azonenberg>
if i zoom in really far on the x axis and drag the timebase
<azonenberg>
it appears that the view moves discretely in single sample steps
<azonenberg>
but the time bar moves continuously
<azonenberg>
i suspect the problem is in part caused by that misalignment
<azonenberg>
unsure on root cause so far but probably rounding error
JJJollyjim has joined #scopehal
<azonenberg>
I bet it's WaveformArea_rendering.cpp:207
<azonenberg>
dividing the offset by the timebase unit
<azonenberg>
So offsets of fractional samples don't go through
<azonenberg>
Not yet sure if this is the actual bug i was originally hunting, but it explains some weird behaviors i saw earlier
<azonenberg>
and definitely has to be fixed
promach3 has joined #scopehal
JJJollyjim is now known as Guest97996
JSharp is now known as Guest98452
Guest98452 has quit []
Ekho has joined #scopehal
JSharp has joined #scopehal
<xzcvczx>
azonenberg: do you get disappearing vertical lines on thresholds?
<azonenberg>
I've seen that here and there, it should be mostly fixed but clearly isn't 100% gone
<azonenberg>
probably a rounding artifact. still investigating
<_whitenotifier-3>
[scopehal-docs] mubes opened pull request #26: Addition of SWD documentation - https://git.io/JO9ip
<xzcvczx>
it would be so nice if libsigrok was bsd
<_whitenotifier-3>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JO9y4
<_whitenotifier-3>
[scopehal-docs] azonenberg 840daef - Fixed typo in extension list
<azonenberg>
xzcvczx: yeah well scopehal exists because it's not :p
<azonenberg>
realistically though, i think glscopeclient beats sigrok for most higher end work. it just doesnt have the huge library of decodes for obscure i2c sensors sigrok does
<GenTooMan>
well considering how screwed up peoples priorities have been for the last 4 decades it's no surprise people are "rebelling" against things with FOSS, FOSH, and the FSF etc.
<azonenberg>
Having met RMS, i was never a fan
<xzcvczx>
azonenberg: or the cheap oscope/la protocols
<azonenberg>
Ok, rounding bug found and fixed. But that's not the cursor bug
<azonenberg>
it appears the cursor is sampling half a sample offset from where it should
<xzcvczx>
looks like i am going to have to resort to putting in manual time stamps to this damn csv
<azonenberg>
what, do you have raw data with no timestamps?
<azonenberg>
also i'm working on the cursor incorrect value bug now
<xzcvczx>
sigrok is broke and doesn't output time
<azonenberg>
It looks like it's been there the whole time, but normal scope captures had high enough sample rates for this to not be an issue
<azonenberg>
your captures have enough aliasing it's noticeable
<xzcvczx>
all the timefields are 0 even though the sr file has them all correct
<xzcvczx>
woops my bad
<xzcvczx>
i will get a much better scope soon
<azonenberg>
no good catch
<azonenberg>
lol
<azonenberg>
i wouldnt have found this bug otherwise
<azonenberg>
it looks like somehow i'm sampling from the midpoint of the line segment rather than the end. Investigating now
<azonenberg>
i know the bug is in WaveformArea::GetValueAtTime()
<azonenberg>
just hav eto figure out exactly how to fix it
<azonenberg>
What scope was this captured with? and what are you getting?
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±4] https://git.io/JO9HW
<_whitenotifier-3>
[scopehal-apps] azonenberg bbd85be - Fixed rounding bug causing waveforms to move jerkily in the X axis when the timeline was scrolled
<_whitenotifier-3>
[scopehal-apps] azonenberg 97ea9df - WaveformArea: fixed rounding bug in GetValueAtTime() causing sampling point to be wrong
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #318: Incorrect cursor behavior on sharp changes in waveform - https://git.io/JO9HR
<_whitenotifier-3>
[scopehal-apps] azonenberg closed issue #318: Incorrect cursor behavior on sharp changes in waveform - https://git.io/JOSrB