<d1b2>
<louis> May never have come up because the offset is always zero
<azonenberg>
i will test shortly and see
<azonenberg>
i normally use the picoscope with 50 ohm inputs
<azonenberg>
so that might well have slipped through
d1b2 has quit [Remote host closed the connection]
d1b21 has joined #scopehal
d1b21 is now known as d1b2
nelgau has quit []
nelgau has joined #scopehal
massi has joined #scopehal
ericonr has quit [Ping timeout: 256 seconds]
ericonr has joined #scopehal
bvernoux has joined #scopehal
massi has quit [Remote host closed the connection]
Bird|ghosted has joined #scopehal
kbeckmann1 has joined #scopehal
Bird|otherbox has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
<d1b2>
<louis> So, thinking about bridged drivers, but also in general, it seems like it would be good to have a way to report clipping, as well as maybe generally other exceptional conditions or diagnostic information
<d1b2>
<louis> (It would be good to report some information about the performance of the bridge/transport, e.g. what % of possible hardware performance is being lost due to captures being dropped or the driver not being ready for them, how far behind realtime is the most recent sample, etc.)
<azonenberg>
yes. reporting clipping would be nice
<azonenberg>
i think pico and tek both have that capability
<azonenberg>
other diagnostics would be nice to have. i'm open to ideas on how to do that
<azonenberg>
the obvious options are a third socket for logging, or a buffer you can query over scpi (like how normal scopes work, but not performance critical)
<azonenberg>
i also want to be able to report other events
<azonenberg>
e.g. pico has a notification callback for when probes are inserted/removed
<azonenberg>
so you can check attenuation and such
<azonenberg>
this should probably be some kind of packetized information that can contain either freeform text to be displayed in a log window
<azonenberg>
or alert events like "probe connected"
<azonenberg>
that the gui can act on
<d1b2>
<louis> I have been playing around to set up clipping for the DSCope (which doesn't really report clipping, but reports ADC samples outside it's reported range when it's clipping)
<d1b2>
<louis> Have added c++ enum { WAVEFORM_CLIPPING = 1 }; uint8_t m_flags;
<d1b2>
<louis> to WaveformBase
<d1b2>
<louis> and then set that in AcquireData and read it in WaveformArea::RenderChannelLabel to add -CLIPPING- to the info box
<d1b2>
<louis> May want to display it more elegantly... will have to get my hands dirty with cairo if so 😛
<d1b2>
<louis> Does that (flags for Waveforms) strike you as a good idea? m_densepacked could become a flag with a static inline helper accessor.
<d1b2>
<louis> Probably don't need a whole other socket; could just be a different type of message on the data plane socket.
<d1b2>
<louis> (Since really it's only incidental that it separates command and data plane into two sockets, code-wise I think the reason for the two-socket approach is really because we want a synchronous request-response socket and a scope-bridge-push socket.)
<d1b2>
<louis> Another akward UI question is that logic analyzer-only devices (viz. DSLogic) have no way to view sample depth since it's not displayed in the waveform view area (since it's assumed they are all part of MSOs)
<azonenberg>
yeah i like how tek does the display with the red header bar
<azonenberg>
i do not want dense packed to be a bitmasked flag because it's a performance optimization
<azonenberg>
so lower overhead is better
<azonenberg>
but honestly, it probably isnt that big a deal because bitwise operations are so fast
<azonenberg>
and yeah i guess having separate types of messages on the data plane socket makes sense. we need to define the unified format there anyway
<azonenberg>
as far as sample depth, displaying that in the info box was done originally
<azonenberg>
but it increased the height which hurt packing density
<azonenberg>
i figure it's not really *that* important to see sample depth
<azonenberg>
if you really care you can open timebase properties
<d1b2>
<louis> Sure. Just annoying because that may not actually be what was provided from the scope.
<d1b2>
<louis> Yeah... I'll figure out enough cairo to do that 🙂
<d1b2>
<louis> No strong opinion here. Can always move it into a flags field later if we feel like it. Mostly just looking for a 👍 that that seems like the right approach for reporitng clipping.
<azonenberg>
and actually on that note
<azonenberg>
The number of samples that *would* be displayed on the info box is not the raw number anyway
<azonenberg>
as it reflects the number after RLE
<d1b2>
<louis> Oh, that's an interesting (annoying) note 😛
<d1b2>
<louis> since it's just the length of the vecs in the waveform, yeah?
<azonenberg>
Correct
<azonenberg>
you could take the timestamp of the last sample, plus the duration, minus the timestamp of the first sample
<azonenberg>
and divide by the timebase
<azonenberg>
to get a reasonable estimate of the number of raw samples the instrument actually took to give you that waveform
<azonenberg>
@louis: anyway, feel free to tinker with this too but i think top priority is figuring out the flow control issues
<azonenberg>
as that will make all of the bridge based instruments far more usable and responsive
<d1b2>
<louis> Yeah, just got sidetracked tinkering with clipping since it was bugging me 😛
<_whitenotifier-e>
[scopehal] 602p 8953cd7 - Support clipping as a flag on waveforms; support clipping info from DSLabs bridge
<_whitenotifier-e>
[scopehal] azonenberg c654fa5 - Merge pull request #595 from 602p/clipping Support clipping as a flag on waveforms; support on DSLabs
<_whitenotifier-e>
[scopehal-sigrok-bridge] 602p 77d4bec - Bridge-side support for clipping; cleanup
<d1b2>
<louis> So I set up some rudimentary windowed flow control, and it certainly seems to improve responsiveness.
<azonenberg>
Awesome
<azonenberg>
Play with it a bit more, when you have something you're happy with start thinking about how to refactor the AcquireData() and send-data-to-client architecture so that we can share the code across all three bridges
<d1b2>
<louis> What I've done now is extended PopPendingWaveform to ACK the waveform that was just displayed. That means we can keep a constant [goal] queue depth coordinated between bridge and client.
<azonenberg>
Yep, sounds good
<d1b2>
<louis> One issue/question though is that the actual time taken to display waveforms varies greatly (as a function of how big the window is on my laptop :P)... which means that constant queue depth = 5 can mean 80ms responsiveness (at 60FPS), or 400ms responsiveness (at 14FPS)
<d1b2>
<louis> So maybe we want to instead target a constant delay, and compute our queue depth as a function of the de-facto FPS we are getting?
<azonenberg>
So rendering performance is a whole other can of worms lol. I think the idea of treating it like streaming media players, where you can specify a buffer size in milliseconds, makes sense
<azonenberg>
maybe make the sequence numbers be in time units rather than waveform numbers
<azonenberg>
so it's easier for the server to know how long the round trip is
<d1b2>
<louis> That's what I was gonna say next 😛
<d1b2>
<louis> which is that it seems then that it might be simpler + more effective to have the flow control information actually just be the client telling the server the WFM/s rate it wants
<d1b2>
<louis> (computed as a rolling average of the de-facto rate at which it is capable of displaying them)
<d1b2>
<louis> I guess that is maybe less ideal in the situation where the FPS changes abruptly, actually
<d1b2>
<louis> I will try it with timestamps as sequence numbers
<azonenberg>
yeah. use timestamps then the server can calculate the RTT from that
<azonenberg>
then provide a scpi command for the client to specify the target queue depth in ms
<azonenberg>
and rather than rolling, i'd actually do it in real time
<azonenberg>
so basically if you finish sending waveform at time T
<azonenberg>
and you have not yet seen the ack for waveform T+maxQueue
<_whitenotifier-e>
[scopehal-sigrok-bridge] 602p b75e3d6 - Initial TCP-like implementation of flow control
<d1b2>
<louis> T-maxQueue, rather, right?
<d1b2>
<louis> Doing it directly in timestamps is much cleaner than in waveforms; should be able to delete the code I just wrote to keep track of the effective rate at which pop is called 🙂
<d1b2>
<louis> I will set that up. But for now I'm off to go find something to eat, I think :)
<azonenberg>
Yeah exactly why i suggested it
<azonenberg>
we also eventually need a preference setting clientside