<_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 - https://git.io/JsRmx
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JsRO3
<_whitenotifier-1>
[scopehal-pico-bridge] azonenberg closed issue #4: Support for moving trigger location within capture window - https://git.io/J3ReU
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JsRSG
<_whitenotifier-1>
[scopehal] azonenberg 14ea14c - PicoOscilloscope: added trigger delay support
<_whitenotifier-1>
[scopehal-pico-bridge] azonenberg opened issue #12: Allow triggering on MSO channels - https://git.io/JsR7H
<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 - https://git.io/Js0nX
<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>
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 - https://git.io/Js04i
<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>
CL_PLATFORM_NOT_FOUND_KHR
<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] https://git.io/Js0Rv
<_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 - https://git.io/Js81e
<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 - https://git.io/Js04i
<_whitenotifier-1>
[scopehal-apps] azonenberg labeled issue #354: Changing trigger channel does not update the trigger arrow in the right hand side - https://git.io/Js04i
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Js00b
<_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 - https://git.io/Js04i
<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 - https://git.io/Js0o0
<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>
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>
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 - https://git.io/JsEGB
<_whitenotifier-1>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±11] https://git.io/JsEEf
<_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] https://git.io/JsEEt
<_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] https://git.io/JsEVP
<_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 - https://git.io/Jv6hu
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JsEVX