On Fri, Feb 27, 2015 at 11:54:46AM +0100, Bartosz Golaszewski wrote: > 2015-02-26 22:09 GMT+01:00 Aurelien Jacobs <au...@gnuage.org>: > > On Wed, Feb 11, 2015 at 04:20:42PM +0100, Bartosz Golaszewski wrote: > >> Add a parameter to csv output module, which allows to specify the type > >> of data fed to it. By default the module assumes it receives logic data > >> for backwards compatibility. > >> > >> Signed-off-by: Bartosz Golaszewski <bgolaszew...@baylibre.com> > >> --- > >> Initially I thought it would be possible to work with both data types > >> simultaneously, > > > > I also do think that it should be possible. > > > >> but since logic and analog packets can arrive at different > >> times and contain different number of samples it's not very feasible. > > > > Well, even if you limit yourself to ananlog only, packets from different > > channels can also arrive at different time and even different rate, so > > not mixing logic/analog do not solve this issue... > > > > You should always assume that each packet is at a different time (and > > hence a different CSV line), except for packets which are groupped in > > between SR_DF_FRAME_BEGIN/SR_DF_FRAME_END (all the packets inside a > > frame are supposed to start at the same time). > > This means you will often have only one column filled per line, but > > that's to be expected I think. > > > > Moreover, to make those CSV files really usable, at some point we will > > need to add a timestamp for each sample (some devices may output samples > > at very irregular point in time, even on a single channel). > > On the other hand for the CSV files to be usable, they have to be well > defined.
Yes, that's for sure. > We should be able to attribute given samples to their > corresponding channels, right? Definitely. > I don't know if that's what you mean, > but a file looking like: > > 1.2,4.3,6.5 > 3.4 > 3.6,3.1,7.8,9.8 > 3.2,6.5 > > isn't especially easy to interpret. Unless we'd have lines > representing channels and columns representing samples. I'm not sure what you are trying to say here... Here is an example of what I have in mind, including column titles: Timestamp,CH1,CH2,CH3 00:00,4.99,0.102,6.5 00:05,4.98,,6.5 00:10,5.01,0.99,6.5 00:12,,,6.5 So you don't need to have a sample for every channel at every timestamp. And you can add logic samples into the mix without issue I think. The only difficulty would be to associate a precise timestamp to each sample. I think libsigrok is missing such a capability for now. But you can still implement CSV output this way just omitting the timestamp. It would still be useful as long as the channels you are storing produce data at a constant and consistent frequency. Here are two examples of sigrok session data and the corresponding CSV I would output: Exemple session: ANALOG_PACKET: CH1=4.99 ANALOG_PACKET: CH2=0.102 ANALOG_PACKET: CH1=5.02 ANALOG_PACKET: CH2=0.99 Corresponding CSV: CH1,CH2 4.99, ,0.102 5.02, ,0.99 Another exemple session: FRAME_BEGIN ANALOG_PACKET: CH1=4.99 ANALOG_PACKET: CH2=0.102 FRAME_END FRAME_BEGIN ANALOG_PACKET: CH1=5.02 ANALOG_PACKET: CH2=0.99 FRAME_END Corresponding CSV: CH1,CH2 4.99,0.102 5.02,0.99 I hope those examples clarify my idea. Aurel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
