00:06
<
_whitenotifier-4 >
[scopehal] Codysseus commented on issue #361: USB Decoder does not function correctly. -
https://git.io/JIlf6
00:13
_whitenotifier-4 has quit [Remote host closed the connection]
01:29
Degi_ has joined #scopehal
01:32
Degi has quit [Ping timeout: 272 seconds]
01:32
Degi_ is now known as Degi
03:41
electronic_eel has quit [Ping timeout: 240 seconds]
03:42
electronic_eel has joined #scopehal
04:38
<
azonenberg >
So i'm playing around mroe with jitter decomposition
04:48
<
azonenberg >
In particular, i want to be able to get a jitter spectrum with DDJ removed
04:48
<
azonenberg >
I think i'm starting to figure out how to do this
04:51
<
azonenberg >
So the first step is to compute DDJ
04:52
<
azonenberg >
But not just p-p DDJ
04:52
<
azonenberg >
you need the actual data dependent shift in edge TIE for each possible bit sequence
04:53
<
azonenberg >
in my case i'm doing an 8-bit window for ISI
04:56
<
azonenberg >
To do that, you loop over each edge in the waveform, calculate TIE, but also keep track of the past 8 bits
04:57
<
azonenberg >
then you separately average TIE in each of 256 bins
04:57
<
azonenberg >
this averages out any Rj or Pj leaving only the data correlated components (DDJ = ISI + DCD)
04:58
<
azonenberg >
Max - min of that histogram then gives you p-p DDJ
04:59
<
azonenberg >
but the trick is, you can then go back into the TIE curve again and subtract the smoothed DDJ from each bin
04:59
<
azonenberg >
giving you Rj + BUj only
05:34
<
azonenberg >
Results seem to track LeCroy SDAII somewhat closely, although there's some variation likely due to the different PLLs in use
05:35
<
azonenberg >
I still need to implement dual-Dirac Rj + Dj measurements
06:41
juli966 has joined #scopehal
06:49
bvernoux1 has joined #scopehal
06:51
bvernoux has quit [Ping timeout: 240 seconds]
07:04
bvernoux1 has quit [Read error: Connection reset by peer]
08:28
nelgau has quit [Remote host closed the connection]
08:28
nelgau has joined #scopehal
08:30
nelgau has quit [Read error: Connection reset by peer]
08:30
nelgau has joined #scopehal
08:32
nelgau has quit [Client Quit]
08:32
nelgau has joined #scopehal
11:09
bvernoux has joined #scopehal
11:11
<
bvernoux >
I have more details about ffts crash with glscopeclient demo
11:11
<
bvernoux >
Thread 17 received signal SIGSEGV, Segmentation fault.
11:11
<
bvernoux >
[Switching to Thread 8840.0x2008]
11:11
<
bvernoux >
ffts_generate_table_1d_real_32f (p=<optimized out>, sign=-1, invert=1) at C:\msys64\home\Ben\ffts\src\ffts_trig.c:1068
11:11
<
bvernoux >
Python Exception <class 'UnicodeDecodeError'> 'utf-8' codec can't decode byte 0x97 in position 1748: invalid start byte:
11:11
<
bvernoux >
1068 w[i][1] = ct[2*i][1];
11:11
<
bvernoux >
(gdb) display /3i $pc
11:11
<
bvernoux >
1: x/3i $pc
11:11
<
bvernoux >
=> 0x6a4c8380 <ffts_generate_table_1d_real_32f+208>: movapd (%r15,%r13,2),%xmm3
11:11
<
bvernoux >
0x6a4c8386 <ffts_generate_table_1d_real_32f+214>: movaps %xmm3,(%r10,%r13,1)
11:11
<
bvernoux >
0x6a4c838b <ffts_generate_table_1d_real_32f+219>: add $0x10,%r13
11:11
<
bvernoux >
it is very strange to have such issue
11:12
<
bvernoux >
unfortunately gdb provided in MSYS2 Mingw64 is a crap
11:12
<
bvernoux >
doing layout asm
11:13
<
bvernoux >
just crash gdb ...
11:13
<
bvernoux >
what a joke
11:13
<
bvernoux >
the tools under windows are real crap to debug
11:40
<
miek >
wait, how is python involved here?
11:50
m4ssi has joined #scopehal
11:54
<
miek >
bvernoux: you should print out the registers and see if it's the same alignment issue
11:55
<
bvernoux >
yes i have checked the addr
11:55
<
bvernoux >
python is embedded in gdb 10.1 it seems
11:55
<
bvernoux >
do not ask me why ...
11:56
<
bvernoux >
the most valuable details comes from VisualSTudio when trying to debug this mess
11:56
<
bvernoux >
and it seems it read data outside of memory ...
11:56
<
bvernoux >
so it is not an alignment issue but more related to some registers trashed or something buggy when ffts is built
11:57
<
bvernoux >
the fun things is ffts demo work fine
11:57
<
bvernoux >
but it use static lib
11:57
<
bvernoux >
there is of course no any test with dynamic library ...
11:58
<
bvernoux >
and the fun things
11:58
<
bvernoux >
if I use the same libffts.dll from my glscopeclient (no release version which works)
11:58
<
bvernoux >
and I copy it on the release version which crash
11:58
<
bvernoux >
it still crash
11:59
<
bvernoux >
so I heavily suspect something wrong from glscopeclient release
11:59
<
bvernoux >
i checked N
12:00
<
miek >
what are the values of r15 and r13?
12:02
<
bvernoux >
let me check
12:06
<
bvernoux >
interesting I have rebuilt ffts with Debug
12:06
<
bvernoux >
now I have a bt
12:07
<
bvernoux >
(gdb) where
12:07
<
bvernoux >
#2 0x000000006a4c1f4a in ffts_execute (p=0xe83d210, in=0x12fb6fe0, out=0x13037040) at C:\msys64\home\Ben\ffts\src\ffts.c:172
12:07
<
bvernoux >
#1 ffts_execute_1d_real (p=0xe83d210, input=0x12fb6fe0, output=0x13037040) at C:\msys64\home\Ben\ffts\src\ffts_real.c:186
12:07
<
bvernoux >
#0 0x000000006a4c4b24 in _mm_load_ps (__P=0x12b9bc2c) at C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.2.0/include/xmmintrin.h:931
12:07
<
bvernoux >
#3 0x00000000021cbae7 in TestWaveformSource::DegradeSerialData (this=0xb7067e0, cap=0xe81dc80, sampleperiod=20000, depth=100000)
12:07
<
bvernoux >
at C:\msys64\home\Ben\scopehal-apps\lib\scopehal\TestWaveformSource.cpp:307
12:07
<
bvernoux >
#4 0x00000000021cbe3c in TestWaveformSource::GeneratePRBS31 (this=this@entry=0xb7067e0, amplitude=amplitude@entry=0.899999976,
12:07
<
bvernoux >
period=period@entry=96969.6016, sampleperiod=sampleperiod@entry=20000, depth=depth@entry=100000)
12:07
<
bvernoux >
at C:\msys64\home\Ben\scopehal-apps\lib\scopehal\TestWaveformSource.cpp:203
12:07
<
bvernoux >
#5 0x0000000002151d9f in DemoOscilloscope::AcquireData (this=0xb705200)
12:07
<
bvernoux >
at C:\msys64\home\Ben\scopehal-apps\lib\scopehal\DemoOscilloscope.cpp:399
12:07
<
bvernoux >
#6 0x00000000004979dc in ScopeThread (scope=0xb705200) at C:\msys64\home\Ben\scopehal-apps\src\glscopeclient\main.cpp:393
12:07
<
bvernoux >
#7 0x000007fed3a80511 in ?? () from C:\msys64\home\Ben\glscopeclient_build_release\libstdc++-6.dll
12:07
<
bvernoux >
#8 0x000007fed58b4f33 in ?? () from C:\msys64\mingw64\bin\libwinpthread-1.dll
12:07
<
bvernoux >
#9 0x000007fefe16415f in srand () from C:\Windows\system32\msvcrt.dll
12:07
<
bvernoux >
#10 0x000007fefe166ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
12:07
<
bvernoux >
#11 0x00000000779e556d in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
12:07
<
bvernoux >
#12 0x0000000077b4372d in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
12:07
<
bvernoux >
#13 0x0000000000000000 in ?? ()
12:07
<
bvernoux >
(gdb) display /3i $pc
12:07
<
bvernoux >
=> 0x6a4c4b24 <ffts_execute_1d_real+1338>: movaps (%rax),%xmm0
12:07
<
bvernoux >
1: x/3i $pc
12:07
<
bvernoux >
0x6a4c4b27 <ffts_execute_1d_real+1341>: movaps %xmm0,0x770(%rbp)
12:07
<
bvernoux >
0x6a4c4b2e <ffts_execute_1d_real+1348>: mov 0x7dc(%rbp),%eax
12:10
<
bvernoux >
so it is not at same place now
12:12
<
miek >
if it's an alignment thing it's probably gonna move around with different compile flags
12:13
<
miek >
the argument to _mm_load_ps should be 16-byte aligned but isn't
12:33
<
bvernoux >
yes rax is clearly not aligned correctly
12:34
<
bvernoux >
so at the end it seems it is clearly an alignment issue
12:34
<
bvernoux >
which trig an overflow ... or just abort the instruction as it cannot be executed correctly
12:34
<
bvernoux >
here it is hard to find the exact error related to the instruction
12:46
<
bvernoux >
I suspect the bug is with AlignedAllocator<float, 32> g_floatVectorAllocator
12:46
<
bvernoux >
which does not align anything ;)
12:50
<
bvernoux >
let's try something
12:50
<
bvernoux >
replace _aligned_malloc() by _mm_malloc()
12:50
<
bvernoux >
which seems better support more standard
12:53
<
bvernoux >
I suspect _aligned_malloc() is buggy for MSYS2 MINGW64
12:53
<
bvernoux >
as anyway it is not portable and more for VStudio
12:53
<
bvernoux >
_mm_malloc() is standard in C++11
12:54
<
bvernoux >
for all platform
12:56
<
miek >
_mm_malloc is standard in *C11*, which may not be supported in all versions of visual studio
12:59
<
bvernoux >
we do not care of visual studio ;)
12:59
<
bvernoux >
officially it is not supported anyway
13:00
<
bvernoux >
as glscopeclient support only MSYS2 mingw64 so far
13:00
<
bvernoux >
it is impossible to build it with VS
13:00
<
bvernoux >
I'm not even sure it is planned to be compatible with VS ...
13:00
<
bvernoux >
anyway it will requires VS2018 or more to support correctly C11 or more
13:01
<
bvernoux >
older version of VS are crap and are not compliant with C++11 IIRC ...
13:01
<
bvernoux >
they are compliant with M$ stuff ;)
13:03
<
bvernoux >
anyway I have same crash ;)
13:04
<
bvernoux >
rax 0x12e9f76c
13:04
<
bvernoux >
0x6a4c4b24 <ffts_execute_1d_real+1338>: movaps (%rax),%xmm0
13:04
<
bvernoux >
still not aligned correctly
13:05
<
bvernoux >
(gdb) where
13:05
<
bvernoux >
#0 0x000000006a4c4b24 in _mm_load_ps (__P=0x12e9f76c) at C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.2.0/include/xmmintrin.h:931
13:05
<
bvernoux >
#1 ffts_execute_1d_real (p=0xea61a30, input=0x12f9f8a0, output=0x1326c520) at C:\msys64\home\Ben\ffts\src\ffts_real.c:186
13:05
<
bvernoux >
#2 0x000000006a4c1f4a in ffts_execute (p=0xea61a30, in=0x12f9f8a0, out=0x1326c520) at C:\msys64\home\Ben\ffts\src\ffts.c:172
13:05
<
bvernoux >
#3 0x00000000021cbae7 in TestWaveformSource::DegradeSerialData (this=0xb5c67e0, cap=0xe84b810, sampleperiod=20000, depth=100000)
13:05
<
bvernoux >
at C:\msys64\home\Ben\scopehal-apps\lib\scopehal\TestWaveformSource.cpp:307
13:05
<
bvernoux >
#4 0x00000000021cbe3c in TestWaveformSource::GeneratePRBS31 (this=this@entry=0xb5c67e0, amplitude=amplitude@entry=0.899999976,
13:05
<
bvernoux >
period=period@entry=96969.6016, sampleperiod=sampleperiod@entry=20000, depth=depth@entry=100000)
13:05
<
bvernoux >
at C:\msys64\home\Ben\scopehal-apps\lib\scopehal\TestWaveformSource.cpp:203
13:05
<
bvernoux >
#5 0x0000000002151d9f in DemoOscilloscope::AcquireData (this=0xb5c5200)
13:05
<
bvernoux >
at C:\msys64\home\Ben\scopehal-apps\lib\scopehal\DemoOscilloscope.cpp:399
13:05
<
bvernoux >
#6 0x00000000004979dc in ScopeThread (scope=0xb5c5200) at C:\msys64\home\Ben\scopehal-apps\src\glscopeclient\main.cpp:393
13:05
<
bvernoux >
#7 0x000007fed3690511 in ?? () from C:\msys64\home\Ben\glscopeclient_build_release\libstdc++-6.dll
13:05
<
bvernoux >
#8 0x000007fed58b4f33 in ?? () from C:\msys64\mingw64\bin\libwinpthread-1.dll
13:05
<
bvernoux >
#9 0x000007fefe16415f in srand () from C:\Windows\system32\msvcrt.dll
13:05
<
bvernoux >
#10 0x000007fefe166ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
13:05
<
bvernoux >
#11 0x00000000779e556d in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
13:05
<
bvernoux >
#12 0x0000000077b4372d in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
13:06
<
bvernoux >
#13 0x0000000000000000 in ?? ()
13:06
<
bvernoux >
let me check with Ghidra and the libscopehal.dll
13:06
<
bvernoux >
as it is a mess to understand how this C++ stuff mixed with sse are compiled ;)
13:07
massi_ has joined #scopehal
13:08
<
d1b2 >
<Stary> oh 1d/2d
13:09
<
bvernoux >
pontentially i will say yes
13:09
<
bvernoux >
maybe ;)
13:10
<
miek >
try `frame 1` and `print *p`
13:13
<
bvernoux >
#1 ffts_execute_1d_real (p=0xea61a30, input=0x12f9f8a0, output=0x1326c520) at C:\msys64\home\Ben\ffts\src\ffts_real.c:186
13:13
<
bvernoux >
186 __m128 t2 = _mm_load_ps(buf + N - i - 4);
13:14
<
bvernoux >
(gdb) print *p
13:14
<
bvernoux >
lastlut = 0x0, transform = 0x6a4c45ea <ffts_execute_1d_real>, transform_base = 0x0, transform_size = 0, constants = 0x0, plans = 0xea61b70,
13:14
<
bvernoux >
$1 = {offsets = 0x0, ws = 0x0, oe_ws = 0x0, eo_ws = 0x0, ee_ws = 0x0, is = 0x0, ws_is = 0x0, i0 = 0, i1 = 0, n_luts = 0, N = 131071,
13:14
<
bvernoux >
rank = 1, Ns = 0x0, Ms = 0x0, buf = 0x12e1f780, transpose_buf = 0x0, destroy = 0x6a4c453c <ffts_free_1d_real>, A = 0x12e9f7e0,
13:14
<
bvernoux >
B = 0x12f1f840, i2 = 0}
13:15
<
bvernoux >
strange things why N = 131071
13:15
<
bvernoux >
it shall be 131072
13:15
<
bvernoux >
A & B seems correctly aligned anyway
13:17
<
bvernoux >
any idea ?
13:18
<
miek >
so buf is just a float*, so that loop & pointer arithmetic is going to result in addresses aligned to 4 bytes (not 16), i think?
13:19
<
bvernoux >
buf = 0x12e1f780 is also correctly aligned
13:19
<
bvernoux >
ha yes maybe
13:19
<
bvernoux >
so a bug in libffts ;)
13:19
<
miek >
but `buf + 1`, for example, wouldn't be
13:20
<
bvernoux >
strange thing is why it appears only on windows build release ?
13:21
<
bvernoux >
for me the issue is N = 131071
13:21
<
bvernoux >
instead of 131072 to be aligned
13:21
<
bvernoux >
to be checked
13:22
<
miek >
i don't really understand what that loop is supposed to be doing
13:23
<
bvernoux >
yes me too i'm clearly not an expert on sse x64 stuff
13:23
<
bvernoux >
and I really hate their stuff ;)
13:23
<
bvernoux >
I'm more embedded developer
13:24
<
bvernoux >
anyway the issue was in & out was not aligned on 16bytes
13:25
<
bvernoux >
here we have
13:25
<
bvernoux >
ffts_execute_1d_real (p=0xea61a30, input=0x12f9f8a0, output=0x1326c520)
13:25
<
bvernoux >
and in & out are correctly aligned
13:25
<
miek >
oh wait i was misreading the loop, i didn't see that it's i += 16
13:25
<
miek >
ok that makes more sense, so yes the problem is N
13:25
<
bvernoux >
yes why N is with such value
13:26
massi_ has quit [Remote host closed the connection]
13:26
<
miek >
i would set a breakpoint in the plan setup to see if glscopeclient is passing that in
13:28
<
bvernoux >
at start of DegradeSerialData
13:28
<
bvernoux >
TestWaveformSource::DegradeSerialData
13:28
<
bvernoux >
and do step by step
13:28
<
bvernoux >
N is npoints IIRC
13:28
<
bvernoux >
and so with invalid value 131071 ...
13:28
Stary has quit [Ping timeout: 260 seconds]
13:31
<
miek >
oh, i bet it could be - it's doing an implicit cast from float to size_t
13:31
<
bvernoux >
I confirm
13:31
<
bvernoux >
ffts_init_1d_real (N=131071, sign=-1) at C:\msys64\home\Ben\ffts\src\ffts_real.c:607
13:32
<
bvernoux >
ha yes a rounding issue ;)
13:33
<
bvernoux >
depth is 100000
13:33
<
bvernoux >
need to do the computation to check ;)
13:33
<
bvernoux >
const size_t npoints = pow(2, ceil(log2(depth)));
13:33
<
bvernoux >
returns 131071 in actual code
13:33
<
bvernoux >
instead of 131072
13:37
<
bvernoux >
yes at the end results should be 131072
13:42
<
bvernoux >
but it is not ;)
13:42
<
bvernoux >
there is a crazy bug somewhere ;)
13:43
<
bvernoux >
as something is broken
13:44
<
bvernoux >
show it shall returns correctly 131072
13:45
<
Bird|otherbox >
bvernoux, what type is depth?
13:46
<
Bird|otherbox >
yikes. size_t to float to size_t...that's not cheap, atop being not quite right
13:46
<
bvernoux >
yes there is clearly something with a round issue ...
13:46
<
bvernoux >
but when I execute it online with GCC it returns correct result
13:47
<
bvernoux >
let me check with MSYS2 mingw64 now ;)
13:49
<
bvernoux >
even with MSYS2 mingw64 it returns correctly 131072
13:49
<
bvernoux >
very very strange ;)
13:50
<
miek >
i guess log2 impl. may vary between compilers?
13:52
<
bvernoux >
very strange I'm testing with a simple code with same dev env
13:52
<
bvernoux >
maybe I do not have same opt for gcc ...
13:52
<
bvernoux >
just tried -O3
13:53
Stary has joined #scopehal
13:53
<
sorear >
I would not assume log2 produces exact results for powers of two input
13:53
<
sorear >
that's what frexp is for
13:56
<
bvernoux >
yes interesting
13:57
<
bvernoux >
we can also do that with shift ;)
13:57
<
bvernoux >
and do not use float at all
13:57
<
bvernoux >
anyway size_t is not justified here
13:57
<
Bird|otherbox >
yeah, I was kind of thinking that it'd be better done either using a compiler intrinsic or bitwise work, instead of going out to float and back again
13:57
<
bvernoux >
as it means a number of samples and in best case we will never have more than 32bits values for that
13:57
<
bvernoux >
4billions samples is a lot for 1 frame ;)
13:58
<
Bird|otherbox >
eeeh, maybe not?
13:58
<
bvernoux >
just with 200Millions pts it is already ultra slow ;)
13:58
<
bvernoux >
like 1WFM/s
13:58
<
Bird|otherbox >
if you're doing it realtime maybe, but for a "one shot" FFT analysis, feeding several billion points in might just be justified
13:58
<
bvernoux >
for a scope ?
13:59
<
Bird|otherbox >
I'm thinking of this from the library/API developer's view
13:59
<
bvernoux >
I do not know any scope which can provide billions pts for 1 frame
13:59
<
bvernoux >
but yes let's keep this size_t
13:59
<
bvernoux >
we can do the trick using 64bits shifft anyway ;)
13:59
<
Bird|otherbox >
(I'm assuming ffts is the one doing the depth to npoints math)
13:59
<
miek >
you're casting it to size_t whether you like it or not, cause that's what ffts takes :p
14:00
<
bvernoux >
as there is clearly an issue with conversion from float/double/size_t in a special condition
14:00
<
bvernoux >
with log2, ceil and/or pow
14:01
<
miek >
Bird|otherbox: that math is in scopehal
14:01
<
Bird|otherbox >
oh. I see
14:02
<
Bird|otherbox >
FFTS requires depth to be power-of-2
14:02
<
Bird|otherbox >
err npoints
14:06
<
bvernoux >
this things will do the tricks
14:06
<
bvernoux >
uint32_t v = depth; // compute the next highest power of 2 of 32-bit v
14:06
<
bvernoux >
v |= v >> 1;
14:06
<
bvernoux >
v |= v >> 2;
14:06
<
bvernoux >
v |= v >> 4;
14:06
<
bvernoux >
v |= v >> 8;
14:06
<
bvernoux >
v |= v >> 16;
14:07
<
bvernoux >
ok it works only with uint32
14:07
<
Bird|otherbox >
yeah, exactly the recipe I was looking at -- should be trivial to extend to 64bit, no?
14:09
<
bvernoux >
the solution
14:09
<
bvernoux >
uint64_t v = depth; // compute the next highest power of 2 of 32-bit v
14:09
<
bvernoux >
v |= v >> 2;
14:09
<
bvernoux >
v |= v >> 1;
14:09
<
bvernoux >
v |= v >> 4;
14:09
<
bvernoux >
v |= v >> 8;
14:09
<
bvernoux >
v |= v >> 16;
14:09
<
Bird|otherbox >
probably should be tucked off into its own function I reckon though
14:09
<
bvernoux >
const size_t npoints1 = v;
14:09
<
bvernoux >
printf("depth=%zu npoints=%zu\n", depth, npoints1);
14:09
<
bvernoux >
it support 64bits ;)
14:09
<
bvernoux >
so I really doubt it is a limitation ;)
14:09
<
bvernoux >
until we have enough ram for 64bits ;)
14:09
<
Bird|otherbox >
well, try feeding a value >4GB in there
14:10
<
Bird|otherbox >
I think you'd need a v |= v >>32; right before the v++; to make it work right
14:10
<
bvernoux >
$ ./main.exe
14:10
<
bvernoux >
depth=10000000000000000 npoints=18014398509481984
14:10
<
bvernoux >
depth=10000000000000000 npoints=18014398509481984
14:10
<
bvernoux >
volatile size_t depth = 10000000000000000;
14:10
<
bvernoux >
int main()
14:10
<
bvernoux >
const size_t npoints = pow(2, ceil(log2(depth)));
14:10
<
bvernoux >
printf("depth=%zu npoints=%zu\n", depth, npoints);
14:10
<
bvernoux >
uint64_t v = depth; // compute the next highest power of 2 of 32-bit v
14:10
<
bvernoux >
v |= v >> 1;
14:10
<
bvernoux >
v |= v >> 2;
14:10
<
bvernoux >
v |= v >> 4;
14:10
<
bvernoux >
v |= v >> 8;
14:10
<
bvernoux >
v |= v >> 16;
14:10
<
bvernoux >
const size_t npoints1 = v;
14:10
<
bvernoux >
printf("depth=%zu npoints=%zu\n", depth, npoints1);
14:10
<
bvernoux >
return 0;
14:10
<
bvernoux >
it seems to be a hack but let's test it now in real code ;)
14:11
<
bvernoux >
it avoid using tons of lib and conv anyway
14:13
<
bvernoux >
let's test with real code ;)
14:17
<
bvernoux >
even smarter
14:17
<
bvernoux >
uint64_t next_pow2(uint64_t x) {
14:17
<
bvernoux >
return x == 1 ? 1 : 1<<(64-__builtin_clzl(x-1));
14:17
<
bvernoux >
2 instructions
14:18
<
Bird|otherbox >
nice
14:19
<
Bird|otherbox >
I was figuring there'd be something like that based on bitwise intrinsics
14:22
<
bvernoux >
and now that works ;)
14:22
<
bvernoux >
fixed ;)
14:22
<
bvernoux >
we can call that a crazy bug which was affecting only MSYS2 mingw64 build ...
14:24
<
bvernoux >
now I shall fix other class
14:24
<
bvernoux >
with same trick
14:24
<
bvernoux >
like FFT ...
14:25
<
bvernoux >
shall be fixed in DeEmbedFilter.cpp, FFTFilter.cpp and JitterSpectrumFilter.cpp
14:25
<
bvernoux >
will add a common function for that ;)
15:37
<
bvernoux >
ok all is fixed
15:37
<
bvernoux >
waiting azonenberg to merge the PR ;)
15:37
<
azonenberg >
bvernoux: ooh good catch
15:37
<
azonenberg >
also please do keep size_t
15:37
<
bvernoux >
yes i kept it ;)
15:38
<
bvernoux >
the limitation is uint64_t next_pow2(uint64_t v)
15:38
<
azonenberg >
WavePro HD can go up to 5G points per acquisition
15:38
<
bvernoux >
with 64bits we have margin ;)
15:38
<
azonenberg >
so it's plausible we could exceed the range of uint32_t for sample counts
15:38
<
bvernoux >
anyway I have not changed the size_t
15:39
<
bvernoux >
I have done some internal test to validate it
15:39
<
azonenberg >
Will look in a minute. still catching up on what happened in the outside world when i was asleep :p
15:39
<
bvernoux >
in limit is around => 9223372036854775809
15:39
<
bvernoux >
so I doubt you have so much memory one done for 1 frame ;)
15:40
<
bvernoux >
-done+day
15:40
<
bvernoux >
it was really tricky to catch that bug
15:40
<
bvernoux >
as I cannot reproduce it outside glscopeclient release
15:40
<
bvernoux >
with a simple C code it works
15:41
<
bvernoux >
it explain why FFT was crashing with Windows build too
15:41
<
bvernoux >
it affect Demo ...
15:41
<
bvernoux >
JitterSpectrumFilter too
15:41
<
bvernoux >
FFTFilter
15:41
<
bvernoux >
DeEmbedFilter
15:42
<
bvernoux >
and TestWaveformSource
15:42
<
bvernoux >
used only in demo mode
15:42
<
bvernoux >
now it is rock stable ;)
15:42
<
bvernoux >
and i can add some nice FFT
15:42
<
bvernoux >
to Demo ...
15:43
<
bvernoux >
My code is portable and universal ;)
15:43
<
miek >
why are there 6 PRs for it? D:
15:44
<
bvernoux >
because I have done them manually in github ;)
15:44
<
bvernoux >
yes it's crap but there is one line each time in each file ;)
15:58
<
bvernoux >
next PR is to improve Rigol MSO5000 speed and robustness ;)
15:58
<
bvernoux >
we can win 10% speed ;)
16:01
<
azonenberg >
bvernoux: please use proper PRs next time though, not one PR per line changed :p
16:02
<
miek >
also, if you did it all manually on github - is it actually tested?
16:02
<
bvernoux >
it was to win time as all my fork are totally outdated ;)
16:02
<
bvernoux >
yes I have tested it
16:02
<
bvernoux >
locally here
16:02
<
miek >
you checked it back out after all the PRs?
16:04
<
azonenberg >
miek: yeah i'm going to go through and edit it after i've merged everything
16:04
<
azonenberg >
it's just ugly to deal with right now
16:05
<
bvernoux >
more tests are welcome for corner cases ;)
16:05
<
miek >
i gave you one in the review
16:09
<
bvernoux >
fixed ;)
16:10
<
azonenberg >
Fix pushed
16:10
<
azonenberg >
using the clzl intrinsic if gcc and falling back to the portable version if not
16:17
<
azonenberg >
Also my solder-in 4 GHz active diff probe came in over the weekend. Still waiting on the probe positioner which was supposed to have come saturday but ended up being delayed
16:18
<
bvernoux >
yes nice ;)
16:18
<
bvernoux >
clzl is the best but was not portable
16:18
<
bvernoux >
like that we have a nice next_pow2 function ;)
16:18
<
azonenberg >
yeah i have absolutely no problem with platform specific optimizations as long as they don't break things
16:19
<
azonenberg >
have you seen all the avx2 code i have sitting around? :P
16:19
<
bvernoux >
no i have not checked
16:19
<
azonenberg >
I run glscopeclient under vtune routinely and any time something starts feeling slow i try to vectorize it
16:20
<
bvernoux >
it is a nightmare on MSYS2 GDB for mmx/avx code ;)
16:20
<
azonenberg >
de-embed, eye pattern, even lecroy waveform download (conversion from raw adc samples to volts), and more all have hand tuned AVX2 intrinsic implementations as well as portable C++
16:22
<
bvernoux >
let's rebuild all ;)
16:23
<
azonenberg >
724 WFMs / 1 min = 12.06 WFM/s average for a 1-minute test
16:23
<
bvernoux >
and before optim ?
16:24
<
azonenberg >
Can't say, some of the filters i use didn't even exist when i started all of the AVX stuff
16:24
<
azonenberg >
i can say that the eye pattern filter alone is >2x faster than it was
16:24
<
bvernoux >
ha great
16:24
<
azonenberg >
i also cache a bunch of operations like "find zero crossings" that i often call multiple times on one waveform
16:25
<
azonenberg >
The CDR PLL is actually a bottleneck now, but before i optimize it i want to implement a proper, industry standard CDR. Preferably several different PLLs
16:26
<
d1b2 >
<TiltMeSenpai> meanwhile in Rigol MSO5k land...
16:26
<
d1b2 >
<TiltMeSenpai> it has gotten a lot better though, thank you for the work
16:26
<
bvernoux >
on my side I'm searching a very fast 16 IO digital signal generator which can go at up to 250MHz ;)
16:26
<
d1b2 >
<TiltMeSenpai> just not 12 WFM/S better
16:27
<
azonenberg >
Lol. That's 12 WFM/s with a fairly heavy processing graph. it does 30+ just showing waveforms
16:27
<
bvernoux >
so far on MSO5k we cannot reach more than 1 WFM/s ;)
16:27
<
bvernoux >
I have an optimisation to win 10% ;)
16:27
<
azonenberg >
But that's what happens when you're using a scope that would have cost you north of 40K USD if you had bought it new
16:27
<
d1b2 >
<TiltMeSenpai> I wonder at what point do we explore custom firmware
16:27
<
azonenberg >
rather than under 4K :p
16:27
<
bvernoux >
but we shall push Rigol to fix their SCPI management
16:27
<
bvernoux >
it is a real cheat
16:27
<
d1b2 >
<TiltMeSenpai> it's theoretically possible to have a fully custom stack on the Rigol, right? just a ton of work?
16:28
<
bvernoux >
the MSO5k shall be able to push at least 20 WFM/s with 10kpts
16:28
<
azonenberg >
TiltMeSenpai: That is not something i have spent much time looking into because for me, the endgame has always been full custom hardware
16:28
<
azonenberg >
instrumentation purpose built for headless operation with fpga accelerated networking rather than being bottlenecked on slow TCP on a dinky arm core
16:28
<
d1b2 >
<TiltMeSenpai> yeah custom Rigol firmware isn't something I would ask you to support, but we can spread the love
16:28
<
azonenberg >
if someone makes a viable custom firmware that gains traction i will gladly help with the driver side
16:29
<
d1b2 >
<TiltMeSenpai> I'm totally buying whatever you come up with when it becomes a product though
16:29
<
bvernoux >
if they disable the display with a special SCPI mode there will be not limit ;)
16:29
<
azonenberg >
but yeah in general i really rely on third party contributions for driver support
16:29
<
bvernoux >
I'm pretty sure they can saturate the Ethernet Gigabit
16:29
<
azonenberg >
Because i just don't have access to anything other than lecroy scopes, and whatever else i can convince people to let me borrow in person or over a VPN
16:29
<
bvernoux >
it depends on the link to retrieve the data from ADC/FPGA => Zynq7010 Cortex A9
16:30
<
azonenberg >
bvernoux: BTW, I'm tentatively going to be borrowing an 8 GHz MSO64 from a friend in seattle over christmas
16:30
<
bvernoux >
azonenberg, woahou nice
16:30
<
bvernoux >
azonenberg, what the price of such beast ?
16:30
<
bvernoux >
do he have made a deal ?
16:30
<
azonenberg >
high five, low six digits. no idea what he paid for it
16:30
<
bvernoux >
to pay it less than 40KUSD ;)
16:31
<
azonenberg >
My goals there are... test the AKL-PT1/PT2 on a higher bandwidth scope
16:31
<
d1b2 >
<TiltMeSenpai> I was looking at the way the "feature discounts" work, and they're all patching the binary. I think in theory that means you can patch the binary to whatever you want, such as creating a SCPI only mode
16:31
<
azonenberg >
Fine tune and optimize the MSO5/6 driver
16:31
<
bvernoux >
d1b2, yes there is clearly something to do like that or to push Rigol to do it ;)
16:31
<
azonenberg >
and most importantly, i want to debug the multi-scope code a bit more and do a "plugfest" demo with a MSO64 and a WaveRunner 8000 series scope under one UI
16:32
<
azonenberg >
i think that would be yet another world first lol
16:32
<
azonenberg >
Two modern multi-GHz scopes, not just different families but different brands, seamlessly working together under one UI
16:33
<
azonenberg >
In theory i have everything i need for that right now. i'm sure i will run into quirks but that is the goal
16:33
<
azonenberg >
and i'll have a week or two with the scope while i'm off work to debug
16:34
<
bvernoux >
yes will be amazing ;)
16:35
<
bvernoux >
is intended for such type of SCPI tuning ;)
16:35
<
bvernoux >
and is fully reusable for other scope
16:36
<
bvernoux >
anyone is welcome it is fully open source
16:36
<
bvernoux >
advantage is it build in few ms ;)
16:36
<
bvernoux >
compared to build glscopeclient ;)
16:36
<
azonenberg >
Well i'm glad you're adopting the MSO5 driver. even if it's slow it's nice to have someone maintaining it
16:36
<
azonenberg >
also, i have one of those cheap fx2 LAs now
16:36
<
azonenberg >
but have not had time to work on it
16:37
<
azonenberg >
on driver support i mean
16:37
<
azonenberg >
That will be good to have though
16:37
<
bvernoux >
the fx2 LAs will be a big killer
16:37
<
bvernoux >
as it could bring lot of people to help on code
16:37
<
bvernoux >
as LA is not very supported so far
16:38
<
bvernoux >
FFT on LA channel could be fun ;)
16:38
<
bvernoux >
or even ClockRecovery ;)
16:39
<
bvernoux >
main interest is to see in realtime the data with trigger
16:39
<
bvernoux >
which is not possible with LA today
16:39
<
bvernoux >
as it is mainly a big capture then analyze after
16:40
<
bvernoux >
as LA gui like pulseview or saleae are not designed to show things in realtime
16:40
<
azonenberg >
I want to be able to do digital phosphor effects on LA waveforms
16:40
<
bvernoux >
ha yes will be nice
16:40
<
azonenberg >
Which will require, among other things, that i fix persistence which has been broken for months
16:41
<
azonenberg >
Profiling of a 1-minute run on the jitter decomposition example
16:41
<
azonenberg >
showing where the hot filters are
16:41
<
bvernoux >
this intel v-tune profiler is very nice
16:41
<
azonenberg >
yeah that plus nvidia's nsight for the GPU side have been invaluable for performance tuning
16:43
<
bvernoux >
I plan to buy AMD only things ;)
16:43
<
bvernoux >
will be interesting
16:43
<
bvernoux >
I hate Intel & Nvidia ;)
16:43
<
azonenberg >
Meanwhile i'm pretty much 100% intel + nv in my dev environment lol
16:44
<
azonenberg >
my main workstation is dual xeon 6144s plus a 2080 Ti
16:44
<
bvernoux >
Ryzen9 Serie5 Desktop with latest AMD GFX card which explode Nvidia ;)
16:44
<
azonenberg >
also BTW, average CPU usage during this test was only 1.06 cores
16:44
<
bvernoux >
for 3Keuros I shall have something decent with 12x core running near 5GHz ;)
16:44
<
azonenberg >
So i think there is a
*lot* of room for glscopeclient to parallelize more
16:45
<
azonenberg >
There's a lot of stuff being done in the main thread that i think can be moved out
16:45
<
bvernoux >
yes it is still very impressive with the demo
16:45
<
bvernoux >
will be nice to add WFM/s in demo ;)
16:45
<
bvernoux >
as it clearly test the CPU+GPU
16:46
<
azonenberg >
you can see activity of each thread over time
16:46
<
azonenberg >
the first OpenMP worker thread gets a big spike of activity every frame, and the scope driver thread is doing a fair bit of work
16:46
<
azonenberg >
then the second OpenMP thread does a bit here and there
16:46
<
azonenberg >
but most of the cores are not actually doign a ton
16:46
<
bvernoux >
OpenMP is sleeping all the time on 2 cores ;)
16:47
<
azonenberg >
So if i can figure out how to effectively use more threads we should see much better performance
16:47
<
bvernoux >
yes clearly
16:47
<
bvernoux >
and decouple better the UI from WFM from scope
16:47
<
bvernoux >
there is clearly something locked today
16:47
<
azonenberg >
So far i've been focusing on very easy parallelism, like running different blocks in the filter graph in parallel, as well as vectorization because that is also generally easy for DSP-focused stuff
16:47
<
bvernoux >
which can be seen on Rigol MSO5000 with it's 1WFM/s ;)
16:48
<
azonenberg >
Yeah. Definitely a lot of performance tuning to do before we hit my goals of 3-4 digit WFM/s
16:48
<
bvernoux >
the UI is totally unresponsive
16:48
<
bvernoux >
in order to use the UI I switch to step by step WFM
16:48
<
azonenberg >
Write queueing is going to help a lot with that I think
16:48
<
bvernoux >
I'm impatient to see the result when it will be implemented
16:49
<
azonenberg >
But it's going to be a major project so I've been putting it off until I have time to devote to it. That might be another to-do over the christmas holiday
16:49
<
bvernoux >
also a parameter to say single trigger at startup will be nice
16:49
<
azonenberg >
i have two weeks off work
16:49
<
bvernoux >
I will check
16:49
<
azonenberg >
rather than adding that, probably better to just fix things to not be so slow :p
16:49
<
azonenberg >
again, write queueing should make a huge difference
16:50
<
bvernoux >
yes need refactor of the socket
16:50
<
bvernoux >
to expose socket directly
16:50
<
bvernoux >
that will improve lot of cases
16:50
<
azonenberg >
I just don't have enough hours in the day to do everything i want :p
16:50
<
bvernoux >
and add robustness
16:50
<
bvernoux >
for all scope ;)
16:50
<
bvernoux >
in case you change something today it timeout and crash
16:50
<
azonenberg >
Like documentation. I have a 135-page manual that needs major updating and completion
16:51
<
bvernoux >
yes documentation will come later ;)
16:51
<
bvernoux >
You shall ask for GSOC
16:51
<
bvernoux >
to have a student working on scopehal during few months full time
16:53
<
azonenberg >
Maybe for 2022
16:53
<
azonenberg >
there's still a lot more setup work to do before we get to that point. I want to have a proper website for the project, some developer documentation
16:53
<
azonenberg >
a much-updated manual
16:54
<
azonenberg >
and installers, at least a v0.1 level binary release
16:55
<
bvernoux >
the only missing step is to copy libffts.dll today
16:55
<
bvernoux >
or maybe use it as static that will avoid an other DLL ...
16:55
<
bvernoux >
as anyway ffts will do not change it is frozen since 2017
16:57
<
azonenberg >
yes. seriously thinking of updating it myself with AVX support at some point
16:57
<
azonenberg >
and/or going straight to GPU
16:59
<
bvernoux >
a good feature will be to add details on trigger how many GSPS/MSPS
17:00
<
bvernoux >
like we have on "standard" scope
17:00
<
bvernoux >
but it is mainly gui stuff to add
17:00
<
azonenberg >
We have that on every waveform in the infobox
17:00
<
azonenberg >
it shows the timebase config
17:00
<
azonenberg >
At least it's supposed to
17:01
<
bvernoux >
but it is not displayed
17:01
<
azonenberg >
see the infobox on the "TX" channel
17:01
<
azonenberg >
do you not get that with mso5k?
17:01
<
bvernoux >
IIRC no ther is nothing in mso5k
17:02
<
bvernoux >
let me check ;)
17:02
<
azonenberg >
it's per channel not in the footer, because with some scopes or multi-scope setups timebase may not be the same for all channels
17:02
<
bvernoux >
ha yes that work
17:02
<
azonenberg >
Like MSO vs analog, or 8 vs 12 bit mode on BLONDEL
17:02
<
bvernoux >
what is missing is horizontal timebase
17:03
<
azonenberg >
what do you mean? time/div?
17:03
<
bvernoux >
yes like 200us
17:03
<
azonenberg >
That's intentional, "divisions" don't make sense in this kind of UI
17:04
<
azonenberg >
the record length may be longer or shorter than what you see on screen
17:04
<
bvernoux >
with trigger also with the level
17:04
<
bvernoux >
when it is basic trigger
17:04
<
azonenberg >
Trigger level is shown with a little arrow on the right side
17:04
<
azonenberg >
i don't print out the actual level but you can see it in the trigger properties dialog
17:04
<
azonenberg >
i figure for most purposes just seeing the arrow is good enough
17:04
<
azonenberg >
trigger position is shown on the top time bar too
17:05
<
azonenberg >
although right now you cannot drag it to move it around
17:05
<
azonenberg >
you will be able to in the future
17:05
<
azonenberg >
that's one of many to-do items that i've just been too busy to touch
17:06
<
bvernoux >
i will push some fixes also to refresh the channels when restarting trigger (Single Trigger)
17:06
<
bvernoux >
as it does not refresh what happen on scope
17:06
<
azonenberg >
what do you mean "refresh the channels"
17:06
<
azonenberg >
do you mean clearing the cache of voltage range etc?
17:06
<
bvernoux >
it shall poll what chan are enabled/disabled
17:06
<
bvernoux >
as sometimes it is more convenient to pause glscopeclient do all on scope and restart the trigger
17:07
<
azonenberg >
The 'refresh' button on the toolbar clears the cache and is intended to be used if you poke settings on the hardware
17:07
<
azonenberg >
Enabling/disabling channels on the scope is not something you should be doing
17:07
<
azonenberg >
glscopeclient reference counts channels and disables them on hardware when the last filter or viewport using it is closed
17:07
<
bvernoux >
I speak about > and >II (pause)
17:07
<
azonenberg >
Yes. You should NOT clear the cache when you do a single trigger
17:07
<
azonenberg >
that would hugely slow things down
17:07
<
bvernoux >
which do single trigger or continuous
17:07
<
azonenberg >
There's a dedicated toolbar button for that which you can use if you change settings on the scope
17:08
<
bvernoux >
or maybe reload all with the settings button
17:08
<
azonenberg >
Clearing every trigger would be stupid and horribly slow
17:08
<
bvernoux >
Reload configuration from scope
17:08
<
bvernoux >
it shall check again the chan enabled/disabled ...
17:08
<
bvernoux >
that does not work for that
17:08
<
azonenberg >
That doesnt make sense though
17:08
<
azonenberg >
why would you turn channels on/off in the hardware?
17:08
<
bvernoux >
to do a full refresh
17:08
<
bvernoux >
because it is more convenient to do it on scope side with mso5 ;)
17:09
<
bvernoux >
as it is unusable at 1WFM/s on glscopeclient
17:09
<
azonenberg >
what would you expect glscopeclient to do if you turn a channel on? create a new waveform area?
17:09
<
azonenberg >
that's a GUI function
17:09
<
bvernoux >
for such stuff
17:09
<
azonenberg >
we can't have the library calling out to gui code that might not even exist
17:09
<
azonenberg >
and why would you turn a channel off in the hardware if you are still displaying a waveform?
17:09
<
bvernoux >
yes today I shall pause and manually remove the channels
17:09
<
azonenberg >
if you hide that waveform the channel turns off automatically
17:09
<
bvernoux >
yes it works
17:09
<
bvernoux >
in pause ;)
17:10
<
azonenberg >
The proper solution is fixing any UI hangs that make this workflow not usable
17:10
<
azonenberg >
Not adding hacky workarounds
17:10
<
bvernoux >
as with 1 WFM it is too slow to do anything with the GUI today
17:10
<
azonenberg >
again, acquisition framerate should not affect gui performance
17:10
<
azonenberg >
all reads done by gui code should be cached
17:10
<
azonenberg >
if they're not, that's a driver bug
17:10
<
azonenberg >
writes done by gui code are currently blocking but that will be fixed by write queueing
17:10
<
bvernoux >
maybe you can simulate that with your scope ?
17:11
<
bvernoux >
or only the Rigol MSO5000 driver is affected
17:11
<
bvernoux >
it is not clear
17:11
<
azonenberg >
It's very likely that there's a driver bug where something that should be cached is not
17:11
<
bvernoux >
it can be simulated ;)
17:11
<
bvernoux >
with a basic server code simulating basically scope wfm
17:11
<
bvernoux >
with some delay ;)
17:12
<
azonenberg >
Anyway we know write queueing needs to happen
17:12
<
azonenberg >
That's the next of the major refactorings i've had pending
17:12
<
azonenberg >
I'll work on it over christmas
17:12
<
azonenberg >
in the meantime dont do anything major that breaks things :p
17:12
<
bvernoux >
yes let's wait that write queueing ;)
17:13
<
bvernoux >
I will optimize rigol SCPI commands
17:13
<
azonenberg >
But feel free to do wireshark captures of glscopeclient running and look for any read commands it shouldnt be making
17:13
<
bvernoux >
for mso5 only as I do not have the other scope
17:14
<
bvernoux >
just found a new bug
17:14
<
bvernoux >
Unhandled exception at 0x0000000004DBB558 (libscopeprotocols.dll) in glscopeclient.exe: 0xC0000094: Integer division by zero.
17:14
<
bvernoux >
div by zero ;)
17:15
<
azonenberg >
i just fixed one of those this morning
17:15
<
azonenberg >
where is it?
17:16
<
bvernoux >
when adding Jitter Spectrum
17:16
<
bvernoux >
on my 1st scope chan
17:17
<
azonenberg >
What was the input to the jitter spectrum? it should be a TIE waveform
17:17
<
bvernoux >
it was not a TIE waveform ;)
17:17
<
azonenberg >
but it shouldn't crash given an analog channel
17:17
<
bvernoux >
it was an analog chan
17:17
<
azonenberg >
it just won't display useful data
17:17
<
bvernoux >
just a square wave
17:18
<
azonenberg >
I confirm it does crash in that case though. interesting
17:19
<
azonenberg >
scopehal:#379 filed
17:19
<
bvernoux >
Watefall also crash on analog chan
17:19
<
bvernoux >
Waterfall
17:19
<
azonenberg >
scopehal:#380 filed
17:19
<
bvernoux >
with an access violation
17:20
<
azonenberg >
Will work on both after work
17:20
<
bvernoux >
Access violation reading location 0x00000000000000A0.
17:20
<
bvernoux >
now I'm more confident ;)
17:20
<
bvernoux >
as the FFTS mess was really crappy
17:20
<
bvernoux >
it was not the fault of ffts ;)
17:21
m4ssi has quit [Remote host closed the connection]
17:21
<
azonenberg >
All of the filters
*should* reject invalid inputs
17:22
<
bvernoux >
so you reproduce both issue ?
17:22
<
bvernoux >
ok great
17:22
<
azonenberg >
Waterfall expects a FFT as input
17:22
<
azonenberg >
verify it works when you do that?
17:22
<
bvernoux >
yes let's try that
17:22
<
bvernoux >
I was thinking it was doing everything
17:23
<
azonenberg >
No, these are generally pretty single purpose "unix pipe chain" style processing blocks
17:23
<
azonenberg >
i will eventually add shorthands in the UI to handle common cases though
17:23
<
bvernoux >
ha ok logic in that case
17:23
<
azonenberg >
This will all be documented once i've finished writing the manual
17:23
<
azonenberg >
The bug, though, is that it allows you to pick illegal inputs
17:23
<
azonenberg >
I have input validation logic that should prevent you from passing anything but what it expects
17:23
<
azonenberg >
clearly, it's not perfect :p
17:24
<
bvernoux >
yes the waterfall work fine on a FFT
17:24
<
azonenberg >
Ok great so its just an input validation problem
17:27
<
bvernoux >
never heard of I3C ;)
17:28
<
bvernoux >
it is the successor of I2C ;)
17:28
<
azonenberg >
it's some weird mipi thing
17:28
<
azonenberg >
i've never seen it in the wild
17:28
<
azonenberg >
But i generally file a ticket for a protocol once i become aware that other scopes can decode it because clearly someone is using it
17:28
<
bvernoux >
yes funny
17:28
<
azonenberg >
then actually work on it once i get my hands on a device that implements it
17:28
<
d1b2 >
<TiltMeSenpai> there's supposedly a couple Lattice FPGA's that support config over i3c
17:29
<
bvernoux >
you shall add eMMC ;)
17:29
<
bvernoux >
hydrabus fw support it now ;)
17:29
<
azonenberg >
I have emmc support already
17:29
<
bvernoux >
ha really ?
17:29
<
azonenberg >
it's the same as SD Card bus, just with a few different configs
17:29
<
bvernoux >
1bits, 4bits 8bits ?
17:29
<
azonenberg >
So far only the 4 bit SD bus i believe
17:30
<
bvernoux >
how do you compute the horizontal scale ?
17:30
<
bvernoux >
for a scope
17:30
<
bvernoux >
as it is always wrong with mso5k
17:31
<
bvernoux >
I have 200us/div and there is always 10div on mso5k
17:31
<
azonenberg >
Read the driver code. Internally i calculate ps per sample and then use that
17:31
<
azonenberg >
the display scale is variable and decoupled from the scope config
17:31
<
bvernoux >
ha ok so it is the ps per sample which is wrong
17:32
<
azonenberg >
sorry fs not ps
17:33
<
bvernoux >
fs_per_sample
17:34
<
bvernoux >
I do not understand the vertical scale
17:34
<
bvernoux >
as I have no point in negative
17:34
<
bvernoux >
and it is scaled to -6.0485
17:35
<
bvernoux >
maybe some wrong data during capture ?
17:35
<
bvernoux >
as it is scaled automatically depending on live data (min/max) ?
17:36
<
azonenberg >
it should not be auto scaled
17:36
<
azonenberg >
vertical scale should be based on querying the scope for adc full scale range in some way
17:36
<
bvernoux >
ha ok so part is also wrong
17:36
<
azonenberg >
the vertical display scale should always be synced to the adc range so you cannot clip samples off scale
17:37
<
bvernoux >
as both horizontal timebase is wrong and vertical scale too
17:37
<
bvernoux >
I suspect it use code frol OLD_DS ... which is not good for mso5k
17:38
<
bvernoux >
the formula float v = (static_cast<float>(temp_buf[j]) - ydelta) * yincrement;
17:38
<
bvernoux >
is definitely wrong for mso5k
17:38
<
bvernoux >
I shall check what is the correct ones ;)
17:39
<
bvernoux >
it shall take attenuation into account IIRC
17:39
<
bvernoux >
it is crazy no one report anything on mso5k
17:39
<
bvernoux >
as there is tons of guys which have it ;)
17:40
<
bvernoux >
more than guys with high end Lecroy ;)
17:42
<
azonenberg >
No idea
17:42
<
azonenberg >
all i can say is i only fix the bugs people tell me about
18:07
<
bvernoux >
I have just received my STM32F1xxx with LQFP48 socket programmer ;)
18:07
<
bvernoux >
very nice
18:08
<
bvernoux >
it work like a charm with a GD32F103 provided in LQFP48 in the socket
18:08
<
bvernoux >
it is a project to hack the NanoVNA 2Plus4 to replace the MCU by latest STM32LP4
18:09
<
bvernoux >
which is pin compatible LQFP48
19:13
m4ssi has joined #scopehal
19:30
_whitelogger has joined #scopehal
20:34
<
azonenberg >
I really need to build myself a diff probe. But I want to get the single-ended versions fully debugged first
20:46
<
bvernoux >
the orange shall be better
20:46
<
bvernoux >
the pink have a so long ground
20:46
<
bvernoux >
I imagine the mess ...
20:46
<
bvernoux >
it is not a ground it look like an antenna ;)
20:47
<
bvernoux >
if it is differential probe such long ground shall be not too problematic
20:53
<
azonenberg >
They're both differential
20:54
<
azonenberg >
they probably have an inductor or choke in the ground to keep RF from going through it, in fact
20:54
<
azonenberg >
it's just to keep the common mode of the scope and DUT at about the same level
22:02
lukego has quit [*.net *.split]
22:31
lukego has joined #scopehal
22:38
m4ssi has quit [Remote host closed the connection]
22:43
bvernoux has quit [Quit: Leaving]
22:46
<
azonenberg >
ok, fixed those crashes