azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
<_whitenotifier-1> [scopehal-docs] umarcor opened pull request #28: update MSYS2 build/install guidelines -
<_whitenotifier-1> [scopehal-apps] umarcor forked the repository -
<_whitenotifier-1> [scopehal] umarcor forked the repository -
<_whitenotifier-1> [scopehal-apps] umarcor opened pull request #352: CI workflow updates -
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
Tost has joined #scopehal
<_whitenotifier-1> [scopehal-docs] azonenberg commented on pull request #28: update MSYS2 build/install guidelines -
<_whitenotifier-1> [scopehal-apps] azonenberg closed pull request #352: CI workflow updates -
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 12 commits to master [+0/-0/±12]
<_whitenotifier-1> [scopehal-apps] umarcor 3966b10 - ci: update events
<_whitenotifier-1> [scopehal-apps] umarcor b957ad2 - ci: style
<_whitenotifier-1> [scopehal-apps] umarcor 0aa526e - ci: remove redundant 'shell' fields
<_whitenotifier-1> [scopehal-apps] ... and 9 more commits.
<d1b2> <mubes> Is there a ticket open for only using the channels which are already enabled on the scope? That was the immediate pushback I got from my tame windows user and I think it's a 0.1 issue. If not I'll create one.
<azonenberg> So the question is of course what to do if no channels are enabled?
<d1b2> <mubes> That could be a special case where you drop back to what we do today I guess.
<azonenberg> But sure, that was always intended to be a temporary "for testing" thing
<d1b2> <mubes> I'll create an issue. I was amazed how fast, and hard, he hit on it.
<_whitenotifier-1> [scopehal-apps] mubes opened issue #353: On starting, set configuration to be the set of channels enabled on the scope -
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±3]
<_whitenotifier-1> [scopehal] azonenberg 63e85e2 - Removed DESTINATION argument from library installation
<_whitenotifier-1> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal-docs] azonenberg 831c980 - Install documentation
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 2 commits to master [+1/-0/±5]
<_whitenotifier-1> [scopehal-apps] azonenberg 9906bc9 - Finished initial installation support. Only tested on Linux. Fixes #142.
<_whitenotifier-1> [scopehal-apps] azonenberg 495b84f - ChannelPropertiesDialog: don't display "no probe" for MSO channels
<_whitenotifier-1> [scopehal-apps] azonenberg closed issue #142: Proper cmake install support -
<azonenberg> GyrosGeier: FYI "make install" should work now
<azonenberg> We still need a proper icon for the launcher but hey, at least it exists
<_whitenotifier-1> [scopehal-docs] umarcor commented on pull request #28: update MSYS2 build/install guidelines -
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg e2f9d6a - Updated comment for FlushConfigCache()
<_whitenotifier-1> [scopehal-docs] azonenberg commented on pull request #28: update MSYS2 build/install guidelines -
<_whitenotifier-1> [scopehal-docs] azonenberg closed pull request #28: update MSYS2 build/install guidelines -
<_whitenotifier-1> [scopehal-docs] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-1> [scopehal-docs] umarcor 3aca228 - update MSYS2 build/install guidelines
<_whitenotifier-1> [scopehal-docs] azonenberg b6da2a9 - Merge pull request #28 from umarcor/update-msys2 update MSYS2 build/install guidelines
<azonenberg> xzcvczx: Do you have any BSD patches left to merge?
<_whitenotifier-1> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±3]
<_whitenotifier-1> [scopehal-docs] azonenberg 5637106 - Lots of updates to documentation for new build process, driver support, and more
Stephanie is now known as Stephie
<xzcvczx> azonenberg: i do not have any left to merge, still figuring out the best way to do the running folder
<azonenberg> Ok. not sure if you saw but "make install" should now work at least on linux platforms, unsure what it will do on mingw
<azonenberg> on posix*
<xzcvczx> oooo i missed that, i will have to take a lot
<xzcvczx> look
<xzcvczx> should be able to do so in a few hours
sam210723 has joined #scopehal
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg 10149d6 - Added trigger delay support. Fixes #4.
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg closed issue #4: Support for moving trigger location within capture window -
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg 14ea14c - PicoOscilloscope: added trigger delay support
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg opened issue #12: Allow triggering on MSO channels -
<GyrosGeier> azonenberg, cool, thanks!
<GyrosGeier> "make install" was the largest blocker that I could see
<xzcvczx> azonenberg: the make install will remove the need for chdir etc eh?
<GyrosGeier> the only other thing I can see right now is the CL based tests that might be difficult to run on the autobuilders, but that is strictly a packaging issue
<GyrosGeier> and then it will be checking performance
<GyrosGeier> and waiting for stuff to pass NEW in Debian
<azonenberg> xzcvczx: chdir has been removed ages ago
<azonenberg> GyrosGeier: we do not currently have any tests that use opencl
<azonenberg> there's only two unit tests
<azonenberg> right now
<azonenberg> and neither uses CL
<xzcvczx> just a pity it can't sneak in for bullseye :P
<azonenberg> I'm hoping we will have something mature enough for general use - meaning probably v0.2 or later - by the freeze for the next debian release after bullseye
<azonenberg> (has the name been selected yet?)
<xzcvczx> yes
<xzcvczx> bookworm?
<xzcvczx> azonenberg: and i really think your ex-uni might have got ransomed/cryptolocked
<azonenberg> very likely
<azonenberg> last i heard they were trying to push crowdstrike clients on all student computers connecting to the network
<azonenberg> they're... understandably protesting
<xzcvczx> can't say the name rings a bell
<xzcvczx> ah sounds like a wonderful place for a supply line
<xzcvczx> attack
<xzcvczx> gah thats not the proper name for it but its 3:30am sue me
<d1b2> <mubes> Crowdstrike = Merc F1 team sponsors. Anything else they do I'm not so interested in.
<GenTooMan> like most software of it's kind it's actually like most "easy" fixes a form of ransom where. That's what McAfee protection was about.
<d1b2> <mubes> I understand they make State Actor level attack vector software that you deploy onto individual endpoint devices.
<azonenberg> Yep
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg opened issue #13: Add support for 6000E series signal generator -
<noopwafel> would be nice to get the 3000 one working also, it's a pretty simple ap
<noopwafel> i
<azonenberg> noopwafel: well the bigger blocker is actually the glscopeclient side
<azonenberg> we support several instruments with function generators, there's a FunctionGenerator class in the library already that i think at least the lecroy wavesurfer 3000 implements (I don't think i ever got around to tek mso6)
<azonenberg> but we have no UI to interface with the API
<GyrosGeier> azonenberg, during build I get a few
<GyrosGeier> ERROR: OpenCL error: clGetPlatformIDs (-1001)
<noopwafel> azonenberg: ACK :)
<azonenberg> GyrosGeier: are you using asan for those builds?
<azonenberg> There appears to be negative interactions between opencl and asan last time i checked, enabling both is problematic
<azonenberg> this should happen when running though, not during building
<GyrosGeier> the build is running in a chroot that doesn't have a GPU
<GyrosGeier> because that's how we verify that it's somewhat reproducible
<azonenberg> I haven't actually tested what happens if you compile with opencl but there's not a GPU on the system
<azonenberg> That could be what's going on
<GyrosGeier> ... -D CTEST_FILE=/build/glscopeclient-0.0.20210512+git9d0ebd7d/obj-x86_64-linux-gnu/tests/Primitives/Primitives_tests-b12d07c.cmake -P /usr/lib/cmake/Catch2/CatchAddTests.cmake
<GyrosGeier> that's the context
<GyrosGeier> those are run during build
<azonenberg> So you're running the unit tests. Interesting
<azonenberg> It *should* gracefully degrade if no GPU is present
<azonenberg> although printing a better error message would definitely help
<azonenberg> What's the build configuration? release or debug?
<GyrosGeier> should be release
<GyrosGeier> it doesn't fail there
<GyrosGeier> just complains
<GyrosGeier> rerunning build with logging, sec
<GyrosGeier> will take three minutes to run through
<GyrosGeier> done
<azonenberg> So i think that's actually an opencl spec violation :p
<GyrosGeier> it's near the end
<_whitenotifier-1> [scopehal-apps] mubes opened issue #354: Changing trigger channel does not update the trigger arrow in the right hand side -
<azonenberg> clGetPlatformIDs should return CL_SUCCESS or CL_INVALID_VALUE
<azonenberg> so 0 and -30 should be the only possible return values according to the spec
<azonenberg> -1001 isn't even a valid error code in the spec
<azonenberg> ... oh
<azonenberg> interesting so it's an extension
<azonenberg> Which is to say, no devices found
<azonenberg> Let me see if i can handle that a bit more gracefully
<GyrosGeier> yes, that's really a call to clIcdGetPlatformIDsKHR
<azonenberg> ok yeah let me update DetectGPUFeatures to fail a bit more gracefully in this case
Tost has quit [Ping timeout: 240 seconds]
<GyrosGeier> I hope that doesn't bake some local features into the resulting executable
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg 6ff26cf - DetectGPUFeatures: gracefully catch CL_PLATFORM_NOT_FOUND_KHR error
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier-1> [scopehal-apps] azonenberg 673d2ae - Stop trigger before saving waveforms. Fixes #351
<_whitenotifier-1> [scopehal-apps] azonenberg aba0f06 - Updated submodules
<_whitenotifier-1> [scopehal-apps] azonenberg closed issue #351: Saving a session while cionnected to a PicoScope 6000 series scope, and trigger in run state, crashes -
<azonenberg> GyrosGeier: "make test" just runs unit tests
<azonenberg> it doesn't change any of the binaries
<GyrosGeier> yes, but that is before "make test"
<GyrosGeier> if you look at the log, the "make ... test" call is three lines below that
<azonenberg> Maybe tests are incorrectly being run as part of a "make" command
<azonenberg> i.e. tests might be run by "all"
<GyrosGeier> mh
<GyrosGeier> that might be a problem for cross compiling
<GyrosGeier> not that it matters, cmake alone is a problem for cross compiling
<azonenberg> Yeah well like i said right now x86-64 linux and windows via mingw are the only supported platforms
<azonenberg> if it happens to compile and run on anything else, great
<azonenberg> but it's never been tested and probably won't work
<azonenberg> and last time i checked we had enough x86-isms from AVX optimizations that it likely wont even compile
<GenTooMan> hmm here I thought cmake was the penultimate tool for make-ing things
<_whitenotifier-1> [scopehal-apps] azonenberg labeled issue #354: Changing trigger channel does not update the trigger arrow in the right hand side -
<_whitenotifier-1> [scopehal-apps] azonenberg labeled issue #354: Changing trigger channel does not update the trigger arrow in the right hand side -
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal-apps] azonenberg 2aa8d49 - Redraw waveform areas when changing trigger configuration. Fixes #354.
<_whitenotifier-1> [scopehal-apps] azonenberg closed issue #354: Changing trigger channel does not update the trigger arrow in the right hand side -
<GyrosGeier> so far, the compile issue is the UART baudrate setting through struct termios2
<GyrosGeier> that doesn't exist on ppc64 for some reason
<GyrosGeier> but that's fairly early
<GyrosGeier> the vector unit in the PPC should be good
<GyrosGeier> (and IEEE compliant in hardware :> )
<azonenberg> Yeah but we use avx intrinsics rather than autovectorization for a lot of stuff, i even make use of stuff like avx512 FMA in the FIR filter if available
<azonenberg> I dynamically detect cpu features and only actually call those versions if the CPU has those features
<azonenberg> But at compile time, it assumes the compiler knows how to generate code for avx instructions
<GyrosGeier> hm
<azonenberg> There's no #ifdef'ing around the optimized implementations
<azonenberg> That needs to happen for portability, there's a pending ticket
<azonenberg> But for v0.1 we are only targeting amd64
<GyrosGeier> mh
<azonenberg> ARM64 is the next target as it's the second most widely used platform people are likely to try using it on
<GyrosGeier> I'd leave the other architectures enabled so the porters can see there are problems :)
<azonenberg> Yeah feel free
<GyrosGeier> PPC64 is nice because many cores :)
<azonenberg> but i'm telling you now it won't compile :)
<azonenberg> it probably wouldn't be that hard to fix
<GyrosGeier> my ppc64 box has two sockets, 8 cores and 4 threads per core :)
<azonenberg> Does ffts build and run on ppc64?
<azonenberg> it's JIT based so i'm curious what ISAs they support, i havent actually looked
<azonenberg> I know that at some point i will probably want to fork it and add AVX support to the x86-64 back end
<azonenberg> because right now i don't think they go past SSE
<xzcvczx> well since its from waikato i doubt they had anything with avx until like 2019
<azonenberg> Lol
<monochroma> GyrosGeier: POWER7 ?
<ericonr> xzcvczx: I trust you will package scopehal for void
<xzcvczx> errrr fun fact there :)
<xzcvczx> while void has been great in the interim i think i will go to freebsd or debian next
<ericonr> damn it
<GyrosGeier> monochroma, POWER9
<GyrosGeier> azonenberg, ffts builds
<GyrosGeier> haven't run yet
<monochroma> GyrosGeier: ahh, talos II ?
<xzcvczx> ericonr: it probably won't be too hard to package
<GyrosGeier> and their AltiVec specific code is currently disabled so it uses the autovectorizer
<GyrosGeier> monochroma, yes
<GyrosGeier> fixing that shouldn't be too hard
<GyrosGeier> I'd be interested how much current those CPUs pull when the vector unit is active
<GyrosGeier> normal compiling is at 200W per socket
<ericonr> xzcvczx: I don't want to maintain something I'm not using, tho :p
<xzcvczx> fair enough, you should use it, its a great tool
bvernoux has joined #scopehal
<xzcvczx> tool/library/bridges/etc
<_whitenotifier-1> [scopehal] bvernoux opened pull request #481: Add support of PicoScope3000 MSO 16chan option when available -
<bvernoux> azonenberg, I'm waiting your go when you will have finalized working MSO chan for Pico6000
<xzcvczx> option when available?
<bvernoux> yes when detected if you prefer
<xzcvczx> ah duh, thank you
<bvernoux> it is detected with the serial number see the code it is very basic
<xzcvczx> haha nice
Tost has joined #scopehal
<azonenberg> bvernoux: It works now but cannot be used for triggering yet
<azonenberg> everything else works
<bvernoux> ha ok maybe let's wait the trigger stuff
<Degi> I think I'll continue on the MSO5000 driver tomorrow or today night
<bvernoux> Degi, ha great
<bvernoux> Degi, I have sent the Email today to Rigol Support Team to have news about Rigol MSO5k new firmware which was planned for middle of may
<bvernoux> the famous firmware which shall speedup and fix the ultra slow SCPI command/data ...
<Degi> That would be nice
<bvernoux> I suspect they will probably integrate other fix at same time but I does not have any details about that
<Degi> Tbh dev work is a bit hindered by the scope occasionally bugging out and that makes it harder to reproduce bugs on scopehal side
<bvernoux> azonenberg, you should have received the Email as you are in Cc
<bvernoux> Degi, In fact when the scope freeze is because returned value are not checked correctly
<bvernoux> the main case is when it returns 0x0A in data byte 0
<bvernoux> without anything when you are waiting full stream of data
<bvernoux> it means the data is cancelled (synchro problem or something internally)
<bvernoux> when you manage that case there is NEVER any freeze
<Degi> Oh, then we can somehow cancel the acquisition in scopehal or repeat it maybe
<bvernoux> Degi, you can try with if you can freeze it I'm interested ;)
<bvernoux> I have let it runs during hours and hours
<bvernoux> Degi, yes check my code you will see how it is managed unfortunately to do that in scopehal we will need direct socket access which is not the case today
<bvernoux> Degi, I was planning to integrate that in scopehal but as Rigol is doing some fixes maybe that will be solved
<Degi> azonenberg, can we postpone it until rigol pushes new FW?
<bvernoux> but for that it is required to use read_nb = recv(sockfd, (char *)(&buf[nb_total_read]), expected_nb_data, 0);
<Degi> Hm, though I'll take a look again at horizontal and vertical scaling later soonish, I think the vertical scaling misses changing the internal value when scrolled
<bvernoux> which has the advantage to do not wait timeout if 1 byte is received
<bvernoux> so it is ultra fast to manage the case when data receive just 1 bytes which is always 0x0A
<Degi> Hmm good to know
<bvernoux> in that case I just retry doing the full process read_chan_data()
<bvernoux> sometimes that even fail 3 or 4 times in a row ;)
<bvernoux> the murphy law maybe ;)
<bvernoux> with 10 retries ;)
<bvernoux> as I have never reached 10 retries on the same channel
sam210723 has quit [Read error: Connection reset by peer]
<bvernoux> of course I have validated it with max diffrent size up to 100M on both linux & windows with success
sam210723 has joined #scopehal
<bvernoux> even extreme cases like 1chan 8GSPS 100Mpts ;)
<bvernoux> 200Mpts is useless as clearly too slow ;)
<bvernoux> with SCPI
<Degi> Hm, maybe we can check if length of ReadReply in L674 of RigolOscilloscope.cpp is only 1 or if it only contains 0x0A
<Degi> Oh wow, the german wikipedia site on field electron emission is a lot shorter than the english one but the one equation that is there is much more useful than anything on the english version...
<bvernoux> yes we can but the code will timeout
<bvernoux> and it will be slow
<bvernoux> if you do it in 2step like reading 1 bytes then remaining bytes is not safe too
<bvernoux> as the 1st byte can be a legitimate 0x0A ;)
<Degi> oh
<bvernoux> and you will have data not retrieved on remaining bytes waiting and the scope will deadlock ;)
<bvernoux> as it clearly do not like when you do not read all data
<bvernoux> with my hint it always works
<Degi> Hm, your code reads all data it gets and when it only reads one byte it checks for 0x0A and retries if so
<bvernoux> the read_nb = recv(sockfd, (char *)(&buf[nb_total_read]), expected_nb_data, 0);
<bvernoux> do the trick
<bvernoux> as it returns what is available in a TCP/IP packet
<bvernoux> and so if a packet returns just 1 bytes it means it will not return other byte in that special case
<bvernoux> as the packets data are always returned with full frame > 100bytes at least
<bvernoux> Anyway the aim is Rigol will fix that if they release a fix
<bvernoux> They have reproduced all stuff I have mentionned
<bvernoux> slow SCPI and sometimes this bug with data missing with 1st data byte=0x0A
<bvernoux> which is just end of line as it is like they have missed to acquire data and so they send 0 data + end of line ;)
<bvernoux> Degi, I'm planning to change the fan on my Rigol MSO5K as it is very annoying ...
<bvernoux> Something like a Noctua Fan will be a nice replacement ;)
<Degi> Hm yes, apparently thats supposed to be the quieter version too
<Degi> (Like I read somewhere that it was even louder before)
bvernoux1 has joined #scopehal
bvernoux is now known as Guest69216
bvernoux1 has quit [Remote host closed the connection]
bvernoux has joined #scopehal
Guest69216 has quit [Ping timeout: 265 seconds]
maartenBE has quit [Ping timeout: 245 seconds]
maartenBE has joined #scopehal
juli9611 has joined #scopehal
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg opened issue #14: Support for bandwidth limiter -
LeoBodnar has quit [Ping timeout: 258 seconds]
LeoBodnar has joined #scopehal
bvernoux has quit [Quit: Leaving]
Tost has quit [Ping timeout: 240 seconds]
juli9611 has quit [Quit: Nettalk6 -]
<_whitenotifier-1> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±11]
<_whitenotifier-1> [scopehal] azonenberg 49e6738 - Refactoring: moved most of Filter::SerializeConfiguration() into FlowGraphNode class. See #101.
<_whitenotifier-1> [scopehal] azonenberg e47f4e3 - Refactoring: cleaned up SerializeConfiguration() arguments a bit. See #101.
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-1> [scopehal-apps] azonenberg 1ddb4fa - Updated scopehal. Made some fixes to overlay serialization to handle the unified FlowGraphNode serialization
<azonenberg> Trigger configuration is now included in scopesession files
<azonenberg> This is pretty useless because the *loading* code ignores it
<azonenberg> but the data is there :p
<azonenberg> next step will be writing the reader
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±5]
<_whitenotifier-1> [scopehal] azonenberg aecc8c1 - Moved LoadParameters / LoadInputs to FLowGraphNode. Triggers now can load config from scopesession files. Fixes #101.
<_whitenotifier-1> [scopehal] azonenberg closed issue #101: Add trigger configuration to save files -
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal-apps] azonenberg 6b1e125 - Updated submodules