azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
bvernoux has quit [Quit: Leaving]
<azonenberg> electronic_eel: there will be a switchable filter in the BLONDEL afe
<azonenberg> There has to be. with all channels in 12 bit more nyquist is <100 MHz
<azonenberg> So i'm gonna have a switchable 50 MHz filter that is mandatory in 4ch 12bit 125 Msps mode and can optionally be enabled at higher freqs
<azonenberg> unsure at this time if i'm going to cascade it with the existing 100 MHz filter in series/bypass, or have an A/B mux
<tverbeure> An interesting datapoint on my Tek 420A scope: fetching the 4 waveforms in one go (4x 30k points) takes 0.7s. WFMPRE?, which gets the settings for the 4 channels takes ... 1s. WAVF? which combines WFMPRE? and CURV? takes 1.7s.
<tverbeure> So transferring a string of 800 bytes with just configuration data takes 30% longer than transferring the 120000 bytes of data that you really care about.
<azonenberg> tverbeure: lol. settings is probably polling all kinds of i2c registers or something
<azonenberg> Can WFMPRE? change under you or is it constant?
<azonenberg> modulo instrument settings
<azonenberg> I generally cache settings aggressively to minimize polling of the instrument and round trip times
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #scopehal
Degi_ is now known as Degi
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #scopehal
futarisIRCcloud has joined #scopehal
<azonenberg> tverbeure: so how is the siglent driver working for you at this point?
<azonenberg> fairly stable? any major missing features etc? do you have sample rate or memory depth control/querying yet?
<azonenberg> also miek/degi re agilent/rigol stuff, where do we stand on feature completeness? last i heard they worked pretty well in read only mode but were still missing some set calls
<azonenberg> Error_404: when you get a chance can you try out tverbeure's siglent improvements on your scope?
<_whitenotifier-f> [scopehal] azonenberg opened issue #148: Attach units to protocol decoder parameters for better pretty-printing/parsing -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #148: Attach units to protocol decoder parameters for better pretty-printing/parsing -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #148: Attach units to protocol decoder parameters for better pretty-printing/parsing -
<tverbeure> WFMPRE is essentially the same as WAVE:DESC, which you do fetch for each AcquireData. So it changes when you touch the controls of the scope.
<tverbeure> About the Siglent driver: it's still very beta.
<tverbeure> It doesn't split up large waveform fetches into smaller parts that don't time out.
<azonenberg> well i mean that applies to the entire project :p (very beta)
<azonenberg> and so it looks like my lecroy stuff, that i've been complaining about the performance of
<azonenberg> is actually pretty fast compared to a lot of other hardware lol
<azonenberg> curious how a modern keysight or something would compare
<azonenberg> like an infiniium x series
<tverbeure> It's also very much one-way: if you set the controls on your scope, the acquisition will usually be fine. But weird stuff can happen when you set v/div etc.
<azonenberg> possible that's due to cached settings?
<tverbeure> I don't think so.
<azonenberg> hit the refresh button on the toolbar to clear the cache and see
<tverbeure> glscopeclient displayed its first Tek waveforms, BTW. So there's that.
<azonenberg> Awesome
<azonenberg> Let me know when you've got something to merge
<tverbeure> Nothing at all! Most of the stuff is stubbed out with fixed values. :-)
<azonenberg> Lol
<azonenberg> Thats about what i figured at this phase
<tverbeure> Also, the waveform is inverted for some reason. Probably due to unsigned vs signed (again.)
<azonenberg> Once we have the tek and siglent drivers both reasonably stable and complete, though, i'd love if you'd do a test of the multi-scope support between the two
<tverbeure> I started out with the Agilent code.
<azonenberg> so far all of the multi-scope stuff has been tested between my two lecroy's
<azonenberg> i really want to get a test of different vendors' scopes at some point
<azonenberg> but not a rush, just know it's on the roadmap
<tverbeure> Just tried it. The moment mouse-roll-out in the Y axis, things immediately go bad. Like going from a range of 0 to 3V to 0 to 30V on the display, nothing triggering anymore, the scope getting a settings of 11.2V/div etc.
<azonenberg> Lol
<azonenberg> so definitely some bugs to work out :p
<tverbeure> Which makes me wonder: when changing the range on the Y axis in glScopeclient, is it supposed to retain the same steps as the scope? (IOW: not 11.2 V/div?)
<azonenberg> so that's something we need to think about. internally i zoom with fairly small steps, i think +/- 10% of nominal
<azonenberg> lecroy handles this fine but i dont know how well other scopes do
<tverbeure> The moment you set something like 11.2V/div, the scope UI drops all its regular steps and when you turn nobs it goes up in steps of 0.2V or something, instead of something logarithmic. Really annoying.
<azonenberg> so it works fine then
<azonenberg> you probably just have to check a coarse/fine adjust knob in the scope UI
<azonenberg> thats how it works in lecroy at least
<azonenberg> "variable gain" is what they call it
<tverbeure> Well... I learned something new today! :-) Pressing on the knob toggles between coarse and fine.
<azonenberg> glscopeclient prefers fine steps so you can maximize waveforms to use all available ADC range / screen real estate
<tverbeure> Yes. But right now there's a major disconnect between glscopeclient and the scope when you make changes. This will requires a bit of debugging...
<azonenberg> i know most of the drivers right now aggressively cache settings and the UI doesn't flush that cache until you hit refresh. i've experimented with flushing on a timer every X seconds or something
<azonenberg> but that caused disconcerting lag spikes at higher trigger rates
<azonenberg> the fundamental problem IMO is that the scope has no way to push "setting changed" notifications to you
<azonenberg> and polling every setting every waveform is slow
<azonenberg> this is unfortunately an API limitation at the SCPI layer and not something we can solve in software
<azonenberg> right now i cache everything with ~unlimited lifetime, the rationale being that you are probably either using front panel controls or glscopeclient but not both at once
<azonenberg> then i allow explicit flushing when you change settings on the scope
<azonenberg> But i'm open to suggestions to make it configurable etc
<tverbeure> It's not the cache. The scope isn't armed. I simply scroll in the Y axis. glscopeclient sets a certain new range, the scope updates the image, but ranges are all wrong. Or so it seems.
<azonenberg> interesting
<tverbeure> Also: "reload configuration" doesn't do anything until you do a waveform acquire again. Is that expected?
<azonenberg> Hmm
<azonenberg> it flushes the cache but new values aren't loaded until you query the instrument
<tverbeure> Ok.
<azonenberg> what happens if you click reload then trigger a redraw by, say, scrolling the timeline or resizing the window?
<azonenberg> any Get*() function with an empty cache shoudl hit the instrument
<tverbeure> Doesn't query. Only when I restart.
<azonenberg> Hmm
<tverbeure> BTW: I think I see what happens. Wrt to the scale.
<tverbeure> Starting point: 1V/div. all is fine.
<tverbeure> I scroll out one click. SCPI command: VOLT_DV 1.1111
<tverbeure> However, scope shows: 11.2V/div!
<azonenberg> That sounds like a command formatting issue
<tverbeure> Could this be due to 10x ratio of probe?
<azonenberg> or parsing
<azonenberg> i dont think so
<azonenberg> i think this is more likely related to VOLT_DV being parsed or formatted strangely
<tverbeure> "C1:VOLT_DIV 1.1111"
<tverbeure> It's hard to screw that one up with parsing.
<azonenberg> You'd think
<azonenberg> what happens if you send VOLT_DIV 1 or VOLT_DIV 1.0?
<azonenberg> does it jump you to 10V?
<azonenberg> also what do you get back if you send C1:VOLT_DIV?
<azonenberg> (at 1V/div)
<tverbeure> It returns "1.12E+01"
<tverbeure> Maybe it always needs to be exp notation?
<tverbeure> Checking the manual.
<azonenberg> waait
<azonenberg> e+1? not e0?
<tverbeure> Yes.
<tverbeure> So what it returns matches what's on the scope V/div screen.
<tverbeure> At least that's consistent...
<azonenberg> oh so you're at 11.2 v/div not 1 for that
<tverbeure> Yes.
<tverbeure> Ok. I do this: "C1:VOLT_DIV 1", it returns "1.00E+01" (IOW: off by 10)
<tverbeure> Ok. I do this: "C1:VOLT_DIV 1E1", it returns "1.00E+02" (IOW: off by 10)
<azonenberg> sooo it seems like you have to set taking into account probe gain, but not when you get??
<azonenberg> that's really weird
<tverbeure> Right.
<azonenberg> try setting the probe to 1x and see if that changes it
<tverbeure> Yup.
<azonenberg> If this is indeed the case, definitely put a comment in the code to this effect because this is VERY not obvious behavior
<azonenberg> (if you've read the lecroy driver you've probably seen some of my comments complaining about their derpiness too)
<tverbeure> Ok. After I change it to 1x, it behaves as expected.
<azonenberg> So confirmed probe gain is multiplied in when setting, but not querying, channel gain?
<azonenberg> this is tek, not siglent?
<tverbeure> Siglent.
<azonenberg> oh
<azonenberg> we'll need to try with other siglent models
<azonenberg> i strongly suspect this is a bug in specific models' firmware
<tverbeure> BTW: the Siglent has probe settings of 0.1X, 0.2X, 0.5X, 1x, 2x, 5x, 10x all the way to 10000x
<tverbeure> I don't get it.
<azonenberg> for high voltage maybe?
<tverbeure> But you'd expect some relays clicking in that case?
<tverbeure> It seems like a pure SW thing.
<azonenberg> It is, these are not changing anything in the scope
<azonenberg> they're scaling factors for the probe
<azonenberg> i.e. does 1V at the input correspond to 1V at the DUT, 10V, 100 mV, etc
<azonenberg> with a 10x probe you see 100 mV at the scope input for 1V at the DUT so the scope multiplies by 10 to compensate
<tverbeure> Yes.
<azonenberg> but there's no actual gain going on in the scope
<azonenberg> when you ask for 1V/div you get 100 mV/div on the ADC, then it just scales in software
<azonenberg> you dont actually get 10x the frontend gain
<tverbeure> Don't advanced scopes automatically detect that your probe is 10x or 1x?
<azonenberg> Yes. Generally there's two ID schemes used
<azonenberg> one is a ring around the BNC that has an pin that mates with a ring on the scope, just a passive resistor to ground
<azonenberg> scope has a voltage divider to read one of a bunc hof standard values
<azonenberg> the other is I2C via a proprietary connector for active probes, to either read the constant gain or even configure a frontend gain stage
<azonenberg> But in no case does the probe gain change anything the scope does
<azonenberg> the scope sees 100 mV at the input, digitizes it, and it only gets displayed as 1V at the very end
<azonenberg> if you have a 10x probe and tell the scope it's 1x it will happily tell you that you have a 100 mV signal
<azonenberg> and it wont know the difference
<tverbeure> I just plugged/unplugged some probes: the V/div automatically changes. Except for the one for which I changed it manually.
<azonenberg> anyway, what i think is happening is that the siglent firmware is not applying the probe gain compensation in one direction, but it is in the other
<tverbeure> Right.
<azonenberg> on the scpi interface
<tverbeure> Sigh.
<azonenberg> So it's a firmware bug, and one we need to work around
<azonenberg> but definitely comment what scope you saw this issue on
<azonenberg> because i suspect it's only this model and a few siblings
<azonenberg> and when the next guy with a siglent has this problem in the opposite direction we'll have to start adding if(model == foobar) checks
<tverbeure> Yes.
<azonenberg> this is what the initial *IDN? is for, lol
<azonenberg> I already have a bunch of quirks in the lecroy driver, it's about time we started having some for siglent :p
<azonenberg> it's almost like they don't test these things :P
<tverbeure> Well, there's still the signed/unsigned thing.
<azonenberg> ah true ok so we had quirks already
<tverbeure> Right now, I only treat it as signed for the SDS2000X series. But I think it's signed for almost everything (if not all.)
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±3]
<_whitenotifier-f> [scopehal] azonenberg 569547a - Added ParseString() to Unit class, as inverse of PrettyPrint()
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [scopehal-apps] azonenberg bd4cef3 - Added deskew setting to ChannelPropertiesDialog. Fixes #112.
<_whitenotifier-f> [scopehal-apps] azonenberg closed issue #112: Add UI for configuring per-channel deskew -
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [scopehal] azonenberg 47761de - Removed Oscilloscope::PollTriggerFifo() since HasPendingWaveforms() basically does the same thing. Fixes #143.
<_whitenotifier-f> [scopehal] azonenberg closed issue #143: Remove Oscilloscope::PollTriggerFifo() since it basically duplicates HasPendingWaveforms() -
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±3]
<_whitenotifier-f> [scopehal] azonenberg c03b494 - Eye pattern: allow center voltage to be specified, so we can plot eyes of signals with a DC offset. Fixes #1.
<_whitenotifier-f> [scopehal] azonenberg closed issue #1: Eye measurements: allow eye position to be defined somehow -
<azonenberg> woo the oldest ticket on the bug tracker is now closed
<monochroma> :D
<azonenberg> #2 might be a while, it's about allowing measurements to display overlays on the signal showing the thing being measured
<azonenberg> e.g. the 20% and 80% voltage levels for a rise time filter
<azonenberg> there's a lot more thought needed on how to integrate that
<azonenberg> lain: have you tried recent scopehal with deep captures off your DDA?
<azonenberg> Re scopehal-apps:#79 i'd like to close as wontfix since i think i fixed a bunch of the big slowdowns
<lain> azonenberg: have not tried, no
<azonenberg> i think you'll be pleasantly surprised at how much faster it is now
<_whitenotifier-f> [scopehal] azonenberg assigned issue #58: USB: add PCAP export -
* apo spent half the day yesterday implementing segmented data for some rigol scopes for sigrok
<apo> What I /wanted/ to do was take a look at the protocol of our doorbell
<azonenberg> apo: so are you a relatively active sigrok user/dev then?
<apo> yak shaving at its finest
<apo> azonenberg: no :p
<azonenberg> lol
<azonenberg> i was hoping to find someone who had experience with it and scopehal to give some feedback
juli967 has joined #scopehal
<apo> I have some experience with it, but I've spent less than 10h actually working with it
<apo> definitely more than that implementing stuff, though
<apo> ¯\(°_o)/¯
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
juli967 has quit [Quit: Nettalk6 -]
<apo> now I just need somebody with an MSO5000 to test the patch :)
<apo> and a DS1000Z
juli967 has joined #scopehal
<electronic_eel> apo: I think Degi recently bought a Rigol MSO5000, you should ask her
<apo> electronic_eel: I did
juli967 has quit [Quit: Nettalk6 -]
juli967 has joined #scopehal
juli967 has quit [Quit: Nettalk6 -]
juli967 has joined #scopehal
bvernoux has joined #scopehal
<bvernoux> hello
<bvernoux> so I have checked my SouthWest Microwave connectors ;)
<bvernoux> 3 are really bad ;)
<bvernoux> I do not know why but they have solder and are clearly not good
<bvernoux> on center pin
<miek> salvaged from boards, rather than new old stock?
<bvernoux> the strange stuff is why they have soldered the pin !!
<bvernoux> such connectors shall be not soldered
<bvernoux> there is screw for that to avoid soldering
<bvernoux> which are the best for accurate measurements up to 40GHz
<bvernoux> my cheap 20USD microscope worked fine in fact
<bvernoux> it is touchy to have good quality anyway
<bvernoux> as all is manual ;)
<bvernoux> so anyway it is a good deal with 5 perfect connectors, 3 bad, and 2 other usable (with little solder)
<bvernoux> for less than 60USD total ;)
<bvernoux> I have bought 10 others ;)
<miek> nice. did you work out which variant they are?
<bvernoux> see photo
<miek> ooh, neat
juli967 has quit [Quit: Nettalk6 -]
<miek> i've never looked into using a microscope for measurements like that. how accurate is it?
<bvernoux> I have also a photo reference of my other SMA
<bvernoux> I will say accuracy is something like 0.025mm ;)
<bvernoux> I calibrate it why know value
<bvernoux> Reference inside 6.35mm
<bvernoux> in theory such connector are accurate at +/-0.0254mm
<bvernoux> especially for microwave ;)
<bvernoux> like you see on different measurements there is not lot of variation
<bvernoux> I will say they are often better than +/-0.02mm
<miek> i wonder whether there's some linux software to do measurements like that.. :)
<bvernoux> All is done with SuperEyes ;)
juli967 has joined #scopehal
<bvernoux> not too bad for 20USD microscope but take lot of time
<bvernoux> center pin tolerance is +/-0.001 inch
<bvernoux> with center pin diameter 0.015inch
<bvernoux> 0.38mm ;)
juli967 has quit [Client Quit]
<bvernoux> and I measure 0.387mm ;)
futarisIRCcloud has joined #scopehal
juli967 has joined #scopehal
juli967 has quit [Read error: Connection reset by peer]
juli967 has joined #scopehal
maartenBE has quit [Ping timeout: 256 seconds]
maartenBE has joined #scopehal
bvernoux has quit [Quit: Leaving]
juli967 has quit [Quit: Nettalk6 -]
<azonenberg> MEAD enclosures out for delivery
<_whitenotifier-f> [scopehal] tomverbeure opened pull request #149: Adjust VOLT_DIV if initial try is incorrect. -
<azonenberg> tverbeure: 8 divs/screen is pretty industry standard for scopes that work in divs rather than absolute units
<_whitenotifier-f> [scopehal] azonenberg closed pull request #149: Adjust VOLT_DIV if initial try is incorrect. -
<_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier-f> [scopehal] tomverbeure ff1a2e1 - Adjust VOLT_DIV if initial try is incorrect.
<_whitenotifier-f> [scopehal] azonenberg 7ac5671 - Merge pull request #149 from tomverbeure/siglent_volt_div_bug Adjust VOLT_DIV if initial try is incorrect.
<tverbeure> So after this change, things works when you adjust the Y axis while the scope is idle. But it still has the 10x wrong when you're in continuous update mode.
<Error_404> azonenberg: backlog ack
<tverbeure> It seems as if the probe bug only manifests itself when the scope is not armed!
<tverbeure> Or it only manifests itself sometimes.
<tverbeure> I can work around that by bailing out early: if the value is in the right range after the first try, then don't do the adjustment.
<azonenberg> tverbeure: makes sense, and wow
<_whitenotifier-f> [scopehal] azonenberg opened issue #150: RGMII decode only works when link speed is 1 Gbps -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #150: RGMII decode only works when link speed is 1 Gbps -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #150: RGMII decode only works when link speed is 1 Gbps -
<Degi> Hmh maybe we can support 14 bits too
<Degi> offset etc was in ps right
<azonenberg> Degi: yes all timestamps are int64 picoseconds
<azonenberg> this should be documented in Oscilloscope.h in the doxygen comments for each function
<azonenberg> (if it's not, send a PR to clarify)
<Degi> yeah it is
<Degi> Huh now I get a warning td::bad_alloc
<Degi> Executing make again helped
<Degi> How do I show what it sent over the connection again?
<azonenberg> --trace SCPISocketTransport
<Degi> Ok now I get a std::bad_alloc error which I didnt get before, weird
<Degi> I wonder why there's two mutexes in GetChannelVoltageRange
<azonenberg> Degi: one for the cache and one for the scpi link
<azonenberg> the idea is not to block on access to the scpi if thedata is in cache
<azonenberg> also you should be locking the cache mutex when updating m_channelVoltageRanges
<azonenberg> writing to a std::map is not atomic
<azonenberg> use separately scoped blocks, since by this point there's no need to have the scpi mutex (m_mutex) locked anymore
<azonenberg> you want to hold that lock for as little time as possible because it causes contention between the ui and waveform download
<azonenberg> and only grab it if you're certain you need to do scpi stuff, i.e. the data in question is not in cache\
<azonenberg> and avoid holding both at once
<azonenberg> because if you hold the cache mutex while waiting for the scope then you're preventing the whole point of the cache
<Degi> A block is a thing encased by {}?
<azonenberg> yeah
<azonenberg> the lock_guard locks the mutex in the constructor and unlocks in the destructor
<azonenberg> much cleaner and more idiotproof than explicitly calling lock and unlock
<azonenberg> since returning early or throwing an exception will still unlock it
<Degi> Hmh ye
<Degi> s
<azonenberg> there really should be some dev documentation with this kind of info
<azonenberg> but i've been busy enough trying to keep the user docs up to date
<Degi> Can I somehow make the error output more verbose?
<miek> easiest is probably to run it in gdb & break on the exception
<azonenberg> yeah that's what i'd do
<azonenberg> std::bad_alloc is a stl exception thrown saomewhere i wasnt expecting it
<azonenberg> probably means you have some size massively wrong
<azonenberg> gdb "catch throw" should break on an exception
bvernoux has joined #scopehal
<Degi> Thread 5 "ScopeThread" hit Catchpoint 1 (exception thrown), 0x00007ffff6269062 in __cxxabiv1::__cxa_throw (obj=0x7fffdc000f20, tinfo=0x7ffff6393ee0 <typeinfo for std::bad_alloc>,
<Degi> 78/build/gcc/src/gcc/libstdc++-v3/libsupc++/ No such file or directory.
<Degi> dest=0x7ffff6267330 <std::bad_alloc::~bad_alloc()>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/
<azonenberg> and back up a bit?
<azonenberg> "bt" gives a backtrace
<azonenberg> look at the actual scopehal function that triggered it
<bvernoux> azonenberg, if you are interested I have done full check of SouthWest Microwave connectors bought on ebay for about 5USD/unit with shipping
<bvernoux> 3 units are clearly bad ;)
<Degi> test
<Degi> Yes fund it
<Degi> *found
<Degi> "unsigned char* temp_buf = new unsigned char[maxpoints];"
<azonenberg> so maxpoints is probably nonsensically large
<miek> you can switch to a different frame with 'f <n>', taking frame numbers from the backtrace and then print out variables with 'p <name>'
<Degi> Some look kinda oxidized @ bvernoux
<bvernoux> Degi, Yes and the worst is they have soldered them
<Degi> Oh yeah maxpoints is nonsensically large
<bvernoux> I will check If I can repair that to remove this solder...
<bvernoux> but one is particularly broken ;)
<bvernoux> pin length is too short probably cut
<bvernoux> and with a torsion
<bvernoux> yes also BAD_PIN3 ;)
<bvernoux> I doubt I could use such connectors ...
<bvernoux> will do test just for fun to see the impact
<bvernoux> I plan to build some special TRL boards with those connectors
<bvernoux> sma-probetarget_oshpark_bve_v0_5 based on azonenberg test board ;)
<bvernoux> and also a new TRL Board
<bvernoux> TRL board will be produced with RO4350B & I will try also OSHPark If I can have a coupon ;)
<bvernoux> to compare both
<Degi> If I add breakpoints to GetSampleDepth, the correct value is returned
<azonenberg> Degi: memory corruption earlier in the code?
<azonenberg> see what valgrind or something says
<miek> or it only returns junk sometimes
<miek> do you have the scpitransport trace from when the exception fired? did the response to 'ACQ:MDEP?' look right?
<Degi> Yes it returns the right value
<Degi> 1.00000E+03
<Degi> Oh now it has a munmap_chunk() invalid pointer
<azonenberg> So you definitely have some corrupted pointers somewhere
<Degi> At string reply = m_transport->ReadReply();
<Degi> When I start a new session it doesnt even ask for m depth for some reason
<Degi> Almost as if it sometimes ignores if(m_mdepthValid) before returning an invalid value
<azonenberg> is m_mdepthValid maybe not being initialized?
<Degi> Its initialized in FlushConfigCache
<azonenberg> is it initialized in the constructor? or is that called by the constructor?
<azonenberg> the cache isnt explicitly flushed during startup afaik
<Degi> WEll now it gets stuck at sending WAV:DATA?
<miek> btw, i don't think AcquireData should be taking the lock before calling GetSampleDepth - looks like it could deadlock?
<azonenberg> miek: m_mutex is a recursive mutex for exactly this reason
<azonenberg> i.e. you can lock it if you already own it
<miek> ah right
<Degi> Well doesnt make much of a difference if I move it below
<Degi> "for(size_t npoint = 0; npoint < maxpoints; npoint += maxpoints)" huh?
<azonenberg> that sounds like a bug?
<miek> Degi: hang on 'WAV:DATA?' probably means ReadRawData is requesting more than the rigol is sending, so it sits waiting for more
<Degi> Well it tries to read the right amouint at least
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [scopehal-apps] azonenberg 381dbdc - ScopeSyncWizard: Fixed a few bugs. Multithreaded cross-correlations for faster deskewing of deep waveforms. Limited max allowed skew to 10K points.
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-f> [scopehal-apps] azonenberg 8dc9f32 - Fixed crash during shutdown
<_whitenotifier-f> [scopehal-apps] azonenberg 4e647ca - ScopeSyncWizard: fixed bug introduced during multithreading conversion
<_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±5]
<_whitenotifier-f> [scopehal] azonenberg 529be21 - RGMII decode: added support for in-band status
<_whitenotifier-f> [scopehal] azonenberg a7c62c9 - EthernetRGMIIDecoder: now correctly use single or double-rate sampling depending on clock rate. Fixes #150.
<_whitenotifier-f> [scopehal] azonenberg closed issue #150: RGMII decode only works when link speed is 1 Gbps -
<azonenberg> ok so i think i've done what i can do on the RGMII decode, time to dismantle the test setup and free up some bench space
<azonenberg> SGMII / 1000base-X is still an open ticket re ethernet
<azonenberg> but i dont have a board with that readily available right now - there's one but its' a big virtex board racked on the other side of the lab that i dont really feel like moving
<monochroma> azonenberg: grab a cheap media converter :D
bvernoux has quit [Quit: Leaving]