<azonenberg>
interesting, i assumed it was tapered for mechanical reasons
<Degi>
Maybe on AKL-PT1 v2 that could be an idea, to taper the ground around the resistors
<Degi>
That could be too
<Degi>
Like that is just a suspicion
<Degi>
Should I try to make an OpenEMS model?
<azonenberg>
Sure
<azonenberg>
anyway other probe naming... high-z active voltage probes are ZS(bandwidth in MHz)
<Degi>
At lecroy?
<azonenberg>
Yes
<azonenberg>
differential probe amplifiers are D(bandwidth in GHz)(2 digit series ID)
<azonenberg>
where all probes with the same series ID have interchangeable tips
<azonenberg>
e.g. D420 and D620 are 4 and 6 GHz amplifiers compatible with Dx20 tips
<azonenberg>
D830 and D1330 are 8 and 13 GHz amplifiers that use Dx30 tips
<Degi>
neat
<azonenberg>
as far as i can tell the series ID has no meaning
<Degi>
There should be triferential tips for measuring three phase xD
<azonenberg>
10 and 20 are both used for low bandwidth wavelink probes, 30 is for higher end wavelink probes, 05 is the highest end wavelink probes
<azonenberg>
10 are blue, 20 is orange, 30 is cyan, 05 is red
<Degi>
Kinda counterintuitive... Good to know
<azonenberg>
there are also older gray and purple versions that i dont remember the IDs of
<azonenberg>
none of those are in current use but you can find them on ebay
<Degi>
Neat, OpenEMS can simulate STL files
<azonenberg>
As far as I can tell Dx10 and Dx20 have different attenuation but are otherwise ~identical
<azonenberg>
Dx10 is 2.5V p-p range, Dx20 is 5V p-p range
<azonenberg>
that's the low bandwidth series, 4/6 GHz
<azonenberg>
the mid bandwidth Dx30 series is 8/10/13 GHz and are all 3.5V p-p range
<azonenberg>
only one variant offered
<azonenberg>
The high bandwidth Dx05 series is 13/16/20/25 GHz and is 2.0V p-p range
<azonenberg>
and if you look at the documentation they avoid the tip-stub effect by using a short length of carbon fiber rod in the tip as a resistor
<azonenberg>
it looks to actually be be built into the pogo pin itself
<azonenberg>
which puts the resistor super close to the end of the needle
<azonenberg>
Anyway, then that's all the WaveLink series
<azonenberg>
There is also the newer DH series probes which look totally different, different form factor too
<azonenberg>
They have only one family but two different tips, presumably with different resistors
<azonenberg>
the standard is 3.5V range and the "high sensitivity" tip is 2.0V range
<azonenberg>
DH series comes in 8, 13, 16, 20, 25, 30 GHz series which suggests that it's intended to be the next gen replacement for both the Dx30 and Dx05 series
<azonenberg>
interestingly the DH series appear to have the cable to the scope permanently mounted
<azonenberg>
rather than the WaveLink series which is one of a handful of "platform" modules that connect from the scope to a standardized interface, followed by interchangeable amplifiers
<Degi>
:/
<Degi>
Damn libraries get updated every so often
<Degi>
Why are all the science programs arch AUR
<Degi>
And often so shitty packaged with missing dependencies
<_whitenotifier-5>
[scopehal] azonenberg pushed 3 commits to master [+0/-0/±5] https://git.io/JOExD
<_whitenotifier-5>
[scopehal] azonenberg 141ad88 - eSPI: implemented decode of flash non-posted read/erase transactions. See #407.
<_whitenotifier-5>
[scopehal] azonenberg 0a0d03b - eSPI: Implemented merging of "Get Status" and "Get Flash Non-Posted" requests. See #407.
<_whitenotifier-5>
[scopehal] azonenberg 94ad19c - eSPI: Added support for flash channel completion packets. See #407.
<azonenberg>
is that checklist in your comment from almost a year ago still accurate?
<miek>
yup
<azonenberg>
Are there any blockers to proceeding on them other than your time?
<miek>
nope
<azonenberg>
Ok. Any idea when you'll have time to put a bit of work into that?
<azonenberg>
in particular, if we can reach the point of everything but digital channels working
<azonenberg>
i'd say close that ticket saying "basic support works" then make a new separate ticket for digital channel support
<azonenberg>
since that's reasonably self contained
<_whitenotifier-5>
[scopehal] azonenberg commented on issue #341: Split Siglent driver off from LeCroyOscilloscope as they've diverged too much - https://git.io/JOuTw
<_whitenotifier-5>
[scopehal] azonenberg closed issue #341: Split Siglent driver off from LeCroyOscilloscope as they've diverged too much - https://git.io/JksiG
<miek>
don't know at the moment, but yeah that sounds reasonable
<azonenberg>
miek: also we have a couple of USB tickets still assigned to you. Any chance you can work on those at some point?
<azonenberg>
(going through another round of "check on all open tickets and figure out status" now)
<miek>
hmm, i don't really have any immediate plans to work on any of those - they should probably just be left unassigned for anyone to take up
<_whitenotifier-5>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±3] https://git.io/JOuIa
<_whitenotifier-5>
[scopehal-apps] azonenberg 53d3863 - Updated to latest scopehal
<_whitenotifier-5>
[scopehal-apps] azonenberg closed issue #86: Add preference setting to partially redact instrument serial number in title bar - https://git.io/JfnyF
<_whitenotifier-5>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JOuIS
<_whitenotifier-5>
[scopehal-apps] azonenberg 60e9e9e - Update title bar any time preference dialog closes in case user changed Privacy.redact_serial_in_title preference
<Stephanie>
I tried compiling scopehal-apps and it appears to not work with newer versions of opencl-clhpp, unless i diagnosed it wrong
<azonenberg>
Stephanie: What version are you using?
<Stephanie>
2.0.13
<azonenberg>
Hmm, from what I recall CL 1.2 and 2.0 have a bunch of incompatibilities
<Stephanie>
cl.hpp is gone entirely, and when i replaced it with opencl.hpp, there was about 200 compile errors
<azonenberg>
and it should be using 1.2
<azonenberg>
as 2.0 seems to not be supported on a lot of platforms (specifically nvidia)
<Stephanie>
hmm
<Stephanie>
i guess I might have to package an old version of clhpp?
<Stephanie>
hmm... actually clhpp says it should work with opencl 1.0
<azonenberg>
My understanding was that most CL 2.0 distributions also supported 1.2 because of these incompatibilities
<Stephanie>
it seems like just a breaking change to the headers
<miek>
afaik the clhpp version isn't related to the opencl version. cl2.hpp claims to support opencl 1.0, 1.1, 1.2, and 2.0
<azonenberg>
#define CL_TARGET_OPENCL_VERSION 120 is supposed to build with 1.2 compatibility
<azonenberg>
apparently nvidia just announced opencl 3.0 support for Ampere, Maxwell, and later
<azonenberg>
just = april 6 2021
<azonenberg>
maxwell = geforce 700/800/900 series
<azonenberg>
they might be reversing their stance on it a bit
<azonenberg>
So perhaps it might be plausible to migrate to opencl 2.0 and simply require that nvidia users install a fairly recent driver
<azonenberg>
that would probably clean up a lot of the legacy junk we're currently dealing with
<azonenberg>
Stephanie: anyway, file a ticket for this problem and i'll start thinking about the best way to deal with it
<azonenberg>
nvidia was really the main blocker and them updating seems to have removed it
<azonenberg>
I just need to upgrade my nv drivers on both of my dev machines which is going to be mildly annoying as i'll have to close and restart all of my apps
<Stephanie>
ah, i might have found the kicker: pragma message("opencl.hpp: CL_HPP_TARGET_OPENCL_VERSION is not defined. It will default to 300 (OpenCL 3.0)")
<Stephanie>
anyway, ticket incoming
<Stephanie>
okay, a few #define's later and it appears to be compiling
<Stephanie>
i might send a patch
<_whitenotifier-5>
[scopehal] RX14 opened issue #412: Compile fails with recent opencl CLHPP - https://git.io/JOunU
<azonenberg>
In that case I guess we have two different things to do
<azonenberg>
1) fix the bad defines
<azonenberg>
2) more major refactoring to OpenCL 2.0 or later
<_whitenotifier-5>
[scopehal] azonenberg opened issue #413: Migrate to OpenCL 2.x - https://git.io/JOuni
<Stephanie>
CL_HPP_ENABLE_PROGRAM_CONSTRUCTION_FROM_ARRAY_COMPATIBILITY might be the define
<Stephanie>
quite a mess
<Stephanie>
the new siglent code doesn't seem to support SDS1000x-e it seems
<azonenberg>
mubes: ^
<d1b2>
<mubes> ...
<azonenberg>
stephanie: The old siglent code was basically useless since it was descended from the lecroy driver and pretty much bitrotted into garbage
<d1b2>
<mubes> No, it only supports 2000X+, 5000X+ and 6000.
<Stephanie>
ah
<azonenberg>
mubes: how different is the 1000 series?
<Stephanie>
iirc x-e is new software platform?
<azonenberg>
Also, i'm not sure if anyone has looked at scopehal-docs lately
<Stephanie>
the 1000 and 2000 series share the same code but only the newer models of that series or soemthing weird
<d1b2>
<mubes> From what I can see they're pretty different between the two series. It looks like a new codebase for the new-ones
<azonenberg>
but we should make sure the siglent documentation correctly reflects what is *actually* supported
<Stephanie>
there's docs of the new sw's scpi commands
<d1b2>
<mubes> TBH, I've got docs, but I'll need to borrow a scope to test it out on
<azonenberg>
mubes: can you send a PR to scopehal-docs updating the drivers section to describe what models currently work?
<d1b2>
<mubes> yep
<Stephanie>
if there's any way to share my scope over the internet with you
<azonenberg>
stephanie: please file a ticket against scopehal for support of the 1000x-e and related scopes as well
<azonenberg>
just so we have it on record as a to-do item
<Stephanie>
indeed
<d1b2>
<mubes> Stephanie...that might be possible, but you'll probably need to be on hand to hit reset a bit and set up triggers etc. What timezone are you?
<d1b2>
<mubes> Does your scope have VNC support?
<Stephanie>
it does support VNC
<Stephanie>
i'd need to set up some way of hitting the power switch on demand
<azonenberg>
I would also strongly recommend running through a VPN or SSH tunnel or something
<Stephanie>
of course
<azonenberg>
rather than opening the scope up to the internet unauthenticated
<azonenberg>
Which i have had people do in the past
<Stephanie>
there's already been one remote explot in that software
<azonenberg>
Lol
<azonenberg>
Yeah, it's just not a good idea
<Stephanie>
literally a command which runs any command as root over scpi
<Stephanie>
it was the way you upgraded your scope to 200mhz for a long while
<d1b2>
<mubes> Stephanie...how quickly do you need it?
<Stephanie>
now someone wrote an unlock code generator
<Stephanie>
but you used to just dump the memory and grab the upgrade codes
<Stephanie>
d1b2, not at all really, i was just making the offer open if you wanted to work on it
<azonenberg>
Stephanie: d1b2 is the discord bridge bot :)
<Stephanie>
...right
<Stephanie>
i knew that and yet
<d1b2>
<mubes> OK. I still have more to do on 2000X+ so can stack it after that. Perhaps I can get hold of one in the UK for a week or two...
<Stephanie>
im in the uk
<d1b2>
<mubes> ah, convinient! Roughly where?
<Stephanie>
surrey
<d1b2>
<mubes> OK, I'm in Notts....but at least the same TZ. Can you PM me an email address so I can ping you when I'm ready to hit at it?
<azonenberg>
PM discord to irc is a bit buggy i think
<azonenberg>
mubes: I'll PM her your email
<Stephanie>
im unliekly to be able to drive it to you
<d1b2>
<mubes> OK, perfect
<Stephanie>
i have discord though
<Stephanie>
whats your code
<Stephanie>
also uhh, actually
<Stephanie>
just email me hi @ stephanie.is
<d1b2>
<mubes> done
<azonenberg>
also for both of you - once we have demonstrated good progress on the 2000X+ driver, it would not surprise me if we could get access to other scopes via siglent
<d1b2>
<mubes> I hope so. I'm daily-driving the 2000X+. A few fixes as I go along and a few things i need to dig into
<azonenberg>
not sure if you saw but Digilent sent me some hardware to play with as well
<azonenberg>
I havent had time to do more than unbox it
<d1b2>
<mubes> Yes, I like the look of their hw...software, not so much.
<azonenberg>
Ditto for pico
<azonenberg>
between that, some fine tuning of the pico driver, and writing a couple of decodes i'm booked out for the foreseeable future
<Stephanie>
mubes, what would be your idea for transporting this scpoe when it comes to it
<d1b2>
<mubes> I don't really want your physical scope if we can avoid it. I might ask labtronix if they've got a demo unit I can borrow for a week or so....when I've got the time available that's all it'll take, but I'll co-ordinate with you so we can test it too
<Stephanie>
okay, sure
<Stephanie>
sounds good to me
<azonenberg>
Yeah remote should be good to start
<d1b2>
<mubes> ( @azonenberg...I still maintain the LabNation interface is the nicest PC software I've seen, even if it's functionally a bit light)
<azonenberg>
In general, glscopeclient and libscopehal should function over high latency VPN/WAN connections
<azonenberg>
although performance degrades significantly
<azonenberg>
one thing on my to-do list is improving tolerance for high latency connections by making more stuff nonblocking or run in background threads
<azonenberg>
but again, lots of things to do and i'm one person doing this in my spare time
<azonenberg>
So unless somebody else wants to take that on as a project it will be a while
<d1b2>
<mubes> Yes...good behaviour when it looses connection to the scope is on my list
<azonenberg>
That would also be good. Having it detect that it's lost connectivity and somehow fall back to offline mode?
<azonenberg>
or try to reconnect, or both
<azonenberg>
right now Bad Things(tm) happen
<d1b2>
<mubes> yes..doing something would be handy.
<azonenberg>
I've also got a few other things to work on, like right now there's some destructor ordering bugs
<azonenberg>
where when the app closes it crashes with a pure virtual function call
<azonenberg>
because it's trying to free a trigger too late in the destructor chain
<d1b2>
<mubes> yeah, I noticed. It gets very upset with my opengl header files atm too!
<azonenberg>
and then the Pico bridge still needs some work
<azonenberg>
But again, one me and a lot of code to write :)
<azonenberg>
What i really need at some point is at least one other person working on the library core and glscopeclient itself
<azonenberg>
Basically all of the community contributors right now are either maintaining drivers or writing protocol decodes
<azonenberg>
which, don't get me wrong, is useful work
<azonenberg>
but it's not the only thing that needs doing
<azonenberg>
What probably needs to happen at some point is for me to take several days and just focus on refactoring and cleanup of glscopeclient itself
<azonenberg>
to try and decouple various parts of the UI
<azonenberg>
the back end is much cleaner code than the front end right now
<_whitenotifier-5>
[scopehal-apps] azonenberg opened issue #314: Lots of tree view error spam - https://git.io/JOuVE
<_whitenotifier-5>
[scopehal-apps] azonenberg labeled issue #314: Lots of tree view error spam - https://git.io/JOuVE
<_whitenotifier-5>
[scopehal] RX14 opened issue #414: Support Siglent 1000x-e series - https://git.io/JOuVX
<Stephanie>
it looks like the same commands and software base for all of sds1000, sds2000x and sds2000x-e
<azonenberg>
I don't want to just copy their design though
<azonenberg>
I want to learn from and, ideally, improve on it
bvernoux has quit [Quit: Leaving]
<_whitenotifier-5>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JOuXJ
<_whitenotifier-5>
[scopehal-apps] azonenberg 56ec47b - ProtocolAnalyzerWindow: fixed bug causing last row to not be selected correctly. Fixes #314.
<_whitenotifier-5>
[scopehal-apps] azonenberg closed issue #314: Lots of tree view error spam - https://git.io/JOuVE
<azonenberg>
woop, annoying bug fixed
<azonenberg>
that one had been bothering me for a long time, i just had never spent the time to track it down
<_whitenotifier-5>
[scopehal-apps] azonenberg commented on issue #184: When loading a save file, the view sometimes has a weird negative offset putting the view off to the left of the data - https://git.io/JOu1G
<_whitenotifier-5>
[scopehal-apps] azonenberg closed issue #184: When loading a save file, the view sometimes has a weird negative offset putting the view off to the left of the data - https://git.io/JUggb
<azonenberg>
I think next on the agenda is going to be #169, adding markers
<azonenberg>
I'm still working on scopehal:#407 but need a break from it
<azonenberg>
I'm probably also going to work on horizontal cursors
<azonenberg>
Which is one of the longest standing tickets
<azonenberg>
and I've just never bothered to spend time on it
Tost has quit [Ping timeout: 260 seconds]
<d1b2>
<mubes> @Stephanie it sees there are two primary platforms, the 1000/2000x/2000x-e and the 2000x+/5000x/6000. The driver for the 1000 etc was basically a re-aiming of the LeCroy, the 2000x+/5000x/6000 is a new driver that really just needs a bit of hardening off now.
<Stephanie>
the newer 1000 stuff isnt lecroy related at all
<Stephanie>
jusging by what was implemented in that old file
<Stephanie>
it was a full XP based environment that the old driver was expecting
<d1b2>
<mubes> The stuff in the old file was all windows calls...these scopes aren't.
<Stephanie>
yep
<Stephanie>
i think there have been many different platforms over the years, 2 of which are current, neither of which are windows based
<Stephanie>
idk what that old file was supporting
<Stephanie>
some really old model i'd guess
<Stephanie>
on the high end
<d1b2>
<mubes> I don't think the old file was supporting much...I think it was more a starting point. The actual Siglent specific stuff was pretty small, then it broke off into lecroyisms. Ive only given the 1000 series documentation a cursory look but I suspect it will be easiest to implement it as a separate driver and then select between the two based on *IDN? Response.
<d1b2>
<mubes> Anyway...bedtime now. Night all.
<Stephanie>
indeed
<azonenberg>
Yeah it's going to have to be something similar to the rigol driver
<azonenberg>
picking commands to use for different instruments based on the IDN family
<Stephanie>
might even be worth splitting into different classes
<Stephanie>
i've been fucking around with SCPI and this scope loves to crash entirely when you do something wrong
<azonenberg>
That is a possibility too
<azonenberg>
so far we havent had any instruments that were so different that two classes made more sense