Hi Jason, > I gave this a shot, but something went wrong (Pulseview gives a > "generic / unspecified" error when I try to open up the resulting zip > file).
libsigrok complains: session-file: Not a sigrok session file: no version found. This is because the "out" folder is used within the .sr file, which libsigrok doesn't expect. Once I moved the files to the top level, the session could be loaded. > I threw together a quick python script to mux the binary files. I > think I got it right -- the resulting logic-1-1 file is exactly twice > the size of the two source files. I've attached the two source srzip > files and the resulting output srzip file. > > So I'm guessing I made some sort of mistake in the metadata file. > I've attached that as a text file as well. Yes and no :) Yes, because the unitsize needs to be 2 instead of 1 and the Dx from the second file would ideally be renamed to something else, e.g. Xx or whatever. Otherwise, D3, D4, D5, D6 and D7 appear twice. Since you're using a script, it would be easy to rename D0..D7 to DIO0..7 while you're at it. This way, the GPIB decoder will use them automatically and you don't have to manually assign them every time. Also, it's not really your mistake because I forgot to mention that the unit size needs adjustment. Somehow I thought it would auto- calculate it but I was wrong :) > Maybe there is a way I can make Pulseview spit out some debugging > info or a more detailed error? That would be achieved by running "pulseview -l 5". Looking at the resulting file I noticed a more serious issue that can still be fixed but it's a little less trivial: there is a 266us shift between the data of both devices. It makes perfect sense really but it's still an issue regardless. I was hoping the difference would be too small to be noticeable but we are talking fast (for humans) signals here, so even tiny delays are becoming noticeably quickly. The quick solution to this is chopping off the first 266 samples of logic-1 in B.sr and chopping off the final 266 samples of logic-1 in A.sr, keeping the overall length the same while fixing the time offset. However, the number will need adjustment if you change the sample rate and I don't know if the number varies a lot between acquisition runs. Worst case, you'd have to do two adjustment runs: Acquire A/B -> merge to 16-channel file -> measure offset -> fix offset I think it would be nice to make your tool more flexible and maybe add it to our sigrok-util repo. Your tool could a) use probe names from a supplied text file (very flexible but still allows probe renaming) b) auto-adjust the time offset by simply going through the data and looking for data != 0, counting the number of samples up to that point. Then, the difference between the counters for the two input files is the offset, by which it can truncate the data for A and prepend the data for B. Wouldn't work in all scenarios of course but for yours (and a lot of others), this would be simple and yet correct. This way, you'd do both adjustments in a single run of the tool. What do you think? I attached the working file (muxed.sr) and one with the offset manually removed using the method I described (out.sr). Regards, -Soeren > > Thanks, > Jason > >
muxed.sr
Description: Zip archive
out.sr
Description: Zip archive
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
