When doing a CSV import, the time column is not processed. The csv file producing this bug is attached.
Hi, there's no attachment. Can you please check?
(In reply to Soeren Apel from comment #1) > Hi, there's no attachment. Can you please check? Ah, it seems that the file was too large to attach. I'll truncate it and try again.
Created attachment 688 [details] CSV file which produces this bug
Note: I am using the GUI to produce this bug, pulseview v0.4.2 (64bit, windows)
Please try with a current nightly or AppImage.
*** This bug has been marked as a duplicate of bug 1500 ***
(In reply to Soeren Apel from comment #5) > Please try with a current nightly or AppImage. I tried again with the nightly build currently on the downloads page and I get the same problem. Here is a paste of the version numbers from the "About" page: Versions, libraries and features: PulseView 0.5.0-git-d8cdab7 Qt 5.7.1 glibmm 2.42.0 Boost 1_60 exprtk 20200101 libsigrok 0.6.0-git-a3fe36d/4:0:0 (rt: 0.6.0-git-a3fe36d/4:0:0) - glib 2.44.1 (rt: 2.44.1/4401:1) - libzip 1.5.2 - libserialport 0.1.1/1:0:1 (rt: 0.1.1/1:0:1) - libusb-1.0 1.0.20.11003-rc3 API 0x01000104 - hidapi 0.8.0-rc1 - libftdi 1.4 - Host x86_64-w64-mingw32.static.posix, little-endian - SCPI backends TCP, serial, USBTMC libsigrokdecode 0.6.0-git-f96f633/4:0:0 (rt: 0.6.0-git-f96f633/4:0:0) - glib 2.44.1 (rt: 2.44.1/4401:1) - Python .4.4 / 0x30404f0 (API 1013, ABI 3) - Host x86_64-w64-mingw32.static.posix, little-endian
okay, so what's your understanding of "properly importing" the time column? If it means that the samples should reflect the time associated with each sample in the CSV then that would require additional work in the CSV input module as the time is currently not used for this.
(In reply to Soeren Apel from comment #8) > okay, so what's your understanding of "properly importing" the time column? > > If it means that the samples should reflect the time associated with each > sample in the CSV then that would require additional work in the CSV input > module as the time is currently not used for this. Yes, that I what I was expecting; that the value in the CSV would place the sample on the timeline at that point. I was searching for documentation about the expected format of the timestamp column and came up short, so I assumed that the behavior was going to be what most people probably expect - that the timestamp in the CSV would govern the location of the sample. I see that this has been marked a duplicate of bug 1500; the description of that bug is exactly what I would have expected to happen. Just so you can get some insight into my use case: I have a logic analyzer that is not supported by Sigrok (KingST MIPI16, I think its a Saleae knockoff), but I wanted write a protocol decoding plugin for a SPI device I am working with. So I am capturing samples with my logic analyzer, exporting them as CSV, and importing them into PulseView so I can run my custom decoder plugin. By the way, Kudos on the ability to have custom decoder plugins, and the ability for them to stack on top of each other - its a feature I have been trying to find for years so I was very excited when I discovered Sigrok!