ehntoo has quit [Quit: Ping timeout (120 seconds)]
ehntoo has joined #scopehal
ehntoo has quit [Quit: Ping timeout (120 seconds)]
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<t4nk_fn>
johnsel, you may have been right about the 'vulkansdk' on gentoo
<t4nk_fn>
I was about to make an ebuild when I noticed that the files to be copied, hinted to by glscopeclient-manual.pdf were already on my system
<t4nk_fn>
I downloaded the installer file anyhow, and put it in my projects dir
<t4nk_fn>
then also did the exports,
<t4nk_fn>
-- Found Vulkan: /usr/lib64/libvulkan.so (found version "1.3.224") found components: glslc glslangValidator
<t4nk_fn>
I don't know if that's enough, but I can only run glscopeclient
ehntoo has joined #scopehal
<d1b2>
<johnsel> as opposed to?
<t4nk_fn>
ngscopeclient will still give me 'scopehal-apps/src/imgui/backends/imgui_impl_vulkan.cpp:1076: bool ImGui_ImplVulkan_Init(ImGui_ImplVulkan_InitInfo*, VkRenderPass): Assertion `info->Queue != nullptr' failed. Aborted'
<d1b2>
<johnsel> aah
<t4nk_fn>
euh, nothing really, johnsel, it wasn't really an effect of the exports
<t4nk_fn>
I guess it was always found, but I'm not sure
<d1b2>
<johnsel> well let's go back to the basics, does vulkan work on your system? i.e. can you run vulkaninfo ?
<t4nk_fn>
yes, it gives me a whole buffer+ of info
<t4nk_fn>
which I don't understand ;)
<d1b2>
<johnsel> can you share it with us?
<d1b2>
<johnsel> put it up on a text dump somwhere though not directly in irc please
<d1b2>
<johnsel> probably you know but, just to be sure
<d1b2>
<johnsel> hmm, azonenberg you reading with us?
<ehntoo>
I think you're hitting the same thing I did under Molten
<d1b2>
<johnsel> seems very similar indeed
<d1b2>
<david.rysk> I was running into that on my ivy bridge Linux
<d1b2>
<david.rysk> glscopeclient works but ngscopeclient does not
<ehntoo>
*MoltenVk - the first queue type only has a single queue available, and the allocation logic is trying to hand out two of them
<d1b2>
<david.rysk> Ivy Bridge is super-old though
<d1b2>
<johnsel> I'm not sure if they're all the same problem but it definitely seems like there's some weirdness in the queues requesting
<d1b2>
<johnsel> azonenberg you said that it would take the same queues if there's duplicate/too many requested. Perhaps this is implementation specific and you are actually running out on other systems
<d1b2>
<johnsel> because this is core imgui code that for some reason can't request a queue
<d1b2>
<johnsel> yup I second trying that
<t4nk_fn>
ifdef apple?
bvernoux has quit [Quit: Leaving]
<d1b2>
<johnsel> wihtout the ifdef
<d1b2>
<johnsel> just the return
<t4nk_fn>
ah, ok ;)
<d1b2>
<johnsel> wouldn't do much otherwise no 🙂
<t4nk_fn>
euh, you gotta give me a minute, I'm not exactly sure where to locate the file
<d1b2>
<johnsel> scopehal/VulkanInit.cpp
<d1b2>
<johnsel> you could also do cd lib; git remote add ehntoo https://github.com/ehntoo/scopehal; git cherry pick c3d8fd5866f233d9dd91bddec103e28ed16774fc to cherry pick that commit to your local git repo
<d1b2>
<johnsel> it's a nice trick to try out sometime
<ehntoo>
even cooler, every commit to a fork on GitHub is reachable from every other. `git fetch c3d8fd5866f233d9dd91bddec103e28ed16774fc; git cherry-pick c3d8fd5866f233d9dd91bddec103e28ed16774fc` should work. Though you'd still need to find the file to edit out the apple ifdefs. ;)
<t4nk_fn>
sorry that took a while.. yeah, that changes things
<d1b2>
<johnsel> yeah I wasn't sure if that was going to work because there's some weirdness with relative path in the current git setup
<t4nk_fn>
yeah, I patched it by hand, I'm not the brightest ... apple in the sack ;)
<d1b2>
<johnsel> you know what they say, better on apple patch then 20 in the air
<t4nk_fn>
well, it at least shows me a window, though it doesn't last very long
<t4nk_fn>
but that's no problem... see.. I have no scope ;)
<d1b2>
<david.rysk> There’s the demo scope
<t4nk_fn>
yeah, I found that in glscopeclient
<t4nk_fn>
ngscopeclient crashes out, that's probably not strange
<d1b2>
<johnsel> it shouldn't though
<ehntoo>
it shouldn't crash.
<t4nk_fn>
mmm
<d1b2>
<johnsel> but without a debug build I don't think your error should be all the informative
<d1b2>
<johnsel> but feel free to share
<t4nk_fn>
mmmmm I see, I'll change to a debug build
<t4nk_fn>
I'm close to bed right now though
<t4nk_fn>
but uhm.. I have this chinese LA, fx2lf based, been using pulseview with that
<t4nk_fn>
and recently got some fx2 boards
<t4nk_fn>
and some ADCs and opamps and such
<t4nk_fn>
I'd like to see if I can build something of my own
<t4nk_fn>
starting with perhaps an stm32 adc, see if I can get it to work with this software?
<t4nk_fn>
don't laugh, but I also have a rpi pico and tested that with pulseview.. 500k samples, but it worked
<d1b2>
<johnsel> there's a definitely a way
<d1b2>
<johnsel> thunderscope project is being developped a driver for which is a open source oscilloscope
<t4nk_fn>
but I don't like how pulseview shows the analog part, would rather see something more scope-like instead of LA-like
<d1b2>
<johnsel> I don't know who specifically is working on that but you probably would find it useful
<t4nk_fn>
everything is so cumbersome to adjust and select
<t4nk_fn>
(src/imgui/imgui.cpp:8927: void ImGui::ErrorCheckNewFrameSanityChecks(): Assertion `(g.FrameCount == 0 || g.FrameCount == g.FrameCountPlatformEnded) && "Forgot to call UpdatePlatformWindows() in main loop after EndFrame()? Check examples/ applications for reference."' failed. was the error btw)
<t4nk_fn>
oh btw, I read straight past your mentioning the ifdefs in the first place, ehntoo ... sorry bout that
<t4nk_fn>
yeah, that's probably gonna do it (lol, I had to have a look first, for possible ifdefs :)) )
<ehntoo>
re: inexpensive diy "oscilloscopes", there are a couple raspberry pi pico projects that would probably fit the bill. they're absolutely no replacement for a "real" oscilloscope in most places I reach for one, though.
<d1b2>
<johnsel> nope
<d1b2>
<johnsel> I have a smartscope which is a partly open source 100msps usb scope but I'd easily just go for a cheap rigol or siglent if I had to do it over
<d1b2>
<johnsel> though I might still write a driver for scopehal for it
<d1b2>
<johnsel> sadly they left out the mcu code from the version I bought which handles usb (and in a wacky way) so that's kinda lame
<t4nk_fn>
ehntoo, the first commit stopped the crash indeed
<ehntoo>
cool, that's good to know.
<t4nk_fn>
well, see, that rpi pico is really lousy, not much of an adc
<d1b2>
<johnsel> it's better than you'd think with the pio
<t4nk_fn>
but I was thinking that a bluepill or black has 2.4Msps already
<d1b2>
<johnsel> the beaglebone can do that trick too
<d1b2>
<johnsel> and it does a 100 msps scope this way
<d1b2>
<johnsel> pi pico is not far off afaik
<t4nk_fn>
and if I free up my stm32f4vet6 board from my diy cnc.. that has 3 of those which can be interleaved
<t4nk_fn>
if you'd include the fx2 cheap LAs... that would probably attract a bunch of users
<t4nk_fn>
mmm, that's interesting, johnsel, I hadn't seen those projects before
<d1b2>
<johnsel> yeah just so you're aware, those programmable IO make them punch above their weight in speed
<d1b2>
<johnsel> same w/ the beaglebone which is also sigrok supported and does the same trick with it's pio
<t4nk_fn>
yeah, I have an ecp5 board too, but I aint seeing myself soldering a bga onto my hand-milled pcb anytime soon ;)
<d1b2>
<johnsel> other than that I don't think there is a lot of motivation here to build support for the cheap LAs etc, most here just work with what they have on hand
<t4nk_fn>
yeah, I'm just messing around for fun myself, want to get my foot in the doorway, see where it takes me
<ehntoo>
I may end up writing an fx2lafw driver or socket bridge at some point, I use them somewhat frequently. I'm new to the scopehal codebase, but my impression is that it may take some nontrivial effort to support the "streaming" mode that they usually operate in. that's definitely not going to be in the near term at least for me.
<d1b2>
<johnsel> as a random aside I believe the streaming mode limits the max throughput
<d1b2>
<johnsel> or at least I remember a chinese clone proudly proclaiming they support not using it because of said reason
<d1b2>
<johnsel> might be a storm in a glass of water, but it might be worth looking into
<ehntoo>
it limits the max sample rate. your pipe to the computer has a fixed upper bandwidth, if you want to sample signals at an effective data rate faster than that you're pretty much limited to whatever buffer memory is on the probe.
<t4nk_fn>
I wouldn't have even considered the RP2040 as a go-between myself, but it's very interesting
<d1b2>
<johnsel> for the rp2040 to the pc you do have super slow usb2 though
<d1b2>
<johnsel> 12 mbps or so
<t4nk_fn>
yeah, that's why I want to use the fx2 to do the usb
<d1b2>
<johnsel> they're cheap enough to start with the eval board directly
<t4nk_fn>
I don't know how a breakoutboard would affect things though
<t4nk_fn>
but it sure is nice
<ehntoo>
that's ~an order of magnitude more expensive than an fx2 board.
<t4nk_fn>
but you have to understand that the fx2 is already a step up from full speed usb which I'm used to
<d1b2>
<johnsel> I mean sure but that chip was old 5 years ago
<t4nk_fn>
yeah, I got them for like 4euros a pop
<ehntoo>
old doesn't make them any less useful.
<t4nk_fn>
and fx3 is sort of overkill for me since I don't deal much with fpga
<d1b2>
<johnsel> you're free to do whatever you want ofcourse but I don't see much added value those fx2lp have been perfected as saleae clones and have open source everything already
<t4nk_fn>
look, it's been really really nice chatting to you, I'd like to do it again sometimes, but I was close to bed a decent while ago ..
<t4nk_fn>
gotta shoot
<t4nk_fn>
thanks for the assistance, I appreciate it!
<d1b2>
<johnsel> or maybe in other words, you seem smart people, why not invest your time building something that is a step above what already exists
<d1b2>
<johnsel> but it was nice chatting to you too fomer sure, hopefully we'll run into each other again some ti
<t4nk_fn>
later folks.
ehntoo has quit [Ping timeout: 252 seconds]
massi has joined #scopehal
sajattack[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
sajattack[m] has joined #scopehal
<azonenberg>
Back. Making good progress resetting my sleep schedule
<azonenberg>
johnsel: i'm not running out of queues. all of my nvidia systems i'm doing dev on have 16 instances of queue type #1
<azonenberg>
i allocate one for memory transfers, 8 for each of the filter graph processing threads, and (in ngscopeclient) one for rendering
mikolajw has joined #scopehal
whitequark has joined #scopehal
jevinskie[m] has joined #scopehal
<azonenberg>
what i've found is that if you request e.g. queue type 0 twice, things work fine
<azonenberg>
So i definitely need to work on the queue allocation logic
<azonenberg>
re the other discussion: supporting cheap fx2 LAs is on the todo list, but not currently implemented
<azonenberg>
We are excited about a bunch of open hardware/low cost scope projects including the thunderscope, i actually have a prototype thunderscope on one of my lab benches now that i'm helping debug
<azonenberg>
And then i have a bunch of scopes of my own under development (mostly on ice due to component shortage) however they're targeting higher end performance class (GHz bandwidth, 5 digit price tag)
<_whitenotifier-7>
[scopehal] azonenberg b183f1c - Added SCPIFunctionGenerator class
<bvernoux>
I'm checking the scopehal-apps build on a clean Ubuntu 22.04 LTS
<bvernoux>
Using the scopehal-docs (my version as I have done a fix for Release)
<azonenberg>
ok i just merged some fixes for osx that hopefully wont break anything. doing a clean build to double check and making a few fixes i'll push momentarily
<_whitenotifier-7>
[scopehal-apps] azonenberg a2151d1 - Allow standalone function generators to be added to a session
<azonenberg>
Great. I just added a bunch of infrastructure for function generators, next step is to actually put widgets in the dialog to control the generator
<azonenberg>
that should be quick and likely done before the call
<bvernoux>
So far so good all build fine
<bvernoux>
respecting strictly the scopehal-doc (in my latest PR) for Ubuntu 22.04 LTS on a clean system (installed with wsl2)
<bvernoux>
I just do copy paste ;)
<bvernoux>
There is few warning remaining in actual code
<_whitenotifier-7>
[scopehal-docs] bvernoux eb28719 - Cleanup build steps adding explicit cd for each steps
<_whitenotifier-7>
[scopehal-docs] bvernoux b0a9027 - Merge branch 'glscopeclient:master' into master
<_whitenotifier-7>
[scopehal-docs] azonenberg ff21e17 - Merge pull request #48 from bvernoux/master Cleanup build steps adding explicit cd for each steps
<_whitenotifier-7>
[scopehal-apps] azonenberg 0902ac7 - Initial work on function generator configuration
<_whitenotifier-7>
[scopehal-apps] azonenberg ea6b905 - Continued work on function generator dialog
<_whitenotifier-7>
[scopehal-apps] azonenberg 095101a - Added DejaVu Sans font, now using it by default. Add Greek letters to our font so that we can render them in the UI.
<ehntoo>
nice! are the power waveforms being recorded in a form that can be saved/reloaded, or just shown for display right now?
<azonenberg>
ehntoo: there is no file load/save support whatsoever in ngscopeclient
<azonenberg>
at this time
massi has quit [Remote host closed the connection]
<azonenberg>
Long term, i'm not sure. we have to think about what the behavior of such stuff in offline mode would make sense to be
<azonenberg>
I definitely think at some point it might make sense to have a button to export a trend as a regular scopehal waveform
<azonenberg>
that you can use as input to filter blocks etc
<azonenberg>
but we also have to figure out a lot of details about on/offline handling of stuff
<ehntoo>
the screenshot has me thinking about integrating my Joulescope, where those capabilities would be really useful.
<azonenberg>
in particular i want to support seamlessly transitioning from online to offline
<azonenberg>
if you pack up a laptop and go home from th eoffice
<azonenberg>
you should be able to pick up where you left off and look at your saved session without having to close and reopen it
<azonenberg>
just notice loss of network connectivity and transition to offline mode
<azonenberg>
or at least go offline if you click a button
<azonenberg>
at this point, ngscopeclient is still very much an experimental ui testbed
<azonenberg>
more than just a mockup, the widgets are backed by APIs talking to real instruments, but not nearly something you'd want to use for real work yet
<azonenberg>
The lack of proper load/save support being just one of many issues
<d1b2>
<johnsel> Shit sorry I fell asleep. I have a really bad migraine on top of everything
<d1b2>
<azonenberg> Well feel free to join the call if your'e feeling up to it
<d1b2>
<johnsel> I’ll listen in
<d1b2>
<david.rysk> ngscopeclient doesn’t work on this computer either
<d1b2>
<EGOD> Bump
ehntoo has quit [Quit: Client closed]
Johnsel has joined #scopehal
<azonenberg>
louis: so in ngscopeclient my plan is for each waveform to have a bunch of display settings that apply to the... i dont know what it's going to be called yet
<azonenberg>
the pairing of a plot and a waveform
Johnsel has quit [Remote host closed the connection]
<azonenberg>
i.e. display settings for a particular view of a signal
<azonenberg>
these settings will include flags like persistence on/off, color mode (channel color or a ramp function)
<azonenberg>
and i guess we can add linear vs zero order hold to the list too
<azonenberg>
my thought is when you click the channel properties button you will have two tabs in the dialog, channel/filter settings that apply to the signal as a whole and then view-local settings for the plot you clicked from
<d1b2>
<johnsel> also quick FYI that I did not get in in the call. This imgui is not the Unity imgui.
<d1b2>
<josuah> thank you for letting me join, that offered me a nice overview
<d1b2>
<azonenberg> you can also do --nogpufilter to disable the GPU accelerated waveform processing as a test
<d1b2>
<azonenberg> it will be slower but if the crash is related to some of the vulkan accelerated stuff it should skip that code path
<d1b2>
<Mughees> nogpufilter worked
<ehntoo>
if you're on an intel GPU, I wonder if you might also be hitting https://github.com/glscopeclient/scopehal/issues/685? I don't know if/how it manifests on glscopeclient or what the equivalent patch would be off the top of my head.
<ehntoo>
@Mughees, could you run `vulkaninfo` in a terminal, stick the output in a pastebin or similar and share it here?
<bvernoux>
the look and feel is exactly like Lecroy
<d1b2>
<david.rysk> Huh a new 12-bit model
<d1b2>
<azonenberg> Yes. I actually have an unreleased video review of it from like a month and a half ago
<d1b2>
<azonenberg> i quite liked it
<d1b2>
<azonenberg> i found a small issue on the unit they sent me and contacted them for a resolution before editing and releasing
<d1b2>
<azonenberg> i should follow up
<d1b2>
<david.rysk> I'm hoping my earlier-hardware SDS2000X-Plus isn't obsolete 😛
<electronic_eel>
the siglent website says "up to 350 MHz bandwidth (upgradable to 500 MHz)". if the hw is capable of 500 MHz, why don't they sell a 500 MHz model right away?
<d1b2>
<david.rysk> upselling and calibration
<d1b2>
<david.rysk> there are lots of unlockers available for siglent scopes, and it doesn't seem like siglent cares too much as their distributors openly post about them on eevblog
<d1b2>
<david.rysk> that said, if you were to do that, the scope wouldn't have been calibrated, tested, and certified to 500MHz, so you'll likely have more attenuation than expected
<electronic_eel>
yeah, i have an unlocked siglent siggen and specan
<electronic_eel>
but, why don't they put the 500 mhz model on their website right now if the hw can do it? or aren't they sure they can reliabliy call it a 500 mhz model?
<electronic_eel>
i mean the 2 gsps are a bit tight for 500 mhz and 12 bits
<miek>
they sell a legit 500MHz software upgrade though, it's not just hacked units. they should be ensuring it meets spec
<d1b2>
<david.rysk> so then they're selling it to make a bit more money
<electronic_eel>
strange the "update only" policy. but when it is just a sw update, they will have to cal all the scopes to 500 mhz. so the hackers get a properly cal'ed unit...
<azonenberg>
Yes lol
<d1b2>
<ehntoo> The upgrade option licenses are generally more expensive than buying it from the get-go. I imagine their marketing folks figure it's a more profitable marketing segmentation move.
<azonenberg>
meanwhile e.g. lecroy sells upgrades for some of their higher end scopes but it has to go back for cal
<azonenberg>
its not field installable
<azonenberg>
(and in at least some cases there are parts added/swapped)
<electronic_eel>
yeah, with the bigger scopes they don't install more capable hardware than necessary, because the parts are quite expensive
<azonenberg>
well
<azonenberg>
in the case of e.g. the wavemaster/sda 8zi
<azonenberg>
they are the same hardware up to i think 20 GHz
<d1b2>
<TiltMeSenpai> not gonna lie, if they're actually swapping parts around I feel a lot better about the cost of the upgrade. The Rigol jailbreak kinda feels like a slap in the face because that capability is kinda just... there already
<azonenberg>
and after that they add the DBI deck
<azonenberg>
and then the 25/30 are the same hardware
<electronic_eel>
but do you still have to send the scope to lecroy for the upgrade from say 25 to 30?
<azonenberg>
Yes
<azonenberg>
They do not do field BW upgrades on any scope afaik
<azonenberg>
any other software option you can just punch in a code and be good
<electronic_eel>
maybe they tweak the filters somehow for each bw step, so they have to do a proper cal run
<d1b2>
<ehntoo> On the topic of jailbreaking scopes, one of the projects on the top of my side project stack is writing a scopehal-compatible waveform server that'll run on my Rigol MSO5000 and get waveform update rates that are actually worth using. Still thinking about architecture and whether/how much of the existing app infrastructure on the scope I want to use, though.
<d1b2>
<david.rysk> oh yeah on that topic I also saw that there's an open source FPGA replacement for some of the older siglents
Johnsel has quit [Ping timeout: 252 seconds]
Johnsel has joined #scopehal
<electronic_eel>
hmm, i would prefer if siglent could be convinced to put a SFP+ or SFP28 slot in their higher end scopes and adapt the fpga gateware to allow dumping the data straight off the fpga at full speed
<d1b2>
<david.rysk> do their higher end scopes still use a Zynq?
<electronic_eel>
i'm not sure. didn't the signal path do a teardown? i don't exactly remember, maybe the fpga is shown there
<electronic_eel>
the zynqs don't have a serdes fast enough for sfp28 i think
<azonenberg>
electronic_eel: the sds6000 is ultrascale+ kintex based
<azonenberg>
xilinx disclosed this in a whitepaper somewhere
<azonenberg>
(very little technical details, but they mention that)
<azonenberg>
And we are leaning on every scope vendor we talk to, suggesting they do exactly that
<azonenberg>
R&S actually *has* a SFP+ in one of their higher end scopes, hanging off the fpga
<azonenberg>
but there is no firmware to use it
<azonenberg>
it's just... there
<azonenberg>
i dont even think it links up
Johnsel has quit [Ping timeout: 264 seconds]
<electronic_eel>
maybe for some special government project or something like that. r&s has lots of such deals
<azonenberg>
i think it's more likely that it's an abandoned/future feature
<electronic_eel>
unfortunately the programming manual is quite sparse on how the data transfer with the sfp+ is supposed to work and i don't think they have any software that is capable of using it
<azonenberg>
it costs almost nothing to route the diff pair and put the cage on
<azonenberg>
yes that rigol looks interesting. i'd like to get my hands on one eventually
<azonenberg>
But currently too busy w/ other stuff
<electronic_eel>
i fear that the sfp+ feature of the rigol is either uncomplete or buggy. because there is so few info or programs available for it
<electronic_eel>
but maybe the programs are there and are just not translated from chinese yet? don't know
<d1b2>
<david.rysk> hmm why is beyondmeasure.rigoltech.com on adblock lists
<electronic_eel>
otherwise the design of the rigol scope looks really nice, small rack formfactor and 2 GHz / 10 Gsps is quite usable
<d1b2>
<ehntoo> I like Rigol's gear for what you get for the price, but I think "incomplete and buggy" is unfortunately applicable to quite a chunk of their product portfolio.
<azonenberg>
Siglent is best value for money at the low end IMO
<azonenberg>
rigol's stuff seems to have less attention paid to quality
<electronic_eel>
yeah, i think siglent has better quality too
<d1b2>
<ehntoo> Both in hardware and software. I had to RMA my MSO5000 after a week because some power DCDC stage had loud enough coil whine to make it unusable in my quiet office
<d1b2>
<ehntoo> But considering I paid <$800USD shipped for a 10GSps scope, still worth consideration in certain cases.
<d1b2>
<david.rysk> they advertise 8GSps
<azonenberg>
Also... resistors I needed for the AKL-AD4 rework, plus the new AKL-AV1 stencil, are here
<azonenberg>
will try and assemble one or both tonight after work depending on how tired i am, i woke up at 2am sooo... :p
<d1b2>
<louis> I'm still not jazzed with the waveform display for the pulse width waveform, but not entirely sure what would be better
<d1b2>
<louis> i don't like that the samples are rendered as extending to the next sample (their m_duration s are only as long as the pulse) but I'm not sure what the best thing to do to avoid rendering like that would be, since I don't want to have the rendered line drop to zero (since that's a "possible" reading)
<d1b2>
<azonenberg> So, having the sparse waveform shader handle gaps between samples would be nice to implement at some point
<d1b2>
<azonenberg> i dont want to make too aggressive changes until lain gets the vulkan port done
<d1b2>
<azonenberg> sine that will just mean more variables in the equation
<d1b2>
<azonenberg> Right now i think we only look at the offsets and not the durations
<d1b2>
<azonenberg> and assume the data is gap-free
<d1b2>
<azonenberg> but it'd be totally possible to implement that. probably the right thing to do for sparse data
<d1b2>
<azonenberg> (Since it is not guaranteed to be gap-free)
<d1b2>
<azonenberg> let me file a ticket for that so i remember
<d1b2>
<azonenberg> so no change needed on the filter side, this is a renderer bug
<d1b2>
<louis> made it possible to zoom the histogram filter and revealed some major rendering bug
<d1b2>
<azonenberg> lol oh?
<d1b2>
<azonenberg> i cant tell if that's wrong or not because i dont know what the actual bind counts are
<d1b2>
<azonenberg> that looks plausible for a lot of equal values and a few slightly larger ones
<d1b2>
<azonenberg> or do you mean the fill extendin below zero
<d1b2>
<louis> i meant the extended fill below zero
<d1b2>
<louis> the bin rendering seems fine
<d1b2>
<louis> .s/major/funny/ really
<azonenberg>
ah, ok. Yeah so the histogram shader assumed pixel value 0 was zero counts and just filled pixels from 0 to the highest count value
<azonenberg>
We can fix that if you think there's a reason to make it zoomable
<d1b2>
<louis> if it's not zoomable/scrollable it's hard to look at small bins (they hide behind the label or are hard to tell relative magnitudes)
<d1b2>
<louis> more generally, i don't like when a waveform area can't be zoomed, feels sorta claustrophobic :p
<azonenberg>
eye patterns too? :p
<d1b2>
<louis> maybe? that's probably less practical
<azonenberg>
i do actually want to re-evaluate how i do eyes in ngscopeclient. in particular, i want to render to a fixed (or maybe one of a discrete set of sizes) sized persistence buffer4
<azonenberg>
rather than clearing the potentially significant history if you resize the viewport
<azonenberg>
since it's all a texture, there's no inherent reason why the integration buffer has to be 1:1 with the viewport pixels
Johnsel has quit [Ping timeout: 252 seconds]
Johnsel has joined #scopehal
<azonenberg>
Thinking about how to handle my Siglent SSG5060X-V
<azonenberg>
It's a vector signal generator, so it outputs an RF carrier with I/Q modulation
<azonenberg>
but it also has a low frequency oscillator that can output sine, square, sawtooth, triangle, or DC waveforms
<azonenberg>
this is intended for use in analog modulation but can also be output as a front panel port
<azonenberg>
my tentative thought is to expose the LFO as a function generator
<azonenberg>
the trick being, if you configure analog modulation on the RF port the LFO is used to do that
<azonenberg>
so do i have more knobs to twiddle for analog modulation under the vector signal generator view?
<azonenberg>
or do i have a selector for modulation source and have LFO be one of the options, then you configure the LFO separately?
<azonenberg>
more interesting: it appears that if analog modulation is active, the LFO is disabled
<azonenberg>
i.e. you cannot output the modulation signal and the RF at once. that's a bit odd
Johnsel has quit [Ping timeout: 268 seconds]
<azonenberg>
oh more interesting
<azonenberg>
this only applies to AM
<azonenberg>
if FM, you can output LFO and RF simultaneously
<azonenberg>
also interesting: you are limited to sine and square if using the LFO as a modulation source for FM
<azonenberg>
while if you are not doing FM, you can do triangle and sawtooth
<azonenberg>
well that will make the driver interesting to say the least lol
<josuah>
Earlier, during the call, there was a discussion about how to handle developer API documentation without digging the code for comments.
<josuah>
What I started using and am happy with is a script that turns a header into a .rst document (works with any other language):
<azonenberg>
well so the dream would be end user facing docs generated from the filter source as well
<josuah>
variables, functions, #defines, typedefs... are wrapped with some syntax, and the content are normal .rst or .md formatted text, a bit like litterate programming, but only for the headers
<josuah>
of course, there is Doxygen an the like which already do that
<josuah>
for integrating it with filters, there could be something to extract comments, generate a file with all the comments in a table or in variables, which are referred by the code?
<josuah>
then the whole source (filters or dev API) could use the same documentation format, with a special case for what also need to be documented into the GUI?
<azonenberg>
We have doxygen comments in the source
<azonenberg>
but i dont know if we actually have a doxyfile or any cmake integration
<azonenberg>
(if we do it's waaaay out of date)
<azonenberg>
and coverage is not the best
<azonenberg>
The question is mostly about whether it makes sense to put end user facing docs in the code
<azonenberg>
i'm leaning towards no
<azonenberg>
dev docs are a different story
<josuah>
so it is a matter of having the documentation written and actually generated more than finding a way to di it?
<josuah>
azonenberg: user-facing docs could have a lot of section not bound to any piece of code, like a "get-started" or "compiling on Linux/MacOS/Windows"
<josuah>
did you want to drop the LaTeX format or just host it somewhere else?
<josuah>
the PDF does look good at least to me.
<azonenberg>
At this point my priority #1 is getting it written
<azonenberg>
it's straightforward to copy-paste content from a .tex to a .md or whatever and change some formatting codes
<azonenberg>
My priority for documentation at the moment is, specifically, filter blocks
<azonenberg>
the UI docs are not the greatest but with the major UI rewrite in progress anything we'd write now will be obsolete soon on that front
<azonenberg>
transports and drivers are fairly well documented at this point
<azonenberg>
so the main hole in the backend docs is filters