29c3
We're getting together at the annual CCC conference, 29c3, for a sigrok hackathon. In addition to the usual "whatever we feel like hacking on", we also have several architectural decision to make, and doing this in person is a lot easier.
If you want to be part of the conversation and decision-making process, show up!
What's decided here is what goes.
Precision/accuracy analog format
We have a real problem with analog values at the moment. A new format is needed. Some options are listed on the High precision analog page.
Timestamps
Some devices, such as dataloggers, actually log the time at which a measurement was made. This is not the current time — some of these cannot even stream live data — so the driver needs to submit these measurements to the session bus with an attached timestamp.
Chained packets
It may be interesting to link several packets together, and submit them to the session bus at the same time. For example, a timestamp + temperature measurement + relative humidity measurement submitted together would denote that these two measurements were taken at that specific point in time.
Samplerate: meta or DI?
Samplerate is a part of the SR_DF_META_LOGIC packet. However there is also a SR_DI_CUR_SAMPLERATE info type. Do we really need two?
Supporting devices/formats with more than 64 probes
We're currently limited to logic analyzers (and other devices) with a max. number of 64 probes. However, there are also devices with a lot more than just 64 probes. Independently of such hardware, we also want to support input/output file formats which can have > 64 probes and protocol decoders with > 64 probes.
This issue needs to be addressed in libsigrok and libsigrokdecode and in the frontends.
Better support for controlling devices
The current API focuses on getting samples (logic/digital or analog) from devices such as logic analyzers, multimeters, oscilloscopes, and so on.
For the upcoming support of more "control-oriented" device types such as power-supplies, function generators, GPIB interfaces, and others we'll need additional, generic API functions that allow specifying various controllable parameters, their types, allowed values, and so on.