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] https://git.io/JIeTs
<_whitenotifier-f>
[scopehal] azonenberg 1e7ba07 - EmphasisRemovalFilter: added pre-emphasis support
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #292: Use mapped textures for eye patterns so we can download in parallel - https://git.io/JIeHc
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #292: Use mapped textures for eye patterns so we can download in parallel - https://git.io/JIeHc
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #292: Use mapped textures for eye patterns so we can download in parallel - https://git.io/JIeHc
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #293: Parallelize compute/download of Cairo over/underlays - https://git.io/JIeHu
<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 - https://git.io/JIvTH
<azonenberg>
bvernoux: i suggest you fix #185 and send a PR for that in isolation, then work on the actual rigol bug separately
<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