Error Interpretation

of decoded SeaTag data

SeaTag data is retrieved by first collecting it with the SeaWatch utility from the CLS server. The resulting .DRL 'DesertStar Raw Log' file is then decoded it with the SeaConvert utility. The result is a bundle or collection of .csv files encapsulated in a .zip archive. There is one file for each data packet type, plus a SUMMARY file and a file containing INVALID packets, i.e. packets with a FALSE checksum indicating a data error.

The radio link from the tag to the satellite is subject to various errors. And, SeaTag data itself can contain conditions that appear unusual. Here is a list of the more common error conditions:

Two or more TRUE archival packets with the same time stamp, but different data

Most SeaTag data packets conclude with a checksum, which is the last byte of a message. A TRUE checksum generally indicates there is no data corruption, and a FALSE checksum indicates at least one data value is corrupted due to a transmit error. However, because the checksum is just one byte, it is not very strong. For example, two bytes in a message may get corrupted in such a way that they cancel out, and the checksum is TRUE even though there is a data error. If you notice such a situation, look closely at the data value. In the above example, one version of the packet shows a minimum depth of 890m and a maximum depth of 1620m. The second version has a minimum depth of 0m and a maximum of 240m. This is from an animal that can be expected to visit at least the proximity of the surface each day, and so the 0m/240m version is most likely correct.

Far more packets with FALSE checksum in INVALID file than with TRUE checksum

Priority data such as the daily summary packets will generally be sent multiple times by the tag to assure that a high percentage is received by an Argos satellite. Each time a packet is transmitted, there is a significant chance of data corruption. At best, about 80% of received packets will be received without corruption. The nominal for ocean conditions is about 50% OK. And, if conditions are stormy or there is a lot of interference from other tags or from radio noise, then the percentage OK can be much lower. However, SeaConvert will remove any duplicate data packets. But, since there are many ways for a packet to be 'bad' (FALSE checksum). But with the above exception only one way for it to be 'good' (TRUE checksum), the FALSE checksum packets tend to accumulate while the TRUE is stated just once. Take a look at this excerpt from a SUMMARY report:

Packet Statistics 



154 68 86 23


58 19 39 7


20 11 9 11


0 2 0 2 0 Likely 

Notice that a total of 154 SeaTag-3D daily summary packets were received (SDPT_3DDAILY). Of those, 68 were valid. That is, 44% valid. But, only 23 daily summary packets were unique. Since SeaConvert removed all the duplicates, you will only see the 23 unique entries in the 3DDAILY .csv file, but 86 entries in the INVALID .csv file.

More than one Daily Summary received for a day

SeaTag archives a daily summary packet if it has seen some duration of light followed by two hours of uninterrupted darkness. So, it decides that it is now 'night' and a day is completed after two hours of darkness. Multiple daily summaries in a 24 hour period occur if there are irregular light/dark intervals Often this is just before deployment when a tag may be handled, then placed in a dark box or bag, then removed again. But, it can also happen if an animal dives to darkness and stays for at least two hours. The 'night' light threshold is at about 1.4Lux. This is a bit brighter than full moon light (considered 1 Lux) so that moonlight will not 'interrupt' a night.

Daily summary received with a day length of zero

This occurs if there is no light for 30 hours continuous. SeaTag recognizes that is in a condition of sustained darkness (such as very deep or perhaps devoured). It archives a daily summary to note the condition. If darkness continues to persists, additional daily summaries will be filed in 30h intervals.