Over the last couple of years we’ve been trying to operate a Seabird SUNAV2 for continuous, real-time nitrate observations as part of the Scripps Ecological Observatory effort. At the start of the project this seemed like a simple thing… verify the factory calibration against a standard, stick it in the water, and stream some ASCII data for parsing and plotting, right? I should have known better. Although the SUNA can operate through Seabird’s UCI GUI (a vast improvement over the nightmarish landscape of configuration files and aughts-era GUIs required to run some Seabird devices) we were never successful in operating ours for more than 1-2 weeks via the GUI. While UCI did produce an interpretable *sbslog file that could be parsed for nitrate concentration and other data, inevitably either the software would freeze or the SUNAV2 would become unresponsive after a few days. Whenever the latter happened we would need to power cycle the instrument to bring it back online and this eventually corrupted the memory (or so say Seabird) requiring a factory flash of the firmware and other maintenance. I think in two years of operation we maybe acquired 2 weeks of usable data and the SUNA made two trips to Bellevue, WA. Once upon a time I lived near Bellevue and I wish I could go back as frequently.
We recently received the instrument back from Seabird and I was stumped on what to do with it. I knew it was capable of RS232 communication, which might free us from the UCI GUI and solve at least one of our problems, but I have limited experience with serial device communication. With few other options and only cryptic guidance from the SUNAV2 manual I grabbed a power supply and USB-serial converter and gave it a try.
PuTTY was the logical starting place as I use it for SSH connections on my Windows laptop. After the normal guessing of COM ports I made contact at the specified baud rate of 57600 and otherwise default connection parameters. It took me a few tries to realize that I needed to send some (any) character to the instrument to “wake it up” and induce a response and command prompt. Protip, you gotta be fast on that command prompt else it the instrument goes to sleep. But you can’t prompt with a command!
PuTTY worked great for the initial connection but provides no solution for continuous, real-time monitoring. You can get PuTTY to create a log file (containing your data and anything else sent over the serial connection), but the file isn’t created until the session closes which makes it not very useful for real-time monitoring. PuTTY includes the plink utility that is supposed to provide an automation solution. While it can do some cool things I couldn’t crack it for this task. Because the instrument takes some time to respond to the initial “wake up” keystroke, a programmatic solution needs a delay, and I couldn’t find a way to implement one with plink.
Almost in desperation I turned to Python, which is probably where I should have started. A previous day’s frustration turned into a pleasant hour of tinkering over a cup of coffee, and voilà! Here’s the solution, may it help others. The major unsolved issue is that some encoding issue (?) prevents proper parsing of the data passed from the instrument. I tinkered with io.TextIOWrapper and various encoding options to no avail, and ultimately settled on Python string operations to set things right.
