[5pt,7pt] graph-prototype: Port and simplify picoscope implementations

[frankosterfeld]

The implementations for the different picoscope devices (3000a, 4000a, 5000, 6000) contain a lot of duplicated logic, only differing in the driver functions they call and the enums etc. they use. Check what of that can be simplified easily, where the differences are accidental and where they actually stem from different device functionality.

[RalphSteinhagen]

meeting minutes: main focus: stress commonality and modularise the differences between PS3000, PS4000, PS4000, PS6000

development against graph-prototype new branch in gr-digitizer

Linked to #116

[vimpostor]

Some useful bullet points from Matrix:

• Rationalise the existing implementation to also support PS[3000,4000,5000,6000] digitizer. There is a build/header-include component but also abstraction since all these models are very similar but not identical, we should check the integration of the meta-tag information via the incoming MsgPortIn onto the detected trigger (for testing we assume that there is some trigger edge and the MsgInPort supplied with some test meta-tags that not necessarily are derived from a timing source block) , and rationalise the output types to:
  • std::int16_t: the raw output of each digitizer channel w/o further pre-processing but with trigger tags and some meta information (e.g. signal_name, rate, etc.)
  • float: the physical gain-scaled output with tags and full meta-info (i.e. and signal name, quantity, unit, min, max, etc.)
  • gr::UncertainValue<float>: containing the above plus the estimated measurement error -- the new UncertainValue<> wasn't available yet with the initial implementation but we should simplify and use this from now on.