<_whitenotifier-3>
[scopehal] azonenberg 156517c - Initial WIP towards having test waveforms use a more realistic channel model
<_whitenotifier-3>
[scopehal] azonenberg fc74aed - Demo scope now uses a much more realistic S-parameter channel model instead of a brick wall lowpass filter
<_whitenotifier-3>
[scopehal] azonenberg 2b15b18 - Merge branch 'master' of github.com:ngscopeclient/scopehal
<_whitenotifier-3>
[scopehal-apps] azonenberg 0f48d10 - Updated to latest scopehal
bvernoux has joined #scopehal
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
ALTracer has quit [Read error: Connection reset by peer]
<d1b2>
<fredzo_72653> Hi, anyone @here using / testing ngscopeclient with a Siglent SDS 2000X HD ?
<d1b2>
<fjullien> hi, I'm building ngscopeclient: [...]/scopehal-apps/src/ngscopeclient/MainWindow.cpp: In member function ‘void MainWindow::StatusBar(float)’: /home/franck-rdp/scopehal-apps/src/ngscopeclient/MainWindow.cpp:1601:28: error: format not a string literal and no format arguments [-Werror=format-security] 1601 | ImGui::Text(it.second.c_str()); | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
<d1b2>
<fjullien> My fault? Quick fix or issue to fill in github ?
<tnt>
fjullien: Try to remove -Werror from the options. Your gcc is too recent probably and has more warnings.
<tnt>
ImGui::Text("%s", it.second.c_str()); should also work.
<d1b2>
<fjullien> yes, I did not see the error came from a warning, thanks
<d1b2>
<fjullien> I tried it on my Lecroy: terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::substr: __pos (which is 15) > this->size() (which is 1) Aborted (core dumped)
<d1b2>
<fjullien> I'll give another try later, when I have time
<_whitenotifier-3>
[scopehal-apps] azonenberg 19e433d - Added more status bar help
<_whitenotifier-3>
[scopehal-apps] azonenberg e082092 - Fixed accidental use of Text() instead of TextUnformatted()
<d1b2>
<azonenberg> The correct fix is TextUnformatted() which does the same thing but without the printf overhead
<d1b2>
<azonenberg> Fix pushed
<d1b2>
<azonenberg> not sure why that didn't complain for me locally
<d1b2>
<azonenberg> I tested an early production demo unit of the 2000X HD when it first came out
<d1b2>
<azonenberg> it worked then, havent tried since
<d1b2>
<azonenberg> It's slow, as with all siglents. expect 1-2 updates per second even at shallow memory
<d1b2>
<azonenberg> which lecroy? older model?
<d1b2>
<azonenberg> If you can run it with --debug --trace VICPSocketTransport and send me the last few lines, as well as getting me a gdb stack trace, i can look into what's going on
<d1b2>
<azonenberg> it's clearly sending data the driver doesn't expect but that exception doesn't give me any hint as to where
<d1b2>
<azonenberg> I use the lecroy driver on a daily basis with multiple recent generation scopes so i'm very curious what's wrong 🙂
<d1b2>
<fredzo_72653> Hi @azonenberg , thx for the reply. OK pre-production model, hence the 1.1.7.0 firmware version mentioned in the quirk comment (line 2070 of SiglentSCPIOscilloscope.cpp) ! I could not find this version in the release-note history of Siglent. Well 1.2+ versions also report the size of frame in points rather then bytes, which is consistent with docuementation for E11 protocol ("The header is “#9000001000” which nine ASCII integers are
<d1b2>
used to give the number of the waveform data points (1000 pts). " see page 694 PrgrammingGuide_EN11F.pdf). To fix ngscopeclient support for up-to-date SDS 2000X HD I had to set m_requireSizeWorkaround to true. I'm willing to prepare a PR for that. Do you want to keep support for this pre-release firmware or can we assume that all 2000X HD report size in word ?
<d1b2>
<azonenberg> Keep the quirk, we don't know exactly when they fixed it
<d1b2>
<fredzo_72653> OK I'll do that
<d1b2>
<azonenberg> add a check for your firmware version, we can fine tune if we have people on older firmware that trigger it too
<d1b2>
<azonenberg> But yeah, that's siglent being broken
<d1b2>
<azonenberg> the SCPI standard says the digits are supposed to be the number of bytes
<d1b2>
<azonenberg> (your version or later, that is)
<d1b2>
<azonenberg> The joys of driver development lol
<d1b2>
<azonenberg> Doesnt matter if it's a scope or a sound card, sooner or later you'll be adding quirks modes to work around bugs
<d1b2>
<fredzo_72653> Yeap... and Siglent is borken in many ways regarding SCPI, I've learned it the hardway while working on Sigrok driver !
<d1b2>
<azonenberg> Lol well add this to your list then 🙂
<d1b2>
<azonenberg> I'm neck deep in the demo scope driver now working on ripping out the old legacy FFT library
<d1b2>
<fredzo_72653> Regarding the 1-2 updates per second, maybe we can optimize that a bit by allowing an 8bit option for data dump and by pruning some WAVE:PRE? requests while un run mode. I'll have a look.
<d1b2>
<azonenberg> The primary limiting factor is how long the scope takes to trigger and begin responding to queries
<d1b2>
<azonenberg> data download especially at shallower memories isn't a big contributor to overall time
<d1b2>
<azonenberg> At a high level, total acquisition time is a linear function T = a * memdepth + b
<d1b2>
<azonenberg> for siglent scopes, the B term is huge
<d1b2>
<azonenberg> Feel free to try to optimize, just warning you you'll probably find most of the slowdown is on their end
<d1b2>
<fredzo_72653> OK thx for the heads up ! I can confirm that everything is blinkng on the scope when un run mode, and when you stop acquisition, it stays unresponsive for quite some time before comming back to life !...
<_whitenotifier-3>
[scopehal] azonenberg 48ed319 - Moved RectangularWindow shader to scopehal. TestWaveformSource now uses AcceleratorBuffer's as working storage and RectangularWindow shader to copy input. FFT still done on CPU for now, but laid groundwork for GPU implementation
sgstair_ has quit [Ping timeout: 276 seconds]
bvernoux has quit [Quit: Leaving]
<d1b2>
<fjullien> Sure, I'll do that. HDO9404-MS
<d1b2>
<fjullien> @azonenberg is it supposed to generate a file or just a trace in the terminal ? Now I have another error: Installed options: Code Type Description Action * DFP2 Math DSP Filter Ignoring * HDTV Trigger HD analog TV Ignoring *
<d1b2>
JITKIT Miscellaneous Jitter/Timing Analysis Ignoring * JTA2 Miscellaneous Jitter/Timing Analysis Ignoring * SPECTRUM Math Spectrum analyzer Ignoring * XDEV SDK Software development kit FastWavePort waveform download available * XWEB
<d1b2>
UI Processing web Ignoring * -M Hardware Extra sample rate and memory Enabled terminate called after throwing an instance of 'vk::OutOfDeviceMemoryError' what(): Device::createBuffer: ErrorOutOfDeviceMemory Aborted (core dumped)
<d1b2>
<azonenberg> Trace just logs to stdout, you can pipe that to a file as you see fit
<d1b2>
<azonenberg> I used to have a HDO9204 and did some development on it, so it should work fine although i haven't tested the HD mode in a while
<d1b2>
<azonenberg> out of device memory is interesting, what GPU do you have and what is your scope memory depth set to?
<d1b2>
<azonenberg> and was this error instant or after several acquisitions?
<d1b2>
<azonenberg> (in general we need to spend some time working on improving handling of low-memory conditions, there are various things we can do rather than crashing if we run low)
<d1b2>
<fjullien> instant, as soon as I click on start acquisition (with trigger)
<d1b2>
<azonenberg> and how many points is your timebase set to?
<d1b2>
<fjullien> by default, let me see where I change this
<d1b2>
<azonenberg> Just look at what's set on the scope front panel when it crashes
<d1b2>
<azonenberg> 1M points should absolutely not be oom'ing your GPU, hmmm
<d1b2>
<azonenberg> that's only a 4 MB per channel memory allocation
<d1b2>
<azonenberg> Can you run under a debugger and let me know the full stack trace where it aborts so i can see which buffer it's trying to allocate? and maybe print the size of the buffer if possible?
<d1b2>
<azonenberg> Also, if you open ngscopeclient and connect to the scope but don't acquire a waveform, can you go to window | performance metrics
<d1b2>
<azonenberg> open up the "memory" section and send me a screenshot or report the budget and usage figures it reports
<d1b2>
<azonenberg> So you're on a laptop with 16GB of ram available to CPU + GPU shared, and using a bit over half
<d1b2>
<azonenberg> My guess is that the scope is sending a reply ngscopeclient doesn't understand and it's trying to make a huge memory allocation as a result of mis-parsing that
<d1b2>
<azonenberg> so the trace should help shed some light on what's going on
<d1b2>
<azonenberg> (but if it's something in the WAVEDESC that's binary data and doesn't get printed, we'd have to get down and dirty with a debugger to figure out)
<d1b2>
<fjullien> I can test a version with debug prints if you want
<d1b2>
<fjullien> later
<d1b2>
<azonenberg> your backtrace is cut off
<d1b2>
<azonenberg> at row 18 whats the line number in LeCroyOscilloscope.cpp that it was at?
<d1b2>
<azonenberg> 2257?
<d1b2>
<fjullien> let me get it again, I just quit gdb 🙂
<d1b2>
<azonenberg> no rush i have to run out to take my kid to a doc appt in a min
<d1b2>
<azonenberg> but if you can hop into LeCroyOscilloscope::ProcessAnalogWaveform and print out the values of num_samples, datalen, num_sequences, and num_per_segment
<d1b2>
<fjullien> I get back home in 30 minutes, end of office day. So it's now for me 🙂
<d1b2>
<azonenberg> that should help narrow down what's going on