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.

• libsigrok defines SR_MAX_NUM_PROBES to 64. This limit shouldn't exist at all. Uses in libsigrok:
  • input/vcd
  • output/gnuplot
  • output/text
  • output/chronovu_la8
  • output/csv
  • output/vcd

These uses mostly come down to static arrays, which can be made dynamic.

• pulseview has an assert that uses it. Is this due to a uint64_t used to store sample values?
• sigrok-cli uses it in an array, which can be made dynamic.

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.

New sigrok file format

The current .sr file format is a ZIP file containing multiple files (some metadata files and actual sampling data files). This works fine, but it also has some issues:

• In order to get to the data you want, you need to decompress the whole file.
• Appending to a file is not possible easily (and it's not efficient).
• ...

Wish list for the new file format:

• It should be able to store metadata and arbitrary data (logic samples, and/or analog samples, and so on).
• It must support compression.
• It should be able to handle run-time changes in the data streams (via meta packets on the session bus), e.g. changing samplerates, changing probes, etc. etc.
• Better compression properties (e.g. using LZO or other algorithms, this is to be evaluated). What we ideally want out of the compression algorithm is:
  • Good and relatively fast compression results at only moderate CPU usage.
  • Very fast decompression (LZO is probably the best one here, as it's specifically designed for this).
  • Ideally, support for appending further data to already compressed data chunks (though this could be also implemented outside of the compression algorithm per se).
  • Open-source license and OS portability. There should be an open-source library or code chunk for compression/uncompression and it should be widely available in Linux distros, and portable to Windows, Mac OS X, FreeBSD, and so on.
• Independent of hardware architecture (x86, ARM, PowerPC, MIPS, and so on), OS, endianness, float representation, and so on. All data fields must be properly specified (endianness, signedness, size, format).

We were planning a new file format and a full spec for it for other reasons already, but this will probably be obsolete anyway and solved differently (see above).

libusbtmc

• Properly understand what's there now
• Sketch out the general shape of things to come and at least the API for basic functionality
• Stubs for all public API functions
• Define complete structs for all USBTMC packet types

Scanning hints

• conn: HWOPT_CONN_[USB|SERIAL]_[OPTL|REQD] ?
• serialcomm OK?
• spec formats