LIBUARTE strange behaviour

[rchaudet]

Hi everyone,

I am trying to solve a bug I am facing for several days now, it is related to LIBUARTE communication with a GPS module

Communication is init at 115200 BAUD and with a timeout of 100us.

The GPS module sends data every second. This data is composed by several frames, all starting with '$' and ending with " *xx " (xx can be any number)

Here is an example of correct data:

$GNRMC,164352.97,V,,,,,,,060421,,,N,V*11
$GNGGA,164352.97,,,,,0,04,8.0,,M,,M,,*7D
$GNGLL,,,,,164352.97,V,N*5D
$GPGSV,16,,,31,26,,,20,27,,,32,1*6D
$GPGSV,2,2,07,08,,,25,26,,,21,27,,,25,8*60
$GLGSV,1,1,02,82,,,20,81,,,24,1*7D
$GNGSA,A,1,,,,,,,,,,,,,16.7,8.0,14.7,4*3C
$GNGSA,A,1,,,,,,,,,,,,,16.7,8.0,14.7,5*3D
$GNGSA,A,1,,,,,,,,,,,,,16.7,8.0,14.7,6*3E

But here is the data I actually receive from GNSS module:

"NEWFRAME" is to indicate the beginning of a new packet of data in the UART handler.

NEWFRAME$PQGNSS,001*15
$PQVER,MODULE_LC79DANR01A04S,2019/12/18,10:17:15*25
$PQVER,SUB_V03*22
$PQVER,GL_20.23*15
$PQVER,GL_ANEWFRAME000100000000000000000000000000000000000000000000000000000000000000000000*42
$PQSWCONFIG,1,2,4,000000000000000000000000NEWFRAME00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000NEWFRAME101010101010000*3E
ER,MODULE_LC79DANR01A04S,2019/12/18,10:17:15*25
$PQVER,SUB_V03*22
$PQVER,GL_20.23*15
$PQVER,GL_ANEWFRAME$GNRMC,164052.86,V,,,,,,,060421,,,N,V*12
$GNGGA,164052.86,,,,,0,00,99.0,,M,,M,,*42
$GNGLL,,,,,164052.86,V,N*5E
$GNGSNEWFRAME99.0,3*01
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,4*06
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,5*07
$GNGSA,A,1,,,,,,,,,,NEWFRAME$GNRMC,164053.86,V,,,,,,,060421,,,N,V*13
$GNGGA,164053.86,,,,,0,00,99.0,,M,,M,,*43
$GNEWFRAMENGLL,,,,,164053.86,V,N*5F
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,1*03
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,2*00
$GNGNEWFRAME,1,,,,,,,,,,,,,99.0,99.0,99.0,6*04
$GNVTG,,T,,M,,N,,K,N*32
$GNRMC,164053.88,V,,,,,,,060421,,,N,V*1D
$GNGGA,164053.88NEWFRAME,1,,,,,,,,,,,,,99.0,99.0,99.0,2*00
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,3*01
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,4NEWFRAME$GNRMC,164054.86,VNEWFRAME,,,,,,,060421,,,N,V*14
$GNGGA,164054.86,,,,,0,00,99.0,,M,,M,,*44
$GNGLL,,,,,164054.86,V,N*58
$GPGSV,1,1,01,08,,,30,1NEWFRAME
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,4*06
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,5*07
$GNGSA,A,1,,,,,,,,,,,,,99.0,99NEWFRAME$GNRMC,164055.86,V,,,,,,,060421,,,N,V*15
$GNGGA,164055.86,,,,,0,00,99.0,,M,,M,,*45
$GNGLL,,,,,1NEWFRAME64055.86,V,N*59
$GPGSV,1,1,01,16,,,24,1*64
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,1*03
$GNGSA,A,1,,,,,,,,,,,,,99.0,99NEWFRAME9.0,5*07
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,6*04
$GNVTG,,T,,M,,N,,K,N*32
64054.86,V,N*58
$GPGSV,1,1,01,08,,,30,1NEWFRAME$GNRMC,164056.86,V,,,,,,,060421,,,N,V*16
$GNGGA,164056.86,,,,,0,00,99.0,,M,,M,,*46
$GNGLL,,,,,164056.86,V,N*5A
$GPGSNEWFRAME0,99.0,99.0,1*03
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,2*00
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,3*01
$GNGSA,A,1,,,NEWFRAME$GNRMC,164057.86,V,,,,,,,060421,,,N,V*17
$GNGGA,164057.86,,,,,0,00,99.0,,M,,M,,*47
$GNGLL,,,,,164057.86,V,N*5B
$GPGSNEWFRAME,,,,,,99.0,99.0,99.0,3*01
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,4*06
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,5*07
$GNGNEWFRAME$GNRMC,164058.86,V,,,,,,,060421,,,N,V*18
$GNGGA,164058.86,,,,,0,00,99.NEWFRAME0,,M,,M,,*48
$GNGLL,,,,,164058.86,V,N*54
$GPGSV,1,1,02,16,,,25,27,,,28,1*69
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,1*NEWFRAME$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,5*07
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,6*04
$GNVTG,,T,,M,,N,,K,N*32
,V,N*5NEWFRAME$GNRMC,164059.86,V,,,,,,,060421,,,N,V*19
$GNGGA,164059.86,,,,,0,00,99.0,,M,,M,,*49
$GNGLL,,,,,164059.86,V,N*55
$GPGSNEWFRAME$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,1*03
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,2*00
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.NEWFRAME.0,6*04
$GNVTG,,T,,M,,N,,K,N*32
,V,N*54
$GPGSV,1,1,02,16,,,25,27,,,28,1*69
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0,1*NEWFRAME$GNRMC,164100.86,V,,,,,,,060421,,,N,V*14
$GNGGA,164100.86,,,,,0,00,99.0,,M,,M,,*44

Here are my two problems:

1- UART handler is not called at the end of the gps module packets, but somewhere in the middle of them

2- Sometimes, even inside one uart handler packet, I can see that NMEA frames are truncated (missing several bytes)

I already tried to increase uart timeout between 100 to 10000 whithout any improvement (I am getting the exact same output)

my UART instance is defined this way: 

NRF_LIBUARTE_ASYNC_DEFINE(libuarte_gnss, 0, 2, NRF_LIBUARTE_PERIPHERAL_NOT_USED, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);

Any idea where this issue could come from?

Best regards

[rchaudet]

Here is more talkative logs:

If I enable GGA & RMC frames, here is the log I get:

NEW PACKET AT 55220 ms OF 85 bytes
$GNRMC,100336.39,V,,,,,,,070421,,,N,V*14
$GNGGA,100336.39,,,,,0,00,99.0,,M,,M,,*45

NEW PACKET AT 56220 ms OF 85 bytes
$GNRMC,100337.39,V,,,,,,,070421,,,N,V*15
$GNGGA,100337.39,,,,,0,00,99.0,,M,,M,,*44

NEW PACKET AT 57210 ms OF 45 bytes
$GNRMC,100338.39,V,,,,,,,070421,,,N,V*1A
$GN
NEW PACKET AT 57230 ms OF 40 bytes
GGA,100338.39,,,,,0,00,99.0,,M,,M,,*4B
¬þ
NEW PACKET AT 58230 ms OF 85 bytes
$GNRMC,100339.39,V,,,,,,,070421,,,N,V*1B
$GNGGA,100339.39,,,,,0,00,99.0,,M,,M,,*4A

NEW PACKET AT 59230 ms OF 85 bytes
$GNRMC,100340.39,V,,,,,,,070421,,,N,V*15
$GNGGA,100340.39,,,,,0,00,99.0,,M,,M,,*44

NEW PACKET AT 60220 ms OF 45 bytes
$GNRMC,100341.39,V,,,,,,,070421,,,N,V*14
$GN
NEW PACKET AT 60230 ms OF 40 bytes
GGA,100341.39,,,,,0,00,99.0,,M,,M,,*45
¬þ
NEW PACKET AT 61230 ms OF 85 bytes
$GNRMC,100342.39,V,,,,,,,070421,,,N,V*17
$GNGGA,100342.39,,,,,0,00,99.0,,M,,M,,*46

NEW PACKET AT 62240 ms OF 85 bytes
$GNRMC,100343.39,V,,,,,,,070421,,,N,V*16
$GNGGA,100343.39,,,,,0,00,99.0,,M,,M,,*47

NEW PACKET AT 63230 ms OF 45 bytes
$GNRMC,100344.39,V,,,,,,,070421,,,N,V*11
$GN
NEW PACKET AT 63240 ms OF 40 bytes
GGA,100344.39,,,,,0,00,99.0,,M,,M,,*40
¬þ

If I enable GGA frames only:

NEW PACKET AT 13110 ms OF 43 bytes
$GNGGA,101954.00,,,,,0,00,99.0,,M,,M,,*40

NEW PACKET AT 14110 ms OF 43 bytes
$GNGGA,101955.00,,,,,0,00,99.0,,M,,M,,*41

NEW PACKET AT 15120 ms OF 43 bytes
$GNGGA,101956.00,,,,,0,00,99.0,,M,,M,,*42

NEW PACKET AT 16120 ms OF 43 bytes
$GNGGA,101957.00,,,,,0,00,99.0,,M,,M,,*43

NEW PACKET AT 17140 ms OF 43 bytes
$GNGGA,101958.00,,,,,0,00,99.0,,M,,M,,*4C

NEW PACKET AT 18130 ms OF 37 bytes
$GNGGA,101959.00,,,,,0,00,99.0,,M,,M,
NEW PACKET AT 18140 ms OF 6 bytes
,*4D

NEW PACKET AT 19140 ms OF 43 bytes
$GNGGA,102000.00,,,,,0,00,99.0,,M,,M,,*4B

NEW PACKET AT 20150 ms OF 43 bytes
$GNGGA,102001.00,,,,,0,00,99.0,,M,,M,,*4A

NEW PACKET AT 21150 ms OF 43 bytes
$GNGGA,102002.00,,,,,0,00,99.0,,M,,M,,*49

NEW PACKET AT 22150 ms OF 43 bytes
$GNGGA,102003.00,,,,,0,00,99.0,,M,,M,,*48

NEW PACKET AT 23150 ms OF 43 bytes
$GNGGA,102004.00,,,,,0,00,99.0,,M,,M,,*4F

NEW PACKET AT 24150 ms OF 34 bytes
$GNGGA,102005.00,,,,,0,00,99.0,,M,
NEW PACKET AT 24160 ms OF 9 bytes
,M,,*4E

NEW PACKET AT 25150 ms OF 43 bytes
$GNGGA,102006.00,,,,,0,00,99.0,,M,,M,,*4D

NEW PACKET AT 26160 ms OF 43 bytes
$GNGGA,102007.00,,,,,0,00,99.0,,M,,M,,*4C

NEW PACKET AT 27160 ms OF 43 bytes
$GNGGA,102008.00,,,,,0,00,99.0,,M,,M,,*43

NEW PACKET AT 28170 ms OF 43 bytes
$GNGGA,102009.00,,,,,0,00,99.0,,M,,M,,*42

NEW PACKET AT 29030 ms OF 43 bytes
$GNGGA,102009.79,,,,,0,00,99.0,,M,,M,,*4C

NEW PACKET AT 29160 ms OF 31 bytes
$GNGGA,102010.00,,,,,0,00,99.0,
NEW PACKET AT 29170 ms OF 12 bytes
,M,,M,,*4A


Basically, clean frames are periodically received (85 bytes in the first example, 43 bytes in the second example),

Then a truncated  frame is received in two parts, then several clean frames are received again, and so on.

I don't get any UART error, and I call nrf_libuarte_async_rx_free() at the end of every NRF_LIBUARTE_ASYNC_EVT_RX_DATA event

[Jørgen Holmefjord]

Hi,

libUARTE have been configured with buffer size of 255 bytes in your application. You will receive a RX event whenever the timeout is hit, or the buffer have been filled completely. If you receive 40 bytes, then 85 two times, you will only be able to bit 255-85--85-40 = 45 bytes before the buffer is full. libUARTE will then switch to the next buffer for the last 45 bytes of the 85 bytes transfer.

If you only receive 85 bytes packets, you should be able to fit 3 full packets in the buffer, but you may have received some other initial (shorter) data before getting into this situation where the transfers are splitted into different buffers. You will have to re-assemble the packets yourself in the application.

Best regards,
Jørgen

[rchaudet]

Hi,

It seems that libUARTE does not want to give me a break.

My data is always coherent now, but everytime I get a fix on my GNSS module, I get truncated frames (frames are longer when there is a fix since there are more filled fields):

$GNGGA,093207.58,,,,,0,00,99.0,,M,,M,,*4A
$GNRMC,093208.58,V,,,,,,,270421,,,N,V*16
$GNGGA,093208.58,,,,,0,00,99.0,,M,,M,,*45
$GNRMC,093209.58,V,,,,,,,270421,,,N,V*17
$GNGGA,093209.58,,,,,0,00,99.0,,M,,M,,*44
$GNRMC,093210.58,V,,,,,,,270421,,,N,V*1F
$GNGGA,093210.58,,,,,0,00,99.0,,M,,M,,*4C
$GNRMC,093211.58,V,,,,,,,270421,,,N,V*1E
$GNGGA,093211.58,,,,,0,00,99.0,,M,,M,,*4D
$GNRMC,093212.58,V,,,,,,,270421,,,N,V*1D
$GNGGA,093212.58,,,,,0,00,99.0,,M,,M,,*4E
$GNRMC,093213.58,V,,,,,,,270421,,,N,V*1C
$GNGGA,093213.58,,,,,0,00,99.0,,M,,M,,*4F
$GNRMC,093214.58,V,,,,,,,270421,,,N,V*1B
$GNGGA,093214.58,,,,,0,00,99.0,,M,,M,,*48
$GNRMC,093215.58,V,,,,,,,270421,,,N,V*1A
$GNGGA,093215.58,,,,,0,00,99.0,,M,,M,,*49
$GNRMC,093216.58,V,,,,,,,270421,,,N,V*19
$GNGGA,093216.58,,,,,0,00,99.0,,M,,M,,*4A
$GNRMC,093217.58,V,,,,,,,270421,,,N,V*18
$GNGGA,093217.58,,,,,0,00,99.0,,M,,M,,*4B
$GNRMC,093218.58,A,4713.692362,N,00133.688716,W,0.0,,270421,,,A,V*04
$GNGGA,093218.58,4713.692362,N,00133.688716,W,1,06,2.1,33.3,M,,M,,*48
$GNRMC,093219.57,A,4713.691725,N,00133.695061,W,0.5,,270421,,,A,V*00
$GNGGA,093219.57,4713.691725,N,00133.695061,W,1,06,2.1,33$GNRMC,093220.57,A,4713.690230,N,00133.694088,W,0.2,,270421,,,A,V*0B
$GNGGA,093220.57,4713.690230,N,00133.694088,W,1,06,2.1,34.3,M,,M,,*42
$GNRMC,093221.57,A,4713.690674,N,00133.694167,W,0.6,213.8,270421,,,A,V*2C
$GNGGA,093221.57,4713.690674,N,00133.694167,W,1,06,2$GNRMC,093222.00,A,4713.690116,N,00133.693416,W,0.1,,270421,,,A,V*0B
$GNGGA,093222.00,4713.690116,N,00133.693416,W,1,06,2.1,34$GNRMC,093223.00,A,4713.689873,N,00133.693244,W,0.1,,270421,,,A,V*09

You can see everything is fine until I get a fix, then some frames get truncated and filled with the next frame since end line char is missing.

Any ideas?

[Jørgen Holmefjord]

Not sure I see exactly what the problem is, as I do not know what your expected output is.

Anyway, if you can post your full code used for handling\printing the received frames, I may help you pinpoint the problem in the code.

[rchaudet]

Ok so let's recap:

My GNSS module sends only 2 kind of NMEA frames (GGA and RMC), formatted this way:

$GNGGA,093207.58,,,,,0,00,99.0,,M,,M,,*4A
$GNRMC,093208.58,V,,,,,,,270421,,,N,V*16

When there is not enough satellites signal, and this way:

$GNRMC,131444.00,A,4713.689658,N,00133.702428,W,0.1,,280421,,,A,V*0A
$GNGGA,131444.00,4713.689658,N,00133.702428,W,1,05,1.8,25.3,M,,M,,*46

When satellites signal is good enough for location computation.

This is the kind of frames I am supposed to receive all the time.

Note that all these frames are ended by \r\n characters.

First, I use this "raw" UART handler, only displaying received data:

void uart_event_handler(void * context, nrf_libuarte_async_evt_t * p_evt)
{
    nrf_libuarte_async_t * p_libuarte = (nrf_libuarte_async_t *)context;

    switch(p_evt->type)
    { 
      case NRF_LIBUARTE_ASYNC_EVT_RX_DATA:
      {
          printf("%s",p_evt->data.rxtx.p_data);
          nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data, p_evt->data.rxtx.length);
      }break;
      case NRF_LIBUARTE_ASYNC_EVT_ERROR:
      {
          printf("\nUART ERROR: %d", p_evt->data.errorsrc);
      }break;
      case NRF_LIBUARTE_ASYNC_EVT_OVERRUN_ERROR:
      {
          printf("\nUART OVERRUN ERROR");
      }break;
    }
}

In this case this is what I get: 

$GNGGA,000009.00,,,,,0,00,99.0,,M,,M,,*41
$GNRMC,000001.00,V,,,,,,,020712,,,N,V*1E
$GNGGA,000001.00,,,,,0,00,99.0,,M,,M,,*49
$GNRMC,000002.00,V,,,,$GNRMC,000010.00,V,,,,,,,020712,,,N,V*1E
$GNGGA,000010.00,,,,,0,00,99.0,,M,,M,,*49
$GNRMC,000002.00,V,,,,,,,020712,,,N,V*1D
$GNRMC,000011.00,V,,,,,,,020712,,,N,V*1F
$GNGGA,000011.00,,,,,0,00,99.0,,M,,M,,*48
$GNRMC,000003.00,V,,,,,,,020712,,,N,V*1C
$GNRMC,000012.00,V,,,,,,,020712,,,N,V*1C
$GNGGA,000012.00,,,,,0,00,99.0,,M,,M,,*4B
$GNRMC,000004.00,V,,,,,,,020712,,,N,V*1B
$GNGGA,000004.00,,,,,0,00,99.0,,M,,M,,*4C
$GNRMC,000005.00,V,,,,$GNRMC,000013.00,V,,,,,,,020712,,,N,V*1D
$GNGGA,000013.00,,,,,0,00,99.0,,M,,M,,*4A

You can see the "ghost" effect I explained earlier, and truncated frames due to a lack of '\0' char at the end of the p_evt->data.rxtx.p_data buffer.

So if I add \0 char then everythings looks fine again, wheither I add it in the handler this way:

p_evt->data.rxtx.p_data[p_evt->data.rxtx.length] = '\0';

Or by using a copy of the buffer to avoid messing up with the buffer index as you suggested:

char frame_buffer[p_evt->data.rxtx.length+1];
strncpy(frame_buffer,p_evt->data.rxtx.p_data,p_evt->data.rxtx.length);
frame_buffer[p_evt->data.rxtx.length] = '\0';
printf("%s",frame_buffer);

In both these cases, I get correct frames:

$GNRMC,131431.97,V,,,,,,,280421,,,N,V*1F
$GNGGA,131431.97,,,,,0,04,13.9,,M,,M,,*4C
$GNRMC,131432.97,V,,,,,,,280421,,,N,V*1C
$GNGGA,131432.97,,,,,0,04,13.9,,M,,M,,*4F
$GNRMC,131433.97,V,,,,,,,280421,,,N,V*1D
$GNGGA,131433.97,,,,,0,04,13.9,,M,,M,,*4E
$GNRMC,131434.97,V,,,,,,,280421,,,N,V*1A
$GNGGA,131434.97,,,,,0,04,13.9,,M,,M,,*49

But then If I get good sattelites signal, I start getting truncated frames again (whithout the "ghost" effect though):

$GNRMC,131435.97,A,4713.690609,N,00133.699195,W,0.0,,280421,,,A,V*0F
$GNGGA,131435.97,4713.690609,N,00133.699195,W,1,05,1.8,28$GNRMC,131436.97,A,4713.690288,N,00133.699073,W,0.1,,280421,,,A,V*09
$GNGGA,131436.97,4713.690288,N,00133.699073,W,1,05,1.8,27.3,M,,M,,*47
$GNRMC,131437.96,A,4713.690509,N,00133.700876,W,0.0,,280421,,,A,V*0A
$GNGGA,131437.96,4713.690509,N,00133.700876,W,1,05,1.8,27$GNRMC,131438.96,A,4713.690116,N,00133.701570,W,0.1,,280421,,,A,V*04
$GNGGA,131438.96,4713.690116,N,00133.701570,W,1,05,1.8,27.3,M,,M,,*4A
$GNRMC,131440.00,A,4713.689887,N,00133.701877,W,0.5,,280421,,,A,V*03
$GNGGA,131440.00,4713.689887,N,00133.701877,W,1,05,1.8,26$GNRMC,131441.00,A,4713.689844,N,00133.701963,W,0.8,357.8,280421,,,A,V*23
$GNGGA,131441.00,4713.689844,N,00133.701963,W,1,05,1.8,26.3,M,,M,,*42
$GNRMC,131442.00,A,4713.689644,N,00133.702321,W,0.2,,280421,,,A,V*0C
$GNGGA,131442.00,4713.689644,N,00133.702321,W,1,05,1.8,25$GNRMC,131443.00,A,4713.689508,N,00133.702514,W,0.4,,280421,,,A,V*00
$GNGGA,131443.00,4713.689508,N,00133.702514,W,1,05,1.8,24.3,M,,M,$GNRMC,131444.00,A,4713.689658,N,00133.702428,W,0.1,,280421,,,A,V*0A
$GNGGA,131444.00,4713.689658,N,00133.702428,W,1,05,1.8,25.3,M,,M,,*46

You can see that frames are truncated when there is "$GNRMC" or "$GNGGA" in a middle of a line instead of the begining of a new line as it should. When this occurs then the previous frame is cut.

[Jørgen Holmefjord]

Sorry for the slow response. Have you tried increasing the number of buffers for the libUARTE library (last argument to NRF_LIBUARTE_ASYNC_DEFINE), or the size of the buffers? If you do not free the buffers back to the library fast enough, you may get behavior like this.

[rchaudet]

Hi,

Increasing the number of buffers makes no difference. It seems like my problem could indeed be solved by increasing the size of the buffer, but size above 255 is not supported. Where does this 255 bytes limit comes from? Would there be a way to bypass this limit?

Best regards

[Jørgen Holmefjord]

Sorry, I did not think of this limit. Since you are using nRF52832, this has a HW limitation of 255 bytes in the MAXCNT registers (8-bit length) for UARTE (and other serial peripherals). There is no way to get around this limit for nRF52832. Other nRF52 series ICs have larger MAXCNT registers, allowing for longer transfers up to 16 bit/65535 bytes in nRF52833/nRF52840.

If increasing the number of buffers does not help, I'm afraid that the only other suggestion I have is to add HW flow control pins and/or reduce the baudrate.