Hi Chris,
It has been a while since I have done anything with mavproxy - we have all our own in-house solutions now…
It definitely seems doable…in fact I vaguely recall doing just this…
After a quick refresher, I remember the issue I faced with this. If you have no NTRIP caster to connect to using the Mavproxy NTRIP module, then your only option is the DGPS module. Unfortunately, this module sets itself up as UDP server that you have to feed corrections to. I ended up re-writing the code to use TCP but there is a workaround.
On your RPi, you can use str2str to source the RTCM data directly from the serial port with the F9P on the other end and then act as a TCP server. Something like:
str2str -in serial://ttyUSB0:115200 -out tcpsvr://:2101
If you configure Mavproxy running on your companion computer to load the DGPS module, it will set up a local UDP server on port 13320.
You can run socat on the companion computer to connect to the TCP server on the RPi and also connect to the local UDP server running on Mavproxy and forward the data
socat TCP4:remote_RPi_host:2101 UDP4:127.0.0.1:13320
You will need to make sure that the RPi and Mavproxy are up and running before you run socat - this will ensure that socat can connect to live servers
For debugging, you can omit the “-out” parameter in the str2str command which will cause it to dump to the console. Because it is binary data, it will look like gobledegook. You can install the following:
sudo apt-get install gpsd gpsd-clients
This will give you the gpsdecode command. If you pipe the output of str2str to gpsdecode, you will better be able to see the messages being received. There is still a lot of binary data in the output but take note of the message types to confirm you are seeing the RTCM MSM messages you expect
str2str -in serial://ttyUSB0:115200 | gpsdecode
You can also do something similar on the companion PC side:
socat TCP4:remote_RPi_host:2101 - | gpsdecode
This should allow you to confirm that the data is getting to the vehicle.
Let me know how you get on!