Difference between revisions of "User talk:Knarfs"
| Line 10: | Line 10: | ||
=== Scopes === | === Scopes === | ||
All | All sample data for scopes is related to a sample rate, so the time stride between the individual sample points can be calculated. None of the scopes is announcing their actual sample rate (SR_CONF_SAMPLERATE) via a SR_DF_META packet, but only by a config key (get/set/list). | ||
==== Frames ==== | ==== Frames ==== | ||
Most scopes use SR_FRAME for transmitting their buffer (display buffer, sample buffer or similar). | Most scopes use SR_FRAME for transmitting their buffer (display buffer, sample buffer or similar). | ||
Some scopes don't use frames and | Some scopes don't use frames and transmit a continuous stream of sample data (fxla, hantek-xxxx) (?) will this really be continuous | ||
=== Input formats === | === Input formats === | ||
This input formats use SR_CONF_SAMPLERATE via a SR_DF_META packet to | This input formats use SR_CONF_SAMPLERATE via a SR_DF_META packet to announce their sample rate: CSV, Raw Analog, Saleae and WAV. | ||
This input format doesn't | This input format doesn't announce a sample rate: Feed Queue. | ||
==== Frames ==== | ==== Frames ==== | ||
| Line 28: | Line 28: | ||
=== Measurement devices === | === Measurement devices === | ||
Measurement devices | Measurement devices normally (exceptions see below) don't have a sample rate, but even when it doesn't matter for the SR_ANALOG packet for live data. The individual drivers only receive one sample at a time and forward the samples via SR_ANALOG one by one. | ||
A sample rate must not be used, because the time stride between each sample can vary depending on various facts, e.g. the | A sample rate must not be used, because the time stride between each sample can vary depending on various facts, e.g. the connecting interface (USB, RS232, GPIB, etc.). | ||
(!) A timestamp is missing | (!) A timestamp is missing | ||
| Line 41: | Line 41: | ||
(?) Is the buffer send over and over when in acquisition mode | (?) Is the buffer send over and over when in acquisition mode | ||
(?) Is this data | (?) Is this data represented as a "normal" channel | ||
=== Problems === | === Problems === | ||
=== Suggestions === | === Suggestions === | ||
Revision as of 13:15, 7 February 2021
Understandig analog signals in sigrok
There are tree main use cases for analog signals in sigrok:
- Fast sample data for scopes
- Input file formats: CSV, Feed Queue, Raw Analog, Saleae and WAV
- Slow sample data for measurement devices like multimeters, power supplies, sound level meters and so on.
A minor use case for analog signals is buffered measurement data for a small number of devices: One multimeter (mooshimeter-dmm), one thermometer (lascar-el-usb) and one (or two) sound level meters (cem-dt-885x and maybe kecheng-kc-330b).
Scopes
All sample data for scopes is related to a sample rate, so the time stride between the individual sample points can be calculated. None of the scopes is announcing their actual sample rate (SR_CONF_SAMPLERATE) via a SR_DF_META packet, but only by a config key (get/set/list).
Frames
Most scopes use SR_FRAME for transmitting their buffer (display buffer, sample buffer or similar). Some scopes don't use frames and transmit a continuous stream of sample data (fxla, hantek-xxxx) (?) will this really be continuous
Input formats
This input formats use SR_CONF_SAMPLERATE via a SR_DF_META packet to announce their sample rate: CSV, Raw Analog, Saleae and WAV. This input format doesn't announce a sample rate: Feed Queue.
Frames
Non of the input formats is using frames.
Measurement devices
Measurement devices normally (exceptions see below) don't have a sample rate, but even when it doesn't matter for the SR_ANALOG packet for live data. The individual drivers only receive one sample at a time and forward the samples via SR_ANALOG one by one. A sample rate must not be used, because the time stride between each sample can vary depending on various facts, e.g. the connecting interface (USB, RS232, GPIB, etc.). (!) A timestamp is missing
Frames
When measurement devices transmit samples between a frame, this means that these sample points were received at the same time by the driver (reload pro).
Buffered data
This is a specific use case and rater unclear for me at the moment.
(?) Is the buffer send over and over when in acquisition mode (?) Is this data represented as a "normal" channel