The recently introduced support for a "timestamp" column type in the CSV input
module does not _control_ how the input data gets processed, instead it's only
used for information, as a fallback approach to somehow get the input samplerate
when the user did not specify one.
It might be desirable to use the timestamp column (when specified) as a means
to repeatedly feed the most recent set of samples to the session when the
timestamp difference suggests that more time has passed than one step in the
This could be low hanging fruit for somebody with a personal interest in seeing
this feature supported in mainline. :) The source is in src/input/csv.c. The
process_buffer() routine's queue_*_samples() calls need to get repeated when
the parse_timestamp() routine determined how many sample sets to feed for the
current line of CSV input.
*** Bug 1620 has been marked as a duplicate of this bug. ***
See bug 1625 for more information on internal constraints. Automatic
samplerate detection from incompletely received input data may not be
possible at all. And the submission of "missing" sample points' values
which were omitted during generation of the input file will depend on
having _some_ samplerate available right from the start of processing
any of the input data. So the need to specify the samplerate remains
for those situations where the input data is not suitable for the task.
(In reply to Gerhard Sittig from comment #2)
> See bug 1625 for more information on internal constraints. Automatic
> samplerate detection from incompletely received input data may not be
> possible at all. And the submission of "missing" sample points' values
> which were omitted during generation of the input file will depend on
> having _some_ samplerate available right from the start of processing
> any of the input data. So the need to specify the samplerate remains
> for those situations where the input data is not suitable for the task.
Would it be feasible to pre-process the CSV to calculate the smallest gap between timestamps, and use that as the samplerate? Even if that was not the true samplerate of the captured data, would that value be sufficient for display?
The file format supporting input module receives the data in a strict linear
sequence. It cannot seek, and shall not. Being able to work in a pipeline
is an important feature that must not be broken without necessity. The only
exceptions in the current code base are those formats which don't lend
themselves to sequential processing in the first place (ZIP files, header
information kept in foot sections, or similar constraints).
The libsigrok using applications should not bother implementing specific
hacks or assuming specific properties of individual file formats. They
should just feed the input data to the library as is, and not interpret
the content in any way. Doing so violates API layers, introduces additional
complexity and redundancy, and burdens maintenance.
The current implementation of CSV input just expects to see a continuous
stream of sample data. It's easy enough to provide that. The timestamp
column is an optional feature, and support for its automatic processing
is limited as is stated above.
If you consider removing that limitation you are welcome to do that as is
outlined above. Though you need to have a samplerate for that (as was also
mentioned above). If the input data doesn't provide the rate, specify it.
It's easy enough to have that information when you are the creator of the
input data. It's of limited use to process the input data without knowing
the capture's most essential properties.
You can always do such pre-processing outside of sigrok applications if you
want to automatically determine a file's properties, or convert not supported
cases to supported types of input. Or pick a better match for your specific
needs from the set of supported input formats.
*** Bug 1652 has been marked as a duplicate of this bug. ***
So if I'm understand correct, all import from .csv will consider the same time between each line? it will not consider the time passed between each line. Am I understanding correct? strange is the it take the time between line 2 and line 3 (disconsidering the header) and use for all others. So if I have a PWM imported will always presented as 50% duty, independent of the time between lines, Am I understanding correct?