<_whitenotifier-f>
[scopehal] azonenberg opened issue #351: Provide hint for filters with scalar output to skip the waveform display and go straight to stats - https://git.io/Jk7g4
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #351: Provide hint for filters with scalar output to skip the waveform display and go straight to stats - https://git.io/Jk7g4
<bvernoux>
Thread 1 received signal SIGSEGV, Segmentation fault.
<bvernoux>
Connecting to SCPI oscilloscope at 192.168.0.10:5555
<bvernoux>
0x000007fefc6036a9 in ?? () from C:\Windows\system32\mswsock.dll
<bvernoux>
It seems socket are not compatible with WIndows ;)
<bvernoux>
hmm where give more details
<bvernoux>
#0 0x000007fefc6036a9 in ?? () from C:\Windows\system32\mswsock.dll
<bvernoux>
#1 0x000007fefd4ed8d4 in setsockopt () from C:\Windows\system32\ws2_32.dll
<bvernoux>
#3 0x00000000016939bd in SCPISocketTransport::SCPISocketTransport (this=0x75a4dd0, args="192.168.0.10:5555")
<bvernoux>
#2 0x0000000001702220 in Socket::SetRxTimeout (this=0x75a4dd8, microSeconds=5000000) at C:\msys64\home\Ben\scopehal-apps\lib\xptools\Socket.cpp:586
<bvernoux>
at C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SCPISocketTransport.cpp:68
<bvernoux>
#4 0x0000000001721df7 in SCPISocketTransport::CreateInstance (args="192.168.0.10:5555")
<bvernoux>
at C:/msys64/home/Ben/scopehal-apps/lib/scopehal/SCPISocketTransport.h:61
<bvernoux>
#5 0x000000000169371a in SCPITransport::CreateTransport (transport="lan", args="192.168.0.10:5555")
<bvernoux>
at C:\msys64\home\Ben\scopehal-apps\lib\scopehal\SCPITransport.cpp:67
<bvernoux>
#6 0x000000000046acd7 in main (argc=3, argv=0x13cdc50) at C:\msys64\home\Ben\scopehal-apps\src\glscopeclient\main.cpp:292
<bvernoux>
Great with this trivial fix glscopeclient works on Windows with Rigol MSO5000 !!
<bvernoux>
ok after like 1 minutes glscopeclient is frozen and stop to retrieve data
<bvernoux>
very instable
<bvernoux>
I suspect some bugs in Windows code ...
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jkdva
<_whitenotifier-f>
[scopehal] azonenberg bff39d3 - Updated to latest xptools to fix crash in Windows socket handling
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JkdvV
<_whitenotifier-f>
[scopehal-apps] azonenberg 51b71e4 - Updated to latest scopehal
<azonenberg>
bvernoux: fix merged and pushed to master
<bvernoux>
great
<bvernoux>
I have lot of freeze when using the GUI at same time as sampling from scope
<bvernoux>
Do you have such type of issues on Linux with Lecroy scope ?
<azonenberg>
No. but they're a lot faster
<azonenberg>
What you are probably encountering is the lack of write queueing
<azonenberg>
When performing certaion operations, like changing the vertical scale on a channel, I make a method call which changes settings on the scope
<azonenberg>
but this requires blocking on a mutex to gain access to the socket so we don't interrupt a waveform download
<azonenberg>
And if you're busy pulling a waveform this can result in several hundred ms of delay
<azonenberg>
The proper fix is to have write-only operations, which don't need an immediate reply, queue up the commands
<azonenberg>
and execute when the scope is free
<bvernoux>
does it is planned to implement that ?
<azonenberg>
this only requires a mutex to get access to the FIFO, which won't have much contention
<bvernoux>
You can also use lock free FIFO
<azonenberg>
Yeah but i dont think that's necessary as this isnt used in an inner loop
<bvernoux>
One Consumer One producer 100% thread safe without need to use any mutex/lock
<azonenberg>
i just need to avoid a several hundred ms delay
<azonenberg>
scopehal:#179 is the ticket
<azonenberg>
i've just been too busy with other stuff to touch it
<bvernoux>
ok good as there is an issue on that
<miek>
what sort of gui interactions are you doing to trigger it? does it still happen when you're not modifying anything and just opening the right click menu?
<azonenberg>
yeah if that is triggering it, then there's some missing caching. although the context menu is gradually getting those operations removed from it which also helps
<azonenberg>
But if it happens when changing channel settings or doing anything that results in a Set* method call, then it's caused by the lack of write queueing
<bvernoux>
Yes I heavily suspect it is one of the root cause of the issue I have with my Rigol MSO5000 on WIndows
<bvernoux>
with maybe other issues related to the WIndows port
<bvernoux>
1kpts are so slow
<azonenberg>
Well, if it's that big an issue i'll bump it up in priority
<bvernoux>
1WFM/s max
<bvernoux>
with 1kpts it is a real crap
<bvernoux>
need to check what happen with wireshark
<azonenberg>
People are saying that MSO5 just has a bad architecture, there's rumors that the MCU and FPGA are connected by a slow spi bus
<azonenberg>
and thus any waveform download is capped at a few Mbps
<azonenberg>
I have not opened it up to verify this myself
<bvernoux>
It is a good candidate to check robustness of glscopeclient ;)
<bvernoux>
as everything is slow ;)
<azonenberg>
Lol yes
<azonenberg>
bvernoux: btw did you see my pcie and jitter analysis work?
<bvernoux>
It is strange you have not see such type of issues with remote scope on Tek ...
<azonenberg>
my focus for the holiday weekend is probably going to be improving jitter decomposition
<azonenberg>
the remote tek was ungodly slow :P
<bvernoux>
yes the pcie and jitter stuff seems very interesting
<azonenberg>
but it wasnt fully locking up, just took several seconds to respond
juli966 has joined #scopehal
<bvernoux>
here I see the slowness comes from PC side ;)
<bvernoux>
to ack things from the scope
<bvernoux>
something is broken with some delay on PC side in glscopeclient for Rigol MSO5000
<bvernoux>
with some delay of 0.7s
<bvernoux>
TRIG STAT is pretty slow from scope side too
<bvernoux>
0.5s
<bvernoux>
1kpts take 0.1s in fact
<azonenberg>
If you can find specific things we're slow on, file tickets and i can help you dig into it
<azonenberg>
although obviously lacking an mso5 myself, my debug abilities are limited
<bvernoux>
I think we can group some commands
<bvernoux>
to avoid tons of push ;)
<bvernoux>
I will check the code when I have time
<bvernoux>
Anyway today it is not usable because of other bugs
<azonenberg>
I seem to recall the rigol firmware crashes or hangs if you send too many commands back to back
<azonenberg>
could be wrong
<bvernoux>
which are crazy to track
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±9] https://git.io/JkdT4
<_whitenotifier-f>
[scopehal] azonenberg f915f7c - Added IsScalarOutput() method to Filter providing a hint that this waveform contains only a single sample. Fixed some regressions in eye measurements. Fixes #351.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #351: Provide hint for filters with scalar output to skip the waveform display and go straight to stats - https://git.io/Jk7g4
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±5] https://git.io/JkdTR
<_whitenotifier-f>
[scopehal-apps] azonenberg 8cce9c8 - Fixed integer underflow causing GPU hang when we have <2 samples in a waveform
<bvernoux>
Fix Socket::SetRxTimeout & Socket::SetTxTimeout setsockopt() level parameter shall be set to SOL_SOCKET for WIN32 & Linux instead of m_type which is set to SOCK_STREAM
<bvernoux>
why level was set to SOCK_STREAM ?
<bvernoux>
On windows it is totally wrong
<bvernoux>
I checked the 2 define
<bvernoux>
SOCK_STREAM = 1
<bvernoux>
SOL_SOCKET = 0xffff
<bvernoux>
I do not know on Linux
<bvernoux>
as you seems to do not have "visible" issue with this broken code
<bvernoux>
maybe on Linux by luck SOCK_STREAM & SOL_SOCKET define have same value ?
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JkdOz
<_whitenotifier-f>
[scopehal] azonenberg b5c0911 - Changed some eye measurement names
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JkdO2
<_whitenotifier-f>
[scopehal-apps] azonenberg 108f670 - WaveformArea: non-scalar measurement filters are now selectable display as graphs or stats
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JkdO6
<_whitenotifier-f>
[scopehal] azonenberg 35b1edf - Updated xptools with more bugfixes
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JkdOi
<_whitenotifier-f>
[scopehal-apps] azonenberg 7712ff0 - Updated to latest scopehal
<bvernoux>
ok nice ;)
<bvernoux>
potentially I will check how to implement the Rigol/Agilent Import for Waveform *.bin
<bvernoux>
in the MockOscilloscope
<bvernoux>
It could be a very nice feature
<bvernoux>
I'm not very interested in csv as the file are very big ...
<bvernoux>
anyway like that it is a good start / template to add other import
<bvernoux>
how do you change the Y scale ?
<bvernoux>
as it is wrong with Rigol MSO5K
<azonenberg>
Mouse wheel on the Y axis
<azonenberg>
That should call SetVoltageRange / GetVoltageRange() in the driver
<azonenberg>
so if you have problems, those methods are likely acting up
<azonenberg>
i'm surprised nobody else has mentioned y scale issues though?
<bvernoux>
yes it is buggy
<bvernoux>
like X scale in fact
<bvernoux>
at least it is a bug in Rigol MSO driver
<bvernoux>
to be checked
<bvernoux>
mouse wheel on Y scale do nothing ;)
<bvernoux>
on horizontal it is ok
<bvernoux>
ha ok i need to pause the scope ;)
<bvernoux>
just click on Single Trigger
<bvernoux>
to adjust Y scale
<bvernoux>
how to change the min/max per chan ?
<bvernoux>
it is also wrong ;)
<azonenberg>
you should not need to pause
<azonenberg>
you can drag the y axis with the left mouse button to adjust offset
<azonenberg>
The viewport should be perfectly scaled to match the adc data range at all times
<azonenberg>
so min adc code should be the lowest pixel of the viewport and max should be the highest
<bvernoux>
yes but I think something is wrong in RigolOscilloscope.cpp
<bvernoux>
as the scale is wrong
<bvernoux>
X & Y
<bvernoux>
I see the code is a mess
<bvernoux>
mixing OLD_DS with MSO5
<bvernoux>
DS_OLD
<azonenberg>
yeah unfortunately the two have different commands for a lot of stuff
<bvernoux>
there is even DS
<bvernoux>
without any explanation
balrog has quit [Ping timeout: 256 seconds]
<bvernoux>
I heavily suspect DS & DS_OLD are broken ;)
<bvernoux>
But I could not check that anyway
balrog has joined #scopehal
<azonenberg>
DS1000D/E is DS_OLD iirc
<bvernoux>
maybe the best is to do RigolMSO5_Oscilloscope
<bvernoux>
will be cleaner
<azonenberg>
and a lot of the commands are the same
<bvernoux>
as It is a mess to support different scope very different in features
<azonenberg>
Having type IDs makes sense, we do the same for tek
<bvernoux>
MSO5K have a lot more features
<azonenberg>
yeah but mso5 isnt the only rigol scope in the current model
<azonenberg>
mso 5, 6, etc are likely all pretty similar
<azonenberg>
having type IDs lets you easily do a switch with fallthrough when several models use the same command for something
<bvernoux>
yes but you cannot compare MSO5K vs DS1000E ;)
<bvernoux>
it is a joke
<bvernoux>
even if basic commands are the same
<bvernoux>
BW is totally different and Digital Channel also I think
<bvernoux>
I do not speak about advanced trigger too
<bvernoux>
as MSO5K have unique features
<bvernoux>
I say that because maintenability in unique file to manage all will be more and more a big mess
azonenberg_work has quit [Ping timeout: 256 seconds]
<bvernoux>
I confirm my fix with setsockopt have huge impact
<bvernoux>
now when i move things with mouse in worst case I have readtimeout before it was a crash ;)
<bvernoux>
also I can read more than 150waveform now before all was frozen after 100waveform ...
<bvernoux>
I'm at 280wfms ;)
<bvernoux>
oups crashed glscopeclient when moving offset of a channel from the scope
<bvernoux>
azonenberg, do you have tested with SOL_SOCKET with linux ?
<bvernoux>
maybe you will have good effect with the correct level ;)
<bvernoux>
anyway we see the effect mainly when there is slowness on the scope and rx/tx timeout appears
<bvernoux>
deleting channels works ;)
<bvernoux>
but it is not faster
<bvernoux>
it is the trigger which is very slow strange
<bvernoux>
Single Trig take >04s
<bvernoux>
0.4s
<azonenberg>
I suspect the delay is how long it takes to copy waveform from the fpga to the cpu
<azonenberg>
inside the scope
<azonenberg>
but i could be wrong
<bvernoux>
strange as it is the same for 1 or 4 chan
<bvernoux>
1.02WFM/s
<bvernoux>
so I would expect 1 chan to be 4x faster vs 4 chan ...
azonenberg_work has joined #scopehal
<azonenberg>
yeah with my lecroy scopes performance beyond a few hundred points is dominated by waveform download time
<azonenberg>
there's a small fixed cost to each trigger, then a linear cost per point
<bvernoux>
I'm pretty sure we can optimize something
<bvernoux>
need to check different way to retrieve those waveform data ...
<bvernoux>
and also experiment with triggers...
<bvernoux>
oups FFT on a threshold crash ;)
<bvernoux>
something strange is the latency to pause the trigger
<azonenberg>
that's almost certainly also write queueing
<azonenberg>
if you have multiple threads contending for a mutex there's no guarantee which one will win
<azonenberg>
So it's possible for the "poll scope" thread to win the mutex several times before the GUI thread gets it
<azonenberg>
That's the performance i get with my lecroy scope and some fairly heavy analysis going. performance is bottlenecked by glscopeclient in this demo, the scope can stream much faster if i am just viewing waveforms without all of the analysis
<bvernoux>
ha nice
<azonenberg>
25-30 FPS on 800K points for a single channel is quite typical
<bvernoux>
you sniff PCIE of RPI ?
<azonenberg>
Yes
<azonenberg>
The pcie decode by itself, without the eye, is quite a bit faster
<bvernoux>
the eye diagram is not very good
<bvernoux>
very strange
<azonenberg>
It's bouncing between 15 and 25 FPS with full pcie decoding and the eye hidden
<azonenberg>
This is the TX eye right off the VL805
<azonenberg>
It has full 1.2V p-p differential swing and 6 dB of de-emphasis
<azonenberg>
which is massive overkill for 20mm or so of pcb trace, but i'm also looking right at the ac coupling cap
<azonenberg>
i plan to add some filters that will undo pre/de emphasis in the future
<azonenberg>
the RX eye look at lot better because whatever emphasis the pi's soc does is canceled out by channel loss
<bvernoux>
interesting
<azonenberg>
but yeah the VL805 seems to be using too much drive. i don't know if it supports configurable drive strength or not
<bvernoux>
anyway good point is now glscopeclient is pratically usable with Rigol MSO5000 on Windows ;)
<bvernoux>
I need to test on native Linux to compare
<bvernoux>
as I'm pretty sure there is tons of bugs specific to Windows
<azonenberg>
very likely
<bvernoux>
I need to find a good debugger for GDB on windows ;)
<bvernoux>
I really hate gdb in command line
Bird|otherbox has quit [Read error: Connection reset by peer]