Closed ZhangYao1369 closed 2 years ago
Hello Yao, I'll look into it in the course of this week.
Thanks. The data in zip file is a small piece from original data. The nbr_of_scansbytes_per_scan is not equal to the length of byte_stream in the original data. I tried the data file in zip file, the nbr_of_scansbytes_per_scan is equal to the length of byte_stream. However, there ara some NaN value after typecast at line 79. I set them to 0, but the final timedata value is not correct
After looking into your file I've come to some conclusions and a working solution. The Can signals that are decoded are sampled at a lower frequency than the audio signal and the raw can stream. This can be verified in the artemis suite where the sampling frequency for the decoded can signals is given at 1500 Hz. For a signal of this length this is the exact nbr_of_scans, after that the file itself only contains zeros in the place of the bits for the decoded signals. When exporting from the Artemis suite to .mat there is an implicit interpolation / oversampling to give out all values at the same apparent sampling rate. This can be verified with the test_inca.mat that I included in the repository. I personally feel that interpolation and oversampling should be up the end user to decide so I have not included it into the conversion process, instead you will get a timeData struct that is separated by the type of data it contains, e.g. 'Audio_Decoded', 'ControlSignal_Decoded' and 'Codec_CAN_24_Headlab_1'.
There is a problem when I import a HDF file. There are some signal channel from INCA in the HDF file. The nbr_of_scans* bytes_per_scan is not equal to the length of byte_stream. I try to supplement zeros, but the final time data value is not right. Could you help me fix it, thanks! 220315_hb_01_Geely_DCT260_Abnormal noise_1G_LOT_001 19.15 - 23.56s.hdf.zip