User talk:Knarfs
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
Problems
Suggestions
Repository Sync
One sync workflow per repository
Pros
- One permission change (additional write access) per repository for the GITHUB_TOKEN. As secure as the Github repositories themself.
- Permission/Token doesn't expire.
Cons
- Each repository must be pushed manually to Github for the sync to work.
- Repositories are "polluted" with a sync workflow and will be executed when the build workflows are activated in a cloned repository.
- Change of configuration must be done in each repository (e.g. change to the cron configuration)
One sync repository to sync them all
Pros
- Easy to initialize and to manage: Just push the new sync repository to Github
- Possible enhancement: Store the hash of the heads for the sigrok.org repositories into the sync repository to minimize transfer volume (each sync clones the sigrok.org repositories)
- sigrok.org and Github sync repo will diverge!
- No side effect on cloned repositories (minimizes transfer volume tn sigrok.org)
Cons
- Uses SSH public/private keys (private key must be stored on Github for each Github destination repository, public key must be stored on Github for the sync repository). As secure as the Github repositories themself.
- SSH keys may have an expiration date and must be renewed every now and then
Open questions
- cron configuration: every hour or 2x/4x a day? Transfer volume to sigrok.org!