azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
codysseus has quit [Remote host closed the connection]
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #scopehal
futarisIRCcloud has joined #scopehal
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
juli966 has quit [Quit: Nettalk6 -]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg> miek: it could be related
<miek> reading that issue back, i think there were some misunderstandings and different people were talking about different issues
<miek> #146 originally was a hang because WAV:DATA? never got the amount of data it was expecting. after adding a timeout, it became clear that the rigol wasn't providing any data for channel 1 (the same issue bvernoux just ran into)
<azonenberg> so you think #146 was actually two bugs
<azonenberg> and one is fixed
<azonenberg> while the other is still there
<miek> the other issue people ran into was the rigol itself crashing when a lot of scpi stuff happened (cause unknown), and people reported it fixed with a newer firmware version
<azonenberg> ah, ok
<azonenberg> SO that's fixed while the original bug is still present
<miek> yup, i think so
<azonenberg> Seems likely
<azonenberg> also bluezinc just contributed an I2S decode implementation. I haven't had time to review the PR yet so that's my next focus for tonight
<miek> also possible that some workarounds made it into the codebase, but might've got lost later? i didn't track things close enough, but pepijndevos_ might remember more
<azonenberg> bluezinc: ping
<azonenberg> I looked at your i2s decode and have a few comments
<azonenberg> Let me know when you're around to discuss
<azonenberg> in particular, while what you have looks like it will work, I think there are some fixes that will make the code cleaner and the results more useful to users
m4ssi has joined #scopehal
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #scopehal
juli966 has joined #scopehal
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [scopehal] azonenberg 1e7ba07 - EmphasisRemovalFilter: added pre-emphasis support
juli966 has quit [Quit: Nettalk6 -]
<_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier-f> [scopehal] azonenberg 625dc6c - TappedDelayLineFilter: now fixed size of 8 taps
<_whitenotifier-f> [scopehal] azonenberg 30ed2c3 - TappedDelayLineFilter: AVX optimizations
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [scopehal-apps] azonenberg e6a289c - WaveformArea: RescaleEye() no longer double-refreshes eye patterns
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #292: Use mapped textures for eye patterns so we can download in parallel -
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #292: Use mapped textures for eye patterns so we can download in parallel -
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #292: Use mapped textures for eye patterns so we can download in parallel -
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #293: Parallelize compute/download of Cairo over/underlays -
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #293: Parallelize compute/download of Cairo over/underlays -
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #293: Parallelize compute/download of Cairo over/underlays -
<_whitenotifier-f> [scopehal] azonenberg opened issue #354: Add flag to Waveform indicating "waveform is dense packed" -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #354: Add flag to Waveform indicating "waveform is dense packed" -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #354: Add flag to Waveform indicating "waveform is dense packed" -
<_whitenotifier-f> [scopehal] azonenberg opened issue #355: Cache Filter::FindZeroCrossings results -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #355: Cache Filter::FindZeroCrossings results -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #355: Cache Filter::FindZeroCrossings results -
<azonenberg> (can you tell i've been spending a while looking at vtune? lol)
m4ssi has quit [Remote host closed the connection]
bvernoux has joined #scopehal
<bvernoux> hello
<bvernoux> I have just received my LeoBodnar Fast risetime pulse generator (2.92mm output) [PULSER-2.92mm]
<bvernoux> It work fine just tested it with my Rigol MSO5000 ;)
<bvernoux> I obtain about 700ps Rise/FallTime on Rigol MSO5000 which is clearly not bad ;)
<azonenberg> I think you need a faster scope :p
<bvernoux> yes ;)
<bvernoux> and with native SMA/2.92mm connector not BNC ;)
<bvernoux> I have finished to build my EEZ BB3 too
<bvernoux> with a new LCD Touch screen ;)
<bvernoux> which is clearly brighter and better for 15USD ;)
<bvernoux> I have an annoying noise on my scope too something like 20mVpp
<bvernoux> Do you have such with your Lecroy ?
<bvernoux> I suspect it is the probe/scope as I have the same on my old DS1102E (maybe a bit less noise about 15mVpp)
<bvernoux> I was expecting something better with Rigol MSO5000
<bvernoux> I need to check the spec ;)
<azonenberg> In 50 ohm mode with the input floating, on my HDO9204
<bvernoux> I speak on 10Mohms
<bvernoux> I do not have 50 ohms option :(
<azonenberg> Ok... 1M mode, no probe connected, 8 bit mode, I have 1.07 mV p-p
<bvernoux> me no probe or probe is the same about 20mVpp
<bvernoux> So it is the noise of the scope
<azonenberg> actually wait that wasnt at full sample rate
<azonenberg> 40 Gsps, 1M input, HD off, no probe: 1.23 mV
<bvernoux> anyway yours cost 20x more new ;)à
<azonenberg> 40 Gsps, 1M input, HD on, no probe: 1.18 mV
<bvernoux> ok so around 1mV
<azonenberg> 40 Gsps, 50 ohm input, HD off, no probe: 1.17 mV
<bvernoux> ha interesting the same on 50 ohms
<azonenberg> 40 Gsps, 50 ohm, HD on, no probe: 1.08 mV
<azonenberg> Now let me see what happens if i back off a bit
<azonenberg> what's the sample rate on your scope?
<bvernoux> If I use averaging 16K samples it is better of course ;)
<azonenberg> and bandwidth?
<azonenberg> 8 Gsps 350 MHz?
<bvernoux> 568MHz on Chan1
<bvernoux> 547MHz on Chan2
<bvernoux> 558Mhz on Chan3
<bvernoux> 580Mhz on Chan4
<bvernoux> the Chan4 is clearly better in fact ;)
<azonenberg> Ok
<miek> when you have no probe connected, is the channel set to 1x?
<bvernoux> miek, let me check again with 1x
<azonenberg> so, in order to keep measurements comparable
<bvernoux> anyway IIRC I have always 20mVpp noise ...
<azonenberg> i'm dialing my sample rate down to 10 Gsps
<miek> on my scope i see 2mV with no probe connected, but of course if i plug in a 10x probe the scale changes that to 20mV
<bvernoux> to measure the BW I have connected my Agilent E4432B with 50Ohm adapter to BNC
<azonenberg> and applying an 1.5 bit noise/enhanced resolution filter
<azonenberg> Which has a -3 dB bandwidth of 605 MHz
<azonenberg> So now i effectively have a 10 Gsps 600 MHz scope
<azonenberg> in 1M ohm 1x mode, no probe, I measure 870 uV p-p
<bvernoux> and I have checked the frequency up to obtain -3dB on amplitude
<bvernoux> increasing freq
<azonenberg> And about the same in 50 ohm mode
<azonenberg> Lowering the bandwidth more gives even less noise
<azonenberg> if i set the bandwidth limit to 200 MHz I can get 12.2 bit resolution and 533 uV p-p noise
<azonenberg> at 20 MHz bandwidth effective resolution goes up to 13.8 bits and p-p noise is 388 uV
<bvernoux> yes 1X 1Mohm I have max 2.7mVpp
<bvernoux> with 1mV scale I have <1.36mVpp
<bvernoux> so it is not bad compared to big scope
<_whitenotifier-f> [scopehal] azonenberg edited issue #190: Add filter to apply pre/de emphasis to a signal -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #190: Add filter to apply pre/de emphasis to a signal -
<_whitenotifier-f> [scopehal] azonenberg commented on issue #190: Add filter to apply pre/de emphasis to a signal -
<bvernoux> also here using Hi-Res mode is better for noise
<bvernoux> anyway it does decimation ;)
<azonenberg> yeah the high res mode is basically a LPF so it makes sense noise above the passband is attenuated
<azonenberg> bvernoux: oh did you see the pcie demo vid i posted a day or so ago?
<bvernoux> yes very nice
<bvernoux> I'm working to improve the support of Rigol MSO5000 in glscopeclient ;)
<azonenberg> I'm gonna be doing some performance and additional signal processing stuff over the next few days
<bvernoux> it requires an evolution of class SCPITransport
<bvernoux> void ReadRawData(size_t len, unsigned char* buf)
<bvernoux> it shall return number of data read
<bvernoux> to check if there was an error
<bvernoux> as it can appears that all samples are not read ...
<azonenberg> There is already an open ticket for that
<azonenberg> scopehal:#185
<azonenberg> Nobody is actively working on it
<azonenberg> so if you wanna work on that, go for it.
<_whitenotifier-f> [scopehal] azonenberg commented on issue #185: Expose actual number of bytes transferred in ReadRawData and possibly other commands -
<azonenberg> bvernoux: i suggest you fix #185 and send a PR for that in isolation, then work on the actual rigol bug separately
<bvernoux> yes
<miek> i think you should have a closer read of #146 - the root of that issue is the same thing you're seeing where channel 1 returns empty
<bvernoux> I will need also a lower access to socker recv
<bvernoux> to detect special case when we receive 1 data
<azonenberg> If you need to amend xptools too, go for it
<bvernoux> that avoid to loose lot of time waiting rx timeout
<bvernoux> the idea is to expose the socket
<bvernoux> are you ok ?
<bvernoux> it is just for some specific case to read the socket quickly (1st byte of data) to check if it returns 1 byte it means there is a bug ;)
<azonenberg> as long as it works on linux and windows
<bvernoux> yes I have done the code on my PC to instrument all
<azonenberg> and i'm not sure how much access to the raw socket you have on liblxi
<bvernoux> with my own C code using socket compatible with Linux & Windows
<azonenberg> anyway, fix #185 and we'll go from there?
<bvernoux> yes I will check the #185
<bvernoux> anyway that will improve lot of case if you stop the scope during glscopeclient running ;)
<bvernoux> and lot of robustness test
<bvernoux> ha nice pepijndevos have described exactly what I see ;)
<bvernoux> also I have found way to improve things ;)
<bvernoux> I can upload 10Mpoints now in 1WFM/s
<bvernoux> 10Kpoints is something like 2WFM/s anyway ...
<bvernoux> as there is limitation/slowness in Rigol MSO5000 FW ...
<bvernoux> especially trigger and few SCPI commands which are slow
<azonenberg> you have deep memory working now?
<azonenberg> fast?
<azonenberg> nice :D
<azonenberg> that makes it a lot more usable
<bvernoux> the data transfer is quite fast in fact about 40MBytes/s
<azonenberg> it just takes a long time to respond to a trigger or something?
<bvernoux> main issue is trigger is slow to rearm ;)
<bvernoux> and return STOP
<bvernoux> also issue is actual code thinks TD is OK but it is not with RAW data we shall wait Trigger to return STOP
<bvernoux> to have access to buffer
<azonenberg> Ok, well that's good to know
<azonenberg> i wonder if that will prevent the 1-byte read issue?
<bvernoux> I'm still doing lot of tests to see where we can gain some previous time and robustness with my own test code ;)
<azonenberg> if you treat TD as "armed" rather than ready to go?
<bvernoux> no that does not prevent it
<azonenberg> ah ok
<bvernoux> but I have it less often
<azonenberg> And yeah the rigol driver definitely needs some love
<bvernoux> the 1bytes is in fact a bug
<azonenberg> i've spent a lot of time optimizing and tweaking the lecroy driver
<azonenberg> the rigol driver never got that
<bvernoux> the scope think it has sent the data and it just return the 0x0A end of frame
<azonenberg> because i dont have a rigol to optimize/debug on
<miek> the reply from rigol in #146 is a little worrying, "oh just wait 500ms after a trigger"
<bvernoux> no there is no need to wait 500ms more ;)
<azonenberg> miek: btw how's usb stuff going?
<bvernoux> with my trick for the 1 byte returned we can acquire the buffer again and it works without loosing any time
<azonenberg> i forget if i mentioned, i implemented usb crc checking
<miek> yeah, i did see the crc checking, that's cool. i haven't had a chance to do anything more, mainly cause it's such a hassle to setup everything for probing :p
<azonenberg> Sounds like i need to respin my usb inline probe board
<azonenberg> if i made a board with SMAs for D+/D-, integrated resistive probes, and flow-through USB A/B ports would that help?
<miek> yeah, that would be great
juli966 has joined #scopehal
<azonenberg> the challenge is that USB isnt a big fan of DC coupling
<azonenberg> So the probes have to be AC coupled, and i need to choose an appropriate value for the coupling cap
<azonenberg> what i mean is, a 500 ohm load to ground from the probe across D+ and D- is bad
<azonenberg> usb guarantees a keepalive packet every millisecond or so right?
<azonenberg> A 10 uF coupling cap would have a time constant of 5 ms with a 500 ohm probe discharging it to ground. So we shouldn't see too much droop given the worst case 0.2*T delay between toggles
<bvernoux> azonenberg, My proposal is to also add a new API RecvRawData
<bvernoux> which will do not do the RecvLooped
<bvernoux> to be used only for specific case
<bvernoux> in fact that can optimize treatment for data
<bvernoux> as we can do the loop in high level and convert at same time the data
<bvernoux> without requiring a huge big buffer like today
<azonenberg> I prefer having a huge buffer because i can push it to gpu, do avx, etc
<bvernoux> in future like that we could even multithread the treatment on data and doing acquisition ...
<bvernoux> today It is not required of course as we do simple things like mul + add ...
<bvernoux> to scale the raw data to real value to float
<bvernoux> I speak about the raw big buffer
<bvernoux> the one used for raw data
<azonenberg> Yeah i know. and i am already looking into multithreading some of the waveform processing
<azonenberg> but i'm starting out with SIMD optimizations
<azonenberg> AVX2 is already enough to get some pretty substantial speedups
<miek> so i'm looking at what the big names do for this, and it seems like they all just have .1" headers to stick an active probe on :p
<azonenberg> Lol
<azonenberg> Yeah. I don't do that
<azonenberg> i like fixtures that are self contained and have 50 ohm outputs
<azonenberg> worst case, if active buffering is needed, it should be simple and on the fixture
codysseus has joined #scopehal
<azonenberg> miek: in general it looks like the big names have an over-reliance on active probes
<azonenberg> i think passive probes can get a lot better than they are now
<wbraun> Azonenberg whats the odds that putting a attenuator on a PCB to serve as a low Z scope probe going to a SMA will work without any weird frequency response issues?
<azonenberg> A matched attenuator is a terrible idea
<wbraun> Without needing to model it. Like say, two 100 ohm resistors in series with a 50 ohm trace going to a SMA connector? Up to 1Ghz.
<azonenberg> because it has 50 ohm input impedance
<azonenberg> That's not a matched attenuator :p
<wbraun> most of your reflections and frequency response issues were more than 1GHz and in large part due to the input leads, right?
<azonenberg> If you want, you can use my tested and proven attenuator design which is good out to 6 GHz with a probe tip and probably well past that if it's right up against a line on the DUT
<azonenberg> Vishay FC0402 resistors, 200-200-50
<azonenberg> with the 200 at the DUT end and the 50 closest to the SMA
<azonenberg> place them as close as you possibly can, preferably with the pads overlapping
<azonenberg> increasing space between them will hurt frequency response
<azonenberg> however you can get away with a fair bit of space out to 1-2 GHz
<azonenberg> on my 6 GHz probe the resistor bodies are essentially touching
<wbraun> How much do you think things would suffer if I just did this on the standard cheap JLC stackup or something/
<wbraun> things cant be that critical only up to 1GHz I assume
<azonenberg> There will be losses, which can be mitigated by putting the SMA as close to the resistors as practical. at 1 GHz the loss shouldnt be too bad even with a good inch or two of line
<azonenberg> as long as the line and SMA launch are well matched to 50 ohms
<azonenberg> if you keep the distance from resistors to SMA electrically short at 1 GHz this becomes less critical
<wbraun> I guess the JLC / oshpark prepreg is a bit thin but it should be close enough and JLC claims impedance control.
<wbraun> Thanks for the advice, I will let you know how it goes!
<azonenberg> the bigger thing is getting a good match at the sma launch itself
<azonenberg> this is why i like the amphenol connector i use
<azonenberg> with fairly easily achievable stackups, like oshpark 4 layer, and very small tweaks to the trace dimensions
<azonenberg> you can make it well matched to a coplanar waveguide
<wbraun> P/N?
<azonenberg> in fact, if you just take the recommended footprint and extrude it into a GCPW with ground on layer 2
<azonenberg> you get something fairly close to 50 ohms. it's not ideal but very close
<azonenberg> 901-10511-3, aka ARF2500-ND
<azonenberg> it's a little expensive but a very nice connector
<azonenberg> That's what i use on the AKL-PT1
<wbraun> I will see what I can figure out without modeling anything. Nothing is that critical. I am creating a low power diode reverse recovery tester and want to avoid needing any fancy $$$ probes
<azonenberg> Didn't you buy an AKL-PT1 on my kickstarter?
<azonenberg> that version is only good to ~2 GHz but why not just use it?
<azonenberg> or do you specifically want something integrated into the fixture?
<wbraun> Bandwidth is only going to be ~1GHz (I think thats the fastest scope in the lab) and I should be able to characterize the test fixture with a VNA
<wbraun> Yah, I want something integrated. I might bring my AKL-PT1 to verify things though.
<azonenberg> Great. I'm also working on a solder-in AKL-PT1 variant, the AKL-PT2
<azonenberg> if you're interested i can probably hook you up with a beta unit at some point
<azonenberg> the second PCB iteration is at oshpark now
<azonenberg> also you may still be interested in the v1.3 AKL-PT1 at some point because it has lower loading than the kickstarter edition (less input capacitance)
<azonenberg> even if the extra bandwidth isn't helpful
bvernoux has quit [Quit: Leaving]
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #scopehal
<marshallh> wbraun: i did that on a pcb, embedded 950 ohm resistors to SMA>coax
<marshallh> it worked pretty well