<Kenley>
I have glscopeclient running on a Linux box and it manages to crash my MSO5074.
<azonenberg>
Kenley: great, you can reproduce the crash now :p
<azonenberg>
now hopefully we can investigate
<Kenley>
Both glscopeclient and the scope crash.
<azonenberg>
glscopeclient going belly-up when the scope stops responding is not surprising
<azonenberg>
does it display a socket read failed or something like that on the console?
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #scopehal
<Kenley>
Socket read failed along with going unresponsive.
<Kenley>
If I can remember how to do this again...would a pcap be helpful?
<azonenberg>
Yes. Also open a bug ticket, i dont think there is one for this yet.
<azonenberg>
glscopeclient dying is not surprising in this case, we generally need to improve robustness to connection problems but that isnt a super high priority
<azonenberg>
fundamentally the bug is that the scope stops responding when we do stuff
<azonenberg>
This is most likely a bug in Rigol's firmware, but i hope to find a workaround for it on our end
<azonenberg>
if not, i want a minimal test case we can send to rigol support
<_whitenotifier-f>
[scopehal-apps] kench opened issue #249: Rigol MSO5074 crashes when we try to do stuff with glscopeclient - https://git.io/JTVqJ
<Kenley>
Can you comment with some instructions on how to get a packet capture locally?
<azonenberg>
run wireshark on the machine glscopeclient is on, select your ethernet interface
<azonenberg>
capture filter "host 192.168.1.1" with the IP of your scope
<azonenberg>
(capture filter, not display filter, this is important to avoid bloating the file with other data)
<azonenberg>
I'm not sure how much help the pcap will be, though. In particular unless we can catch glscopeclient sending invalid commands, it's going to be difficult to pin down the source of the bug
<Kenley>
It will tell us when it crashes.
<azonenberg>
True
<azonenberg>
the fun bit, which is gonna have to be done by you or somebody else with a mso5 handy
<azonenberg>
is going to be trying to generate a minimal test case
<azonenberg>
find the smallest set of commands that crashes the scope, which may be timing critical as well
<azonenberg>
somebody else, i think Degi, said the crashes were nondeterministic but the longer you ran the more likely they were
<azonenberg>
which leads me to expect a race condition, just not sure on which end
<azonenberg>
Actually, hold on a minute
<azonenberg>
Kenley: before you waste time with a full pcap
<azonenberg>
try rerunning glscopeclient with "--trace SCPISocketTransport" and pipe the output to a file
<azonenberg>
this will give us full command and response logging
<azonenberg>
Might shed some light on it and is easier to set up
Pretzel4Ever has joined #scopehal
Pretzel4Life has quit [Ping timeout: 246 seconds]
<Kenley>
No trace.
<Kenley>
Are you sure that's the right command?
<azonenberg>
Kenley: how did you connect to the scope, LXI or LAN?
<Kenley>
LAN
<azonenberg>
did you also specify --debug?
<azonenberg>
if not, that has to be on
<Kenley>
Nope.
<azonenberg>
Add that then and you should get a trace
Pretzel4Life has joined #scopehal
electronic_eel has quit [Ping timeout: 246 seconds]
Pretzel4Ever has quit [Ping timeout: 260 seconds]
electronic_eel has joined #scopehal
Kenley has left #scopehal [#scopehal]
_whitelogger has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #249: Rigol MSO5074 crashes when we try to do stuff with glscopeclient - https://git.io/JTVcH
<_whitenotifier-f>
[scopehal-apps] azonenberg edited a comment on issue #249: Rigol MSO5074 crashes when we try to do stuff with glscopeclient - https://git.io/JTVcH
<azonenberg>
Continuing to implement different trigger types
<azonenberg>
Tek has a lot more options for many trigger types than LeCroy does
<azonenberg>
for example, LeCroy's window trigger only triggers when the signal leaves a window
<azonenberg>
Tek can trigger when entering the window from either direction, exiting in either direction, exiting the window towards the top, or entering the window from the top
<azonenberg>
or exiting/entering from the bottom
<azonenberg>
it also has time limits, so you can trigger when you stay in the window for X time then exit to the top or bottom
<azonenberg>
This is far more sophisticated
<azonenberg>
The LeCroy window trigger only supports "trigger when we leave the window"
_whitelogger has joined #scopehal
<electronic_eel>
my impression from past comparisons was that Lecroy had the most sophisticated trigger options. seems like Tek has taken over with their new series
<azonenberg>
oh and it seems like you can cascade this with another trigger too
<azonenberg>
t his can be either the A or B condition and you can combine them with holdoff delays etc
<azonenberg>
lecroy's trigger architecture is flexible but this is a lot more so
<azonenberg>
i have no idea about older teks
<azonenberg>
right now mso5/6 is all i am supporting
<_whitenotifier-f>
[scopehal-apps] electroniceel commented on issue #249: Rigol MSO5074 crashes when we try to do stuff with glscopeclient - https://git.io/JTVVZ
<azonenberg>
also, it appears we have two different issues
<azonenberg>
one is glscopeclient hanging, the other is the scope locking up
<azonenberg>
unclear if they are the same root cause or not
<azonenberg>
for now i'm ticketing them separately
<electronic_eel>
yeah, makes sense to have them separately
<electronic_eel>
there should probably be some kind of timeout / watchdog thing that detects cases like this and allows you to abort and reconnect in glscopeclient, without losing past data
<azonenberg>
Yes, general robustness improvements are planned
<azonenberg>
but it's nontrivial to actually do this
<azonenberg>
the easiest option might be to have the entire scope object have a reset method
<azonenberg>
where it closes the socket, reconnects, and clears all state
<electronic_eel>
I know, getting the threads and locks all to behave correctly is not straightforward
<azonenberg>
this would be called by an exception handler or something if the driver got into a bad state
<azonenberg>
the other thing is, the tek mso6 scpi stack is stateful
<azonenberg>
if i disconnect right after sending a command
<azonenberg>
and reconnect
<azonenberg>
it may give me a reply to the old command
<electronic_eel>
that is a really stupid implementation from them
<azonenberg>
also if you send a bad command the stack locks up or restarts or something and ignores all commands for a while
<azonenberg>
you have to *IDN? in a loop over and over until it replies once
<azonenberg>
(this is my experimental workaround, not from a doc)
<azonenberg>
it is
<azonenberg>
i'm loving most things about the mso6 so far
<azonenberg>
except this
<azonenberg>
for example, if you have a logic probe on a flex channel
<azonenberg>
and you try to query volts/div
<azonenberg>
it will hang the stack
<electronic_eel>
could you always do a small IDN loop when connecting, till you get a sane answer, to clear previous state?
<azonenberg>
Thinking of doing that
<azonenberg>
but its nontrivial because the IDN check is done by the SCPIOscilloscope base class
<azonenberg>
Which stupidly assumes the scope isn't braindead :p
<electronic_eel>
I guess you have to adapt your assumptions to reality...
<azonenberg>
lol
<azonenberg>
yes
<azonenberg>
anyway, my focus for the next day or so is still more mso6 trigger types
<azonenberg>
edge, pulse width, and timeout are done
<azonenberg>
and runt
<azonenberg>
window can pull settings from the scope but i have to implement the push side
<azonenberg>
logic pattern trigger won't be supported for a while, i have to add that to lecroy and some other stuff too
<azonenberg>
tek also has a setup/hold trigger that is nice but i need to do more work to support
<azonenberg>
then rise/fall time is the other one i want to get done soon
<azonenberg>
and sequence/protocol triggers also require more object model work
LeoBodnar has quit [Ping timeout: 272 seconds]
LeoBodnar has joined #scopehal
<azonenberg>
LeoBodnar: Have you given any thought to making a version of your pulse generator for probe testing that includes a test point for signal and a nearby ground plane right on the board?
<azonenberg>
maybe with some refactoring, like switching to a right angle USB connector, to make it easier to use benchtop rather than plugged into the front of a scope
<LeoBodnar>
ooh, that's a good idea, respin is coming soon in a few mo
<LeoBodnar>
anything like a switch will kill the pulse, or at least degrade it to ~100ps
<LeoBodnar>
unless it's a £10k switch
<azonenberg>
yeah i want a short length of line and a terminator
<azonenberg>
that i can probe across
<azonenberg>
right now i terminate the bnc and probe across the bnc solder pad on the back
<azonenberg>
or use a bnc-sma adapter then a sma test fixture
<LeoBodnar>
cool idea, cheers
<LeoBodnar>
it would be easier to get SMA version and take SMA connector off. it's a compression mount connector
<electronic_eel>
azonenberg: the probe test fixture connected via bnc/sma adapter looks quite conveniant to use on the photos you posted
<electronic_eel>
you have to set it up though
<azonenberg>
and more cable/pcb l;ength to attenuate things
<azonenberg>
you lose around 0.5-0.7 dB at 6 ghz in that fixture by my estimates
<electronic_eel>
hmm, do 0.7 dB matter that much?
<azonenberg>
when you're trying to measure 3 db bw? absolutely
<electronic_eel>
couldn't you deembed it?
<azonenberg>
with better data yes
<azonenberg>
i'm working on figuring out how
<electronic_eel>
what is the problem? is it that the values vary over the length of the fixture and you can't just hook up the sma end to the vna?
<azonenberg>
no its that the test point isn't an sma so i cant probe it directly
<azonenberg>
i have ideas to extrapolate though
<azonenberg>
I have a near-identical fixture that is longer
<azonenberg>
so i can extract the parameters of the line
<azonenberg>
but i think this ties into a more general tool i want to build
<azonenberg>
i want to be able to take a set of s-parameters and calculate the time domain response of the channel
<azonenberg>
then window that response to an arbitrary region of time
<azonenberg>
and convert that back to a new set of s-parameters
<electronic_eel>
I think that will be useful, like the idea
<azonenberg>
so i can for example de-embed the connector launch
<azonenberg>
or, given a measurement of a 100mm channel, predict the response of a 50mm channel on the same geometry
<azonenberg>
which is exactly what i want to do here
<azonenberg>
it's not those exact lenghts
<azonenberg>
but given the measurement of a thru line with a sma at each end
<azonenberg>
i want to predict the s-parameters of a terminated line shorter than that
<electronic_eel>
i think to be sure of your calculations, you need a set of 3 or 4 lines with different lengths, but same launch geometry
<azonenberg>
I kinda have that
<azonenberg>
anyway, so the first half is easy and i might code up tonight just as a useful tool to have
<azonenberg>
namely, converting s-parameters to time domain pulse response
<azonenberg>
(or step response, as you prefer)
<azonenberg>
basically create a vector of 000000...11111 samples
<azonenberg>
FFT it
<azonenberg>
then apply the normal channel emulation i do already to it
<azonenberg>
then inverse FFT and i have time domain response
<azonenberg>
this is straightforward
<azonenberg>
Windowing that is also straightforward, it's just a vector of samples i can crop
<azonenberg>
what i don't quite know how to do is going back from windowed impulse response to s-parameters. Not sure if i can just FFT and be done with it
<electronic_eel>
sorry, i can't help with that. i always gave vna calculus implementation a wide berth...
<azonenberg>
anyway, being able to generate impulse/step response of a channel and view it will already be useful
<azonenberg>
Especially when looking at field solver sims
<azonenberg>
since sonnet only outputs frequency domain outputs and i find time domain is handy for a lot of stuff
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JTViO
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+2/-0/±2] https://git.io/JTVM3
<_whitenotifier-f>
[scopehal-apps] azonenberg 823c442 - Added "impulse" tool under examples directory to calculate step (and eventually impulse) response of S-parameters
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTVyD
<_whitenotifier-f>
[scopehal-apps] azonenberg 60ec75e - Impulse tool now displays thresholds
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTVSk
<_whitenotifier-f>
[scopehal] azonenberg fb6cb0f - TouchstoneParser: support "MHz" not just "MHZ" as frequency unit
<_whitenotifier-f>
[scopehal] azonenberg opened issue #317: TouchstoneParser: support dB as well as magnitude as Y axis unit - https://git.io/JTVSq
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTVSb
<_whitenotifier-f>
[scopehal] azonenberg e1d7de2 - TouchstoneParser: now understand dB as Y axis unit. Fixes #317.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #317: TouchstoneParser: support dB as well as magnitude as Y axis unit - https://git.io/JTVSq
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JTVSx
<_whitenotifier-f>
[scopehal-apps] azonenberg ce98a34 - Calculate group delay for mid-span to correctly handle AC coupled signals
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTV9L
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #250: Add unit testing to CI builds - https://git.io/JTV7g
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #250: Add unit testing to CI builds - https://git.io/JTV7g
<_whitenotifier-f>
[scopehal-apps] azonenberg assigned issue #250: Add unit testing to CI builds - https://git.io/JTV7g
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JTV7V
<_whitenotifier-f>
[scopehal-apps] azonenberg 5cb62fd - Initial CTest support. Only one test so far. See #241.
<_whitenotifier-f>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTVFA
<_whitenotifier-f>
[scopehal-docs] azonenberg cfb6e8e - Documented catch2 requirement for new unit tests
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-2/±1] https://git.io/JTVAE
<_whitenotifier-f>
[scopehal] azonenberg 1c63924 - Removed TestCase class as it's not needed in new test model
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+4/-2/±4] https://git.io/JTVxN
<_whitenotifier-f>
[scopehal-apps] azonenberg d1d6039 - Converted FrequencyMeasurement test to catch2 umbrella test for all filters. Fixes #241.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #241: Unit testing - https://git.io/JTE3K
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTVj0
<_whitenotifier-f>
[scopehal-apps] azonenberg adec10d - Added catch2 to Linux build dependencies. Disabled building tests on Windows for now.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTwvZ
<_whitenotifier-f>
[scopehal-apps] azonenberg bba1522 - Build job temporarily requests Ubuntu 20.04 as it's not going to be default for ubuntu-latest until November, but we need 20.04 to have catch2 in a distro package
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTwvQ
<_whitenotifier-f>
[scopehal-apps] azonenberg c9bc14d - Turns out we need to build catch2 from source even on 20.04, it's not packaged until 20.10.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTwvA
<_whitenotifier-f>
[scopehal-apps] azonenberg 988770c - Building from source won't save us if we still try to install the nonexistent package. Derp.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTwJL
<_whitenotifier-f>
[scopehal-apps] azonenberg 5fdd79f - CI build now runs unit tests on Linux. See #250.
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #251: Windows CI builds are failing during mingw setup - https://git.io/JTwU0
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #251: Windows CI builds are failing during mingw setup - https://git.io/JTwU0
<_whitenotifier-f>
[scopehal-apps] azonenberg assigned issue #251: Windows CI builds are failing during mingw setup - https://git.io/JTwU0
juli966 has joined #scopehal
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTwYd
<_whitenotifier-f>
[scopehal] azonenberg 13586bf - Filter: made a bunch of helper functions that didn't need member access static so they're easier to test in isolation
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+4/-0/±3] https://git.io/JTwOe
<_whitenotifier-f>
[scopehal-apps] azonenberg 6a64818 - Added test case for SampleOnRisingEdges()
bvernoux has joined #scopehal
<bvernoux>
hello
<bvernoux>
I'm trying to test my Rigol MSO5000 with glscopeclient
<bvernoux>
so far it is a fail
<bvernoux>
the scope is detecte but glscopeclient freeze
bvernoux1 has joined #scopehal
bvernoux is now known as Guest95201
bvernoux1 has quit [Read error: Connection reset by peer]
Guest95201 has quit [Ping timeout: 256 seconds]
bvernoux has joined #scopehal
<bvernoux>
Degi, what command line are you using to use glscopeclient with your Rigol MSO5000 ?
<bvernoux>
I'm using glscopeclient.exe RigolMSO5k:rigol:lan:192.168.0.10:5555
<bvernoux>
it detect the scope Serial Number but after that glscopeclient freeeze
<bvernoux>
I'm pretty sure it is a windows issue
<Degi>
Hm, I entered it in the GUI of glscopeclient
<Degi>
Not sure if RigolMSO5k is right
<Degi>
Ah thats the name
<Degi>
Is the 0 in 192.168.0.10 right? Otherwise you could enable the SCPI debug trace
<bvernoux>
yes it is name
<bvernoux>
yes it right
<bvernoux>
what is the hint to have SCPI debug trace ?
<Degi>
Hmh, I'd suggest adding --debug, I dont remember the trace command...
<bvernoux>
yes but I have nothing interesting with debug
<bvernoux>
just that OpenGL 4.2 is ok
<Degi>
"--trace SCPISocketTransport"
<bvernoux>
then glscopeclient windows is frozen
<bvernoux>
ha yes more things
<Degi>
I think it might be waiting for a response
<bvernoux>
it is waiting [SCPISocketTransport::SendCommand] Sending WAV:DATA?
<Degi>
So there is probably some kind of error there, I think otherwise it would error somewhere else, if the scope wasn't connected? At least it sends IDN? at first
<bvernoux>
haha it works now
<bvernoux>
I have clicked on Default
<bvernoux>
the init seems not very good depending on what was done on the scope before
<Degi>
default?
<Degi>
On the scope?
<Degi>
Good to know
<Degi>
Maybe file a bug report on the repo
<bvernoux>
In my case I never reproduce your crash of the scope
<bvernoux>
I'm using the latest FW 00.01.03.00.01
<bvernoux>
It is unusable anywa
<bvernoux>
like 1 waveform each 5s
<bvernoux>
I heavily suspect there is lot of issue because of Windows
<Degi>
Hm that is similar on linux, try reducing sample length to 1 kS or so
<Degi>
You have a signal to trigger on, right?
<Degi>
The slowness is from the Rigol
<bvernoux>
yes I hav understood that ;)
<bvernoux>
the support is very basic as I shall have set a signal with trigger on scope
<bvernoux>
after that I have a very slow display
<bvernoux>
I'm pretty sure we can improve that as it is really better displayed with Rigol Web Page
<bvernoux>
I need to add ssh as there is not telnet or ssh now by default
<bvernoux>
So you cannot have a shell on it I shall create a script with AES-CBC encryption to execute it from USB Key ...
<bvernoux>
the famous GEL file is mainly a tar with fw4linux.sh ciphered with AES-CBC with a fixed key ;)
<Degi>
Rigol webpage literally transfers screenshots as far as I know
<bvernoux>
yes
<Degi>
Do you have it too that after ~200 acquisitions it crashes?
<Degi>
The scope I mena
<bvernoux>
No I do not have that issue
<Degi>
Yes, SSH would be good
<bvernoux>
you shall definitely upgrade your scope to latest FW
<Degi>
Hm, is mine outdated? Mabye
<bvernoux>
Check FW
<bvernoux>
FW 00.01.03.00.01
<bvernoux>
It what I have updated
<Degi>
The GEL that gives all options? Does it work on the newest FW?
<bvernoux>
yes ;)
<bvernoux>
I'm full opt now
<Degi>
Oh neat, do you have a link
<bvernoux>
I have reconstructed things
<bvernoux>
let me share it
<bvernoux>
it works like a charm
<Degi>
So you can run .sh scripts on the scope somehow?
<bvernoux>
you just need to upgrade to official firmware first
<bvernoux>
then apply the full opt ;)
<Degi>
Hm yes, I shall do that
<bvernoux>
yes sh script can be run but they shall be ciphered