<d1b2>
<bvernoux> The problem is MSO5K bin files are sometimes buggy depending on how many channels especially if LA is used it was a total nightmare and IIRC Rigol Dev Team have never fixed that ...
<d1b2>
<bvernoux> I have discussed about that with Rigol Support & Dev Team and at the end they told me on Tue, May 31, 2022, 12:37 PM (the discussion with Rigol Support "Rigol MSO5000 SCPI interface" started on Sat, Feb 13, 2021, 1:01 PM): "Well, to be honest, our R&D currently has to delay it due to some other big projects. Since the data transmission speed is not in the specification, we would like to describe the issue as a requirement. Therefore, it
<d1b2>
is a pity to tell you that we are not able to realize it in the next a couple of months. Although I can not provide you the exact date when the issue would be improved, the R&D will deal with it at end of this year. I will keep touch with you on the issue. " My last word to Rigol Support & Dev Team was on Jun 8, 2022, 10:17 AM (without any answer) "My feeling about Rigol MSO5K is it is an amazing scope the best price for performance but it is a Raw
<d1b2>
Diamond and the Firmware is clearly not good enough and like abandonned since years now (latest update was in 2021/10/18 v00.01.03.00.03) I clearly think Rigol shall do more work on firmware side. I will potentially publish things about the fact Rigol R&D is not cooperative and they do not support well their oscilloscope which is found in lot of forum as a major bad point (even Siglent better support their scope with better firmware). On my side I'm
<d1b2>
very disppointed by Rigol R&D and I will buy more "serious" Oscilloscope (like Tek MSO64B) with better support and better performance for my company needs."
<d1b2>
<azonenberg> Fuuuun
<d1b2>
<azonenberg> do you think its possible to patch up buggy rigol files, perhaps via some non default parameters?
<d1b2>
<azonenberg> or is it generally pretty hopeless
<d1b2>
<bvernoux> I have some notes somewhere where I tried that ... but it was pretty impossible with missing parameter ...
<d1b2>
<azonenberg> We can add things like an override for sample rate that is used in the case of garbage data in the file
<d1b2>
<bvernoux> Yes I think it is the best we can do but for some missing things or wrong one I doubt we can do miracle ...
<d1b2>
<azonenberg> Yeah
<d1b2>
<azonenberg> Backing up a bit, i want to develop a better UX for filters to report problems to the end user
<d1b2>
<azonenberg> right now we just log errors to stdout which isnt the best
<d1b2>
<azonenberg> But now is not the time for that, that's a post v0.1 thing
RedMoss has quit [Ping timeout: 260 seconds]
<d1b2>
<xfol_> I've been looking at some other exports from this scope and found most of the fields are constant. A recording of 100MS @ 100MS/s still reports the same file size, duration, interval, etc. 😆
<d1b2>
<xfol_> I've been attempting this in a hex editor just to make the measurements I need to evaluate.
<d1b2>
<xfol_> Is the Windows build broken? I pulled latest master and submodules and now see FAILED: lib/scopehal/CMakeFiles/scopehal.dir/CANChannel.cpp.obj
<d1b2>
<xfol_> C:/msys64/ucrt64/include/c++/14.2.0/bits/char_traits.h:427:56: error: 'void* builtin_memcpy(void , const void , long long unsigned int)' forming offset [32, 42] is out of the bounds [0, 32] of object '<anonymous>' with type 'std::cxx11::basic_string<char>' [-Werror=array-bounds=] 427 | return static_cast<char_type*>(builtin_memcpy(s1, s2, n));