<azonenberg>
pepijndevos: you should see significant performance increases
<azonenberg>
since it won't be polling the scope for attenuation every frame
<azonenberg>
let me update scopehal-apps with the new version of scopehal
<_whitenotifier-b>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JJCjx
<_whitenotifier-b>
[scopehal-apps] azonenberg 5e9203b - Updated scopehal version
<azonenberg>
And done. (Make sure when you pull you get submodules too)
<azonenberg>
So i think i'm gonna go back to PCB work on MAXWELL tonight
<azonenberg>
Have to finish the power plane layout
deltab has quit [Ping timeout: 264 seconds]
deltab has joined #scopehal
<pepijndevos>
okay lemme try
<pepijndevos>
I hate submodules... I always forget how to update them
<azonenberg>
pepijndevos: just set "git config --global submodule.recurse true"
<azonenberg>
and a pull will automatically grab everything\
<azonenberg>
i have no idea why this is not the default
<pepijndevos>
hey it's printing warnings about time
<azonenberg>
?
<pepijndevos>
Warning: Time 4.225157
<azonenberg>
no idea what that is, never seen it before. Maybe degi left some debug logging code in?
<azonenberg>
The important question is, does it still work? and is it faster?
<pepijndevos>
It also plain refuses to start. It worked the first time, but then I still had it set to 40M sample depth
<pepijndevos>
so I set it to 10K and now it's just not responding
<pepijndevos>
It appears to have sent at least on trigger command and the just hangs
<azonenberg>
Clearly still some bugs :p
<azonenberg>
I really need to just buy/borrow some rigol gear for development
<azonenberg>
And set up some kind of CI cluster or something
<pepijndevos>
... as I run it in gdb it acually launches
<azonenberg>
i really would love CI testing but the problem is it requires hardware
<azonenberg>
That sounds like a race condition around some mutexing
<azonenberg>
At least thats what it was every time i had it in the past
<azonenberg>
Try running outside gdb, waiting for it to hang, then attach gdb and look at traces
<azonenberg>
(run gdb like normal but don't do "run", launch the program as normal in a separate shell, then "attach 12345" in gdb where 12345 is the glscopeclient PID)
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JJWUN
<_whitenotifier-b>
[starshipraider] azonenberg ee30268 - Finished power plane layout on in3. Still have to finish in4 and do some via tweaks etc.
<pepijndevos>
I'll post bt in "rigol is f'd" issue
<azonenberg>
The big problem is that a proper CI cluster with even one model from each *family* we want to support
<azonenberg>
would be well over $100K of hardware
<azonenberg>
that's sitting around doing nothing but running nightly builds
<_whitenotifier-b>
[scopehal-apps] pepijndevos commented on issue #146: glscopeclient hangs on Rigol MSO5000 - https://git.io/JJWTI
<azonenberg>
Hmmmm
<azonenberg>
This doesn't make a ton of sense
<azonenberg>
there's no deadlocking
<azonenberg>
the trace you posted appears to be a legitimate block waiting on read data
<azonenberg>
the question is why is that ReadRawData() not returning?
<azonenberg>
Can you post your exact scope model and firmware rev in the thread?
<azonenberg>
and maybe try and get wireshark captures of the hang as it happens?
<azonenberg>
i'm interested in exact numbers of bytes sent in response to the query commands
<azonenberg>
the +1 on RigolOscilloscope.cpp:682 smells like it might be part of the bug
<azonenberg>
i think it's hanging waiting for an extra byte that isnt coming
<azonenberg>
The question is why it's not doing this for degi
<miek>
i notice that the first time it runs through OK, TRIG:STAT = TD and on the failing one it's STOP. i see there's some commentary about that in the driver, but maybe the logic there is wrong? or at least wrong for mso5k? (that trigger logic comes from the original 1054z stuff)
<azonenberg>
hmm
<azonenberg>
i wonder if it's trying to read before the scope triggers
<azonenberg>
and not correctly handling that
<miek>
also, i guess the original 1054z dev you did would've had quite a bit of latency, so might not have hit that
<pepijndevos>
I'm currently fascinated why it doesn't timeout
<miek>
i had that problem with the agilent stuff: all the initial dev was done remotely while i was travelling, then i came home and everything broke when the latency went away :p
<pepijndevos>
I wish I had a working network in my house so I could work form a comfy desk with my scope in the lab
<azonenberg>
miek: yea
<azonenberg>
i did initial dev on whitequark's rigol in moscow
<azonenberg>
from seattle
<azonenberg>
it was suuuuper laggy
<azonenberg>
by that point i had already sold my ds1102d with a busted power supply to somebody who thought she could fix it
<pepijndevos>
the recv call inside recvLooped is not timing out at all
<pepijndevos>
how do I get a debug build with line info? Probably osme simple option to make or cmake
<azonenberg>
cmake .. -DCMAKE_BUILD_TYPE=DEBUG
<azonenberg>
should configure the build for debug
<azonenberg>
that said, even the release build should, iirc, be configured with symbols
<azonenberg>
it just is optimized
<azonenberg>
DEBUG is -O0
<pepijndevos>
doh... SetRxTimeout is not working and not checked for errors
<pepijndevos>
It looks like it's just doing a normal TD, setting all the parameters and then just... not getting any data.
<pepijndevos>
I sent Rigol a message, but I don;t have high hopes
<azonenberg>
pepijndevos: we may just have to rewrite the driver to be tolerant of the device occasionally not working at all :p[
<azonenberg>
:p
<azonenberg>
Error_404: had some issues along those lines with his siglent iirc
<Degi>
Oops sorry about the time warning, that's how many seconds it takes to do something related to getting samples.
<Degi>
What is your scope? MSO5 or DS?
<Degi>
Also um I wont recommend 40 M Samples. I think for the DS its by default 250 k hardcoded and for the MSO it reads it from the scope. I wont recommend anything above 100 k tbh, maybe 1 M is fine
<Degi>
The speedup is limited, I think 250 k took like 80 ms per trace and 1 k took 60 ms
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]