azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
futarisIRCcloud has joined #scopehal
_whitelogger has joined #scopehal
avl has joined #scopehal
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #scopehal
azonenberg_work has joined #scopehal
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-3> [scopehal] azonenberg 87e95b3 - Performance tweaks to LeCroyOscilloscope. Fixed some issues with LA handling
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-3> [scopehal-apps] azonenberg 3197fc1 - Added exponential backoff between polling operations to prevent slamming CPUs of slower scopes
<_whitenotifier-3> [scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-3> [scopehal-cmake] azonenberg 52dfea3 - Updated submodules
<azonenberg> Need to tweak the backoff algorithm a little bit, but i think this should work better with high latency scopes
<azonenberg> whitequark: can you connect your rigol again?
<whitequark> azonenberg: moment
<azonenberg> Basically, some profiling suggested that i was spending a ton of time polling the trigger
<azonenberg> to the point that that thread was jamming out almost everything else
<azonenberg> especially on slow scopes
<whitequark> azonenberg: should be up
<whitequark> azonenberg: one thing i don't yet quite understand
<azonenberg> ?
<azonenberg> and do you have any signal sources or triggers hooked up yet?
<whitequark> is why the Y position of the trace affects the range that is actually being captured
<whitequark> re signal sources, give me a moment
<azonenberg> Because legacy oscilloscope UIs are designed to be used on a single grid where everything is one set of scales
<azonenberg> think back to analog scope era
<whitequark> no, i mean
<azonenberg> to move a trace you literally feed an offset voltage into an analog addition circuit
<whitequark> oh.
<azonenberg> and offset the signal
<whitequark> ohhhhh.
<azonenberg> To make it bigger or smaller you adjust AFE gain
<whitequark> that's actually quite interesting
<whitequark> because it makes the range higher
<whitequark> possible range that is
<azonenberg> DSOs kept this same paradigm despite not being actually necessary in hardware
<azonenberg> you still want gain and offset control
<azonenberg> but there's no requirement that the gain and offset map 1:1 to the pixel position of the signal
<whitequark> right
<azonenberg> i.e. it should be possible to have a signal with huge gain that you just render small
<azonenberg> so it's precise data, but doesnt take up much screen space
<azonenberg> etc
<azonenberg> In glscopeclient i'm trying to decouple these a bit, the rendered Y axis always shows the full range of the ADC
<whitequark> azonenberg: i hooked up 1 khz source
<azonenberg> All plots in a given viewport are equally sized regardless of the actual amplitude (i will eventually support stacking two traces in a single plot if you want an overlay for some reason)
<azonenberg> and offset just moves the numbers on the Y axis of the plot without actually moving the rendered trace
<azonenberg> and yes with an 8-bit scope you need this
<azonenberg> imagine you have a DC to 5V input range for the sake of discussion
<azonenberg> That's 19 mV per LSB
<azonenberg> Which is not a ton of resolution for seeing weak traecs
<azonenberg> weak signals*
<azonenberg> meanwhile if you have DC to 500 mV range you have 1.9 mV per LSB, but then you have to attenuate strong signals
<azonenberg> whitequark: also can you zoom in a bunch? i want a short capture, only a few hundred points, to test something
<azonenberg> (and i havent implemented setting the timebase lol)
<azonenberg> the 250K point captures spam wireshark pretty badly when i'm trying to do profiling
<whitequark> azonenberg: ok sec
<whitequark> azonenberg: 120 pts now
<azonenberg> perfect thanks
<azonenberg> that's 120 points total apparently
<azonenberg> because i am seeing 30 per channel
<whitequark> huh
<whitequark> wait
<azonenberg> which is totally fine for my test
<whitequark> now it says 30
<whitequark> azonenberg: oh
<whitequark> it depends on the amount of selected channels
<whitequark> it makes sense
<azonenberg> So the memory depth is shared across all channels?
<whitequark> i think it's just because of sample rate?
<azonenberg> i.e. if i see 120 and i have 4 channels enabled i should actually have 30 points per channel
<whitequark> no
<whitequark> when i selected only ch1 it said 120
<whitequark> when you selected all 4 channels it said 30
<azonenberg> Then what happened?
<azonenberg> because i am seeing 120 per channel right now in my pcaps and UI
<azonenberg> is that what it's actually doing?
<whitequark> that's because i just switched it back to check it out
<azonenberg> oh, ok
<whitequark> try again
<whitequark> should be 30
<azonenberg> So i'm parsing the results correctly, thats what i needed to know
<azonenberg> yeah i am seeing 30 per now
<azonenberg> So we're good
<azonenberg> Have to go do something for a client but i want to get back to adding write calls to the rigol driver in a bit
<azonenberg> can you leave the scope up for a couple hours or are you gonna have to go somewhere etc?
m4ssi has joined #scopehal
<whitequark> azonenberg: it's up for now
_whitelogger has joined #scopehal
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
m4ssi has quit [Quit: Leaving]
bvernoux has joined #scopehal
maartenBE has quit [Ping timeout: 244 seconds]
maartenBE has joined #scopehal
<azonenberg> bvernoux: FYI the v0.2 probe shells shipped from shapeways ETA monday to my lab
<azonenberg> still waiting on the PCBs
<bvernoux> ha good
<azonenberg> oshpark's estimate when i ordered was shipping a week from today
bvernoux has quit [Quit: Leaving]
futarisIRCcloud has joined #scopehal