azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
juli966 has quit [Quit: Nettalk6 -]
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel_ has joined #scopehal
<_whitenotifier-f> [scopehal] azonenberg opened issue #350: TIEMeasurement: make threshold configurable -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #350: TIEMeasurement: make threshold configurable -
<_whitenotifier-f> [scopehal] azonenberg opened issue #351: Provide hint for filters with scalar output to skip the waveform display and go straight to stats -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #351: Provide hint for filters with scalar output to skip the waveform display and go straight to stats -
electronic_eel_ is now known as electronic_eel
<bvernoux> I'm debugging master of glscopeclient
<bvernoux> on Windows7
<bvernoux> I see a crash
<bvernoux> Starting program: C:\msys64\home\Ben\glscopeclient_build\glscopeclient.exe --debug RigolMSO5k:rigol:lan:
<bvernoux> [New Thread 9064.0x18dc]
<bvernoux> Detecting CPU features...
<bvernoux> Thread 1 received signal SIGSEGV, Segmentation fault.
<bvernoux> Connecting to SCPI oscilloscope at
<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="")
<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="")
<bvernoux> at C:/msys64/home/Ben/scopehal-apps/lib/scopehal/SCPISocketTransport.h:61
<bvernoux> #5 0x000000000169371a in SCPITransport::CreateTransport (transport="lan", args="")
<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> it seems setsockopt is not valid ;)
<bvernoux> hehe found the bug ;)
<miek> `DWORD timeout = (DWORD)(ceil((float)microSeconds / 1000.0f));` into `(const char*)timeout` errr
<bvernoux> (const char*)timeout => shall be (const char*)&timeout
<bvernoux> fix
<bvernoux> if(0 != setsockopt((ZSOCKET)m_socket, m_type, SO_RCVTIMEO, (const char*)&timeout, sizeof(DWORD)))
<bvernoux> it only affect windows build
<bvernoux> I'm testing the fix ;)
<bvernoux> maybe I could use glscopeclient on windows with my Rigol MSO5000 soon ;)
<bvernoux> ok it works now
<bvernoux> but nothing is displayed ;)
<bvernoux> ha nice it works
<bvernoux> it was just horizontal scale which was wrong
<bvernoux> too zoomed
<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]
<_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]
<_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]
<_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 -
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±5]
<_whitenotifier-f> [scopehal-apps] azonenberg 8cce9c8 - Fixed integer underflow causing GPU hang when we have <2 samples in a waveform
<_whitenotifier-f> [scopehal-apps] azonenberg c42cc18 - WaveformGroup: ellipsize channel names >20 characters in stats display
<_whitenotifier-f> [scopehal-apps] azonenberg ca807b2 - WaveformArea: display scalar channels as stats rather than waveforms by default
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [scopehal] azonenberg 96a1765 - TIEMeasurement: made threshold configurable. Fixes #350.
<_whitenotifier-f> [scopehal] azonenberg closed issue #350: TIEMeasurement: make threshold configurable -
<bvernoux> I have found an other bug7
<bvernoux> it seems to affect also linux
<bvernoux> if(0 != setsockopt((int)m_socket, IPPROTO_TCP, TCP_NODELAY, (char*)&flag, sizeof(flag)))
<bvernoux> in scopehal-apps\lib\xptools\Socket.cpp
<bvernoux> oups
<bvernoux> if(0 != setsockopt((ZSOCKET)m_socket, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)))
<bvernoux> is the correct code
<bvernoux> instead of
<bvernoux> if(0 != setsockopt((ZSOCKET)m_socket, m_type, SO_RCVTIMEO, &tv, sizeof(tv)))
<bvernoux> m_type is defined by default to SOCK_STREAM
<bvernoux> which is totally wrong
<bvernoux> it shall be set to SOL_SOCKET
<bvernoux> I do not know what is the effect on Linux but on Windows it is buggy as hell
<bvernoux> when replaced to SOL_SOCKET glscopeclient is clearly more stable
<azonenberg> Send a PR
<bvernoux> yes sent
<bvernoux> could you check on Linux
<bvernoux> but anyway i'm right it is definition of BSD Socket especially setsockopt
<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]
<_whitenotifier-f> [scopehal] azonenberg b5c0911 - Changed some eye measurement names
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4]
<_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]
<_whitenotifier-f> [scopehal] azonenberg 35b1edf - Updated xptools with more bugfixes
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_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]
Bird|otherbox has joined #scopehal
bvernoux has quit [Ping timeout: 240 seconds]