Closed mbrosnahan closed 3 months ago
Validation is here:
Not sure whether you want to reconfigure your CTD, change the code for the new configuration, or make the code smarter about detecting the configuration. The latter is non-trivial.
@mbrosnahan Your change in 3a60701 is not going to be enough to fix it because the length check needs to be 1 greater than the number of variables listed out below. (1 greater because the variable list does not include the timestamp which is extracted separately.)
The list is based on the output of the outputformat channelslist
command I think.
Ok. We've swapped instrument back and machine is working as expected. We'll tinker with the replacement instrument back in the lab and either change CTD config to conform to code or make new instrument-specific code before we swap back.
Smarter code or better documentation on how to read/update for alternate formats are needed. I'll tinker with output format channelslist
and report back.
There is still no support for automatically extracting the channels list, but this is now customizable as of dff912e379b17e495987fba2342abd0fc9d22511 by setting the channels
parameter to either a list of channels of the format like O2_concentration(umol/L)
or a concatenated string using |
as the separator, which is I think how output format channelslist
displays it.
Closing.
We had to swap out the RBR maestro unit deployed in Nauset (March 2024). New unit has 15 instead of 16 headers and order is somewhat different, causing bad data parsing and crash of related winch behavior (arm_chanos). Short term fix is to update hard-coded expectation for header list. How can we capture/review the headers of the new rbr data after serial to udp conversion by RPi?
Better solution here would be one that more flexibly receives and parses rbr data.