How are the arduino and android connected?

You can run both client and server code on an arduino, with the server waiting for request and the client making request upon some event.

To minimize water hammer, one should use a vertical stub at the valve per standard plumbing practice.

You might save time, money, and have a better product using an inexpensive product like below.

http://www.dataq.com/data-acquisition-starter-kits/data-acquisition-starter-kits.htm

You might look for motors used in cars that are quiet and adapt to be servos.

Spar4k fun has a number of sensors that might be of use. Model bridge competitions have been around for a long time, so searching for previous competitions might produce successful load measuring setups. Also, how the bridges will be force loaded will be important (sometimes they are sand bag loaded along the span). Perhaps placing the bridge on a large a large scale would be a practical option.

https://www.sparkfun.com/categories/23?page=all

I was surprised to find that zener diodes required a certain minimum amount of current flow across them before they would limit voltage levels.

The use of the "simple serial" might not have fine enough control to prevent the apparent control overshoot/instability in some conditions. I think this control method uses a single byte to transfer the control info to the sabertooth. What component signal is unstable/hunting in the graph?   

But unfortunately I have tried that, (but to +5V and to a common ground, although it shouldn't make a difference since its rated for 4.8-6V).

If the +5v is the arduino +5v, it will probably never work well.

A wiring schematic showing the power supply and sabertooth setup would also be helpful.

but I just wanna know why.

Because your power supply setup for the servo power is BAD! It is surprising your pc USB port over current fuse hasn't tripped. Get an appropriate ~6v external power supply for the servos.

the OP hasn't said that as far as I see.

If you read the original post you would find the poster is reporting the spurious output on the serial monitor as a problem. So in this case, the use of the same serial pins for two connections is the direct cause of the problem.

You seem to be quibbling about whether a given serial connection can be connected to more than two devices. Each Rx pin must be connected to no more than one Tx pin, or the two Tx devices will end up fighting with each other, which will typically not work and may even cause hardware damage. In this case Arduino pin 0 (Rx) was connected both to the USB serial device Tx pin and the sabertooth controller Tx pin. That's a bad idea.

I agree it's possible to connect one sender to multiple receivers (as long as you don't also connect up the other half of the serial connection in the same way), but that is not what the OP has done here.

Not sure why you don't understand the OP's setup is appropriately working the way it is wired. The OP appears to have his arduino attached to the sabertooth as recommended by dimension engineering (arduino tx connected to the sabertooth rx, and grounds connected between the two). Per the OP, this works as expected. Bytes sent by the code running on the arduino are being sent to the arduino serial out (tx), which is connected to both the arduino serial/USB interface and to the sabertooth motor controller. The serial monitor is displaying the byte being sent by the arduino code, which may or may not appear as an ascii printable character in the serial monitor. Bottom line, what is diaplayed in the serial monitor is expected behavior. Simple stuff. 

I get a repeat of @@@@ - one character for every command the sabertooth is sent.

Just looking into the sabertooth stuff, the @ probably is the byte being sent to the sabertooth indicating that the command is for motor 1.

edit: more info, the single byte commands apparently are what is being seen in the serial monitor.

Simplified Serial  Beginner-friendly
 Fast single byte commands
 Baud rate settable with DIP switches  7-bit on Sabertooth
 No checksumming
 Requires one pin per SyRen or Sabertooth 

And why would that be? the arduino sends serial data out its tx pin and doesn't really care how many rx pins are connected. I used a similar setup to monitor what is being received by my Ethernet shield and being sent to my ssc-32.

I don't know whether you read the original post, but the spurious output in the serial monitor caused by using the same serial port for two jobs is the precise problem we're being asked to resolve.

So what is the basis of your claim "In that case the Serial port is not available for use to communicate with your Sabertooth controller" when the arduino *is* communicating with both the serial monitor and the sabertooth as indicated by the unknown characters in the serial monitor and the sabertooth operating as desired? If the OP wants to use another application on his pc for control, then the serial monitor will not be available, but the OP hasn't said that as far as I see. The OP needs to post the code he is running on the arduino as that probably holds the key to the unknown characters.   

I don't know why PeterH doesn't simply fix your code his way and see if it works. Maybe it won't? Anyhow I looked at your code and the below may have some interesting points. I put in the 2ms delay where a delay is needed in your serial byte capture loop. Why do you basically erase the String you have captured when a - is encountered?

Code:

void initMessageRead(){
  String newMsg = "";
  String str = "";
  GPRS.begin(9600);
  GPRS.println("AT+CMGR=1\r");
  delay(100);

  if( GPRS.available() ){ // if new data is coming from the GPRS UART
    while( GPRS.available() ){ // while there's still data in serial ..
      delay(2);  //delay to allow bytes to arrive in input buffer during capture loop
      char wholeMsg = (char)GPRS.read();
      newMsg += wholeMsg;
      if (wholeMsg == '-') {
        newMsg = ""; // !!!!!!!what is this?

      }
    }

  }
}