Reviewable example of refactoring for testing: Li710 Driver

[zradlicz]

Overview

The intention of these changes are to provide a reviewable example of dependency injection for unit testing of a specific driver, in this case Li710.

Eventually, the Kestrel driver will have each of its dependencies abstracted out in a similar way.

I am looking for feedback on this architecture decision, and the best way to implement it moving forward.

The reason Li710 was chosen to be merged first is because there were ongoing issues with the power draw and the quality of data from this device.

Fixes

Through testing, these bugs were discovered and fixed:

Issue

• The measurement method was continuous measurements as described in the SDI12 standard. After clarifying with a LiCor Application Scientist, it was confirmed that LiCor themselves have never used or tested this method of data collection from the device, although it may be supported.

Fix

• I switched to using regular M commands, which is what has been verified by the Application Scientist as the correct way to use the device.

Issue

• The method of collecting DATA_QC, which correlates to the quality of the computed data from the device, was happening at a separate time from the collection of the data. I believe this may have led to a mismatch between what the DATA_QC value was representing.

Fix

• To fix this I changed the getMetadata() function in the Li710 driver to use data that was collected from the getData() function. This means all data is grabbed from the device at the same time, ensuring there is no mismatch in what data the QC value is corresponding to. I also added DATA_QC directly to the DATA packet reporting instead of just in the Metadata reporting. This will make it easier for users of the data to verify the data is good.

General Architecture Plan

Other

I will have to complete PRs in individual submodules first (Li710, Sensor, etc) before completing this one