futarisIRCcloud has quit [Quit: Connection closed for inactivity]
juli969 has joined #scopehal
bvernoux has joined #scopehal
bvernoux has quit [Read error: Connection reset by peer]
m4ssi has joined #scopehal
Tost has joined #scopehal
bvernoux has joined #scopehal
<azonenberg>
mubes: merged the xptools patch
<azonenberg>
reviewing the scopehal one now
<azonenberg>
mubes: did you confirm that the SDS2000X+ actually has an AC 50 ohm mode?
<d1b2>
<mubes> Yep.
<azonenberg>
Very interesting
<_whitenotifier-5>
[scopehal] azonenberg commented on issue #67: Add API for querying supported input coupling modes - https://git.io/JOICd
<azonenberg>
mubes: any interest in working on #67 after i finish reviewing this PR?
<azonenberg>
you'd be adding a pure virtual to the Oscilloscope class as well as adding implementations to each driver class that report the set of coupling values that scope supports
<azonenberg>
i've got a bunch on my plate and it wouldn't be hard to do, just tedious googling up various supported models and figuring out the correct set of coupling values to return
<azonenberg>
I can handle the GUI side if the API is added
<d1b2>
<mubes> I can take a look. Desperately trying to get Orbuculum finished up but this project tickles me too...
<azonenberg>
SHOW_TRANSACTIONS is unnecessary as all of the scpi transports have built in logging, no?
<azonenberg>
you should be able to just run glscopeclient --debug --trace SCPISocketTransport and it will log all scpi traffic
<azonenberg>
also don't use raw printfs for logging
<azonenberg>
logtools allows things like redirection, streaming logs to files, adjustable verbosity, etc
<azonenberg>
throwing raw prints fin just confuses things
<azonenberg>
raw printfs in*
<azonenberg>
even if it's ifdef'd out by default, it's bad practice
<azonenberg>
also, as part of this PR can you also find the siglent model detection code in the lecroy driver and delete that?
<azonenberg>
given that it's now a full split, that bit of code is redundant
<azonenberg>
your comment on line 265 references five colors, and the switch on 267 does a mod 8
<azonenberg>
but you only have four color values there
<d1b2>
<mubes> Copied from old code...there might be a few bits and pieces like that.
<azonenberg>
And that's why we have code reviews :)
<azonenberg>
So the siglent scopes use the same XML disaster of a file format as the lecroys?
<azonenberg>
for digital waveforms
<azonenberg>
or have you not tested that yet
<azonenberg>
on line 1899, "CHENNEL%ld:SKEW" - is that intentionally misspelled in the actual API, or a typo?
<azonenberg>
If the scope does not support multiple ADC modes, just return an empty set on line 1957, no need for a warning
<azonenberg>
warning on a set call is fine as nobody should be calling set on a non-configurable adc
<azonenberg>
Most of the trigger types you don't handle aren't even present in the trigger object model, i need to add at least IIC and SPI soon as my lecroy has the options for those
<azonenberg>
the comment on 2303-2321 is referencing additional options in the lecroy uart trigger that probably aren't present in the siglent api
<azonenberg>
so you can delete that
<azonenberg>
on 2340, you say it only supports equality, did you update the UartTrigger class to only add those to the enum?
<azonenberg>
a lot of the trigger classes have checks that look at the type of scope they're being created for and hide config options if it's not supported
<azonenberg>
PushTrigger() on 2437 is doing a VBS command, i don't think siglent supports those?
<azonenberg>
it looks redundant anyway as you set the trigger type later on e.g. 2453, 2458, etc
<azonenberg>
oh wait no you're setting the type not the source
<azonenberg>
so the command on 2436-2441 that sets the trigger channel name needs to be updated
<azonenberg>
i see references to a glitch trigger on 2545 that it appears the siglent driver doesn't actually support, guessing that was another copy from lecroy that needs to be cleaned up?
<azonenberg>
PushCondition on 2676 is doing VBS, that's either dead code or has to be updated
<azonenberg>
same with PushPatternCondition on 2705
<azonenberg>
overall it looks like a good start but i want those issues fixed before i merge
<azonenberg>
Shouldn't be too much work, you seem to have all of the important stuff down
<d1b2>
<mubes> I haven't done anything with digital channels as I don't have a digital adaptor (or the option enabled) on this scope. Most of the triggers are copied from the programming manual before I knew what I was doing. As I said, its a pretty minimal port to solve my immediate itch, but we might as well get it good enough that it's useful to others.
<azonenberg>
Yeah if you dont have the digital option then just comment out or somethign that code so people don't try to use it
<azonenberg>
If I do end up getting a scope from siglent for testing i can probably arrange for it to be fully loaded which will let us test all of the trigger types on it
<d1b2>
<mubes> I think it just needs some comments on the front about where it came from and what it's current state is.
<d1b2>
<mubes> It's trivially easy to hack the options on these scopes but I'm not going to do that just to help Siglent get better support for their kit :-) my scope has everything enabled except SENT, MANCH and the Digital channels.
<azonenberg>
ah ok, so you are capable of adding config for e.g. can, i2s, 1553, etc?
<azonenberg>
that will be good to have then
<azonenberg>
Speaking of which, at some point I want to add a 1553 protocol decode
<d1b2>
<mubes> Yes, but what is the state of them in the client?
<azonenberg>
But i have yet to find any waveform data :p
<d1b2>
<mubes> Dont think this scope has 1553 support...
<azonenberg>
The trigger classes for those would have to be created
<azonenberg>
but those are separate from protocol decoding
<d1b2>
<mubes> (TBH SENT and MANCH would have been more useful to me!)
<azonenberg>
it's one class that basically just declares what the settings for the trigger are
Tost has quit [Ping timeout: 265 seconds]
<d1b2>
<mubes> Btw, do some of the protocol decodes only run on digital channels (specifically SWD)? Can I run them on a thresholded analog channel?
<azonenberg>
Most filters are strongly typed at the input
<azonenberg>
and most of the decodes expect a digital input
<azonenberg>
this can be either a native digital input, a threshold of an analog channel, or any other more convoluted filter pipeline that creates a digital signal
bvernoux1 has joined #scopehal
<d1b2>
<mubes> This lot doesn't seem to difficult to clean up. I'll ping you once it's done.
<d1b2>
<mubes> Wavedesc is exactly the same format as LeCroy, so I would suspect the digital channels are too.
<azonenberg>
Yeah, but i want to test
<azonenberg>
i honestly hope they're not
<azonenberg>
lecroy's digital format is a royal pain
bvernoux has quit [Ping timeout: 268 seconds]
<_whitenotifier-5>
[scopehal] azonenberg opened issue #406: SENT protocol decode - https://git.io/JOIRP
<d1b2>
<mubes> Well, there are 30-execution temporary licences available for options. If your contact can issue me one of those then I'm pretty sure we can get it working in 30 attempts....I won't be able to validate the data out, but at least we know we can decide zeros correctly.
<azonenberg>
30 executions is quite light, i'm used to seeing time limited (like a week or month) for trials
<d1b2>
<mubes> No, it's 30 sessions as far as I can tell... Turning it on to off. Tbh I haven't really looked too much.
<azonenberg>
oh 30 *sessions* should be totally doable
<d1b2>
<mubes> Yep.
<_whitenotifier-5>
[scopehal] azonenberg closed issue #108: See if we can unify DRAM protocol decodes to enable measurement/code commonality across DDRx generations when possible - https://git.io/JfCPQ
<_whitenotifier-5>
[scopehal] azonenberg commented on issue #108: See if we can unify DRAM protocol decodes to enable measurement/code commonality across DDRx generations when possible - https://git.io/JOI0q
<_whitenotifier-5>
[scopehal] azonenberg closed issue #105: DDR3 decode: allow CS# to not be specified (assume chip is always selected) - https://git.io/JfCib
<_whitenotifier-5>
[scopehal] azonenberg commented on issue #105: DDR3 decode: allow CS# to not be specified (assume chip is always selected) - https://git.io/JOI04
<d1b2>
<mubes> There is intriguing talk about sparse formats in the wavedesc too. They aren't mentioned anywhere alese in the manual. If there is a way of compressing waveforms it would really help. Delta+RLL or similar is easy enough in an FPGA and would really help with link utilisation.
<azonenberg>
Yeah
<azonenberg>
Although depending on the balance between network and software performance it may or may not be worth it
<azonenberg>
e.g. on all of my instrumentation, i will have 10/40GbE and compression will mean you can't do waveform processing on the GPU in parallel until a serialized decompression step runs
<azonenberg>
unless there's "keyframes" every few hundred/thousand samples
<azonenberg>
in which case each block can be independently compressed
bvernoux1 has quit [Quit: Leaving]
Tost has joined #scopehal
ericonr has quit [Quit: WeeChat 3.1]
ericonr has joined #scopehal
m4ssi has quit [Remote host closed the connection]
<_whitenotifier-5>
[scopehal] mubes synchronize pull request #402: Changes to support SDS2000+ scope - https://git.io/JYiAM
<d1b2>
<mubes> SHOW_TRANSACTIONS is unnecessary as all of the scpi transports have built in logging, no? Removed, Fixed as part of this PR can you also find the siglent model detection code in the lecroy driver and delete that? Fixed your comment on line 265 references five colors, and the switch on 267 does a mod 8 Fixed on line 1899, "CHENNEL%ld:SKEW" - is that intentionally misspelled in the actual API, or a typo? Typo, Fixed If the scope does not
<d1b2>
support multiple ADC modes, just return an empty set on line 1957, no need for a warning Done Most of the trigger types you don't handle aren't even present in the trigger object model, i need to add at least IIC and SPI soon as my lecroy has the options for those Tidied, but I need to do testing on these anyway! the comment on 2303-2321 is referencing additional options in the lecroy uart trigger that probably aren't present in the siglent api so you
<d1b2>
can delete that Done on 2340, you say it only supports equality, did you update the UartTrigger class to only add those to the enum? Mark/Space added...not sure I've understood this? a lot of the trigger classes have checks that look at the type of scope they're being created for and hide configoptions if it's not supported Can you point to an example of this? I need to do more on the triggers anyway. PushTrigger() on 2437 is doing a VBS command, i
<d1b2>
don't think siglent supports those? Fixed, but triggering is not tested. so the command on 2436-2441 that sets the trigger channel name needs to be updated Fixed i see references to a glitch trigger on 2545 that it appears the siglent driver doesn't actually support Removed PushCondition on 2676 is doing VBS, that's either dead code or has to be updated Fixed
<d1b2>
<mubes> There's more work needed on the triggers, I haven't done anything with those yet...just triggering from the scope, but I think what is there is working OK as a basis now.
<_whitenotifier-5>
[scopehal] mubes synchronize pull request #402: Changes to support SDS2000+ scope - https://git.io/JYiAM