So, one thing that kept messing with me was that the packet length was never the same, which i though was pretty wierd. After many data dumps, and start, stop bit combinations, baud changes etc, i finally ended up reaching the conclusion that this was 8N1 at 19200 baud. I decided to try several older encoding/protocols like VT100, VT52, and the likes.

FINALLY some insight. There are ALOT of blank spaces, or dummy bytes, most likely for timing/sync purposes. Im still unclear if the blank chars are NULL or 0x20 (ascii space).

There are escape characters, but these do not seem to match with any known (by me atleast) protocol, yet some characters do seem to be standard escape chars like SOH (0x01).. the data contains binary data and Ascii, but i cant seem to figure out the escape sequence for when Ascii starts and ends. ASCII 85 Maybe? 

This explains the unequal packet lenghts. Some packets need to include more or less escape chars, and thus pretty much no single hex dump was the same length.

At some point i figured out where the "data" was in the packet, in the form of 2 float (4 bytes) variables ph and temp. I wrote a small script to ignore the blank spaces and print a text representation of all the usual escape characters, basically ascii 0x00 to 0x14....  basically on my terminal i got a bunch of hex but when the byte was a 0x00 it printed the word NULL... 

This worked and i managed to evesdrop on the data bus and get PH and Temperature.... for a bit... a lot of data loss or wrong values. This was before i figured out that there are a lot of escape characters mixed in even with the data... which makes sense when you realize that a 4 byte float might contain a byte with the same value as an escape char or something along those lines.

So... next up, do a plain Hex Dump of the bus, and write a new script that purifies the incoming data. If i manage to get a sustained output of PH and temp i will know im on the right path.

I still cant figure out how the SC200 requests data or when the sensor response begins.