<azonenberg>
this is 10Gbase-R after fixing a bug in my CDR PLL
<lain>
:o
<azonenberg>
top eye is with cable de-embedding only, bottom is after 3 dB of CTLE from 4.5 - 6 GHz. Which may or may not actually do what i think it is, but it seems to be opening the eye up a bit
<azonenberg>
tl;dr the original cdr pll calculated the clock period in integer ps, i quickly realized this was inadequate for higher speeds so i switched to using a float for calculating the period
<azonenberg>
but i had some integer math early on that ended up rounding the period down at T=0
<azonenberg>
it recovered after PLL lock but early on we ended up with a PLL period of 96 ps instead of 96.98
<azonenberg>
while it did recover over time, for the first few hundred UIs it was phase shifting all over the place
<azonenberg>
You know what this means, right?
<azonenberg>
Now I can write 64/66b and 10Gbase-R protocol decoders :D
<azonenberg>
I don't have the bandwidth to do proper SI work obviously, but i can at least see the data. And with a faster scope obviously I could do SI work
<azonenberg>
When you're around can you give me a quick update on status of the keysight/agilent driver?
<azonenberg>
What's holding it back from "usable for basic tasks" level completion, if anything?
<azonenberg>
noopwafel: ping
<noopwafel>
I do not have a keysight nor an agilent :)
<noopwafel>
trying to update the compat list?
<azonenberg>
noopwafel: no, i was actually going to poke you about picoscope stuff
<azonenberg>
I'd like to add you to the github project so i can assign the picoscope ticket to you, and you can do dev on a feature branch
<azonenberg>
And so you can, when the time comes, write documentation for the driver
<azonenberg>
long term i think the pico bridge should live in a separate binary within scopehal-apps that is automatically compiled if the pico libs are detected by cmake
<azonenberg>
and if not detected, the bridge isn't compiled but the scopehal driver is still there, so that you can connect to a bridge elsewhere on the LAN
<azonenberg>
make sense?
<azonenberg>
noopwafel: As with the other folks i've given project access to, for the moment it would be probationary. So basically you can do what you want in a feature branch but I'll want to look at the code before it gets merged to master
<azonenberg>
Sound good?
<noopwafel>
It's functionally similar to having a branch in a fork and PRing, I'm fine either way.
<azonenberg>
noopwafel: yeah the difference is, i can assign tickets to you
<azonenberg>
it makes the project management easier
<noopwafel>
ah :) then sure
<azonenberg>
i dont think its possible to give someone an issue in the ticketing system without also giving them commit access
<azonenberg>
at least if it is i havent found a way
<azonenberg>
you're noopwafel on github too?
<noopwafel>
yep
<azonenberg>
Invites sent
<azonenberg>
go accept them and i'll assign you the ticket for pico
<_whitenotifier-b>
[scopehal] azonenberg added user noopwafel - https://git.io/JJ0I1
<_whitenotifier-b>
[scopehal-apps] azonenberg added user noopwafel - https://git.io/JJ0I1
<azonenberg>
Ok, so go move your bridge and driver code to a feature branch under scopehal-apps and scopehal respectively
<noopwafel>
first I have to go rescue my laptop from the hackerspace :-) but should go head that way now
<azonenberg>
Lol. Also what's the status of your testing/experience with the rigol driver?
<azonenberg>
are you having problems or is it being pretty good for you?
<noopwafel>
so I still have pending changes for both Rigol driver and the Tek
<azonenberg>
pending meaning not ready to merge yet, or awaiting my review?
<noopwafel>
not ready :)
<azonenberg>
Ok
<noopwafel>
do you know what the Tek driver was tested on / if someone here cares?
<azonenberg>
I don't think it ever worked
<noopwafel>
I noticed the docs had no listed hw for it
<azonenberg>
tverbeuere wrote the initial skeleton
<azonenberg>
for whatever tek he had
<azonenberg>
then he dropped out of the channel before finishing it i think
<azonenberg>
i havent seen him in a month or two
<noopwafel>
ah okay, so maybe I will just PR code that works for the space's tek
<azonenberg>
Yes. If you can get it working on one tek scope and document that, that's a solid starting point
<noopwafel>
I'm not going to sink much time into either driver because they are both *slow*.
<azonenberg>
Do you want me to assign the tek driver issue to you then?
<azonenberg>
If you get basic functionality working that's enough for me to close the "add tek driver" ticket, we can then file separate tickets for missing/broken features later on
<noopwafel>
but the tek is the only >1gsps scope I have access to
<noopwafel>
sure, that would be also fine
<azonenberg>
Ok
<azonenberg>
yeah like i said i was hoping tom would do that
<_whitenotifier-b>
[starshipraider] azonenberg opened issue #2: Design SATA mid-span test fixture - https://git.io/JJVAk
<_whitenotifier-b>
[scopehal] azonenberg commented on issue #34: Add SATA protocol decoder - https://git.io/JJVAI
<azonenberg>
noopwafel: what is the model of the tek scope at the hackerspace?
<azonenberg>
And what is the Rigol?
<_whitenotifier-b>
[scopehal] azonenberg assigned issue #175: Crash with Rigol DS1104Z connected via USBTMC - https://git.io/JJmOc
<azonenberg>
noopwafel: once your final rigol changes are merged, i want you to sync with whitequark and get her to test those fixes. If no response or she confirms fixed, close #175
<_whitenotifier-b>
[scopehal] azonenberg edited issue #132: Remove support for non-queued acquisition mode in Oscilloscope::AcquireData() - https://git.io/JfPmM
<_whitenotifier-b>
[scopehal] azonenberg assigned issue #132: Remove support for non-queued acquisition mode in Oscilloscope::AcquireData() - https://git.io/JfPmM
<_whitenotifier-b>
[scopehal] azonenberg commented on issue #132: Remove support for non-queued acquisition mode in Oscilloscope::AcquireData() - https://git.io/JJVAi
<azonenberg>
monochroma: ping
<azonenberg>
What's the status of scopehal-apps:#66
<monochroma>
azonenberg: untested, though i know someone came in here a while ago (can't remember who) and was trying to run glscopeclient in a VM without full GL passthrough and iirc i was surprised it basically threw an error similar to what i was working on
<monochroma>
not quite sure where it came from
<azonenberg>
So basically we still dont have proper gl version checking?
<noopwafel>
azonenberg: TDS5104. and Rigol DS1054Z, DS1102D, DS1052E. none of them are working great but I can PR doc updates once tested.. and yes will sync.
<azonenberg>
noopwafel: it's also ok/helpful to doc stuff as not working
<azonenberg>
if there's say a firmware bug we cant work around
<azonenberg>
just so people dont waste time trying
<azonenberg>
negative results are important :)
<miek>
azonenberg: re agilent, basic local use works well at the moment. being able to use it from scopehal without touching the scope front panel is waiting on me implementing a bunch of the remaining Get/Set functions
<azonenberg>
Ok
<azonenberg>
So no major blockers/bugs? any idea when you'll have time to implement it fully?
<azonenberg>
Also what's the status of the USB stuff? have you been working on that lately?
<noopwafel>
.. ooh, usb decoder?
<miek>
nah, no major blocks. no idea on time estimates though :p i've not had a chance to sit down and work on that or USB for a while
<miek>
noopwafel: so there's a decoder for full speed already in there (that azonenberg wrote). i got it doing some high speed decoding a while back, with a bunch of hacky changes :) getting it done properly is on the todo list...
<azonenberg>
and testing / fixing low speed
<miek>
damn, it's performing well these days. i'm getting 45-50WFM/s with two channels
<azonenberg>
I still need to work on those vertical bars in the eye patterns\
<miek>
it's AMD taxichip (90s serdes-ish thing) and yeah, on the agilent
<azonenberg>
i've improved the rounding behavior etc which helps a lot
<azonenberg>
but there's still spots where none of the antialiasing/rounding happens to hit certain columns of pixels
<azonenberg>
But i think i'm done with glscopeclient work for the weekend
<azonenberg>
I already spent more time on it than i wanted because i got nerdsniped by the 64/66 and 10g stuff
<azonenberg>
i need to finish the tweaks to MEAD to get it ready for production, then finish maxwell
<noopwafel>
the usbtmc code doesn't make much sense to me
<noopwafel>
(also it doesn't work)
<noopwafel>
anyone actively using/debugging that?
<noopwafel>
[I switched to the #if 0 code which WFM, so I may PR that change..]
bvernoux has joined #scopehal
NeroTHz has quit [Read error: Connection reset by peer]
<azonenberg>
noopwafel: usbtmc is another of tverbeure's abandoned projects
<azonenberg>
i dont know how far he got with it, he seemed to think it worked with his tek
<noopwafel>
by default it uses a kind of confusing read loop, which doesn't work for me
<noopwafel>
but I will do something about it
<noopwafel>
very nice to have :)
<noopwafel>
so apparently I get 3.6WFM/s on the ds1000, mostly waiting for the arm
<_whitenotifier-b>
[scopehal] noopwafel opened pull request #213: Rigol: basic support for DS1000D/E - https://git.io/JJwla
<_whitenotifier-b>
[scopehal] noopwafel commented on pull request #213: Rigol: basic support for DS1000D/E - https://git.io/JJwlr
<noopwafel>
was first testing this with a DS1000E, which then stopped talking and then refused to back turn on, so I become more and more impressed with Rigol scopes
<azonenberg>
loool
<azonenberg>
I think i've done that with my 1102D
<azonenberg>
When i bought my first lecroy it was like night and day
<_whitenotifier-b>
[scopehal] noopwafel opened issue #214: USBTMC read loop doesn't work when reading entire buffer at once - https://git.io/JJwli
<_whitenotifier-b>
[scopehal] noopwafel assigned issue #214: USBTMC read loop doesn't work when reading entire buffer at once - https://git.io/JJwli
<_whitenotifier-b>
[scopehal] noopwafel commented on pull request #191: [WIP] fix support for Rigol DS1000D/E scopes - https://git.io/JJwly
<_whitenotifier-b>
[scopehal] noopwafel closed pull request #191: [WIP] fix support for Rigol DS1000D/E scopes - https://git.io/JJ0Id
bvernoux has quit [Read error: Connection reset by peer]
<Degi>
Soo like it didnt turn back on at all?
<Degi>
It just broke?
<noopwafel>
apparently it's done this before, maybe caps or so, I didn't have the patience to open it up
<noopwafel>
which is to say, who the heck knows, and have not tried checking rails or anything
<azonenberg>
noopwafel: fwiw, randomly shutting off and refusing to turn back on is a common problem with ds1000 series scopes
<azonenberg>
i've had it too
<azonenberg>
i sent it back under warranty, got a mobo replacement
<azonenberg>
that fixed it for ~4 years
<azonenberg>
then it came back
<azonenberg>
at this point it wasnt under warranty anymore so i gave it to somebody who wanted to try fixing it
<azonenberg>
I had a 350 MHz LeCroy by this point and so didnt really need the rigol
<azonenberg>
I haven't heard from her since, so no idea if she managed to fix it or what
<azonenberg>
noopwafel: So is #213 ready to merge in your opinion?
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #214: USBTMC read loop doesn't work when reading entire buffer at once - https://git.io/JJwli
<azonenberg>
(reads comment) ok not done :p
<noopwafel>
right :D
<noopwafel>
just I prefer to PR useful code early, worst-case someone else can finish
<noopwafel>
and not surprised to hear it's a common problem
<azonenberg>
this is unrelated to the "scope firmware hangs in response to certain SCPI commands" bug
<azonenberg>
in which it didnt power down
<azonenberg>
it just became unresponsive to any button input
<_whitenotifier-b>
[scopehal] tomverbeure commented on issue #214: USBTMC read loop doesn't work when reading entire buffer at once - https://git.io/JJwRJ