azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<_whitenotifier-3> [scopehal-apps] VIPQualityPost commented on issue #739: macOS build failing with ffts.h error - https://github.com/ngscopeclient/scopehal-apps/issues/739#issuecomment-2316537565
<_whitenotifier-3> [scopehal-apps] azonenberg commented on issue #739: macOS build failing with ffts.h error - https://github.com/ngscopeclient/scopehal-apps/issues/739#issuecomment-2316552796
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
Stary has quit [Quit: ZNC - http://znc.in]
Fridtjof has quit [Quit: ZNC - http://znc.in]
Stary has joined #scopehal
Fridtjof has joined #scopehal
<_whitenotifier-3> [scopehal] azonenberg pushed 3 commits to master [+3/-0/±8] https://github.com/ngscopeclient/scopehal/compare/4c91b0eadf74...2b15b1894940
<_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 pushed 1 commit to master [+0/-0/±3] https://github.com/ngscopeclient/scopehal-apps/compare/e5e6daa3dcb7...0f48d10acce3
<_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
sgstair_ has joined #scopehal
_sgstair has quit [Ping timeout: 276 seconds]
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±3] https://github.com/ngscopeclient/scopehal-apps/compare/0f48d10acce3...e082092ade4a
<_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> OK good luck !
<_whitenotifier-3> [scopehal-apps] membranophonist commented on issue #739: macOS build failing with ffts.h error - https://github.com/ngscopeclient/scopehal-apps/issues/739#issuecomment-2317891877
<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 !...
_sgstair has joined #scopehal
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+1/-1/±8] https://github.com/ngscopeclient/scopehal/compare/2b15b1894940...48ed319c0a99
<_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> <fjullien> GPU, AlderLake-S GT1 -> UHD Intel® 770 I guess
<d1b2> <azonenberg> in the bottom right corner under the time/div it should show memory depth and sample rate
<d1b2> <fjullien> I the other room, in the lab 🙂
<d1b2> <azonenberg> oh lol
<d1b2> <azonenberg> Yeah, that is a good use case for ngscopeclient, i do that all the time
<d1b2> <azonenberg> My dev scopes are a WaveRunner 8404M-MS and a SDA 816Zi-A
<d1b2> <azonenberg> (as well as a PicoScope 6824E, a Digilent analog discovery pro 3450, and a ThunderScope prototype)
<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> <azonenberg> #16 AcceleratorBuffer<float>::resize(unsigned long) (size=9223372036854775800
<d1b2> <azonenberg> ok yeah, that's the problem 😛
<d1b2> <fjullien> 🙂
<d1b2> <azonenberg> why, is another question
<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
<d1b2> <fjullien> This time it happend during connection
<d1b2> <azonenberg> Well it was still acquiring data maybe it saw the scope trigger was armed already
<d1b2> <azonenberg> anyway, same bug in either case
<d1b2> <azonenberg> have a look at those variables and we should be able to narrow it down
<d1b2> <fjullien> let me remind how we do that with gdb 🙂
<d1b2> <azonenberg> frame 18
<d1b2> <azonenberg> print num_samples
<d1b2> <azonenberg> etc
<d1b2> <fjullien> oh I was missing frame xx
<d1b2> <azonenberg> yep you gotta specify which stack frame you're inspecting
<d1b2> <fjullien> #18 LeCroyOscilloscope::ProcessAnalogWaveform (this=0x5555560ce880, data=<optimized out>, datalen=<optimized out>, wavedesc=..., num_sequences=<optimized out>, ttime=<optimized out>, basetime=<optimized out>, wavetime=<optimized out>) at /home/franck-rdp/scopehal-apps/lib/scopehal/LeCroyOscilloscope.cpp:2557
<d1b2> <fjullien> all optimized out
<d1b2> <fjullien> meeting in 5 minutes, I'll get back to this tomorrow
<d1b2> <fjullien> I put I breakpoint: Thread 46 "ngscopeclient" hit Breakpoint 1, LeCroyOscilloscope::ProcessAnalogWaveform (this=0x5555561151a0, data=0x555556115928 "1", datalen=18446744073709551600, wavedesc="WAVEDESC\000\000\000\000\000\000\000\000LECROY_2_3\000\000\000\000\000\000\001\000\001\000Z\001", '\000' <repeats 22 times>, "\204\204\036", '\000' <repeats 13 times>, "LECROYHDO9404-MS.w", '\000' <repeats 18 times>,
<d1b2> "BB\017\000BB\017\000@B\017\000\000\000\000\000AB\017\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\t\244\331\067)\\Ͼ\000\346\356F\000\346\360\306\b\000\001\000\377\346[.\346\367\223\021\344\066\372\276,C\034\353\342\066\372\276V\000\000\000"..., num_sequences=1, ttime=1724951386, basetime=0.14460503899999821, wavetime=0x0) at /home/franck-rdp/scopehal-apps/lib/scopehal/LeCroyOscilloscope.cpp:2509
<d1b2> 2509 { (gdb) print num_samples $1 = <optimized out> (gdb) print datalen $2 = 18446744073709551600 (gdb) print num_sequences $3 = 1 (gdb) print num_per_segment $4 = <optimized out> (gdb)
<_whitenotifier-3> [scopehal-docs] fredzo opened pull request #85: Updated Windows compilation documentation - https://github.com/ngscopeclient/scopehal-docs/pull/85
<d1b2> <azonenberg> ok i may have to add some prints toget everything
<d1b2> <azonenberg> but the datalen being garbage is certainly the problem
<_whitenotifier-3> [scopehal] azonenberg pushed 3 commits to master [+0/-0/±4] https://github.com/ngscopeclient/scopehal/compare/48ed319c0a99...e619d6d7a973
<_whitenotifier-3> [scopehal] azonenberg b0c5fa8 - SocketCANAnalyzer: fixed bug causing garbage to be read if bus was idle for a long time
<_whitenotifier-3> [scopehal] azonenberg e5f143a - Improved robustness of some CAN filters to errors
<_whitenotifier-3> [scopehal] azonenberg e619d6d - J1939PDUDecoder: fixed bug causing incorrect waveform timestamps