<_whitenotifier>
[scopehal-apps] azonenberg 089f468 - Fixed broken test caused by refactoring
Degi_ is now known as Degi
<azonenberg>
ok so that fixes the test but i will need to clean it up a lot more because we now have better filter graphs for making test waveforms
<azonenberg>
@mubes ok so i'm looking at the rate limiting code in the siglent driver
<azonenberg>
i think what i'm going to do is refactor this into the SCPITransport class, make it an option you can enable or something
<azonenberg>
in the driver
<azonenberg>
and then integrate with command batching
<azonenberg>
So instead of sendOnly() blocking the main thread and waiting for the timeout
<azonenberg>
it will immediately push the command into the queue
<azonenberg>
then the next time a read is performed, or a flush is requested, it will loop over the list of pending commands, sleeping as needed between them
<azonenberg>
but this will ideally happen in the acquisition thread
<azonenberg>
leaving the gui thread unblocked as long as it doesn't make any calls that involve reading data from the scope
<azonenberg>
i.e. opening properties dialogs or menus for which the relevant variables are not cached
<azonenberg>
also 1.3.9R10 just came out
<azonenberg>
like, it was released last Tuesday
<azonenberg>
i'm going to try and install it on the demo scope and see how things change
<azonenberg>
or not, actually
<azonenberg>
apparently it's just a compatibility upgrade to support a hardware change in recently manufactured units
<d1b2>
<mubes> That rate limiter does belong in generic code ...I only put it there cos itt was one of the first things I did and I didn't want to be creating too big a footprint.
bvernoux has joined #scopehal
azonenberg has quit [Ping timeout: 240 seconds]
azonenberg has joined #scopehal
bvernoux has quit [Quit: Leaving]
<azonenberg>
Yeah
<azonenberg>
well i mean i hope nobody else has the same bug in their firmware
<azonenberg>
but i have to imagine we will find a similar situatio nelsewhere
<azonenberg>
Throwing together some quick notes on a trigger design for scopes. feel free to chime in w/ comments
<azonenberg>
(@MP @louis monochroma lain Degi in particular)
<Degi>
Hmm, it seems to require login
<azonenberg>
Fixed
<Degi>
I'd do it such that if it detects a trigger condition, then it signals that to the main controller, which then sends out a stop signal to all channel FPGAs with a delay equivalent to how much pre-buffer you want
<Degi>
And that the channel FPGA notes down the timestamp of the trigger event
<azonenberg>
yes but the challenge is multi channel triggering
<azonenberg>
i'm getting there :)
<Degi>
Ooh, like conditions which need to be met on multiple channels?
<azonenberg>
Yes. or things like i2c/spi which require multiple channels of input
<Degi>
I see
<Degi>
Maybe there could just be a signal to indicate whether it found anything, then when all channels coincide / that signal is high on all channels, then it reads what it found and checks if that is a valid trigger
<azonenberg>
my thought is to have channels output events then the top level processes thos
<azonenberg>
so "falling edge" event on SDA pin while SCL is high would be an I2C start trigger
<Degi>
I mean the downside with that is that it limits the trigger rate, and if you sample like a 1 GHz wave with edge trigger then you get 2 GEvents/s
<azonenberg>
but in "trigger on i2c address" mode it would just arm
<azonenberg>
Yes
<azonenberg>
but you only need to see the first event
<azonenberg>
it's OK if you drop some of them
<azonenberg>
if you wanted to trigger on a gigabit data stream with some more complex condition you'd preprocess on the channel
<azonenberg>
such that the total event rate to the top level is within the capacity of that link
<Degi>
True, thats why I think that a coincidence mechanism would be neat, at least for high data rate signals. Like "If CH1 has a rising edge, CH2 rose in the last 100 ns, CH3 is between 3 and 5 V then trigger"
<Degi>
(Since you can't just send the first event since then they might miss eachother)
<azonenberg>
Hmmm yeah
<Degi>
Like if you have a 1 GHz sinewave on CH1, on CH2 some voltage which controls something and on CH3 some start signal, or for example when you want to get data for a display and you have clock on CH1, hsync on CH2 or so and only want to trigger on rising edge of clock when hsync rose in the last 100 ns or so
<Degi>
I think a problem might arise when you want to trigger on something complicated on all channels, like with PCIe where things get split up and you want to trigger on a specific sequence in which all channels somehow relate, such that you can't do per-channel triggering, though I guess if the LVDS link was a bit faster then you could just send the decoded symbols to the main processor which then triggers based on that
<Degi>
I mean the precise trigger location can be determined in post-processing too
<azonenberg>
yeah. multilane pcie could be hard
<azonenberg>
but thats a pretty specialized scenario
<_whitenotifier>
[scopehal] azonenberg a6fae18 - Moved rate limiting feature from Siglent driver to base SCPITransport class. Converted SiglentSCPIOscilloscope to use queued command API.
<_whitenotifier>
[scopehal] azonenberg 92a782a - Removed a bunch of unnecessary mutexing in the Siglent driver for write-only methods as the queued command API does that for us
<azonenberg>
@mubes please pull latest and verify that a) it doesn't break anything and b) responsiveness to things like changing channel scale/offset during live capture is greatly improved
<azonenberg>
This goes for other Siglent users in the channel as well