Bug 1625 - no automatic timestamp handling, no support for gaps in the timestamps sequence
Summary: no automatic timestamp handling, no support for gaps in the timestamps sequence
Status: CONFIRMED
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Input: csv (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-17 11:51 CEST by Gerhard Sittig
Modified: 2020-10-17 11:51 CEST (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Sittig 2020-10-17 11:51:44 CEST
An implementation detail of common libsigrok infrastructure requires input 
modules to provide sample data for all sample points which result from a 
given samplerate (specified by the user, or derived from input data). The 
'timestamp' column type is just a hint in the current input/csv version, 
see bug 1500 for details.

The limitation that all timestamps must match the samplerate's resolution is 
independent from the optional support for gaps in the timestamp sequence. The 
latter is actually blocked by the former, automatic submission of "missing" 
(unchanged) samples is only possible when the rate is known, and the rate 
cannot get determined from the first input data of a CSV file, and the input 
module cannot seek and thus cannot scan the total amount of input data before 
first data gets processed and submitted to the session feed. See bug 1624 for 
a similar report on VCD import.

The only workaround to unbreak CSV import of "incomplete" data is to process 
the file with an external tool, and provide an input file to sigrok where each 
row corresponds to a sample point and none of the samplerate's intervals is 
missing. The proper solution is to support a continuous time scale and not 
depend on the samplerate so strict as the current common infrastructure does. 
This is one of the project's long term goals.

This user provided file content illustrates the problem which the input 
module cannot resolve by itself. Neither of the input values allows the 
reliable detection of the capture's time resolution and thus samplerate. 
The number of lines used during "lookahead" does not matter, the samplerate 
remains unknown until the EOF was seen, and even then is only a guess 
(could be higher as well, and the input signals just happened to change 
not so often as samples were taken).

  Time[s], Ch2, Ch3, Ch4, Ch5, Ch6, Ch7
  0.000000000000000, 0, 0, 0, 0, 0, 0
  1.616108640000000, 0, 0, 0, 0, 1, 0
  1.616109120000000, 1, 0, 0, 0, 1, 0