GPS RTK2 NMEA out seems delayed by 0.5-1.0 seconds

I am trying to use the GPS RTK2 ZED F9P board (GPS-15136), along with a MAX3232 transceiver board (BOB-11189) to send NMEA data to an external RS232 device. I was able to configure the NMEA strings, baud rate, RTCM, etc and everything seems to be working correctly, however, I noticed the speed and heading (and I assume location) data is lagging by almost 1 second. I confirmed this by watching the data in U-Center and comparing that with the NMEA strings going to my external device. When I start and stop moving, the velocity data in the VTG string is delayed by about 1 second, compared to the data shown in U-Center. My preferred NMEA settings are GGA, VTG, GSA, and GSV all turned on at 10 hz, with a baud rate of 115,200. I thought maybe this was too many messages for that baud rate, so I tried limiting the NMEA out to only GPS satellite info, but that didn’t help. I also tried going to the 460,800 baud rate, but that didn’t help either. I also tried slowing the messages down to 5 hz, but that didn’t seem to help either. In U-Center, I had to configure the receiver to continue outputting speed data even when speed is zero (frozen COG setting). I am outputting NMEA on UART1 and sending RTCM messages to the receiver via UART2. Is there maybe something I am missing on the MAX3232? I thought it was basically plug and play. Any other suggestions? Thanks in advance.

Hi rick@pfs,

I am not positive what would be causing such a significant delay here. The MAX3232 Breakout should not add much of a delay to your signals and it is, as you thought, more or less plug and play. There should not be any extra configuring you need to do to get it up and running properly.

A test you could try (assuming you are able) is to see if you notice a delay when going from UART1 to another Serial TTL device. You could pipe that data to an Arduino or another microcontroller. You could also try connecting a USB to Serial bridge like an FTDI Breakout to check for delays in a terminal open to that port. Similarly, if you are able, try testing on the RS232 end for a delay in sending or receiving data. That will help you identify where the delay is coming from and work backward from there to resolve it.