ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
<d1b2>
<azonenberg> The reason scopehal and scopehal-apps are separate repos is that long term we wanted to allow this kind of use case
<d1b2>
<azonenberg> Short term, we've put no effort into allowing separate builds or easy integration with third party tools
<d1b2>
<azonenberg> because the v0.x series has no api stability guarantees
<d1b2>
<azonenberg> i.e. we figured that making it too easy to use from outside tools would encourage people to make code that would be constantly breaking as we refactored
<d1b2>
<azonenberg> So while that does need to happen eventually we figured it was best to kick the can down the road a bit longer and focus on shorter term priorities
<d1b2>
<azonenberg> You can add timeouts, the socket transport has this capability already
<d1b2>
<azonenberg> In general, cleaner and more consistent error recovery is something we should spend some time working on
<d1b2>
<chille0417> Okay, then I will just continue to use my hardcoded CMakeLists.txt for now.
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<d1b2>
<azonenberg> Working on a new filter, somebody sanity check me: given two analog signals for data and clock and thresholds for Vih / Vil of the input buffer
<d1b2>
<azonenberg> setup time is data valid to clock invalid
<d1b2>
<azonenberg> i.e. time from data stable to the beginning of the clock edge
<d1b2>
<azonenberg> hold time is clock valid to data invalid
<d1b2>
<azonenberg> i.e. time from end of the clock edge to data beginning to change
<Bird|otherbox>
I'd say "clock changing" and "clock stopping" (vs. "clock valid" and "clock invalid")
<d1b2>
<azonenberg> Valid meaning "has a defined level above Vih or below Vil"
<d1b2>
<azonenberg> and invalid meaning "between Vil and Vih"
<Bird|otherbox>
ah, I see
<d1b2>
<azonenberg> so clock invalid means it's far enough into the edge that you're in the uncertainty band of when the input buffer samples the signal
<d1b2>
<azonenberg> so you have to measure setup time to the beginning and hold time to the end, with the slew time itself not counting towards either since the exact trip point of the buffer is not known
<d1b2>
<azonenberg> ditto for data
<d1b2>
<azonenberg> you care about the point at which the data has changed by a sufficient amount that sampling there could give an incorrect value
<d1b2>
<azonenberg> also as part of this filter i'm piloting a new design pattern for filters
<d1b2>
<azonenberg> rather than having a string name for filter parameters you instead cache a FilterParameter& in th econstructor
<d1b2>
<azonenberg> I'm liking it, and i think i'm going to try to make this the new way going forward
<d1b2>
<azonenberg> it means no need for a bunch of map index lookups during Refresh()
ALTracer has quit [Read error: Connection reset by peer]
<d1b2>
<azonenberg> now displays timestamps plus nice color coded backgrounds of messages
<d1b2>
<josHua> oo
<d1b2>
<azonenberg> Debating whether to make this on by default or not
<d1b2>
<azonenberg> It's really starting to feel like an IDE lol
<d1b2>
<azonenberg> with the stream browser plus the log viewer
<d1b2>
<azonenberg> and tabs of stuff in the middle
<d1b2>
<azonenberg> (i've already changed the warning message color to have better contrast, this is just a draft)
<d1b2>
<josHua> I would say 'not on by default, but pops up if an error or warning fires'?
<d1b2>
<azonenberg> So i actually just came up with that idea independently about a second before you posted it
<d1b2>
<azonenberg> I think that's gonna be the answer
<d1b2>
<azonenberg> As part of that, we will want to make a pass through filters and make them print logs if they can't run due to invalid config
<d1b2>
<azonenberg> (and make the log sticky so it won't print every graph refresh if the config hasn't changed)
<d1b2>
<josHua> the other side of it: if a user has to look at the logs to diagnose what has gone wrong, rather than an inline error message at the point of failure, that's probably a defect
<d1b2>
<azonenberg> So this is me wondering about making the stdout log a more forward facing source of error feedback rather than just being a developer tool
<d1b2>
<azonenberg> i.e. something akin to IDE compile results
<d1b2>
<azonenberg> where it's basically expected that as you tweak the filter graph you'll create invalid states and want to see an explanation of what's wrong, but without a big in-your-face popup that will annoy a power user in the middle of making a bunch of changes knowing the intermediate state is invalid
<d1b2>
<vipqualitypost> i was going to chime in about that, the error handling in freecad shows up as error logs but tends to be extremely frustrating, maybe some modal thing would be nicer.
<d1b2>
<azonenberg> We can figure out if and how to make this a more user oriented error feedback flow later
<d1b2>
<azonenberg> in particular i want to set up a nice gui for turning on debug trace capabilities and changing log levels at run time
<d1b2>
<azonenberg> rather than having to restart and change arguments to get extensive logging
<d1b2>
<chille0417> The OWON HDS200 series have yet another amazing SCPI implementation! You can not explicitly set a manual range on the DMM. But you can ":DMM:RANGE ON" to toggle between the modes, then you can ":DMM:RANGE?" to see what mode was selected. 🚀
<d1b2>
<fredzo_72653> Maybe add a status-bar at the bottom of the main window that displays the last error level log, and have the full LogWindow expand when you click on the status-bar ?
<d1b2>
<azonenberg> Interesting idea i'll think about that
<d1b2>
<azonenberg> seems to be giving plausible values
<d1b2>
<fredzo_72653> @azonenberg I added a timeout on read operations for Windows UART: https://github.com/ngscopeclient/xptools/pull/28 Not sure how to configure/test that on other platform so I did not touch that part.
<d1b2>
<chille0417> @azonenberg I think I might have found a big in RohdeSchwarzHMC8012Multimeter. There is a lot of calls to SCPITransport::SendCommandQueued(). When writing your own application and linking to scopehal the queue never gets flushed unless you do it manually or call something that will flush the queue, like SendCommandQueuedWithReply(). I would assume that something like a DMM driver would never need a queue and should instead send everything
<d1b2>
immidiately. What do you think? Or is there any good reason to queue the commands in this case?
<d1b2>
<azonenberg> I'm moving all drivers over to the queued API because it's properly interlocked between the GUI and instrument threads, and avoids blocking the GUI thread doing write-only operations like changing the meter mode
<d1b2>
<azonenberg> This does mean that if you send a bunch of write commands and never read a result, they can be queued for a while
<d1b2>
<azonenberg> i'd like to figure out some way to do a delayed-commit type flow, perhaps in a separate thread spawned when you create the instrument with a configurable timeout
<d1b2>
<azonenberg> but it's nontrivial to do right
<d1b2>
<azonenberg> open to ideas
<d1b2>
<azonenberg> the whole point of the queued API is that if you have e.g. a slow rigol scope that's in the middle of a 10 second waveform download
<d1b2>
<azonenberg> adjusting the trigger position in the gui shouldn't hang
<d1b2>
<chille0417> Hmm...
<d1b2>
<azonenberg> (we also use the queued API to interlock the scpi console in ngscopeclient with the instrument thread so you can type commands there and not step on a request/reply pair another thread is doing)
<d1b2>
<chille0417> Okay, so it sounds like there is a good reason to use the queued API then. The problem I have right now is that the HDS200 is extremely slow to some things, like changing between V and mV range on the DMM. If I send another command directly after, then it gets dropped. I could of course solve that with the SendCommandImmediate(), but it sounds like it would be a greate ide to get it to work with the queued API instead.
<d1b2>
<chille0417> Is the FlushCommandQueue() supposed to be run from a separate thread?
<d1b2>
<chille0417> I can see three different solutions to this problem: 1) Use the rate limiting, but then I need to set the rate limit to less than 2 messages per seconds, which is not very nice. 2) I send everything immidiately and do my timing with usleep(). This will be blocking code and as I understand this will also lock the GUI while waiting for things to complete. 3) Extend the SCPITransport to have some kind of dynamic rate limiting. This could be a
<d1b2>
second parameter to SendCommandQueued() that tells how long time a command needs to "settle".
<d1b2>
<chille0417> Number 1 seems like a really bad idea. Number 2 is probably the easiest for now, but is not really a good solution. I assume number 3 would be the best way to do it.
<d1b2>
<azonenberg> Rate limiting exists to solve this issue
<d1b2>
<azonenberg> Dynamic rate limiting (delays only after specific commands) doesn't yet exist
<d1b2>
<azonenberg> This may be a reason to add it
<d1b2>
<azonenberg> Yep. Basically the challenge is going to be to figure out an interface for filters to expose information they want to display, perhaps with several levels of "verbosity"
<d1b2>
<azonenberg> and an interface in the UI to select which stuff to show since you obviously don't want this on for every filter all the time
<joshua_>
on the rigol, clicking on a filter, there is a 'indicator' button to turn on/off the ... indicator
<d1b2>
<azonenberg> yeah. lecroy has off, basic, and detailed (i forget the terms but there's two levels of verbosity)
<d1b2>
<azonenberg> this kinda ties also into more general annotation capabilities
<d1b2>
<azonenberg> being able to add an arrow pointing to some feature of wa veform
<d1b2>
<josHua> I guess I want the most recent PollTrigger result that the InstrumentThread got me
<d1b2>
<azonenberg> Correct. That is not somethign we save anywhere at the moment
<d1b2>
<azonenberg> to my knowledge
<d1b2>
<azonenberg> normally the UI thread just does its thing and waveforms show up
<d1b2>
<josHua> hm ok I have a plan for that, I will stash it in the InstrumentConnectionState
<d1b2>
<azonenberg> yeah that seems reasonable
<d1b2>
<azonenberg> I'll have a look at your sidebar changes soon, relatives just left and i'm busy with $dayjob but should have some downtime in the evenings moving forward
<d1b2>
<josHua> I pushed that change if anyone wants to play with it, and suggested more careful language for the frontend
<d1b2>
<josHua> I think my brain is warmed up for programming so I am going to go do some client work now
<d1b2>
<josHua> ok though speaking of UI things, one other thing: it has been a little frustratingly nonobvious to me that the horizontal vs vertical behaviors in ngscopeclient are different in terms of what touches instrument state and what does not
<d1b2>
<josHua> i.e., I can zoom in and out of a waveform in the time domain without touching anything on the instrument, but if I zoom in and out of a waveform on the Y-axis just to look at it a little differently, then it will reconfigure the capture parameters on the instrument
<d1b2>
<azonenberg> Yes. There is an open ticket about that
<d1b2>
<azonenberg> Nobody is actively working on it, but the rise of high bit depth scopes is making that more relevant
<d1b2>
<azonenberg> tentative concept is to have some kind of "lock to vertical range" icon in the top right corner of the plot
<d1b2>
<azonenberg> that you can check / uncheck to enable free navigation or adjusting the instrument
<d1b2>
<azonenberg> like, the implementation would be straightforward
<d1b2>
<azonenberg> the UI/UX bit is where it gets hard
<joshua_>
I would argue that even for 8b scopes it is more relevant in ngscopeclient than on an on-scope UI, because you sit further from the screen in ngscopeclient than onboard
<d1b2>
<azonenberg> (this is the kind of thing that gets back burnered when i'm the sole ui dev and project lead and lecroy/pico/some siglent/some r&s driver maintainer and need to prioritize my limited time)
<d1b2>
<azonenberg> lots of these issues were filed for things that absolutely should happen, and will make ngscopeclient a better tool, but aren't a 'needs to happen today' priority
<joshua_>
and so zooming in on things, even though you do not get any more precision for it, becomes an important adaptation compared to sitting in front of a scope, where the 'get a closer look' is done by craning your neck since you're already not more than arm's length from the unit
<d1b2>
<azonenberg> four years later e.g. #2 still doesn't have to happen today :p
<joshua_>
haha yeah
<joshua_>
is there a ticket that I can propose a UI in?
<d1b2>
<fredzo_72653> Not my domain of expertise, but I will be glad to help on UI if I can @
<d1b2>
<josHua> Mine neither, but "I know what I like"! I found this to be very useful when mocking up UI before I began porting to C++. https://codepen.io/jwise0/pen/eYqNdeM?editors=0011 If you have ideas for things that you want to improve I will be happy to pair with you on them.
<d1b2>
<azonenberg> in general i'm trying to get more folks involved at every stage of the project because its already well beyond what i can do solo
<d1b2>
<fredzo_72653> Sure ! I love your proposal on the StreamBrowserDialog and the idea to show the state of the scope in here. I think the progress-bar would be a great addition for deep memory-depths. I can see how I would implement a DownloadProgress() API on Rigol and Siglent drivers 😉
<d1b2>
<josHua> feel free to work on my branch, I can give you push permissions there if you want
<d1b2>
<fredzo_72653> OK why not ! We'll se what comes out of the zoom meeting tomorrow and who should work on what 🙂
<d1b2>
<azonenberg> Yep. I'm very much in favor of all these ui improvements people are tossing around
<d1b2>
<azonenberg> but i also do want to make sure we have an overall plan to ship a release before the thunderscope developer units ship
<d1b2>
<azonenberg> This may mean some stuff will have to be tabled while we work on the less sexy stuff like stability, portability, and packaging for a bit
<d1b2>
<azonenberg> and then as soon as v0.1 is out the door, full steam ahead on more stuff for v0.2