Reading Serial Data into a byte array results in invalid data being received

Arduino Leonardo - using hardware serial (TX, RX)

The device connected to the Arduino will only TX after it is polled for the most part.
I am porting code from my PC App to the Arduino because PC UART's do not support 9 data bits and faking it with parity bit creates framing errors and duplicate data
I know what the data should look like from my app and other sources.

Also when I do get single byte response from the device it is correct
I use some of the single byte responses to turn on or off an LED connected to pin 13.

problem happens when I read multiple bytes into either byte array or the char array.

Example data in hex: 01 70 10 00 00 00 00 00 00 00 01 00 00 00 00 01 50 00 00 82 98
Here is what I get instead: BE 71 0 2 0 C6 D5 5C 0 2 2B D5 44 0 0 C6 D5 5C 0 0 12

Serial1.begin(19200) //from setup loop
// the following is a code snipet from main loop

byte serData[32]; // more than enough to hold 21 bytes
int count;

UCSR1B = 0b10011101; // turn on 9th bit 
Serial1.write(0x01);
UCSR1B = 0b10011100; // turn off 9th bit
Serial1.write(0x70);

for (count=0; count<Serial.available(); count++)
{
  serData[count]=Serial1.read();
}

I try the following and I get "error: invalid conversion from 'byte*' to 'char* why when it is in the reference library as an allowed data type for readBytes function.
If I have to I could use a char array as the buffer then move it to a byte array so I can do the processing I want to do.

Serial1.readBytes(serData,Serial1.available());

I tried reading into a char array and I still get invalid data.

This looks wrong to me:

for (count=0; count<Serial.available(); count++)
{
  serData[count]=Serial.read();
}

because Serial.available() will change as you read() bytes.

I'd write it like this:

count = 0;
while (Serial.available() > 0) {
    serData[count]=Serial.read();
    count++;
}

but wait! You're testing Serial.available() and then read() from Serial1 ? :fearful:

byte serData[32]; // more than enough to hold 21 bytes

for (count=0; count<Serial.available(); count++)
{
  serData[count]=Serial1.read();
}

Assuming that you fix the issues that tuxduino pointed out, suppose that there are 40 characters available to be read. You'll be trying to stuff them all in a 32 element array. Are they going to fit?

No, I don't want the hear "Oh, that will never happen". Because, it will. You'll copy and paste this code somewhere else, and it will happen.

You need, always, to make sure that the array index is valid BEFORE writing to an array.

When I typed the code I missed the 1 for serial1
I am getting all 0 values, which I know is not correct either

For the poll that produces that response, the result will be less or equal to 21 bytes, and any other responses for a poll that I using will be less than or equal to 32 bytes.
There might be some polls that do result in more than 32 bytes, no plans on using them at this time.

I do have other polls that have different number of bytes.
I have another poll that returns 12 bytes but it will always return 12 bytes or less,

I will try the your code suggestions, and see what happens but adjust it for Serial1, sorry about the missing the 1 for Serial1 in my original post on this.

I was thinking the invalid data may be do to a timing issue from the arduino reading usart faster than bytes arrive or did I confuse that with the TX of a byte.

I was thinking the invalid data may be do to a timing issue from the arduino reading usart faster than bytes arrive

This is usually the case. But the result is not that Serial.read() returns garbage. Instead it will return -1, meaning that at the time it was called no new (complete) byte had entered the "system" receive ring buffer since its previous call.

I did not put a long enough delay after the poll.
Working great now.

I did not put a long enough delay after the poll.

Reading serial data NEVER requires a delay(). It requires some intelligence, instead.

You don't need to add delays. You need to read bytes, using Serial.available() to check if any is there, right now, and keep reading until you have all you need. That's what you need to do. If you fudge it with a delay, one day the delay will be wrong and you will get rubbish data.