Serial data truncated

Ok I’ve read the Serial tutorial, and I think the problem described in the tutorial where the while loop clears out the rx buffer before all the data arrives describes what is happening here.

I have reconnected the FTDI to the rn52 as well as the Arduino Nano via USB, so I can see what the rn52 is putting out on com4, and see what the arduino is receiving on com5. if I do a “D” dump command to the rn52, I see the expected data on the FTDI, and get truncated data on the Arduino. truncated isn’t accurate. I get a couple of complete lines, then missing data, then some lines are incomplete and put together in the same line. I have been able to get my program to do as I wanted, because the data that I use for running it is in short one line output. but while I’m trying to figure things out, and configure the rn52 through the Arduino, I need to make sure I’m seeing everything the rn52 is putting out. and I’m not seeing everything unless I use the FTDI in conjunction with Arduino.

I might also point out that the Arduino is communicating with the rn52 through a level converter, and the FTDI is a 3.3v.

So I am sending commands to, and receiving data from the rn52 via SoftwareSerial.

when you look at the code below, its a striped down version of my program, and contains in the setup unnecessary strings and such. the void loop is the area of concern. There are while loops after commands in the setup portion, but the expected return data is short, and that works. In the void loop, I am able to issue commands to rn52 from the IDE serial monitor. but the returned Data is incomplete as described above. I know this because I am simultaneously monitoring it through the FTDI, on another terminal window. You will also see in the void loop that I have inserted some delays, I have played with delays from 0-100 ms, and it made no difference.
previous versions had assigned inChar to a string prior to a Serial.println rather than printing each character one at a time, with the same result.

//include Software Serial Library

//assign pins 3 a,d 4 tx and rx
SoftwareSerial mySerial(3,4);

//Declare Strings
String compString = ("AVRCP:V");
String inputString = "";
boolean stringComplete = false;
int led = 13;
String compare = "";

void setup() {
    //pin mode will be set to output on pin 13
  pinMode(led, OUTPUT);

  //enable Serial Communications at 115200 baud

  //reserve 200 bytes for the input string
  //reset the rn52
  //this while loop, which you will see following each command issued, in the setup,
  //to the rn52 is to Serial Print the rn52's response following each command.
  //both the Serial print statements, and the while loops can be removed. once the program
  //is working properly.
     while (mySerial.available()){
      char inChar = (char);
  //give rn52 time to reset
void loop() {

//send mySerial data from the rn52 to the IDE serial monitor

  if (mySerial.available())
     while (mySerial.available()){ 
      char inChar = (char);// read one character at a time from the serial buffer
//send serial data from the serial monitor to the rn52
  if (Serial.available())

So, is there a way to make Arduino wait for the rest of the data, or slow it down until more data arrives?
Would slowing down the Baud rate help?

It also occurs to me also that if the serial buffer is too small, and rn52 data overflows it, the Arduino would print the available data, loose a good bit of it, and then print whatever data arrived in the buffer after the initial dump and loss. that theory seems to fit too, as it explains the last bit of data printed seems to be from the end of the data stream.
Can the rx buffer be expanded?

The rn52 has a default baud rate of 115200, and I wonder if slowing down the baud rate would help as I do get some erroneous characters quite often.


What is an rn52? Is it a warship?

Having delays is certainly not helping, it's making things worse.

I'm not sure how fast software serial can run but it puts a lot of demand on the processor. If it will run at 115200, and I'm not sure it will, it will be taking up most of the processor time and I would expect data to be lost.

Setting the baud rate to the serial monitor at the same rate as the incoming data assumes that the data can be sent out as fast as it comes in, with no gaps between receiving a byte and passing it on. As soon as time is lost it can never catch up and eventually data will be lost.

Don't use Strings, they cause memory problems, use C strings, as in null terminated character arrays.

I suggest you use a board that has a spare hardware serial port and use a lower baud rate for the incoming data and no Strings.

The best that I have seen Software serial read, reliably, is 38400, 115200 is a NO GO.

The serial input basics tutorial shows how to receive serial data with non-blocking methods into a null terminated character array (string, not String). The size of the receive buffer is adjustable, in the software, to your needs.