I am running into an issue with the number of samples written to the .mat file. When I load a .psdata file into PicoScope6, PicoScope6 indicates the number of samples. If I save the waveform in a .csv file I get a few more (4) than PicoScope6 says, but all samples seem to be real. If I save the waveform to a .mat file I get quite a few more samples and the extra samples (in excess of those in the .csv file) are all zeros. This seems to be a bug. When I load the .mat file in matlab, the "A" array has the extra samples and the "Length" variable indicates the larger size.
For example
Picoscope6 - No.Samples: 55,557
.csv file - No. Samples: 55,561
.mat file - No. Samples: 59, 641 with all values zero above index 55,561
I am using 6.8.6.9, but had the same issue with earlier versions. I just switched to this version to see if the problem was already corrected in this lastest version.
just came across this bug from another direction. I normally save my 2 channels worth of data to psdata file format and subsequently transform it to a mat file format for onward processing. Usually my 2 channels of data is collected using the single trigger mode, so I collect one full buffer memory of data. This gives me no problems in the psdata to mat conversion. But I have just recently saved an incomplete buffer memory of data. The conversion gives me a mat file with no second channel's worth of data. I am using ver 6.8.11.20 but first found it on 6.6.50. HTH
The file is too large to attach so I will send it.
I presume when you say "The workaround is to load in only channel A into MATLAB, and then export only channel B to .mat file." you are not referring to using the Picosoft 'save as' function. Our process is having recorded the data and saved it as a psdat file, to then using coding in MathCad, open the psdata file with Picosoft, then use the save as function matlab option to save the data in .mat format and then open the .mat file in MathCad. Recording a complete sheet / memory using the single trigger option seems to avoid the bug. I also see if I record more than one sheet then bug also appears
Ah, I had not appreciated that channel hide had that power. I must save data before looking at it to avoid that problem / benefit. Thanks for the info.
has this bug been dealt with yet? I still seem to have the same problem in v6.10.11.15. It would be nice to work directly rather than having to separately record and then stitch back together the data.
It looks as though the bug has not been fixed. Could you please send a psdata file to support@picotech.com and I can test it here and notify our Development Team accordingly.
Update: File has been received via our Support e-mail system (thanks ). The file can be exported and loaded into MATLAB. It looks as though the incorrect length is specified for Channel A (as the trace stopped before the end of the time axis) so please use the Length parameter to extract the correct portion of data.
The simple work around is to always use the trigger function in single shot mode so the data ends at end of screen. That way the conversion from .psdata to .mat works and we can read all channels OK.
However from time to time, we like to use PicoSoft in continuous display mode which gives rise to our problem. Our setup uses MathCad software and the .mat file as a convenient way of transferring the data into MathCad. Unfortunately it appears MathCad is sensitive to errors in the .mat file which the MatLab software apparently can cope with. Our reading of error messages indicates that Channel B data was corrupted by not ending properly and Ch A data is OK.
I am using 6.13.6 and save measurement in matlab-format. MAT-file is generated and arrays with proper size are present, but all values starting at a (un)specific are 0..