best meathod to capture serial data?

I have my gps reciever and arduinoMega talking. The recievers proprietary data format uses byte size data functions. I have been trying to use a state machine setup to read the individual messages I want to record data from. Some messages are a preset data length. These I have been getting fine. All of the messages start with a start byte 0x10, followed by message ID, then data, then, 0x10, 0x03 to end the packet. For the fixed length messages I look for a 0x10, then look for ID, then save into an array the fixed number of bytes. I then check the array for the last 2 bytes being 0x10,0x03. If so I save the data segment to external FRAM at a fixed location to do something with later. That part all works fine.
The problem is messages that have variable length based on how many satilites it is tracking. For instance one message:
0x10,
ID,
header data 28 bytes
sat data 30 bytes
sat data 30 bytes
ect...
0x10,
0x03
end of stream

I am trying to read this all in one piece but get hung up somewhere in this state.

//tempArray is set at 1000 bytes


case pF5sCollectTheData:  //header is 28 bytes, message 30 per sv no delimters 990bytes possible
      int n;
      TimerA =millis();
      for (n=0; n < 990; n++){
        tempArray[n] = Serial2_WaitForByte(&inbyte);  //test for end bytes
        if (tempArray[n] == 0x10){
          Serial2_WaitForByte(&tempArray[n+1]);
          if (tempArray[n+1] == 0x03){


            messageF5 = true;
            Serial.println("F5 end marker");
            for(int i=0; i<29; i++) {
              WriteF5h(addr,i*8,tempArray[i]); //writes header to FRAM
            }

            for (int k=27; k<n; k+30){
              if(tempArray[k] == 0x01){  //glonass data
                countGLO++;
                for(int i=k; i<i+30; i++) {
                  WriteF5hGLO(addr,i*8,tempArray[i]);
                }
                Serial.println("collected glo raw data");
              }
              if(tempArray[k] == 0x01){
                countGPS++;
                for(int i=k; i<i+30; i++) {
                  WriteF5hGPS(addr,i*8,tempArray[i]);
                }
                Serial.println("collected raw gps data");
              }
            }
            state = Fini;          
          }//end if message good
        }// end for staement
      }
      if (millis()-TimerA >= 500UL){
        Serial.println("reciever communication time out error F5h");
        state = Fini;
      }
      break;

Is there a better meathod?
Should I set serial available > number of bytes per satilite segment then do a read instead?

Doing the reads yourself will make it easier to debug what is happening and accommodate issues with the stream.

            for (int k=27; k<n; k+30){

That does not add 30 to k at the end of the loop.

      for (n=0; n < 990; n++){
        tempArray[n] = Serial2_WaitForByte(&inbyte);  //test for end bytes

What are you reading from that sends 990 byte messages? I'm not aware of ANY GPS sentences that are that long.

It is outputting raw measurement data for up to 32 channels. It is not NMEA strings but binary data.
I changed the code to read and output each byte in decimal format. Problem is it appears I am sometimes loosing a byte or two in the data stream along the way. This causes a big problem for me as there is no way to determine along the way which segments are complete and which are missing a byte unless the entire message is recieved and the position in the array of the end byte pair can be found. Then I'm not certain how to go about sorting the rest.
I have the baud rate at 115200. Is it possible the device is sending bytes faster than the ATMEGA2560 can read them from the buffer?

Problem is it appears I am sometimes loosing a byte or two in the data stream along the way.

Quite possibly, you are. You seem to be operating under the assumption that the serial buffer size is unlimited (it is not) and that serial data is guaranteed to be delivered, uncorrupted (it is not).

This causes a big problem for me as there is no way to determine along the way which segments are complete and which are missing a byte unless the entire message is recieved and the position in the array of the end byte pair can be found.

Then, the sender needs a re-write.

Is it possible the device is sending bytes faster than the ATMEGA2560 can read them from the buffer?

Yes, and no, It is not possible to fill the buffer faster than it CAN BE emptied. On the other hand, it is quite possible to fill the buffer faster than it IS emptied.

Writing serial data while reading is slow. Actually, writing anytime is slow, but doing so while reading interferes with your ability to read as fast as possible.

                Serial.println("collected raw gps data");

The intent of that long collection of characters could be conveyed in far fewer characters.

I appreiate the response.
I was just trying to debug it with this code.

case pF5sCollectTheData:  //header is 27 bytes, message 30 per sv no delimters 990bytes possible
      TimerA = millis();
      //  trial1
      Serial.println("entering F5 data collection state");
      while( messageF5 == false){
        for( n=0 ; n<800; n++){
          Serial2_WaitForByte(&tempArray[n]);
          if (tempArray[n] == 0x03 && tempArray[n-1] == 0x10){
            messageF5 = true;
            Serial.println("F5 complete in array");
          }
        }
      }
      if (messageF5 == true){
        n = 27;
        for(int b=0; b<8 ; b++){
          Serial.println(tempArray[n], DEC);
          Serial.println(tempArray[n+29], DEC);
          n = n + 30;
        }
        state = Fini;
      }
      break;

So I get an expected output for the first few satilites. Each segment has an unused byte that should always be 0 and each should start with a system ID 1,2, ect. So maybe I can search down the whole array finding the 1,2,ect and check to see if +29 bytes there is a 0. Based on that I should have very good odds that it would be a good segment.