search

nickrsan / seabird_ctd

Handles command, control, and data reading for stationary Seabird CTDs on fixed deployment
https://seabird-ctd.readthedocs.io
2 stars 0 forks source link

Problem parsing status for SBE37S - details inside #15

Closed nickrsan closed 7 years ago

nickrsan commented 7 years ago

Original report by Nicholas Santos (Bitbucket: nickrsan, GitHub: nickrsan).

Receives this error message:

#!python

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Code\virtualenvs\server_virtualenv\lib\site-packages\seabird_ctd\__init__.py", line 188, in __init__
    self.status()  # will fill some fields in so we know what sample it's on, etc
  File "C:\Code\virtualenvs\server_virtualenv\lib\site-packages\seabird_ctd\__init__.py", line 313, in status
    status_parts = self.command_object.parse_status(status)
  File "C:\Code\virtualenvs\server_virtualenv\lib\site-packages\seabird_ctd\__init__.py", line 64, in parse_status
    return_dict["serial_number"] = status_message[1].split(" ")[4]
IndexError: list index out of range

Here's the output of DS on the device:


DS
SBE37SM-RS232 v4.1  SERIAL NO. 16125  30 Oct 2017 08:12:54
vMain = 18.75, vLith =  2.84
samplenumber = 16, free = 559224
not logging, stop command
sample interval = 15 seconds
data format = raw Decimal
output salinity
transmit real-time = yes
sync mode = no
pump installed = yes, minimum conductivity frequency = 3000.0
<Executed/>
nickrsan commented 7 years ago

Original comment by Nicholas Santos (Bitbucket: nickrsan, GitHub: nickrsan).

Added some better error handling as part of the diagnosis of this. Looks like it's a race condition related to the new, faster way of reading data. At 4800 baud, at least, it seems to decide it's done reading before it really is - I'm guessing because data is still coming across the pipe, but hasn't come in yet. I assumed that the overhead of the loop would be more than enough for each additional character to come in, but apparently not. Going to investigate slowing this down, but just enough to ensure reliable reads. Maybe calculate the data transfer time, and do a microsleep at the end of each loop that's 2x the actual data transfer speed? That way at least one more character should be there if it's in transit?

nickrsan commented 7 years ago

Original comment by Nicholas Santos (Bitbucket: nickrsan, GitHub: nickrsan).

This has been resolved - it now correctly runs read speed