<_whitenotifier-9>
[scopehal] azonenberg 1c7ce18 - Finished decode of initial training register set, calling this good for minimum usable implementation even though not all registers are fully decoded. Fixes #139.
<_whitenotifier-9>
[scopehal] azonenberg 4210df3 - IBM8b10bDecoder: added variable comma search window for use with protocols like DisplayPort that have very long gaps between commas
<_whitenotifier-9>
[scopehal] bvernoux opened issue #765: Issue to build the actual code with MSYS2 / MINGW64 related to usleep (Impact file RSRTO6Oscilloscope.cpp) - https://github.com/glscopeclient/scopehal/issues/765
<d1b2>
<tnt> Is it expected it enables al the scope channels when connecting ?
<d1b2>
<tnt> I have everything setup properly on the scope itself, then I connect and it enables all channels including all 16 digital channels and then I need to disable them one by one ...
<d1b2>
<tnt> Ideally it shouldn't even force a trigger since I might have capture just the event I want to analyse in the buffer ...
<d1b2>
<louis> enabling all the channels depends on the scope driver in question; generally we do
<d1b2>
<louis> which driver?
<d1b2>
<louis> and the triggering-on-connect is a open UX issue, it would be good to have a way to say 'acquire the currently-stored waveform'
<d1b2>
<tnt> Also for some reason the capture depth is ridiculously small and I couldn't figure out how to configure that.
<d1b2>
<miek> hmm, looks like there's a bug in the driver. when it configures all the channel output datatypes at startup, that has the side-effect of enabling the channel. glscopeclient used to enable all channels explicitly, so i didn't notice before
<azonenberg>
miek: yeah now we default to not enabling all the channels
<azonenberg>
because it was annoying
<_whitenotifier-9>
[scopehal] azonenberg closed pull request #766: Replace usleep(..) by std::this_thread::sleep_for(std::chrono::microseconds(..)) to fix issue #765 - https://github.com/glscopeclient/scopehal/pull/766
<_whitenotifier-9>
[scopehal] azonenberg closed issue #765: Issue to build the actual code with MSYS2 / MINGW64 related to usleep (Impact file RSRTO6Oscilloscope.cpp) - https://github.com/glscopeclient/scopehal/issues/765
<_whitenotifier-9>
[scopehal] azonenberg dd59d19 - Added UNIT_RATIO_SCI unit for an arbitrary ratio to be printed in scientific notation. EyePattern now outputs mask hit rate on a scalar channel.
<_whitenotifier-9>
[scopehal] miek c02af85 - AgilentOscilloscope: configure waveform datatype on channel enable, instead of on connect This fixes an issue where all channels were being enabled on connect, because the WAVEFORM:SOURCE SCPI command has an undocumented side-effect where it also enables display of the channel when used.
<_whitenotifier-9>
[scopehal] miek 8b40ab3 - AgilentOscilloscope: only fetch digital waveform preamble when at least one channel is enabled Fetching the preamble also turns on the overall digital function and displays any channels that were previously enabled, so this change only fetches the preamble when a channel is enabled.
<_whitenotifier-9>
[scopehal] azonenberg 9d0b390 - Merge pull request #767 from miek/agilent-fix-channel-enabling Fix Agilent driver so it doesn't enable all channels on connect
<azonenberg>
Great. I have some more eye mask fixes landing shortly
<_whitenotifier-9>
[scopehal-apps] azonenberg c5001f2 - Added a bunch of DisplayPort eye masks
<_whitenotifier-9>
[scopehal-apps] azonenberg a2f2089 - Fixed bug where eye mask was not being drawn as a closed polygon
<_whitenotifier-9>
[scopehal-apps] azonenberg 8f525a8 - Updated to latest scopehal
<d1b2>
<tnt> Anyone used the USB 2.0 HS decoder ? I would have hoped that 4 Gsps / 500 MHz would be enough to be decodable, and "by eye" it looks good but the decoder seems to struggle a bit.
<d1b2>
<miek> yeah, i've been using it a bit, it's working ok for me:
<tnt>
mmm, might be my usb host. It seems to have a brief period at the common mode voltage just before the sync and that gets detected as SE1 and confuses the decoder.
bvernoux has quit [Read error: Connection reset by peer]
<d1b2>
<tnt> Although that seems to be less of an issue after an update & rebuild. But still looking for instance at https://i.imgur.com/h0g3Tuc.png What's the "ERROR" there ? The signals never crossed, so it was a continuous J, so looks fine for EOP or am I missing something ?
<d1b2>
<miek> i guess it dipped low enough to be registered at SE0 briefly. later it clears SE0/SE1 states during transition times, so it ends up as a transition from J to J which probably breaks the packet decoding layer
<d1b2>
<tnt> yeah I just looked at the source of the decoder and figured the issue was the "threshold" voltage. I set that to 0.15 instead of 0.2 and now it decodes perfectly.
<d1b2>
<tnt> I think my probing loads the usb line a bit and drives the signal a tiny bit closer to ground than they should be and it messes it up.
<d1b2>
<tnt> ( Like it dips down to ~ 195 mV while it should technically be 200 mV ... )
<tnt>
Interestingly the specs says a receiver should receive down to 150 mV.
<azonenberg>
So send a PR with a change to the threshold?
<tnt>
Yup, trying to double check I'm reading things right atm.
<_whitenotifier-9>
[scopehal] smunaut 44549cc - USB2PMADecoder: Adjust high speed threshold level USB 2.0 - 7.1.7.2 - Table 7-3 states that "receiver must not indicate squelch if magnitude of differential voltage is ≥150 mV". Also in the receiver sensitivity section, some of the eye templates show "must decode" eyes as low as 150 mW in some cases. Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
<_whitenotifier-9>
[scopehal] azonenberg 04655b3 - Merge pull request #768 from smunaut/usb USB2PMADecoder: Adjust high speed threshold level
<azonenberg>
@louis i'll try and read throguh you new filter shortly