Creating a duration loses nanosecond precision

Hi- I have the signal output of an electronic device, voltage, with respect to time, nanoseconds. I would like to get it into a timetable so that I can use signal processing toolbox functions. The problem is, I am losing precision in the time values when making it into a time table. When this happens, I get duplicate time values with unique voltage values. I have attached a sample csv with data and pasted my code below.

A=readmatrix('D60ALT_MLF.csv');

time=(A(:,1)); %nanoseconds
volts=(A(:,2)); %millivolts

%makes a duration, but has the wrong units 
time_sec=seconds(time);  

%this one has the right units, but I lost precision
time_sec2=seconds(time)/(10^9); 

%loss of precision results in repeated times with unique voltage values
%when I assemble the timetable. Signal processing toolbox gets upset.
TT_demo=array2timetable(volts,"RowTimes",time_sec2);

%how do I get time into a "duration" datatype, without losing precision?

[dpb]

We had a long discussion on the subject just a couple weeks or so ago...see https://www.mathworks.com/matlabcentral/answers/1584579-how-to-preserve-nanosecond-precision-in-datetime-calculations-for-large-numbers#answer_829579 for how to avoid.

What you've got to do, basically, is to not convert to double() at a point you don't still have full precision as Steven illustrates.

[mura0087]

Thanks. I did not understand the other discussion very well, but it seems that there is not a straightforward way around this- I don't have the symbolic toolbox. I'll probably keep my data in arrays- which are compatible with most functions I'm interested in anyway. Timetables seem much less flexible

[dpb]

Your problem is that your data file loses precision, not with a duration...

....
99981442983,2797,0
99981449233,2836,0
1.00E+11,2788,0
1.00E+11,2773,0
1.00E+11,2812,0
1.00E+11,2788,0
...

Unless you saved the original data in another format, you've lost the time detail. The above is at record 19,228 out of 154,195 total records.

But, if you have the raw data still, or can regenerate it, the timestamp variable is sufficiently small to be able to be represented in a double which has ~15 decimal digits so you shouldn't have any trouble with duration and a timetable.

The other thread got into trouble because was trying to put an absolute time together that include the actual date and time and hold the nanosecond precision. That failed owing to internals in the datetime implementation that converted to double internally which, for the given case, did not have sufficient precision.

Your problem (at least in the attached file) is that the csv file was written without specifying the precision for all values and when passed E10, it reverted to a default short form to save disk space. That's a little rude, but is documented behavior; to save full precision a text file isn't that great a choice to begin with.

ttmura=readtable('D60ALT_MLF.csv','ReadVariableNames',1);
ttmura.TIMESTAMP=seconds(ttmura.TIMESTAMP/1E9);
ttmura=table2timetable(ttmura,"RowTimes","TIMESTAMP");
>> [head(ttmura); tail(ttmura)]
ans =
  16×2 timetable
      TIMESTAMP       CH1     CH2
    ______________    ____    ___
    0.00086047 sec    2827     0 
    0.0075338 sec     2836     0 
    0.0075461 sec     2768     0 
    0.039702 sec      2792     0 
    0.039716 sec      2753     0 
    0.039718 sec      2783     0 
    0.03972 sec       2846     0 
    0.040655 sec      2827     0 
    801 sec           2705     0 
    801 sec           2744     0 
    801 sec           2705     0 
    801 sec           2695     0 
    801 sec           2661     0 
    801 sec           2744     0 
    801 sec           2690     0 
    801 sec           2695     0 
>> 

The timestep doesn't seem to be at all uniform at the beginning of the file...

>> tmp=head(ttmura); diff(tmp.TIMESTAMP)
ans = 
  7×1 duration array
    0.0066733 sec
   1.2344e-05 sec
     0.032156 sec
    1.375e-05 sec
      2.5e-06 sec
    2.187e-06 sec
   0.00093443 sec
>>   

[mura0087]

Thank you! This explains it, I found out the file was opened and saved as in Microsoft excel before I got my hands on it.