nelgau has quit [Remote host closed the connection]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 256 seconds]
Degi has quit [Ping timeout: 240 seconds]
Degi_ has joined #scopehal
Degi_ is now known as Degi
nelgau has joined #scopehal
nelgau has quit [Remote host closed the connection]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 256 seconds]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 256 seconds]
<d1b2>
<dannas> @azonenberg Oh, how did I miss the ridicioulous GS/s rate. When I multiplied the waveforms timescale by FS_PER_SECONDS it works much better. Now I have waveforms displayed
<d1b2>
<dannas> Now it's samplerate is ridicioulously low but I'll figure that out.
<d1b2>
<dannas> The timescale looks sort of weird and crowded.
<d1b2>
<dannas> And the 0 marker has the unit fs event when every other markers has s or ms. Well, that's just minor inconveniences. Maybe I'll look into those once I have the siglent driver working.
<d1b2>
<dannas> /m goes to read the manual to figure out how to move the horizontal position of the waveform.
<d1b2>
<dannas> Hm, zooming is really slow during active capture with 7M capture depth. If I reduce it to 7K, things are much snappier.
<d1b2>
<dannas> liblxi will raise SIGPIPE if the connection to the scope is terminated. Is that what we want? Searched for UNIX signal handling but didn't find any.
<d1b2>
<dannas> I'll put it on my todo-list
<azonenberg>
dannas: we should figure out a good way to handle loss of connection to scope at a higher level
<azonenberg>
this should eventually be tied into my plan of having the ability to toggle going on/off line
<azonenberg>
i.e. you should be able to plug into a scope, do some stuff, then click "go offline"
<azonenberg>
grab your laptop and walk back to your desk
<azonenberg>
and be able to look at the same session and do stuff with it
<d1b2>
<dannas> Yeah, I can see how that would be useful.
<azonenberg>
i.e. transparently swapping out the regular scope driver object with a MockOscilloscope - and then going back
<azonenberg>
there's an open ticket for it
<azonenberg>
but long term if you lose connectivity we should display a warning message and switch to offline mode
<azonenberg>
than have the ability for you to go back online once you've corrected whatever made you go offline
<d1b2>
<dannas> Too bad we're not partitioned on processes. 🙂 Then the ScopeThread could die and that would mark the end of a connection.
<azonenberg>
yeah but we need to support multiple scopes in one glscopeclient instance
<d1b2>
<dannas> Oh, right.
<azonenberg>
This is still something i want to improve the UX of, but it's a core feature i want to build around
<azonenberg>
also multiple non-scope instruments
<azonenberg>
i want to be able to have remote control of an entire lab including vnas, psus, multimeters, scopes, signal generators, and more
<d1b2>
<dannas> Another thing while I have your attention: It seems like most (all?) locking is based around recursive_mutexes. Is that a concious design decision or something that happened due to early locking bugs?
<d1b2>
<dannas> Seems like there's a cache_mutex and a regular mutex in most Oscilloscope-classes
<azonenberg>
it's a conscious decision because sometimes you will call APIs from within another function, like AcquireData()
<d1b2>
<dannas> _goes to lock what the non cache mutex protects.
<azonenberg>
and that needs to not deadlock
<azonenberg>
and yes. i may actually refactor those mutexes and some of the caching into the base Oscilloscope class at some point, or perhaps a helper class TBD
<azonenberg>
the cache mutex should only ever be locked for long enoguh to access the data structure storing the cache contents
<azonenberg>
in particular, it should never be locked while you are blocking on the scope doing something
<azonenberg>
whereas the main mutex serializes access to the scpi data stream
<d1b2>
<dannas> It would be nice to have machinery in place for locking, on the other hand with locking it's nicer (in my opinion) to have longer functions were you can inspect most locks at once.
<azonenberg>
so you don't have replies to one command mixed up with another
<azonenberg>
I'm open to ideas on how to clean up the architecture and make it more responsive. but that's definitely not a v0.1 todo item
<d1b2>
<dannas> I don't have any suggestions, just wanted to pick your brain for context.
<d1b2>
<dannas> And I agree that keeping the scope of changes focused for v0.1 is a good idea.
bvernoux has quit [Read error: Connection reset by peer]