Picoscope drivers more series-based and removal of convenience functions from 3403A

[pieterbuzing]

Description

The current PicoTech PicoScope drivers are based on two models: 3403 and 4824. The software has a lot of same base for both of these drivers, namely in the picosdk ps3000a and ps4000a packages and libraries. The only practical difference, up to now with our use of PicoScope functionalities, has limited into using the run_block command and translating the time-base into sampling interval. On top of this, for the 3403A model a convenience function to acquire data by trigger has been included (acquire_by_trigger_and_get_data). This involves a combined usage of the scope with selection of readout and trigger channels, their coupling types and expected input ranges, trigger level and time span with specific sampling range. This was useful for combining the driver with a picoscope GUI program, but the extent of logic in this functions, and its specific use, is outside of the scope for QMI drivers - these should offer only the basis of functions without logic or application-specific implementations.

When looking into the programmer's manuals of the 3000 series and 4000 series, it looks rather like the software is the same for some groups of models, so perhaps having ALL the drivers with specific model names are a bit too specific. We could divide the drivers according to time-base groups of the documentation as these will use the same time-base <-> sample interval conversions. The groups are:

• 2-channel USB 2.0 oscilloscopes of 3200A, 3200B series.
• 4-channel USB 2.0 oscilloscopes of 3400A, 3400B series.
• 2-AI 3200 series USB 2.0 Mixes-Signal Oscilloscopes (MSOs).
• 4-AI 3400 series USB 3.0 Mixes-Signal Oscilloscopes (MSOs).
• 2-channel USB 3.0 oscilloscopes of 3200D series.
• 4-channel USB 3.0 oscilloscopes of 3400D series.
• Picoscope 4000A series incl. 4824(A), 4224A, 4424A and excl. 4444 model.
• PicoScope 4444 model.

The goal of this ticket is to:

1. Move the convenience function (with internal function _get_time_base ) to either be directly in the application in Diamondos, or as an extension for Diamondos QMI instrument in lib/instruments/picotech/picoscope3403.py.
2. Rename the existing file names and classes to:
   - picoscope3403.py --> picoscope3400series.py and PicoTech_PicoScope3403 --> PicoTech_PicosScope3400D
   - picoscope4824.py --> picoscope4000series.py and PicoTech_Picoscope4824 --> PicoTech_PicoScope4000
3. Make new (files and?) classes, e.g. (consider if some classes are so similar that a base class or one merge class can be used):
   - PicoTech_PicoScope3200AB with NUM_CHANNELS = 2
   - PicoTech_PicoScope3400AB with NUM_CHANNELS = 4
   - PicoTech_PicoScope3200Mso with NUM_CHANNELS = 2
   - PicoTech_PicoScope3400Mso with NUM_CHANNELS = 4
   - PicoTech_PicoScope3200D with NUM_CHANNELS = 2
   - PicoTech_PicoScope4444 with NUM_CHANNELS = 4
4. Implement get_time_resolution for each(?) class and see if run_block needs an implementation for each class as well.
5. For MSO models, specific commands are available. Implement these in these drivers.
6. PicoScope 4444 has specific commands available. Implement these in the 4444 model driver.
7. The models in 4000A series have also different number of channels. Solve this perhaps with an extra optional input or make extra classes per NUM_CHANNELS?

Modules to be created

• qmi.instruments.picotech.picoscope3000series
• qmi.instruments.picotech.picoscope4000series
• ?

Modules to be modified

• qmi.instruments.picotech.__init__

Tests to be created/updated

• tests.instruments.picotech.test_picoscope3000series
• tests.instruments.picotech.test_picoscope4000series
• tests.instruments.picotech.test_picotech

Documentation to be updated

• CHANGELOG.md
• docstring so that API reference shows nicely in Sphinx/readthedocs.

Hardware

TBD.