<whitequark>
actually half a second is wrong, it's several seconds
<azonenberg>
the context menu has several radio buttons in it whose state depends on hardware
<azonenberg>
I cache those values to improve performance
<azonenberg>
but the first time you query those states on a channel it has to wait a round trip
<azonenberg>
and rigol firmware is slooow
<whitequark>
*every* time i right click there is this massive delay
<azonenberg>
for this reason among others i'm pushing most of those settings to properties dialogs
<azonenberg>
That sounds like a bug where something that should be cached isn't
<whitequark>
i dismiss the menu, right click instantly again, same problem
<azonenberg>
Try stopping the trigger to reduce spam, packet capturing the usb/ethernet interface, and see what traffic gets sent when you open the context menu
<azonenberg>
then file a bug
<whitequark>
if i stop the trigger it's not slow anymore btw
<azonenberg>
Yes, that makes sense
<azonenberg>
What's most likely going on is an artifact of the braindead SCPI model mixing control and data plane traffic
<whitequark>
WTF is happening on my USB bus
<azonenberg>
sending a tiny query to the scope has to block until the waveform download from the last trigger is done
<azonenberg>
You should also be able to do logging via logtools
<azonenberg>
--debug --trace SCPITMCTransport
<whitequark>
why is something doing SET_FEATURE on port 1798 of a hub
<azonenberg>
loool
<azonenberg>
it's not my code, i promise you that :p
<azonenberg>
the linux usbtmc driver? that i can't promise
<azonenberg>
anyway, this is one of the reasons i plan to add write queueing and some other optimizations to transports in the future. but nothing can really save you from opening a context menu/properties dialog without a warm cache
<whitequark>
it's not even the same bus
<whitequark>
anyway
<azonenberg>
because you have to display that info and you have to round trip to the scope to get it
<azonenberg>
and if a waveform download is in progress you can't send any info to the scope until it's done
<whitequark>
what it sends is CHAN1:COUP? CHAN1:PROB? CHAN1:BWL? TRIG:EDGE:SLOPE?
<azonenberg>
On the first time you right click , or every time?
<azonenberg>
they should only ever be queried once
<whitequark>
oh wait
<azonenberg>
Try setting a breakpoint on RigolOscilloscope::FlushConfigCache() and see if it's being called more than the expected once during startup?
<whitequark>
you don't update the submodule in scopehal-cmake
<azonenberg>
... OH
<whitequark>
this sucks
<azonenberg>
scopehal-cmake is dead
<whitequark>
wtf
<whitequark>
oh
<azonenberg>
it hasnt been updated in like six months
<azonenberg>
scopehal-apps is the top level repo
<whitequark>
ohhhhhh
<whitequark>
oh you *fixed* it
<azonenberg>
Yes
<azonenberg>
But i didnt delete the old one
<whitequark>
can you please delete scopehal-cmake
<whitequark>
like, the contents
<whitequark>
not the actual repo
<whitequark>
replace it with a README saying to use scopehal-apps
<whitequark>
what's "catch2"?
<whitequark>
oh, testing thingy
<azonenberg>
Done. and yeah that's listed in the manual of dependencies, or should be at least
<azonenberg>
i use glscopeclient in 4K all the time, but it's on a 1.1 meter display :p
<whitequark>
it's not silly-high! it's just 277 dpi
<whitequark>
silly-high is like 400+
<whitequark>
which also exist although not on laptops
<azonenberg>
anyway the bug is probably me not handling scaling in the mouse event handler
<whitequark>
Pixel 2 XL has a 538 dpi (!) screen
<azonenberg>
i fully expect that 100% of mouse input is going to be mis-scaled
<whitequark>
strangely, no
<azonenberg>
except in dialog boxes which use the core GTK stuff
<whitequark>
dragging the timeline seems to work
<azonenberg>
That makes sense because it only works on deltas
<azonenberg>
and the timeline is its own widget
<azonenberg>
so GTK collision detects your mouse to the timeline
<whitequark>
ah
<azonenberg>
you're probably gettting 1/2 or 2x the motion you should
<azonenberg>
depending on which way the scaling works
<azonenberg>
and gtk collision detects to each plot
<azonenberg>
but within the plot there's no widgets, it's all custom cairo+opengl rendering
<azonenberg>
so all collision detection in there is gonna be wrong
<azonenberg>
e.g. try double clicking the channel name box to open the properties windo
<azonenberg>
it probably wont work with scale=2
<whitequark>
that explains why none of the ui makes any sense to me lol
<azonenberg>
I have a 4K screen on my laptop for work but i dont use GTK scaling, i just set large fonts
<azonenberg>
Which you can't do in glscopeclient yet because the entire user preferences system is in a patch that's being merged tomorrow as soon as katharina fixes a windows build error :p
<whitequark>
hmm but you don't need that
<whitequark>
you need to handle GDK_DPI_SCALE for fonts
<whitequark>
well
<whitequark>
let me rephrase: if you handled GDK_DPI_SCALE for fonts (there's a gtk function for it) you wouldn't necessarily need font preferences for high-dpi screens
<azonenberg>
File a separate ticket for that then. I render text with Pango so it should be easy enough
<azonenberg>
Right now all fonts in the glscopeclient UI are hard coded to fixed pango names/sizes, i want to allow user tweaking of serif/sans serif/monospace etc anyway
<azonenberg>
i create a Pango::FontDescription in the constructor for each unique type of UI element
<azonenberg>
but you can't modify it yet
<azonenberg>
handling font scaling would be a good short term fix though
<azonenberg>
silly me assumign when i ask for a 10 point font i get a pixel size that's 10/72 inches high on the current output device
<azonenberg>
that would make too much sense :p
<whitequark>
hm
<whitequark>
pango doesn't know what you're rendering to, i think?
<azonenberg>
hmm, i thought i had to specify a gdk surface when querying size of a font layout. but i dont remember
<azonenberg>
anyway, i'll work on it when time permits. in the middle of a few dozen things
<azonenberg>
with scale=1 does the UI work better even if it's hard to read?
<azonenberg>
and with a <6 months old build is the context menu more responsive after the first time it loads?
<whitequark>
yes and yes
<whitequark>
actually the first time might be ok too?
<azonenberg>
I'm also trying to speed up the first time load by moving some of that into a properties dialog
<whitequark>
i didnt notice any slowdown
<azonenberg>
which is OK to lag a bit more than a context menu
<azonenberg>
but yes there have been massive performance improvements over the past few months
<whitequark>
what i'd really like to see is usability improvements
<whitequark>
things like remembering which scope i connect to
<whitequark>
but i'll file issues for those when i start actually using it
<azonenberg>
whitequark: there is already a ticket for recently used scopes
<azonenberg>
it will be saved as a preferenec
<azonenberg>
it's one of about ten tickets blocked on having a preferences system
<azonenberg>
which is hours to days from being merged and unblocking them :p
<whitequark>
ahh
<azonenberg>
we also have a new contributor who is actively working on improving the "first user experience" side of things
<whitequark>
excellent
<whitequark>
really glad to hear that
<azonenberg>
documentation, build process tweaks, automated CI builds, eventually packaging/installers
<azonenberg>
we also have unit tests now :D
<azonenberg>
only two of them but hey it's a start
<whitequark>
mhm
<azonenberg>
So yeah the project is definitely picking up steam, we have multiple semi-regular contributors. It's still not really ready for general use as you can see, quite rough around the edges
<whitequark>
i see that it's getting there though
<azonenberg>
but given how far it's progressed during 2020 i think it will be in really good shape bythis time next year
<azonenberg>
yeah
<azonenberg>
i mean at the start of 2020 i think one person other than me had managed to even compile it successfully
<azonenberg>
:p
<whitequark>
i... think i built it in 2019?
<azonenberg>
I think you were that one person then
<azonenberg>
maybe it was a bit before the start of this year, i dont remember
<azonenberg>
anyway, point is it wasn't really that useful to people at that time
<whitequark>
right
<azonenberg>
Hard coded absolute paths etc
<azonenberg>
but yeah, the community is starting to grow so i think it's gonna go nice places moving forward
<azonenberg>
In parallel with all this i'm working on the hardware/accessory side
<azonenberg>
not sure if you saw but my handheld low-z probe is now at 6 GHz bandwidth
<whitequark>
yeah
<azonenberg>
the solder in version is at 3 GHz and i think the next pcb rev will hit 5-6
<whitequark>
not something i can actually use
<azonenberg>
yeah, but as i've mentioned before i'm not trying to be the open hardware competitor to rigol
<azonenberg>
i'm aiming at being competitive with midrange keysight/tek class platforms
<whitequark>
not by price though :p
<azonenberg>
and if some of that trickles down to enable better low end hardware that's great , but i dont expect to be able to compete with rigol on cost
<azonenberg>
whitequark: actually i think i could make a 500 MHz 4 Gsps 8 bit / 2 Gsps 12 bit, 8 channel scope for a price competitive with a new LeCroy HDO
<whitequark>
but... if i need something like that i don't buy new
<whitequark>
i buy used and 20 year old
<whitequark>
if not more
<whitequark>
how old mostly depends on how much i'm ready to pay for shipping tbh
<azonenberg>
Yes, but unfortunately i can't buy PCBs with 20 years of depreciation already baked into the price
<azonenberg>
:p
<whitequark>
you have 20 years of electronics evolution instead!
<whitequark>
anyway, we had this convo long ago re: glasgow
<whitequark>
you make tools for people with infinite cash, i don't :p
<azonenberg>
Lol
<azonenberg>
well that's why i am also trying to make accessories etc as well
<azonenberg>
like the probes
<azonenberg>
which are useful to people on lower budgets. maybe not for a scope but for a specan/SDR it could be handy to have a wideband probe
<whitequark>
yes, that's true
<azonenberg>
i want to make an affordable active differential probe too
<azonenberg>
but also, you can get GHz bandwidth scopes on ebay for low single digit kUSD if they're old enough
<azonenberg>
monochroma grabbed a 5 GHz 10/20 Gsps LeCroy DDA5005A from 2004ish for under $2K
<azonenberg>
it ran windows... 2000? or xp? on it and had i think a pentium 3 and 800x600 display
<whitequark>
yep
<azonenberg>
but it worked with glscopeclient and had 5 GHz of bandwidth for $2K
<whitequark>
your scope is something like 2-3 times the cost of that, right?
<azonenberg>
the ones i'm building?
<whitequark>
yea
<azonenberg>
The 10 Gsps 12 bit ADC i wanted to use for the two highest end models is $3.5K per ADC on digikey
<azonenberg>
so about $25K for 8 channels worth, plus a sodimm of ddr4 to keep up with the 120 Gbps of sample data
<whitequark>
christ. i had no idea they make ADC that expensive (and sell them on digikey)
<azonenberg>
and probably an ultrascale fpga per ~2 ADCs to buffer it
<azonenberg>
and a 12+ layer pcb
<azonenberg>
but the three lower end models will be built around the HMCAD1520 which is 1 Gsps 8 bit / 640 Msps 12 bit (I'll probably run at 500 Msps for PLL reasons) and is $113 on digikey @ qty 1
<azonenberg>
and has lvds output a cheapish fpga can buffer
<azonenberg>
it has four inputs and muxing/interleaving so you can share that sample rate across one, two, or four channels
<azonenberg>
its little brother the HMCAD1511 is slightly cheaper, lacks the 12 bit mode, and is used in the DS1000Z series (one per scope)
<azonenberg>
My first scope, BLONDEL, will have two 4 channel acquisition boards which will each have one of those ADCs and four frontends, so basically two DS1000Zs in 1U
<whitequark>
i'm ambivalent between that and rigols. glscopeclient is nice, and all the high end scopes are just PCs with more steps, anyway
<azonenberg>
you can omit one board to almost halve the system cost although the fpga/ram is shared
<whitequark>
but for low end stuff you get physical UIs and those are good
<whitequark>
even rigol physical UIs
<azonenberg>
BLONDEL is intended to be a stepping stone to the next gen, not necessarily useful by itself
<azonenberg>
DUDDELL, the next model up, will be 250 Msps and have one of those ADCs per channel so you don't lose sample rate when enabling more channels
<azonenberg>
so 500 Msps 12 bit / 1 Gsps 8 bit per channel, individually selectable
<azonenberg>
250 MHz bandwidth*
<azonenberg>
then ZENNECK will be four ADCs per channel, 32 total in a full 8 channel instrment, 500 MHz bandwidth, 4 Gsps 8 bit / 2 Gsps 12 bit, selectable per channel
<azonenberg>
For that system you're looking at a total of $3341 of ADCs at digikey pricing assuming you're only building one unit, then probably an 8-layer board and... two? kintex7s, probably xc7k160t, so $700ish of FPGA
<azonenberg>
all told it would probably be high 4 digit price tag. Considering that commercial scopes with similar specs are low 5 digits it would not be unreasonably priced. but definitely not *cheap*
<azonenberg>
If i made more than one the cost would come down, but i don't expect to ever make enough of them for serious volume discounts to be a factor
<sorear>
it would be nice if "5G" meant cheap commodity adcs
<azonenberg>
sorear: until a few years ago, 10 Gsps 12 bit was "Keysight ASIC" territory
<azonenberg>
now you can buy them on digikey. They're not cheap but it's possible to get them
<azonenberg>
which is already a step forward
<azonenberg>
in a few more years hopefully a next gen will be cheaper on a new process
<sorear>
i'd also like to know what the specs on the ADCs they use for pcie 4 are
OmniMancer has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
mumptai has joined ##openfpga
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
X-Scale` has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
Asu has joined ##openfpga
Asu has left ##openfpga ["Konversation terminated!"]
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 260 seconds]
[X-Scale] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew.]
<whitequark>
azonenberg: once again: i CANNOT reopen an issue on scopehal-apps
<whitequark>
github literally won't let me do that
<whitequark>
stop telling me to do that!
Asu has joined ##openfpga
<whitequark>
azonenberg: oh sorry, that wasn't you
<implr>
hum amdilinx might also mean them adding the infinity fabric thing to fpgas
<implr>
that seems like the easiest way to do it, drop an ultrascale die into an epyc and glue it to the fabric, the chiplet approach is pretty much already set up for that
<azonenberg>
whitequark: also see my other issue comment
<azonenberg>
there are two separate bugs, input and output scaling
<azonenberg>
input scaling is untouched, output scaling is believed fixed
<whitequark>
hm
<whitequark>
fonts are still tiny for me
genii has joined ##openfpga
<azonenberg>
with GDK_DPI_SCALE?
<whitequark>
yeah
<azonenberg>
weeeird
<azonenberg>
because when i override that on my machine all the text gets bigger
<whitequark>
i think they got bigger on the timeline
<whitequark>
btu not on the Y axis
<azonenberg>
it should also have done the rest of the stuff
<azonenberg>
and run glscopeclient ethernet-example.scopesession
<azonenberg>
(there's not yet a UI for opening files when starting up, although once you have glscopeclient running on a file passed on the command line, or a scope, you can then do file|open to load a new one)
<azonenberg>
that's another pending issue
<whitequark>
uh... that doesn't work. "Unable to open file ethernet-example.scopesession"
<azonenberg>
well you have to unpack the tarball first
<whitequark>
yes of course i unpacked it
<whitequark>
and used the right path etc
<azonenberg>
oh
<azonenberg>
you have to specify an absolute path on the command line
<azonenberg>
that's another pending issue
<whitequark>
ugh
<whitequark>
okay
<azonenberg>
glscopeclient chdirs to the build dir in order to load resources and doesnt change back
<azonenberg>
like i said, rough around the edges still
<whitequark>
ok that works
<azonenberg>
this type of polish is one of my big focuses right now, but there's only so many hours in the day
<azonenberg>
and my top priority is implementing protocol decodes i need for work/other projects, or fixing bugs that block other stuff
<azonenberg>
and reviewing PRs from other contributors
<whitequark>
okay, yes, GDK_DPI_SCALE does work
<whitequark>
it's just that Y axis font is really small
<azonenberg>
It's... 10 point i think right now
<azonenberg>
You will be able to change that as soon as we have preferences for font configuration
<whitequark>
yeah, no problem then
<azonenberg>
Which will happen as soon as the preferences system understands what a font is :p
<azonenberg>
Which is one of katharina's current tickets
<azonenberg>
we merged the initial feature branch of the preferences system this morning after finally fixing the windows build issues
<whitequark>
great!
<azonenberg>
now we have four or five more pending tickets for supporting new datatypes in preferences, improving the UX, etc
<azonenberg>
and then we can start adding settings for actual config
<azonenberg>
This was supposed to all have happened months ago
<azonenberg>
then she had the bright idea to get covid and be in the hospital for a while, then be too exhausted to spend time on f/oss stuff for a while after that :p
<azonenberg>
and nobody else had time to touch that part of the code lol
<azonenberg>
but it's coming together slowly
<whitequark>
damn covid. hope she didn't get any permanent damage
<azonenberg>
she was in the icu for a while, has recovered to the point that she was able to go out and run a mile recently but it was utterly exhausting rather than comparatively easy. So she's got a long road to fully recover still
<whitequark>
oh dear :/
<azonenberg>
anyway, she's on the mend and back to working on scopehal stuff
<azonenberg>
So i'm expecting lots more improvements there in the next few weeks
<azonenberg>
She was talking about some gaming setup she has at home that uses CAN to connect various perpherals, i think for flight sim
<azonenberg>
So with any luck we'll see the CAN decoder get finished soonish
<azonenberg>
somebody contributed a half-baked decode like 8 months ago and nobody's touched it since, the ticket is still open
<whitequark>
ooh
<azonenberg>
once that's done i will probably write a J1939 decode
<azonenberg>
i encounter it at work every once in a while
<azonenberg>
we have fancy can protocol analyzers but it'd be nice to be able to decode on a scope too
lambda has quit [Quit: WeeChat 2.9]
lambda has joined ##openfpga
calle__ has quit [Quit: Verlassend]
lambda has quit [Client Quit]
lambda has joined ##openfpga
moho1 has quit [Quit: WeeChat 2.6]
unkraut has quit [Remote host closed the connection]
unkraut has joined ##openfpga
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
kristianpaul has quit [Ping timeout: 256 seconds]
kristianpaul has joined ##openfpga
<Bob_Dole>
I haven't been active in this channel much, but with the news of AMD buying Xilinx confirmed.. is there any reasonable speculation if they'll be less hostile to the FOSS stuff?
<whitequark>
yes
<whitequark>
only speculation though
<Bob_Dole>
I imagined with it only just being confirmed they're being bought that there's been no time for anything concrete on the matter.
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
<daveshah>
Companies move slowly, so don't expect anything overnight
<kc8apf>
acquisitions move even more slowly and often don't shake up the smaller company's organizational structure too much
<daveshah>
I think the timescale here should be O(5 years)