azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
juli964 has quit [Quit: Nettalk6 -]
maartenBE has quit [Ping timeout: 240 seconds]
maartenBE has joined #scopehal
Degi has quit [Ping timeout: 258 seconds]
Degi has joined #scopehal
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #scopehal
Bird|ghosted has quit [Remote host closed the connection]
Bird|ghosted has joined #scopehal
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #scopehal
<pepijndevos> I can;t for the life of me get the rigol usbtmc0 device to be user accessible
<pepijndevos> I stole some rules from other devices that seem to be working just fine, and changed the vendor and product id
<pepijndevos> I guess back to ethernet...
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+5/-0/±7]
<_whitenotifier-b> [starshipraider] azonenberg 1246693 - Initial work on MAXWELL trigger system architecture
<azonenberg> ok so here's the first block of the trigger system
<azonenberg> The SPME is parameterizable width and takes in 3 probe channels for data, clock, and reset/chip select
<azonenberg> deserializes into N-bit blocks, then checks that block against four constant values
<azonenberg> The output of each comparator is a 4-bit one-hot value indicating the presence and phase of a match
<azonenberg> (since the trigger path runs at 1/4 the sample rate)
juli964 has joined #scopehal
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+2/-0/±3]
<_whitenotifier-b> [starshipraider] azonenberg 8972afe - Initial SPME implementation, lightly tested in simulation
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±5]
<_whitenotifier-b> [starshipraider] azonenberg 1689c83 - SPME: now use bitmask on all comparisons
<azonenberg> ok so 153 total config bits for a SPME, although not all of them are valid for 8/16 bit patter nmatching
alexhw_ has joined #scopehal
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+3/-1/±7]
<_whitenotifier-b> [starshipraider] azonenberg 182ef45 - Initial implementation of PPME
maartenBE has quit [*.net *.split]
alexhw has quit [*.net *.split]
maartenBE has joined #scopehal
<azonenberg> ... OOF i use ~1% of the luts on a 7k160t for a single PPME
<azonenberg> almost entirely on the input crossbar
<azonenberg> I guess i'll only have one of them for the moment
<azonenberg> Maybe two
<azonenberg> SPMEs are much smaller because less crossbar
<azonenberg> Post synth (no optimization) a PPME is 1058 LUT / 89 FF and a SPME is 411 / 70
<azonenberg> block diagram of PPME for referenec
m4ssi has joined #scopehal
<pepijndevos> sigh... even at 1k sample depth glscopeclient is borderline unusable. Pretty much any action hangs the ui for a second because it needs to acquire the lock that is held for receiving the next waveform.
<pepijndevos> Maybe there should be more fifos? Seems bad in general that the UI acquires locks depending on IO, that's basically doing IO in the UI thread.
<azonenberg> pepijndevos: the io done in the UI thread is supposed to be almost instantaneous
<azonenberg> but rigol is sloooow
<pepijndevos> well yea, but if that IO needs to wait on some other slow IO...
<miek> this sounds like the driver still isn't caching all the meta stuff
<azonenberg> queueing write-only operations to yet another thread might make sense, for things like start/stop
<azonenberg> but yeah that sounds like missing caching
<azonenberg> the intent is, during normal operation, for the UI thread to never touch the socket
<azonenberg> it should only lock the cache mutex, which is needed because STL data structures like std::map are not atomic
<azonenberg> but the scope thread should never hold that mutex for more than a few microseconds
<monochroma> probably need to isolate the UI completely from IO tasks, UI threads only run when background IO threads have completed and are 100% ready for the UI to render something
<azonenberg> it should do all of the I/O and *then* grab the mutex, update the cache, and immediately free
<azonenberg> monochroma: the issue is that when you click e.g. start capture
<azonenberg> that's an asynchronous event that goes direct to the scope driver
<azonenberg> But it *should* be almost instantaneous
<azonenberg> incidentally this is why all of the scopes i'm building have separate command and data streams on different sockets
<azonenberg> pepijndevos: do more poking around in gdb
<azonenberg> Look at where the UI thread is blocking
<miek> i'd just scan through the driver code, stuff like this:
<azonenberg> The first one I see not cached is that
<monochroma> azonenberg: mayyybe the scope driver just needs to be non blocking then
<azonenberg> attenuation doesnt cache either
<azonenberg> monochroma: the driver code called from the UI is all supposed to be instantaneous and hit in the cache 100% of the time
<azonenberg> except maybe the very first render cycle
<_whitenotifier-b> [scopehal] azonenberg opened issue #177: RigolOscilloscope::Get/SetChannelCoupling() doesn't cache -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #177: RigolOscilloscope::Get/SetChannelCoupling() doesn't cache -
<monochroma> and the cases where the driver is mis-behaving is why you don't do that :P
<_whitenotifier-b> [scopehal] azonenberg opened issue #178: RigolOscilloscope::Get/SetChannelAttenuation() doesn't cache -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #178: RigolOscilloscope::Get/SetChannelAttenuation() doesn't cache -
<pepijndevos> azonenberg, happy to gdb more, but pretty sure I'll just find the scope thread in recv and the UI thread in whatever button I pressed.
<azonenberg> pepijndevos: those two look like the big offenders
<azonenberg> they're called from the right click menu to set checkboxes in the menu
<azonenberg> among other thigns
<azonenberg> So if they block it bogs down everything
<azonenberg> Anybody have time to write a fix? i'm in the middle of some other stuff but can review a PR if somebody submits one
m4ssi has quit [Remote host closed the connection]
<azonenberg> miek: ?
<azonenberg> at some point we should do a general code quality review of a lot of the drivers
<azonenberg> the LeCroy one is heavily optimized as i use it on a daily basis, most of the others are clearly not up to that level of quality/maturity
<miek> mmmaybe, i don't have the new project structure setup yet
<pepijndevos> What would be interesting is do the get config thing and see where it hangs until I hover the play button
<azonenberg> pepijndevos: yeah
<pepijndevos> I also managed to hang it hard by fiddling with the frontpanel witht he scope running remotely, but that might be expected.
<azonenberg> Not expected, but not surprising either :p
<azonenberg> i had a few crashes in the lecroy driver from that. i think i've fixed those
<azonenberg> but it's easy to have bugs when settings change under your feet
<pepijndevos> If it doesn;t block the Ui thread and has timeouts it should be fine. But it seems neither is fine.
<azonenberg> Yeah
<azonenberg> I pushed very hard on not blocking the UI thread in the lecroy driver
<azonenberg> but it's very easy to write code that blocks if you're not careful about it
<pepijndevos> How do you avoid that when you need to do IO? I would imagine either your API is blocking, or you go with futures and event loops and stuff, so now is this different per driver?
<azonenberg> reads of settings should always cache
<azonenberg> writes might block if an acquisition is in progress but this should be quick
<azonenberg> longer term we might want to think about queueing writes that don't need an acknowledgement, like changing vertical scale
<azonenberg> as a general rule i didn't do a lot of testing with scopes that take more than a couple of ms to respond to a command
<azonenberg> Here's a concept: transports will have two functions for sending commands
<azonenberg> the first one is for sending a command that needs a response
<pepijndevos> Right, so to work properly with scopes that take a second to acquire a waveform... ouch
<azonenberg> actually no we dont even need that
<azonenberg> Just have SendCommand() use a mutex sync to write to a fifo of outbound commands, remove synchronization code from drivers around SendCommand() calls that aren't reading replies
<azonenberg> (since you don't care when that write executes in relation to other stuff)
<pepijndevos> Can you just open two sockets to the same scope?
<azonenberg> No
<azonenberg> Most scopes only support one concurrent connection
<azonenberg> otherwise this would be 100x easier
<azonenberg> I have ideas, let me open a ticket and we'll work on it
<_whitenotifier-b> [scopehal] azonenberg opened issue #179: Add write queueing to transports for better handling of high-latency instruments -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #179: Add write queueing to transports for better handling of high-latency instruments -
<azonenberg> but hey, thanks for being a beta tester and finding an area we need to improve on :
<azonenberg> :)
<pepijndevos> Maybe there should be a single command fifo with a thread executing commands and use futures to notify the sender of the response. the UI is probably event based anyway
<azonenberg> relatively few if any UI accesses need to round trip to the scope
<azonenberg> almost all queries need an immediate response and it's OK if it's a bit stale
<azonenberg> and most commands can be deferred until the current waveform is done with no problem
<azonenberg> but shouldn't block the UI until that point
<azonenberg> Write command queueing should solve this nicely
<pepijndevos> right okay
<azonenberg> It's just going to require a fair bit of refactoring across many drivers
<pepijndevos> hrm...
<azonenberg> Not something that will happen quickly. easily a day or two of work
<azonenberg> But this is one of the reasons why i'm holding off on even considering a general release, publishing binaries, etc
<pepijndevos> I have some holiday in september, who knows...
<azonenberg> i know there are still major changes to be made and breaking refactoring to be done
<azonenberg> I want to do it myself, this is a major architectural change that touches delicate parts of the whole project
<azonenberg> i know that code better than anyone else right now
<azonenberg> Just need a bit of time
<azonenberg> Maybe i can work on it later this week
<_whitenotifier-b> [scopehal] miek opened pull request #180: RigolOscilloscope: cache atten/coupling. -
<pepijndevos> great
<azonenberg> miek: you need to lock the cache mutex when updating the cache
<azonenberg> not just the main mutex
<azonenberg> otherwise cache reads at the same instant could read inconsistent state from the std::map
<azonenberg> Lock the main mutex during the write-to-read interval, save the reply, then lock the cache mutex and parse the reply and update the cache
<azonenberg> Try to avoid holding both at once, and especially avoid locking the main mutex when you hold the cache mutex
<miek> mm yeah. though, this is getting more involved than the drive-by PR i was hoping for :p
<miek> also it's missing a cache on BW limit too
<Degi> Hmh
<Degi> SERDES based AWG
<azonenberg> miek: good catch on the bwl
<azonenberg> yeah that's like 12 round trips to the scope every context menu
<azonenberg> no wonder it's slow
<Degi> huh
<Degi> Oops
<azonenberg> Degi: your driver, you wanna fix it since miek is busy?
<Degi> Yes I can have a look at it
<azonenberg> you can use his PR as a starting point but see my comments re the mutexes
<azonenberg> basically the cache mutex should be grabbed for an instant, used, and immediately released
<azonenberg> and you should never touch a std::map based cache without holding it
<azonenberg> We're now up to 3 things that need caching
<azonenberg> attenuation, coupling, and bandwidth limit
<Degi> Can I just git clone and then fix that
<azonenberg> Sure
<azonenberg> Longer term i'd like to refactor this into a more general attribute framework that doesnt need every driver to manage their own caching
<azonenberg> there's a bunch of duplicated code i think can be cleaned up and unified
<Degi> yess
<azonenberg> but command queueing comes first and that will touch a lot of stuff too
<miek> something else to think about longer term: how do we invalidate that cache? is there even a good way?
<Degi> SetChannelAttenuation is a stub
<azonenberg> miek: No, there's not
<azonenberg> That's what the "refresh" button is for
<azonenberg> time based will lead to random lag spikes, i tried that and it was really disconcerting
<azonenberg> i update the cache with metadata from waveform headers every trigger if it's included in the wavedesc
<azonenberg> the PROPER solution is for the scope (if it has front panel controls at all) to *push* notifications about updates to the client when you move a knob
<azonenberg> basically all of the scpi apis for these scopes are not designed for performance
<azonenberg> they're designed for 1970s era gpib scripting
<pepijndevos> lemme guess, no scope ever has a push api?
<azonenberg> nope
<azonenberg> you know how i figure out if there's a new waveform to display?
<azonenberg> polling a status register in a loop
<Degi> Wait didnt I implmeent that
<azonenberg> on every scope i've checked
<Degi> Hey who deleted my never-ending switch case statements
<azonenberg> Degi: was there some merge conflicting going on or something?
<azonenberg> look at history
<azonenberg> i know there were some fixes to the rigol driver recently and somebody might have screwed up a merge
<Degi> Can I just copy paste it from the copy I have of it
<pepijndevos> New proposal: find a buffer overflow and inject working code in the scope
<Degi> lol
<azonenberg> Degi: lol sure
<azonenberg> pepijndevos: lol
<azonenberg> there are actually some... siglent? scopes people have written open firmware for iirc
<Degi> Ah yes
<Degi> they're deleted from your branch it seems
<Degi> hmm
<miek> did you grab my master maybe?
<Degi> yes
<Degi> wait theyre implemented there it seems
<azonenberg> pepijndevos: and ziggggggy was working on a C# API for the lecroy scopes that would run on the scope and we could write our own, sane, remote control server in C#
<azonenberg> bypassing the maui scpi stack entirely
<miek> my master will be way out of date, the change was on the branch rigol_caching
<Degi> Wait wtf did I git clone
<azonenberg> status of that is apparently up in the air as he no longer works at lecroy, although apparently management planned to release it anyway
<Degi> Ok whatever I cloned it again its there now
<Degi> Truly some galaxy brain code //+ 0.1 in case atten is for example 0.049999 or so, to round it to 0.05 which turns to an int of 500
<miek> oops, i accidentally bought another bench multimeter
<Degi> Ahh I should get a proper multimeter sometime
<azonenberg> miek: which one?
<miek> agilent 34410a
<azonenberg> ah 6 1/2 digit?
<azonenberg> I'm pretty happy with my R&S HMC8012s, 5 3/4 digit, although i think you can probably get better bang for the buck by now
<miek> yup. i'm most excited about an ethernet port on the back though!
<azonenberg> the nice thing about them is they're smallish and fit next to my power supplies
<azonenberg> scopehal supports DMMs
<azonenberg> would love a driver
<azonenberg> although there isnt yet much of a UI for them
<azonenberg> but the APIs exist and i've scripted some experiments using it
<miek> cool. yeah, i'll probably write something at some point
<azonenberg> I also have the early beginnings of a power supply control utility
<miek> i've got a keithley 6.5 digit meter already, but i've been too lazy to do anything with the rs232/gpib on it
<pepijndevos> azonenberg, the efforts to unlock the rigol scopes seem to have resulted in ways to get ssh on the scope and such. Probably trivial to run a daemon on the scope, but an api, not so much probably...
<azonenberg> The other thing that needs to happen is a function generator UI, and we need to figure out how to integrate it with glscopeclient
<Degi> So how was that with mutex and so on
<azonenberg> because most scopes don't support multiple concurrent connections
<azonenberg> Which means you cant just have one socket for the func gen and one for the scope function
<azonenberg> Degi: you should acquire m_mutex when accessing the socket
<azonenberg> release it as soon as you're done doing network operations
<Degi> and m_cacheMutex for cache?
<azonenberg> acquire m_cacheMutex when reading or writing the cache
<Degi> The lock_guard does that for me automatically and releases after the function ends?
<azonenberg> Correct
<Degi> So theres like lock_guard<recursive_mutex> lock2(m_mutex);
<azonenberg> But you can create a new scope with curly braces to hold it for a shorter time
<pepijndevos> azonenberg, maybe another reason to have a single socket thread with a queue and async api, so both applications can send it commands simultaneausly
<azonenberg> pepijndevos: well it's more in terms of higher level structure
<azonenberg> both "apps" would have to be in the same thread
<azonenberg> the same application*
<Degi> WE could have a server and then gui clients heh
<azonenberg> But then how do we handle standalone function generators?
<Degi> like cups
<azonenberg> Degi: so i actually consiered that
<azonenberg> some kind of multi client proxy
<azonenberg> i honestly think that is the cleanest solution
<azonenberg> just havent had time to define the interface for it
<Degi> I guess VNC works too heh
<Degi> Yeah, like minecraft...
<azonenberg> anyway minimize time holding the cache mutex as this can block the UI thead, and especially avoid holding it when the user socket is held too
<azonenberg> the socket mutex*
<Degi> SO it writes to the cache later on, is it in this case right that its held for the whole call
<pepijndevos> You could maybe have a veeery generic command multiplexer daemon that acts as a scope that can accept multiple commands, but serializes them to the scope over one socket
<azonenberg> Degi: no, that's bad. because now while waiting for the reply from DISP? another thread can't call a get*() function
<azonenberg> pepijndevos: yes the challenge is to handle multiple request/response pairs
<azonenberg> and not confusing them
<azonenberg> you'd have to have higher level scpi protocol awareness i think
<azonenberg> when yousee a ? command hold until you get a reply
<azonenberg> basically
<Degi> How do I do it with for only some time? Replace lock_guard<recursive_mutex> lock2(m_mutex); with lock_guard<recursive_mutex> lock2(m_mutex) {stuff}?
<pepijndevos> azonenberg, yea it'd have to be at the scpi level for sure
<azonenberg> Degi: see LeCroyOscilloscope::GetChannelVoltageRange()
<azonenberg> for a good example
<azonenberg> i acquire the cache mutex, check if i have a hit
<azonenberg> if miss, free it, acquire the main mutex, do the network stuff
<Degi> ahh
<azonenberg> Then acquire the cache mutex just long enough to update the cache
<azonenberg> then free everything
<azonenberg> Holding the cache mutex momentarily while the main mutex is locked is fine
<azonenberg> what you want to avoid is blocking on attempting to get the main mutex while the cache mutex is already held
<Degi> Thx
<azonenberg> again this needs to become a more generic settings framework longer term
<pepijndevos> This would also simplify the current command queue complications. the rigol driver could just have two sockets for commands and data, and the siggen could have a third. no queue neede in the ui
<azonenberg> caching should be done in the base Oscilloscope class
<Degi> So if I have cache mutex and do network req it hangs till thats done
<azonenberg> Yeah. Avoid that
<azonenberg> pepijndevos: well the thing is, this will also add latency and require you run a server on your local box
<azonenberg> i want to avoid requiring such a proxy
<azonenberg> It's something i would allow you to use if you want to use the func gen and scope features on a combined instrument
<azonenberg> but not something that should be required to only use one chunk of an instrument
<pepijndevos> hm fair
<azonenberg> initial area for MAXWELL firmware so far
<azonenberg> Brown = xilinx DDR controller (it's massive, lol)
<azonenberg> pink = debug logic that wont be in the final design
<azonenberg> blue = input serialization and buffering
<azonenberg> green = ethernet and tcp/ip
<azonenberg> yellow = triggering
<azonenberg> no actual compression or saving of sample data is implemented yet
<azonenberg> the dram controller just refreshes forever, and the network stack responds to pings, accepts TCP connections on 5025, and bridges that out to a UART going to the stm32
<azonenberg> the trigger logic just outputs intermediate status to a debug IP
<azonenberg> Overall i'm at 22% LUT, 8% FF, 15% BRAM, 85% IO right now
<azonenberg> The IP stack is 1G only, no 10G/40G support yet
<azonenberg> no 10 Gsps channel support yet
<azonenberg> no trig in/out, no pps, lots of more niche features not implemented
<azonenberg> Just getting started, basically trying to sanity check the pinout and clocking structure before finalizing th ePCB
<azonenberg> so far it all looks solid
<azonenberg> Except the trigger logic is failing timing slightly so i have to optimize it more
<miek> you don't need to, just push up to your existing fork of the main repo
<Degi> What does that mean
<Degi> So I can git clone your repo, switch the branch to rigol_caching and then git push that to my fork?
<miek> yeah
<Degi> ah cool
<miek> do something like: git remote add mine; git push mine rigol_caching
<Degi> Oh cool
<Degi> Do I need to check if the bandwidth, coupling, attenuation cache are validß´
<Degi> I guess that'd need a std::map of size_t, bool?
<azonenberg> Degi: no, just check if there's an entry in the cache
<azonenberg> look at the lecroy driver for an example
<Degi> ahh
<azonenberg> if the entry is invalid, delete it from the map
<Degi> if(m_channelCouplings.find(i) != m_channelCouplings.end())
<Degi> This?
<azonenberg> yeah
<azonenberg> so you need to add clear calls to FlushConfigCache()
<azonenberg> i only use boolean valid flags for things like the trigger level that are instrument wide vs per channel
<Degi> Hmh flush is called at the beginning right so that no leftover RAM poop ends up in there
<Degi> okay
<miek> i assume it'll get called by pressing the UI refresh button
<azonenberg> miek: correct
<azonenberg> The ui refresh button flushes the cache on all active scopes then i think forces a redraw
<azonenberg> its sole purpose is to resync the UI with front panel changes
<azonenberg> if you dont make any front panel changes, it should stay synced forever
<Degi> How can I best compile it?
<Degi> Can I clone scopehal-cmake and somehow tell git to use this repo instead
<Degi> I think im done
<azonenberg> Ok so the input buffers, crossbars, and pattern matching blocks pass timing in hardware
<Degi> I think I figured it out
<Degi> Rigol startup vs scopehal-apps make
<Degi> Hmh well rigol is much faster, make only uses 1 core and my CPU isnt the newest
<Degi> Uhh I dont have a build/doc
<Degi> Oh great it segfautls when I do trigger change
<azonenberg> Degi: doc is now a non-default build option
<azonenberg> just go to the cmakecache and enable build_doc
<Degi> Nvm theres online doc now
<azonenberg> i think you can do it on the command line too, cmake .. -DBUILD_DOC=1 or something like that
<azonenberg> You can also do "make -j2" or "make -j4" to build with more cores
<azonenberg> Degi: so you have a fix for the caching and it's more responsive now?
<Degi> Hmh ill first have to get samples on screen and changing trigger causes it to crahs
<azonenberg> well what i'm saying is, if you have a fix for that bug
<azonenberg> send it in, pepijndevos can test it
<azonenberg> the trigger crash is likely unrelated
<azonenberg> Don't hold back a fix for one bug to fix a different one, unless the other bug is new
<pepijndevos> wah?
<azonenberg> pepijndevos: degi fixed the lack of caching but hasnt sent in the code yet
<azonenberg> i was saying she should post the code somewhere you can test it while working on the other bug
<Degi> Hm when I change voltage scale it hangs
<Degi> I can drag the time scale no prob
<Degi> First time right click on trace hangs
<Degi> Setting BW limit hangs
<Degi> And I can only set to 20 M lol
<Degi> How does it find out which bandwidths are avaialble
<azonenberg> Degi: Not sure if there's an option to query that from the scope
<azonenberg> you may have to just have a table to look up by model number
<Degi> Especially what does off translate to for limit_mhz?
<azonenberg> there's a lot of stuff you are expected to just know
<Degi> azonenberg: I mean how does the GUI get a list of bandwidths?
<azonenberg> right now i hard code a list
<azonenberg> an API to query the list is planned
<azonenberg> but not implemented
<azonenberg> I believe my convention (check comments in Oscilloscope.h) is that 0 = no limit
<azonenberg> i.e. instrument max
<Degi> oh
<Degi> Kinda wonder why it hangs though, for nc the replies are instant
<Degi> ping is like 200 µs
<Degi> Wonder why scrolling is slow. its all cached
<Degi> Aha
<Degi> make -j 4 heh
<Degi> Damn should upgrade my PC to a threadripper or something
<Degi> Oh jeez theyre like 4k
<Degi> glscopeclient seems to take a whole while before it sends out the commands
<Degi> Does m_transport->SendCommand(buf); where buf is char [128] send all 128 bytes?
<azonenberg> Yes
<azonenberg> it internally calls write(2) as many times as needed
<Degi> Hmh reducing it to 32 doesnt make it much faster sadly
<Degi> Is there a way to measure time and log it
<azonenberg> a profiler, or just call GetTime() and print to the log (good for temporary quick stuff)
<azonenberg> that returns the current time as a double in seconds.fractional
<Degi> Hmh, do I need something for GetTime
<Degi> nvm
<Degi> nah thats not the slowdown
<Degi> Also why does it trigger like 5 times before displaying something?
<azonenberg> It shouldnt
<azonenberg> it should trigger once and update immediately
<Degi> I mean when I start the program it triggers five times before the gui shows up
<azonenberg> That sounds like a driver bug
<azonenberg> it shouldnt trigger at all until the gui is p, then it should trigger
<Degi> Yeah theres a relatively high latency between inptu change and display
<Degi> Is it normal that it takes 750 ms to acquire data
<azonenberg> With rigol? maybe :p
<Degi> WAV:DATA over nc seems kinda faster
<azonenberg> on my lecroys with shorter (4k point) capture depths i can get 50+ Hz
<Degi> Can I change that in the gui
<azonenberg> If the driver supports it, yes
<azonenberg> It probably doesnt :p
<azonenberg> you wrote it, you should know
<azonenberg> double click the timeline up top
<Degi> SetSampleDepth is implemented
<azonenberg> it should give you a list of valid memory depths and sample rates
<Degi> Even with 1 ks it takes 580 ms
<azonenberg> That sounds awful
<azonenberg> hopefully you can find an optimization to improve it
<Degi> reading the data takes 60 ms
<azonenberg> Wow
<azonenberg> That sounds like an inefficient driver
<azonenberg> Have you worked with profilers before?
<Degi> m_transport->ReadRawData(header_blocksize + 1, temp_buf); takes 15 µs
<azonenberg> And what kind of CPU do you have?
<Degi> size_t header_blocksize;
<Degi> sscanf((char*)header, "#9%zu", &header_blocksize);
<Degi> Some i5 5675 C iirc
<azonenberg> Download vtune, it's free from intel but i think you have to give them your email to make an account
<azonenberg> set it up, spend a little while fiddling with it
<azonenberg> The "hot spots" profiler mode is a good one to start with
<azonenberg> it shows you every function called during the test run and how long it took
<azonenberg> you can drill down to figure out where your time is going
<azonenberg> If we're CPU limited due to inefficiencies in the driver that's a lot of room for improvement
<Degi> Why does m_transport->ReadRawData(11, header); take 70 ms hmh
<Degi> Whatever theres still some 500-700 ms wasted elsewhere
<Degi> Ahh its in a for loop
<Degi> Oh it is for 1 channel what i measured
<Degi> Its 403 ms for all h
<azonenberg> Still, the profiler should give you a better idea of where your time is going
<azonenberg> maybe you can batch requests or something?
<azonenberg> i suspect mostly it's rigol firmware being derpy though
<azonenberg> and slooooow
<Degi> Haha "batch"
<Degi> no
<Degi> What does ReadRawData do? It seems to take the most time, does it wait for TCP reply?
<miek> wireshark might give some hints - see whether most of that delay is waiting for the rigol after a query?
<azonenberg> Yes ReadRawData is a blocking read on the SCPITransport
<azonenberg> and yeah that might be worth doing too
<Degi> Hmh now how to use that...
<Degi> Wow indeed
<Degi> 80 ms response time
<Degi> 96 ends with WAV:DA TA?
<Degi> And gets the response of 1078 bytes length at 5.7837
<Degi> Which is some way after 5.7025
<Degi> ;(
<Degi> The connection is over a shared gigabit switch
<azonenberg> Sounds like the firmware is stupidly slow then
<azonenberg> and there's nothing we can really do but heavy caching to keep the UI responsive
<azonenberg> and minimize time spent waiting on network traffic that isnt absolutely essential
<azonenberg> Degi: you see why BLONDEL is doing all of the waveform processing in FPGA now? :p
<Degi> I can make a damn UART go faster .-.
<noopwafel> my code for the ds1054z grabs 250k points per request, I think you can do more also
<Degi> Yes that decreases the speed by like 20% between 1k and 250 k
<Degi> Like wtf is the scope doing
<noopwafel> but I think it's clear that 'responsiveness' is not exactly on Rigol's priority list, see also: the scope UI
<Degi> Hmh is it slow?
<Degi> Lets just make our own scope but add FibreChannel ha
<noopwafel> there's usually like 0.5s lag on the ds1054z ui :x try e.g. moving the vertical
<noopwafel> anyway this is kind of off-topic :p but yeah the Rigol network interface is sadly frustratingly slow
<Degi> On the MSO5 its solved by freezing the waveform and moving it graphically and when done sampling again
<miek> yeah, the slow rigol UI was what pushed me towards getting an old agilent instead
<miek> i had the fancier version of this scope in an old job, and i guess i was spoiled by it :p
<azonenberg> miek: yeah even the lower end lecroy stuff (rebadged siglent) is a bit slow
<azonenberg> like wavesurfer 3000 etc
<azonenberg> i'm spoiled by working on scopes with five-digit price tags lol
<Degi> Hmm I have a tektronix, sadly its broke
<noopwafel> I mean there are plenty of second-hand scopes in the <$5k range which manage this fine
<noopwafel> rigol situation is just a bit frustrating since they're everywhere+affordable
<azonenberg> Yeah
<azonenberg> And they're awful
<azonenberg> that's what BLONDEL etc are meant to address, although not as cheaply as rigol
<Degi> Wanna make PCIe scope when this thing works out for really cheap
<noopwafel> yeah I mean, I love picoscope for <$1k
<Degi> HMCAD1511, some cheaping out on analog components could give 4 ch for like 300 €
<miek> i mean, there's some issues with them, but i think the 1054z is still a great deal for what it is
<Degi> They all kinda waste on having a screen
<Degi> If it is a PCIe card: No buttons, no screen, no PSU, no case (besides a metal bracket), no housing
<noopwafel> azonenberg: do you have a BOM estimate for BLONDEL?
<noopwafel> ah nm found it in logs, 1k-1.5k
<Degi> Oh and you dont need RAM
<noopwafel> (want)
<azonenberg> noopwafel: Yeah it's next on the list after MAXWELL is done
<azonenberg> I pushed it ahead because i had somebody who wanted to buy one right away, and because it wasn't blocking on corgi to finish the probe power work
<noopwafel> makes sense
<azonenberg> And my good scope is out for service right now which is a partial blocker to BLONDEL characterization
<noopwafel> I do miss having knobs
<azonenberg> sooooo
<noopwafel> when vacation happens (aug?) I will build something with potentiometers in a laser-cut case and see how satisfying that is
<azonenberg> that brings me to an idea i came up with
<Degi> Some kinda USB device with knobs and E Ink displays as labels would be nice
<azonenberg> i wanted to build something similar to what SEMs use for their controls
<Degi> A lan cable?
<Degi> :P
<azonenberg> a usb attached gizmo with channel select buttons (maybe a touchscreen that shows actual channel names or something?) and encoders for selecting scale/offset
<azonenberg> that you could connect to glscopeclient
<noopwafel> ah yeah
<Degi> Hm yes something that outputs keycode impulses or acts as a joystick
<Degi> And not only glscopeclient would be nice... Like actually putting e ink there or so heh
<azonenberg> Yeah. It's been on my mental roadmap for a while but i havent had time to think of actual requirements yet
<noopwafel> yeah I was thinking potentiometers plus a Teensy or so, for the cheap-and-easy hack, but it'd be lovely to have something with display etc too
<Degi> Why not rotary encoders
<Degi> e ink cost monies .-.
<miek> i wouldn't be surprised if the HID spec has an entry for this
<miek> ..right after the magic carpet controller
<noopwafel> so I was originally looking for midi controllers
<noopwafel> I figured there'd be something widely-available with a bunch of knobs that I could just buy
<noopwafel> there are options if you like sliders
<noopwafel> buttons with lights so you can do channel on/off, etc
<Degi> Yes like 2 RGB LEDs on each button / slider / knob heh
<miek> ooh, that's neat. i like the encoder & led combo. i tried to use something like that before but it had pots so syncronising with the PC was annoying
<Degi> Rotary encoder with button would be nice
<Degi> Or double rotary encoder like on some scopes. Sometimes you can pull them out too to activate a switch
<noopwafel> seems like it's all controllable over midi, I'm tempted to just grab one
Stary has quit [Quit: ZNC -]
juli964 has quit [Quit: Nettalk6 -]
Stary has joined #scopehal