Managed to get the reach RTK base and rover connected and operable as per the Quickstart guide. Fix took 5 min or so. Nice. I have now set the rover solution output path to ‘serial’ as ‘ttyMFD2’ at 115200 baud in NMEA format. The serial data that is delivered to ttyMFD2 is completely mixed up - no clear NMEA structure at all? It looks like wrong baud rate or some sort of character encoding format or something else on the port. Couldn’t get to the bottom of it - I was expecting straight $GPGGA… type ASCII NMEA strings. Setting the solution output path to ‘tcpsvr’ and ‘file’ both worked fine for nmea and llh format as expected.
Is there anything else using ttyMFD2 that could cause a garbled data stream? Anyone else found this to be an issue?
If I ssh in and try something like:
echo -e ‘\x31\x32’ > /dev/ttyMFD2
-> I get nothing sensible out of the serial port. What am I missing?
Thank you for you prompt reply. I have solved the problem. I had the TX/RX of ttyMFD2 connected to a long FTDI serial to USB cable. The cable provided power too. It looks like the signal levels were poor and the data stream was corrupted. The supply from the FTDI cable was noisy and by the looks of it started ringing on the falling edges of the UART TX signal. Lesson is to keep an eye on power supply (storage and decoupling caps if possible) and don’t load the TX/RX lines with much C (capacitance).
Now that is sorted and I am getting NMEA data from ttyMFD2 serial port, how do I only get $GPGGA NMEA messages from the rover? Do I mod the reach_raw.cmd file in the /ReachView/rtklib_configs dir on the rover? If I comment out for ex:
#!UBX CFG-MSG 240 1 0 0 0 0 0 0
Will this stop NMEA GLL messages from being generated? Do I have to do the same thing on the base ublox config file? Any help greatly appreciated.
