<Katharina_>
azonenberg want me to store the enum as its underlying value or its name in the config file?
<azonenberg>
Katharina_: I think text is better. we want configs to be readable to the extent practical
<Katharina_>
got it
<azonenberg>
Although this may come to bite us when we do i18n
<Katharina_>
haha yea
<azonenberg>
but unless you change languages you should be ok
<azonenberg>
it just means configs arent portable
<Katharina_>
but its easy to change back but it would fuck up peoples config :')
<azonenberg>
i would never do that for a file format that was meant to be used for interchange
<azonenberg>
but for user settings i think it's ok
<azonenberg>
they're not going to be moving around
<azonenberg>
and if we get to the point of doing i18n we can probably just have a translate subsystem
<azonenberg>
that converts configs from one language to another, using the language stored at the top of the config as a key
<Katharina_>
ok :)
<azonenberg>
anyway, we can worry about i18n in the distant future
<azonenberg>
especially because in the EE space English is pretty much a must-have language to read chip datasheets etc so it's less crucial than in other industries
<azonenberg>
I would expect all of our users know English, Mandarin, or both
electronic_eel has quit [Ping timeout: 240 seconds]
<Katharina_>
im on a caffeine fueled programmign spree :D
<azonenberg>
Lol
bvernoux has quit [Quit: Leaving]
<Katharina_>
oops apparently my english doesnt like that
<azonenberg>
Katharina_: also implementing any of the easy "actually make preferences to do something" tickets
<Katharina_>
sure
<azonenberg>
for example redacting serial numbers in the title bar
<azonenberg>
or the toolbar icon sizes
<Katharina_>
i will quickly redo how i manage rows in the pref dialogue, my software engineering professor must be furious with how i did that
<azonenberg>
lol
<azonenberg>
Also as far as fonts go
<azonenberg>
not sure if there is a ticket for it yet or not
<azonenberg>
but WaveformArea::m_*Font needs to get hooked up to prefs at some point
<Katharina_>
alright :)
<azonenberg>
my sleep schedule is all out of whack so i'm probably going to sleep soon
<Katharina_>
sleep well
<azonenberg>
but i figure there should be enough work to do in the prefs system to keep you from getting stuck
<Katharina_>
definitely
<Katharina_>
its going forward pretty quickly rn which is good
<azonenberg>
:)
<Katharina_>
its good to be able to perform well again after getting the rona
<azonenberg>
Yeah, how's that going? starting to feel more normal finally?
<Katharina_>
there isnt really any impediment left other than i cant really run that far anymore
<Katharina_>
so im doing pretty good id say
<Katharina_>
thank god for german labour laws that i didnt get sacked lmao
<Katharina_>
i was on sick leave for multiple months
<azonenberg>
fuuun
<azonenberg>
Still having a job is definitely nice :p
<azonenberg>
Katharina_: so besides fonts
<azonenberg>
what's left to do on the core of the prefs system as far as functionality goes? anything?
<azonenberg>
the rest is refactoring, cleanup, and prettifying the dialog?
<Katharina_>
id say other than fonts the core features are done
<azonenberg>
one thing to look into, this is probably more on the theming side
<Katharina_>
my todo items are 1) fix the mess that is the row classes in the dialog (doing it rn) 2) use kathi::variant<Ts...> in preference class 3) prettify the dialog
<azonenberg>
but at least on my system the resize handle on the splitter between the tree and the prefs looks a lot like a quotation mark
<azonenberg>
and there's no color cue to distinguish that it's a splitter
<Katharina_>
azonenberg: would be cool if you could get me a screenshot of that when you can
<azonenberg>
i think the best fix is just to set the background color for the splitter bar to a grayish color rather than the same almost-black the background is
<Katharina_>
i agree
<azonenberg>
but i'm not sure if we want to do that globally or only in dialogs
<azonenberg>
so play around a bit and experiment
<Katharina_>
sure
<azonenberg>
let me put it this way, when i first took that screenshot
<azonenberg>
my initial impression was "oh i typoed the name of that pref"
<azonenberg>
looked for an extra quote, didnt find one, got very confused
<azonenberg>
lol
<azonenberg>
Then realized it was the resize handle
<azonenberg>
oh also while we're nitpicking small UI thinkgs
<azonenberg>
things*
<azonenberg>
right now i'm sticking with the windows convention of having ... for menu items that open a dialog, like instrument sync and halt conditions
<azonenberg>
prefs does not have it
<azonenberg>
I don't care much one way or the other
<azonenberg>
but we should be consistent
<azonenberg>
also i feel like the setup menu should probably be reorganized a bit, maybe add some separators... i'm not sure
<azonenberg>
it just feels kinda random right now
<azonenberg>
Not asking you to make any changes at this time, but think about it
<_whitenotifier-f>
[scopehal-apps] nshcat edited pull request #268: Refactored preference dialog internals and implemented font support - https://git.io/JT9Ew
<_whitenotifier-f>
[scopehal-apps] nshcat edited pull request #268: Refactored preference dialog internals and implemented font support - https://git.io/JT9Ew
<_whitenotifier-f>
[scopehal-apps] nshcat synchronize pull request #268: Refactored preference dialog internals and implemented font support - https://git.io/JT9Ew
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #scopehal
esden has quit [Ping timeout: 268 seconds]
esden has joined #scopehal
elms has quit [Ping timeout: 264 seconds]
elms has joined #scopehal
Pretzel4Ever has joined #scopehal
Pretzel4Life has quit [Ping timeout: 268 seconds]
<_whitenotifier-f>
[scopehal-apps] nshcat labeled issue #269: Preferences Dialog: Warn user if they are about to discard changes - https://git.io/JT9ox
<_whitenotifier-f>
[scopehal-apps] nshcat opened issue #269: Preferences Dialog: Warn user if they are about to discard changes - https://git.io/JT9ox
<_whitenotifier-f>
[scopehal-apps] nshcat edited issue #269: Preferences Dialog: Warn user if they are about to discard changes - https://git.io/JT9ox
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #scopehal
bvernoux has joined #scopehal
_whitelogger has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #227: Preference system should support Pango::FontDescription's - https://git.io/JTkqa
<_whitenotifier-f>
[scopehal-apps] azonenberg closed pull request #268: Refactored preference dialog internals and implemented font support - https://git.io/JT9Ew
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 4 commits to master [+0/-0/±19] https://git.io/JTHTT
<_whitenotifier-f>
[scopehal-apps] azonenberg c8541f2 - Merge pull request #268 from azonenberg/kathi_dev Refactored preference dialog internals and implemented font support
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #270: Font size text in font-chooser dialog is dark color and almost unreadable - https://git.io/JTHT4
<_whitenotifier-f>
[scopehal-apps] azonenberg assigned issue #270: Font size text in font-chooser dialog is dark color and almost unreadable - https://git.io/JTHT4
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #270: Font size text in font-chooser dialog is dark color and almost unreadable - https://git.io/JTHT4
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #270: Font size text in font-chooser dialog is dark color and almost unreadable - https://git.io/JTHT4
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #270: Font size text in font-chooser dialog is dark color and almost unreadable - https://git.io/JTHT4
<_whitenotifier-f>
[scopehal-apps] azonenberg unlabeled issue #270: Font size text in font-chooser dialog is dark color and almost unreadable - https://git.io/JTHT4
Katharina has joined #scopehal
<Katharina>
o/
<azonenberg>
o/ Katharina
<azonenberg>
just merged, and found a bug in, your PR :p
<_whitenotifier-f>
[scopehal-apps] Cushychicken opened issue #271: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHTP
<azonenberg>
actually i think it was a bug in the GTK theme from day one
<azonenberg>
But we never used that widget and didn't see
<_whitenotifier-f>
[scopehal-apps] Cushychicken edited issue #271: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHTP
<Katharina>
oh is it the font size in the font button?
<Katharina>
its black on black for me
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #271: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHTd
<_whitenotifier-f>
[scopehal] Cushychicken opened issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHTb
<azonenberg>
Katharina: yeah
<azonenberg>
so fix it :)
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHkI
<_whitenotifier-f>
[scopehal] Cushychicken commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHk8
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHkK
<_whitenotifier-f>
[scopehal] azonenberg edited a comment on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHkK
<Katharina>
ill try ^^ im not very familiar with the themeing
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JTHk7
<_whitenotifier-f>
[scopehal-apps] azonenberg 943bb9e - Refactoring: cleaned up function names that imply Y axis units are always volts. Fixes #59.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #59: Rename "volts" to "Y axis units" in function names, e.g. VoltsToYPosition - https://git.io/JvELy
<azonenberg>
Katharina: i'm not either
<azonenberg>
What may help is the interactive debug features in GTK
<_whitenotifier-f>
[scopehal] Cushychicken commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHkx
<azonenberg>
set GTK_DEBUG=interactive then run glscopeclient
<_whitenotifier-f>
[scopehal] Cushychicken edited a comment on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHkx
<azonenberg>
you should be able to browse the widget hierarchy
<azonenberg>
there's also a box to type in custom CSS and theme widgets dynamically
<azonenberg>
great for trying out theme changes without constant restarts
<azonenberg>
Looking at your current GTK theme in /usr/share/themes/$theme/gtk-3.0/gtk-widgets.css should give you some hints as to the schema
<azonenberg>
i haven't found good documentation on what css properties are available in gtk
<azonenberg>
i'm sure its there but its not easy to find
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHIC
<azonenberg>
monochroma, lain, Katharina: So i have an interesting API problem i'm trying to figure out
<azonenberg>
Working on scopehal:#151, bit depth configuration for LeCroy HDO9000 series. This is to my knowledge the only LeCroy scope with a reconfigurable ADC (although i've heard hints that it might actually just be FPGA filtering on the ADC output)
<azonenberg>
But this is an API we will also need for our HMCAD1520 based scopes
<azonenberg>
The actual interface to the scope is trivial, it's one automation variable i need to poke
<azonenberg>
The harder part is figuring out how to structure the API/UI
<_whitenotifier-f>
[scopehal] Cushychicken commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHLV
<_whitenotifier-f>
[scopehal] Cushychicken edited a comment on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHLV
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHL6
<azonenberg>
So, for HDO9000: there is one global config setting for the entire instrument
<azonenberg>
Default is 8 bit resolution. When you enable "HD mode", according to the info displayed in the GUI, the ADC is reconfigured from 8 to 9 bit resolution. Additionally, a 2 point sin(x)/x interpolation filter is applied, which increases total resolution to 10 bits
<azonenberg>
If you are in interleaved 40 Gsps mode, however, the ADC goes to 10 bit resolution (which makes me think it's actually just two ADCs and FPGA filtering, although I guess it *could* be RAM bandwidth limits somewhere?)
<azonenberg>
then the interpolation brings total resolution to 11 bits. With HD mode active it appears your bandwidth is limited to 1 GHz on 1M ohm inputs
<azonenberg>
as if that isnt confusing enough, on 50 ohm channels your bandwidth is limited to 2 GHz and you get only 0.5 bits of extra resolution from filtering (ADC is still 9 bits)
<_whitenotifier-f>
[scopehal] Cushychicken commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHLj
<azonenberg>
anyway, i think for the most part i dont need to care toooo much about actual bit depth or resolution because ultimately i get 16 bit samples, just some of the LSBs are always zero
<azonenberg>
But it would eventually be nice to be able to display this to the user
<azonenberg>
More fundamentally though there are a couple of scenarios we need to consider
<azonenberg>
a) one global bit depth mode like on HDO9000
<azonenberg>
b) bit depth mode for a group of channels like BLONDEL
<azonenberg>
c) bit depth mode for individual channels like DUDDELL/ZENNECK
<azonenberg>
So i'm trying to figure out what the APIs should look like
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHt3
<_whitenotifier-f>
[scopehal] Cushychicken commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHtC
cushychicken has joined #scopehal
<cushychicken>
Hiya - new guy here. Got a pretty generic question that I sent to azonenberg, but I'd find all your input valuable. How is the scopehal/glscopeclient support for Siglent scopes? I've been kicking the tires of glscopeclient with my benchtop Rigol and there are some gaps in functionality
<cushychicken>
Asking because I am joining a HW startup on Monday, and one of the things I'm looking to invest in is increased productivity for the firmware engineering team
<cushychicken>
From what I can tell: none of them have oscilloscopes, or a means of sharing captures from their nonexistent scopes
<cushychicken>
I've seen some things in the manual that suggest that Siglent firmware was developed in tandem with Teledyne Lecroy, and I've seen enough of azonenberg's Twitter feed to know that glscopeclient has reasonably good support for Lecroy equipment
<cushychicken>
My goal: spend under $5k on lab equipment, help unblock some remote firmware engineers, get some free software to help them capture bugs and file tickets against bad hardware behavior.
<azonenberg>
cushychicken: siglent and lecroy partnered on the WaveSurfer 3000, 3000Z, and 4000HD family
<azonenberg>
they also appear to use a mostly lecroy compatible command set on other scopes, Error_404 has one... sds2000 i think?
<azonenberg>
Rigol stuff in general is flaky and has firmware bugs that make it difficult to support well
<azonenberg>
Siglent has quirks but not as much
<azonenberg>
cushychicken: As far as the channel naming goes, I suspect what is happening is that Rigol does not support displaying named channels in hardware like some higher end scopes go
<azonenberg>
So it falls back on the default implementation of Oscilloscope::GetChannelDisplayName()
<azonenberg>
Which looks at m_channelDisplayNames and doesn't handle the case of no name having been set
<azonenberg>
Give me a minute and i think i have a fix
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JTHYX
<_whitenotifier-f>
[scopehal] azonenberg 1af3ff8 - OscilloscopeChannel: if display name is not set by hardware in constructor, use hardware name
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTHYM
<azonenberg>
cushychicken: please pull latest (make sure to recurse submodules if that's not default for your git config) and test
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHYF
<Katharina>
ok, the variant idea has to be canned, I forgot generic lambdas were introduced in C++14
<Katharina>
variant fundamentally relies on those
<azonenberg>
Katharina: I'm OK with switching to C++ 14 if we have a good reason
<azonenberg>
as long as that's supported by the default compiler on our supported platforms
<azonenberg>
on my debian box --std=c++14 works
<azonenberg>
if current mingw-w64 supports it i'm OK with switching. C++ 20 is off limits until the next debian release at least
<azonenberg>
but 14 or even 17 should be OK
<monochroma>
C++ 30
<azonenberg>
monochroma: lol
<azonenberg>
monochroma: btw, did you see my discussion about the HD bit depth mode above?
<azonenberg>
trying to figure out what our APIs should look like. I wanted to proof of concept on HDO9000 but build the APIs with BLONDEL/DUDDELL/ZENNECK in mind
<azonenberg>
The cases to consider are.
<azonenberg>
* one fixed bit depth
<azonenberg>
* available bit depths vary depending on if interleaving is enabled
<azonenberg>
* bit depth can be configured per channel
<azonenberg>
* bit depth can be configured per block of channels
<azonenberg>
* bit depth can only be configured for the instrument globally
<azonenberg>
I need to figure out how both the UI and API should look
<monochroma>
these are good questions.
<azonenberg>
On lecroy it comes down to
<azonenberg>
if model is HDO other than HDO9000, or WavePro HD, or WaveSurfer 4000HD: 12 bits all the time
<azonenberg>
If model is any other family: 8 bits all the time
<azonenberg>
if model is HDO9000: it gets fun
<azonenberg>
There is a single HD on/off setting but what it does depends on the set of enabled channels
<azonenberg>
tl;dr you always have 8 bits with HD off, with HD on you get 9 on 4 channels or 10 on 2 channels
<azonenberg>
plus an extra bit from some interpolation trickery
<azonenberg>
except that extra bit is not always there
<azonenberg>
yeah, lots of fun complexity :p
<Katharina>
C++17 would mean i wouldnt have to implement variant myself which would be great
<azonenberg>
Katharina: test latest mingw gcc and see if c++ 17 is supported
<azonenberg>
if so, go ahead and do it
_whitelogger has joined #scopehal
<cushychicken>
@azo
<cushychicken>
azonenberg I'd take "quirks" over "flaky"
<cushychicken>
Error_404 would love to hear more about your experience with Siglent/glscopeclient
<azonenberg>
From what i remember the main problem we had was the scope occasionally discarding a command, we think maybe because we sent commands too fast
<azonenberg>
i dont think he had time to fully debug it
<cushychicken>
Seems like spending $1500 on three Siglent SDS1104 scopes would be a good investment then if there's compatibility with glscopeclient
<azonenberg>
Yeah potentially. But you might want to be prepared to do some debugging and testing first
<azonenberg>
cushychicken: as far as getting nice scopes on a budget the other option to consider is going with a higher end model secondhand
<cushychicken>
I don't know that there's necessarily the need to get something high bandwidth - most work they do is around bread-and-butter low speed digital, with a bit of motor control thrown in
<cushychicken>
Though the motor control stuff is mostly outsources to COTS controllers
<azonenberg>
i meant more in terms of stability/feature set
<azonenberg>
more so than bandwidth
<cushychicken>
Ah, sorry - misread that. Yes, I think you're right. I biased for Siglent because:
<cushychicken>
1. They're on Amazon - we could get them more or less overnight
<azonenberg>
Older high-end scopes, while they are bigger and more power hungry than a modern one built around a cheap arm soc, are usually x86 based and have far more horsepower
<azonenberg>
I'm not saying you're making the wrong choice
<azonenberg>
just making sure it's an *informed* choice :)
<cushychicken>
Yeah, I appreciate what you mean. I'm mostly shying away from the higher end vendors because I don't want to deal with the rigamarole of POs right now
<cushychicken>
My experience buying refurb stuff from Keysight (or really anything from Keysight) is that the process is S L O W
<azonenberg>
LeCroy sells some of their refurbs on ebay
<azonenberg>
but i dont see anything in your price/peformance range right now
<cushychicken>
A 100MHz lunchbox would do wonders in unblocking this team.
<azonenberg>
(They do have one WaveSurfer 3024Z actually, you might want to inquire about that?)
<azonenberg>
it's not on ebay but i can put you in touch with the sales rep who handles refurb stuff
<azonenberg>
That's one of the lecroy+siglent collabs
<cushychicken>
I see that a new one of those goes for about $5k. What's a refurb run? $2k?
<tnt>
I'd also point out that compatibility is one thing, usability is another. If the scope is super slow at uploading samples, it's not a great experience :/
<cushychicken>
+!
<azonenberg>
cushychicken: That would be my guess, yes. LeCroy refurbs are generally on the order of half off MSRP
<cushychicken>
+1
<cushychicken>
Hm. OK.
<azonenberg>
and yes that is one of the issues we have with Rigols
<cushychicken>
azonenberg tnt yes, I'm learning all about usability struggle with Rigol in real time XD
<azonenberg>
They work with glscopeclient for the most part, aside from some firmware bugs on the 5000 series
<tnt>
It might actually be good to document the upload time (even some automated benchmark ?)
<azonenberg>
But the cpus are slooow
<azonenberg>
tnt: i've thought about doing that
<cushychicken>
I'd love to help with this
<azonenberg>
set up a standard test case for, say, one channel hooked up to the probe compensation output
<azonenberg>
defined sample rate and memory depth supported by most/all scopes, say 1 Gsps * 10K points
<azonenberg>
and benchmark waveforms per second
<cushychicken>
In any case - I might just end up going with Siglents for now just due to the fact that I can get test equipment in peoples' hands ASAP
<azonenberg>
this could probably be done with libscopehal headless, not using glscopeclient at all
<azonenberg>
and be something you can just run and get a number
<cushychicken>
Even a cell phone picture of the scope screen would be better that what they have now
<azonenberg>
cushychicken: Lol
<azonenberg>
Anyway, siglent seems to be a good choice for low end
<azonenberg>
if you're buying new
<tnt>
having a couple of data points would probably be useful, just to estimate the 'fixed' time and the 'depth/samplerate' dependent part of the time.
<azonenberg>
We'll do what we can to help if you have problems but sometimes we do run into issues on the firmware side that are hard to avoid
<azonenberg>
tnt: yeah good point
<cushychicken>
I agree re:value for money on Siglent - I spoke with one of their reps at a trade show a few years ago and I was impressed by their offerings
<azonenberg>
cushychicken: But we would love to have more people using glscopeclient in commercial environments
<azonenberg>
Especially if they contribute patches or even just testing/feature requests
<cushychicken>
I'd love to get more involved with this. I loved every bit of automation I had on my old workplace's Agilent MSO-9000
<cushychicken>
I hated the price tag
<azonenberg>
also, i'm not sure how familiar you are with the architecture here
<azonenberg>
but the project is fundamentally two separate components
<cushychicken>
This seems like a great way to get all that bang for a little bit of elbow grease
<azonenberg>
libscopehal is the underlying C++ library that abstracts away all of the config and waveform download etc
<azonenberg>
and then its sister component, split off for modularity but in the same repo, libscopeprotocols which has all of the protocol decodes/math functions/measurements
<azonenberg>
then glscopeclient is the UI around that
<cushychicken>
Gotcha - I guess I mean "libscopehal" where I was previously saying "glscopeclient"
<cushychicken>
(still not terribly far along the learning curve here)
<azonenberg>
but for ATE purposes, you can write your own software in C++ that calls directly to libscopehal and runs some automated test
<azonenberg>
as of now glscopeclient, the UI, does not currently have any automation/scripting support
<cushychicken>
But I love the work that's been done here so far. Seeing the MIPI decode got me very excited. We paid $$$$$ for that software at my previous job.
<azonenberg>
however this would be nice to have eventually
<azonenberg>
libscopehal is essentially a less awful VISA replacement
<azonenberg>
to give you an idea of what you can do with it, check out scopehal-apps/src/examples/curvetrace/main.cpp
<azonenberg>
125 lines of code including argument parsing and the BSD license comment
<azonenberg>
and it turns a multimeter and a bench supply into a curve tracer
<azonenberg>
then outputs a CSV to stdout with the measured I/V curve
<azonenberg>
cushychicken: btw did the MIPI decode you had before do framegrab or just packet level decoding?
<azonenberg>
and if it did framegrab, did it let you cross-probe from framegrab back to phy layer waveforms?
<Katharina>
oh id love to work on automation support someday
<Katharina>
i did a lot of work on that kind of stuff at ${DAYJOB}
<Katharina>
our measurement devices are fully scriptable using python (: to great enjoyment of our bigger customers who create huge batch jobs
Katharina has quit [Read error: Connection reset by peer]
<azonenberg>
Currently working on CSV import btw
Katharina has joined #scopehal
Katharina has quit [Quit: Quit]
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±5] https://git.io/JTHuc
<monochroma>
cool, i'm more familiar with the toshiba MIPI to HDMI ASICs
<cushychicken>
No relations with those Wookiees, I have
<_whitenotifier-f>
[scopehal] Cushychicken commented on issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHVD
<_whitenotifier-f>
[scopehal] Cushychicken closed issue #331: Channel names not populating in "Trigger properties" dialogue (Rigol DS1054Z) - https://git.io/JTHTb
<cushychicken>
Can I get some guidance as to how I'd see the raw data being sent from the scope to the scopehal?
<cushychicken>
What I'm seeing on the scope screen does not match what I see in glscopeclient
<azonenberg>
cushychicken: Right now there is no debug output for this. If it's attached by USB and you're on Linux, you should be able to use Wireshark to capture the usb traffic and look at that
<azonenberg>
the other option is to attach a debugger and look at RigolOscilloscope::AcquireData() and see what it's doing
<cushychicken>
Would I at least be able to see the SCPI call to :WAV:DATA? using `--trace SCPITMCTransport`?
<azonenberg>
Yes
<azonenberg>
you just won't see the reply
<azonenberg>
because that's done with ReadRawData(), not ReadReply()
<azonenberg>
and ReadRawData() doesn't do trace logging
<cushychicken>
OK - gotcha - I do not see a call to `:WAV:DATA?` in the SCPITMCTransport trace
<cushychicken>
At least not when I set for single trigger from `glscopeclient`
<azonenberg>
Hmm, interesting
<azonenberg>
It's possible glscopeclient doesnt think it's triggering?
<cushychicken>
When glscopeclient starts up, it's in freerunning auto trigger mode
<cushychicken>
I stop it manually
<cushychicken>
Then click the single trigger in the GUI client
<azonenberg>
So, normal users dont need to know this
<azonenberg>
but when you're debugging, you should
<azonenberg>
glscopeclient does not use auto/normal trigger mode
<azonenberg>
Because if you do that, you can run into problems where you get inconsistent state where half a waveform is from one trigger and half is from another, etc
<azonenberg>
so what looks like free running trigger is actually a sequence of (single trigger, wait, download waveform data, arm trigger again) events
<azonenberg>
The single shot trigger does the exact same thing, it just doesn't re-arm the trigger afterward
<cushychicken>
OK - is that why it starts up with the trace getting spammed with `Sending :TRIG:STAT?` / `Got WAIT` ?
<azonenberg>
That's the scope thread polling the scope to see if it's triggered yet
<cushychicken>
Gotcha
<azonenberg>
there's always a background thread hammering on the scope because scope vendors havent implemented a sane push-based notification protocol
<azonenberg>
anyway, so it looks like what's happening is RigolOscilloscope.cpp:665 in the sscanf is seeing npoints = 0 (third field in the reply to WAV:PRE?)
<azonenberg>
then doesn't download any data because it thinks there's none to be ahd
<azonenberg>
Why the scope is saying there's no data is another question
<azonenberg>
But that's why the driver isn't downloading anything
<cushychicken>
Wait - I think I can guess - flaky firmware? X-P
<cushychicken>
(seems to be something of a theme here with Rigol)
<azonenberg>
Lol. There might be some commands you have to set beforehand to set memory depth or something
<azonenberg>
But it would not surprise me
<cushychicken>
If you can give me a hint on where I can do that I'd be happy to give it a shot before I leave for my 4 PM cookout
<cushychicken>
(thank you so much for handholding me on this)
<azonenberg>
I'm in the middle of debugging CSV import and once I get that working have to hop in the shower myself. I would start out by trying to run the scope in manual mode via the remote interface
<azonenberg>
DS1000Z has Ethernet, right?
<cushychicken>
It does, but I have never tried to use it
<azonenberg>
that's probably easier to debug withthan USB
<cushychicken>
Is Ethernet > USB in most cases?
<cushychicken>
Gotcha
<azonenberg>
because you can just use a standard network tool like netcat to connect to the scope on the remote control port
<azonenberg>
and type commands by hand and see how it replies
<azonenberg>
i do that all the time when debugging drivers
<cushychicken>
Mm, OK. I'll see about rustling up a switch.
<azonenberg>
the command set and everything else should be the same, it's just easier to test on
<azonenberg>
and you can use wireshark etc to debug
<azonenberg>
not that you cant sniff usb with wireshark, but TCP sockets are much friendlier to debug
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTHKE