<d1b2>
<johnsel> not sure this is causing an AC waveform to look like a DC voltage but that's what I'm having now
<d1b2>
<johnsel> I am trying an older ngscopeclient now to verify if it's ngscopeclient side or not
<d1b2>
<johnsel> but almost seems it has to be
<azonenberg>
@johnsel so i did not change any of the cpu side conversion code, or any drivers other than picoscope
<azonenberg>
But 15e616b does change a bunch of stuff around how we dispatch compute shaders
<azonenberg>
I suppose it's possible we have a bug there
<d1b2>
<johnsel> I reverted, but it seems to be affecting only 2/4 channels I have since found out
<azonenberg>
but is that commit involved in some way?
<d1b2>
<johnsel> there is likely a locale bug though so it interpreted the requested range wrong and
<azonenberg>
We should always be using "C" locale internally except for printing user-facing stuff
<d1b2>
<johnsel> it's likely in the SCPI
<azonenberg>
ah ok
<d1b2>
<johnsel> or .Net not sure where it is
<azonenberg>
Well i cant help with TS-specific issues until i get my hands on a beta unit
<d1b2>
<johnsel> something at least got off by a few order of magnitudes because the , and . usage is reversed in Dutch vs US
<d1b2>
<johnsel> so we have . as delimiter and , to indicate decimals
<azonenberg>
Yes. for anything serialization related, we should be using dot for decimal and no comma
<azonenberg>
for end user facing stuff, we should be using the user's locale
<azonenberg>
any failures to do that is a bug and should be treated as such
<d1b2>
<johnsel> I think it was more a matter of TS.Net not using the user locale to parse the SCPI
<azonenberg>
but anything over the wire or in the .scopesession uses '.' as decimal separator
<azonenberg>
that's my point, the user locale should not be used for scpi
<azonenberg>
if we *are* using user locale anywhere in scpi, that's a bug and needs to be fixed
<d1b2>
<johnsel> it may not be used, may be an artifact of the .Net parsing
<azonenberg>
If it's on their end, same deal
<azonenberg>
the protocol needs to be the same no matter what language the user is using
<azonenberg>
otherwise you run into all kinds of fun problems like not being able to VPN into a scope in another country
<d1b2>
<johnsel> Sure, just giving you the context for the bug I found
<azonenberg>
Yeah
<azonenberg>
And i'm making sure we're clear on the expected behavior :)
<azonenberg>
Any use of '.' in gui elements if using a euro-style locale, and any use of ',' in network or file serialization, is a bug
<d1b2>
<johnsel> Lol, thanks for making sure. Not necessary though
<azonenberg>
Anyway, keep me posted on what you find
<azonenberg>
i'm in the middle of some FPGA debug and wishing i had ngscopeclient able to talk to the vivado logic anyalyzer
<azonenberg>
that has been an open todo for a very long time
<azonenberg>
one day i need to just sit down and reverse the jtag format
<d1b2>
<johnsel> Well I just did, there seem to be 2 broken channels which is what I was facing. The Locale issue is being fixed in TS.Net by mark
<d1b2>
<johnsel> Yeah that and litescope support would be awesome
<d1b2>
<johnsel> I know litescope would be very much appreciated by everyone in the IC design community
<azonenberg>
Litescope has also been a longstanding todo
<azonenberg>
i dont use litex myself, but if it looks like T&M gear and quacks like T&M gear
<azonenberg>
i eventually want a driver for it :D
<d1b2>
<johnsel> I may write it as I get a little further with the LiteX side of TS and my project
<d1b2>
<johnsel> or at least something basic
<d1b2>
<johnsel> but to be clear, I went back to latest ngscopeclient and things functioned as expected on the ngscopeclient side
<azonenberg>
Ok
<azonenberg>
So no known regressions there?
<d1b2>
<johnsel> assuming your shaders don't magically change between channels
<d1b2>
<johnsel> I did run into a new (to me) crash while scaling the channel beyond reasonable and then trying to rescale automatically
<azonenberg>
i can't promise they don't, any bugs are possible, but they *should* not :)
<d1b2>
<johnsel> Not sure if that is just an exotic bug or something new but I'll keep an eye on it
<azonenberg>
and havent seen that one before. closest i've seen is a bug where mouse wheel to change vdiv fails because y range is zero and the mouse wheel uses multiplicative scaling
<azonenberg>
and anything*0 is zero
<d1b2>
<johnsel> did you try autoscaling at that point?
<azonenberg>
the workaround, which i havent implemented yet, is to say if you see below some epsilon when zooming scale to set scale to some reasonable minimum value
<d1b2>
<johnsel> I may have triggered that
<azonenberg>
yes, in fact autoscale is the easiest way to *recover* from that situation
<d1b2>
<johnsel> just add epsilon to the mult
<azonenberg>
(the other being open channel propertires and manually type a nonzero scale under the vertical settings)
* azonenberg
looks around for a trout large enough to slap vivado with
<azonenberg>
i got bit *again* by the bug where it randomly stops responding to all keyboard input, but mouse works just fine
<d1b2>
<johnsel> vivado is really something
<d1b2>
<johnsel> I love having 2x 300GB installs and then maybe also another 2x200GB older versions because backward compatibility is a pipe dream here
<azonenberg>
there's a reason i installed my vivado to ceph and not local storage :p
<d1b2>
<johnsel> I'm still too poor for Ceph
<d1b2>
<johnsel> I am getting there though again lol
<azonenberg>
Speaking of ceph any updates on your CI work? anything needed on my end?
<d1b2>
<johnsel> I doth not had the time yet. I need to set up the NUC with an install of XCP-ng etc
<d1b2>
<johnsel> I had seas of time while the GPUs laid on your desk/in a box/somwhere
<d1b2>
<johnsel> the moment you mounted it I suddenly get a lot of other work
<d1b2>
<johnsel> but I'll get to it in the next say week or 2
<d1b2>
<johnsel> should not be too hard to figure out what is going wrong with root on the base system
<d1b2>
<johnsel> nothing needed on your end though for that until I figure out what the problem is
<d1b2>
<johnsel> what I do kindly ask your help with is to help me understand what the API changes are to update this old driver to working again
<d1b2>
<johnsel> it uses an older pattern, perhaps you can link me to a commit where that got updated for another driver or just explain it to me
<d1b2>
<johnsel> we would like to use it as a reference to integrate LiteX TS gateware with TS.Net, so it just needs to what it did before. I think it's just some inheritance changes and a few functions that are slightly differently laid out now but I looked at it a while ago
<azonenberg>
what is the older pattern in particular?
<d1b2>
<johnsel> azonenberg: blegh gotta build it again to remember. I was hoping you'd see it when you say the code lol
<d1b2>
<johnsel> I'll do that at some point then
<azonenberg>
no the code is constantly being updated and we dont yet have what i'd consider a stable API (that's something to shoot for at v1.0)
<azonenberg>
what in particular broke that driver is not something i can predict lol
<azonenberg>
i know we did switch to virtual inheritance some time ago in roder to allow something to be a scope and a function generator and such
<azonenberg>
in order*
<azonenberg>
but that was years ago i thought
<d1b2>
<johnsel> I suspect it's that
<d1b2>
<johnsel> this code if 1.5y old
<azonenberg>
in that case a lot more things probably broke
<azonenberg>
like the refactoring of the sparse/uniform waveform data types earlier this year
<d1b2>
<johnsel> that also rings a bell
<d1b2>
<johnsel> I was going to take another driver and base my own driver off of that
<d1b2>
<johnsel> but that was just for my own use not necessarily TS
<d1b2>
<johnsel> set up XCP-ng btw
<azonenberg>
in general you should be able to look at any of the current drivers and use them as a baseline
<azonenberg>
the big thing that's changed is that sparse and uniform waveforms are different data types, and that we have our own allocator that we use which tries to reuse vulkan memory allocations rather than making new ones for each waveform
<d1b2>
<johnsel> yes I'll have to study it a little more. Was hoping it was a little less involved and that you could just point out the changes more easily
<d1b2>
<johnsel> I thought I was just overcomplicating things due to unfamiliarity
<azonenberg>
No, there have been sweeping changes to the object model over the last two years that are necessary for performance
<d1b2>
<johnsel> but I guess the changes are as involved as they seemed
<azonenberg>
they're not that bad if you keep things updated as we go, and any upstreamed driver is going to get updated as we refactor
<azonenberg>
but if it's out-of-tree and not being updated then yeah two years of refactoring to catch up on is gonna be a bit of work
<azonenberg>
this won't be a problem once we hit v1.0 with stable APIs
<azonenberg>
but the whole point of the 0.x series is to get these growing pains out of the way and stabilize on something that's actually *good*
<d1b2>
<johnsel> I understand and it is how it goes, it's a shame nobody upstreamed that driver at the time though
<d1b2>
<johnsel> We'll just have to reconsider if we want to update it even if it's a decent amount of work
<d1b2>
<johnsel> It does barely anything beyond feed samples through
<d1b2>
<johnsel> Might be better to just take one of our better drivers as a starting point and strip that back to bare minimum
<d1b2>
<johnsel> which would you recommend? pico?
<d1b2>
<johnsel> just scpi, not twinlan btw
<azonenberg>
pico uses twinlan but the only real difference is that ReadRawData() pulls from a different socket than the scpi path
<azonenberg>
the driver for the most part is written the same
<d1b2>
<johnsel> ooh I like it having a vulkan reference
<d1b2>
<johnsel> I'm going to use it then
<d1b2>
<johnsel> I don't see twinlan though
<d1b2>
<johnsel> or is that just GUI picked?
<azonenberg>
yeah you have to pick in the gui. the whole point of the scpitransport layer is you can mix and match transports
<azonenberg>
so you can have the same scope itnerfaced over gpib or rs232 or raw tcp or lxi or usbtmc and use one driver for it all
<d1b2>
<johnsel> yep sometimes I ask quicker than I think
<azonenberg>
Some drivers do actually care about the transport for obscure reasons. but it's something we try to avoid, and only use in drivers where the hardware literally doesnt support any other
<d1b2>
<johnsel> well I have replicated the issue locally on xcp-ng
<d1b2>
<johnsel> I may have to get creative in how to deal with this
<d1b2>
<johnsel> if I can't give it cloud-config data on the fly then the alternative is to use a template
<d1b2>
<johnsel> but my user can't make those templates due to the ACL not supporting that
<d1b2>
<johnsel> hopefully I can figure out why it doesn't take the cloud-config