Electronic – arduino – How to detect when an LED changes color from red to green and quickly send a message to a PC to capture an image from a camera

First, 'Serial.println("loop")' is going to execute every time loop() is called, whether there are characters available or not. That would show you that the loop is executing but it's likely to obscure the output when you get any.

Second, the while() loop isn't going to wait for you to finish typing; it will only collect the character (or maybe, two) you just typed and then exit, printing out the partial sentence each time.

Third, '*line += (char)Serial.read()' doesn't does something quite different from what I think you intended. If you're trying to put characters into an array, you need either an index or a pointer into the array which you increment after storing each character.

Here's an example (there are other ways to do it to avoid where some duplicate code, but this way is closer to your original program structure):

char line[80];
int count = 0;

void setup() {                
   Serial.begin(9600);
   Serial.println("loop");  // prompt for a sentence
}

void loop() {

   // loop() will called faster than you can type so there's
   // no need for the next block to loop; you need only test
   // once for the presence of one or more characters.
   if (Serial.available() > 0) {

      line[count] = (char)Serial.read(); // store the char
      if (line[count++] == '\r'){        // if its a CR,
         line[count] = '\0';             //  zero-terminate it
         Serial.println(line);           //  and print it.

         Serial.println("loop");         // re-prompt
         count = 0;                      //  and reset the index.
      }
   }
}

The feasibility of transferring live video over Bluetooth from an Android mega is low but not zero, being constrained by the following:

1. Bluetooth practical throughput limitations:
   • Bluetooth 1.2 = ~ 700 Kbit / sec
   • Bluetooth 2.0+EDR = ~ 2.1 MBit / sec
   • Bluetooth 3.0+HS, 4.0: These use a separate wireless path (e.g. 802.11, like WiFi) for the high speed data, so not considering these for now.
   • Low-resolution (VGA 256 color) live video needs at least 200 KBPS, HD needs 2 MBPS or more, sustained bandwidth. That's the reason there aren't many live video streaming Bluetooth gizmos for smartphones yet.
   • Work-around: Use a WiFi shield instead of Bluetooth for communication.
2. Arduino Mega limitations:
   • Capturing, processing and compressing live video in real-time, even at VGA resolution (640 x 480 pixels) is going to be quite a challenge for the ATmega2560 microcontroller, if it can be done at all
   • Memory (RAM, Flash, whatever) will be another challenge: A single frame at VGA 256 color resolution requires over 300 kB for just the frame buffer, twice that for higher color depth. For MJPG or other encoding / compression, a minimum of 2 x Frame Buffer Size would be needed for processing. This necessitates an external memory solution added to the Arduino Mega.
   • Work-around: Perhaps an external shield with video capture and compression, with an on-board DSP and frame buffer RAM, could be used, if you find any such.
     • In which case, the Arduino Mega isn't really needed any more.
   • Are there Bluetooth modules, XBee / ZigBee modules, or shields, which can sustain the maximum throughput rates noted above? If there are, that would be interesting to know.
3. Android Phone constraints:
   • Does the current Android OS release support video endpoints via Bluetooth yet? If not, low-level code will be required at the Android side, just to retrieve the video stream data.
   • The processing requirements for displaying such incoming raw Bluetooth video streams would require hefty batteries, or permit very short operating duration unless docked to a charger.
   • Work-around: Use WiFi, stream from Arduino using a standard streaming video protocol, use a standard Android video player with streaming support to play the stream.

As is evident from the points above, the requirement is feasible, as long as constraints are accepted: Very low resolution, low color depth, low frame rate video, OR... all video processing offloaded to a DSP daughterboard more powerful than the Arduino itself, with its own on-board wireless connectivity.

That last is the work-around the question asks for.

Whether this is the practical approach at all, is up to debate.