I will try to answer this…I think I have it clear in my mind. There are at least 2 different ways of achieving rtk with a base and rover. Using the “Here plus” hardware you have a pc permenterly connected to the base unit and the rtcm3 corrections are sent “injected” through mission planner to the rover by telemetry from the PC to the rover.
With the Ublox C94 M8P evaluation boards the corrections calculated by the Base are sent by telemetry radio directly to the rover and the rover then outputs corrected coordinates. This way avoids having a PC connected to the base all the time. Ie less gear to lug around and have exposed to the weather
I think this is correct.
Regards
Max
Corrections through Mission Planner or another GCS running from a laptop are the most common use-cases. I understand that you are looking for a lightweight custom solution, but @WickedShell provides the easiest solution that seems to work for nearly everyone. Getting RTK from a laptop also gives flexibility to use a virtual reference stations through a newtwork (NTRIP).
@maxbirley, that is basically my reason for wanting to use the built-in radios on the C94-M8Ps. I am working toward a rover that can roam over a 100+ acre farm. I foresee the RTK base mounted on my barn in the center of the property with an antenna high enough that the rover can receive the corrections everywhere and no PC required except when I want to check on it. That said, I do appreciate the other suggestions. I saw that Mission Planner can pass the corrections. And I have thought about using NTRIP, so that may be in my future.
BUT HERE IS THE BIG NEWS: I GOT THE C94-M8P WORKING WITH THE PIXHAWK over the weekend. I have written up the instructions and plan to post it. I am unsure if I should just post it in a message here (it is about one and a half pages) or some other way. I may have gone into too much explanation with it, but I would have loved to have had something fully described when I started trying to do this.
Basically, the problem was that the C94-M8P, if using the built-in telemetry radios for RTCM must use 19,200 baud and Ardupilot can’t send config to it. Ardupilot configured the Pixhawk for 115,200 baud. I could not find in the code where to change that behavior. I had the parameters set for Serial 4 to be 19,200, but it was still 115,200. Not being able to find how to fix, I did kind of a klugey thing. I inserted an Arduino Due between that received 19,200 and transmitted 115,200. I configured the C94-M8P for 5 Hz at 19,200. Worked great. I wrote a much longer description but that’s the gist of it.
19,200 is rather slow, I highly recommend not doing that. The minimum message set we are looking for will use 65% of the bandwidth, and will delay the reception of the GPS data by a minimum of 131 milliseconds. This will exceed the amount of lag that the EKF is configured to handle, giving up the ability for the driver to manage the GPS limits the ability to configure and check for errors. If you are comfortable with brining an Arduino into the equation why not use that to inject the RTCM stream via MAVLink encapsulation and allow the driver to function as needed? The GPS driver requires 38,400 baud as a minimum if auto configuration is turned off, as lower rates have proven to have significant issues in the past.
Basically my emphasis here is that you might be able to get this to work, but the configuration of the messages will be tight on available bandwidth, and potentially quite error prone. (If you have too many messages turned on your GPS will slowly lag further and further behind, or periodically skip updates).
The C94-M8P radios can be programmed. Although the default radio baud is 19200 it seems that it can be changed
From the manual
The C94-M8P application board uses a HM-TRP radio modem with SiK open source firmware, which supports a subset variant of the Hayes “AT” modem commands for advance configuration.
It seems by using PUTTY or similar the following parameters can be altered
This would be expected as these are the same type of radios used by Mission Planner
As yet I have not tried to do this as I currently do not have the time, in case something goes wrong.
So if the baud rate can be increased will the C94 work with the Pixhawk ???
Regarding frequency of rctm messages sent from the base to rover. On page 14 of the above manual it states the following.
The last paragraph clearly states that the rover can update the gps position @ 5Hz whilst the corrections can only be sent from the base to the rover @ 1Hz.
The NEO-M8P UART1 port is connected to the radio modem on the application board to transmit the correction data. Hence the UART1 port must be selected as the source for all RTCM messages. To do this, use the UBX-CFG- MSG messages as shown in Figure 5 and Figure 6. The following points should be considered when selecting RTCM message configuration:
• A default of 1 Hz Navigation Rate is recommended for the Base and Rover.
• It is recommended that RTCM messages should be configured to be output at 1 Hz. The output rate must
match the Base station navigation rate, which is 1 Hz by default.
• Individual RTCM messages should be configured at the same rate, except for message 1230.
For customers requiring a higher update than 1 Hz at the Rover, the Rover can be configured for either 5 Hz (Dual constellation) or 8 Hz (GPS only) maximum rates but the Base must remain at a default of 1 Hz. The update rate of the RTCM3 messages sent from the Base should remain at 1 Hz and will not affect the accuracy of the Rover. N.B This is not supported in moving baseline operation.
@WickedShell That is good information. I had not trouble with several hours of operation at 19,200 but that doesn’t mean it wouldn’t fail at some point. AND, when I say no trouble, I may be deceived. I did not get the PID tuning done very well yet. I am taking a step back now to finish some things on the mower before I really get back to testing and tuning. I will post my results later. Thank you for the help.
@maxbirley I may look into changing the radio baud rate but I believe range would be reduced. I need to finish trialing what I have first. It seems to be working perfectly, BUT, @WickedShell is suggesting that the GPS data could begin to lag and then data become lost. I cannot say yet if that is happening. It may be. I appreciate all these ideas.
If you have a long log if you look at the GPA.Delta messages you will see the time in milliseconds between parsed positions. This should always be around 200 milliseconds +/- 20 milliseconds. If you see jumps on the order of 400 milliseconds this indicates an error.
Thank you for that. I was wondering how I would tell if packets are being lost, other than by erratic behavior. I have a lot to learn about the logs, status words, etc. This is amazing, full-featured software. I have held back from further testing until I can get a few things in better shape, such as an emergency stop. I have not had the time to get much done either. I hope to be ready for more testing tomorrow evening, though.
It won’t tell you if it drops the DOP messages/HW debug messages, but those are not that important. The main one it will let you know is if you miss a PVT message, which is very important.
Hi Kenny
I will start on this again next week. If you have a detailed write up on this I would appreciate a copy so I do not need to start at the beginning again
regards
Max
Yes, Max. I wrote up a nice document and was very proud of it, but after the cautions here, I said “oops, don’t be so cocky, boy!”. I may have problems I don’t know about! But, I will edit it a bit and share it. What is the best way to upload a Word document or is that a bad thing? I could just cut and paste the text in a message. It is about 1.25 pages in Word. I plan to add figures to it at some point, but right now it is just text so I could put it all in a post.
As far as what messages are needed, what I did when trying to figure out why Ardurover wouldn’t see my C94-M8P (before I discovered it was simply a baud rate thing), I bought a Ublox M8N, which is widely used. I soldered pins to it’s transmit and ground and hooked up a 3.3V TTL serial to USB converter to those while connecting it to the Pixhawk. The only messages I saw (very short duration session, however) were these 5: 0A-09 MON-HW, 0A 0B MON-HW2, 01-06 NAV-SOL, 01-07 NAV-PVT, and 01-04 NAV-DOP. So that is all I have my C94 doing and I have had good results. If all 5 of those are sent each cycle, it is 290 bytes, but most cycles after a FIX occurs just sends the 01 messages. With 290 bytes, at 10 bits per byte (start and stop bits counted), there are 14,500 bits per second required IF, AND A BIG IF, there are no delays in the system for other stuff.
@maxbirley Here is a link to the DRAFT of the documentation on using the C94-M8P with the Pixhawk. I certainly don’t claim that all is well, yet! Let me know how it goes for you. I hope to be roving again by Saturday. Link: DRAFT of C94-M8P Instructions
Only one comment. When I use my c94-m8p rover I use pin 10 on he j8 connector as the TX for transmitted gps data to the pixhawk. If I hook up the rx it would be to pin 9.
You are using pin 13 to transmit gps to pixhawk. According to the manual that pin is RDX-EXT.
Can you explain
Regards
Max
TXD_GNSS that you are getting on pin 10 is directly from the M8P module. The one I am getting is from an AND gate of TXD_GNSS and a signal from the DB9 RS232 port (after a level converter). So, unless something is plugged into the RS232 port transmitting data into the board, we are getting the same data. I chose pin 13 based on this statement on page 29 of the C94-M8P User Manual: “Pin 13, pin 14, pin 20 and any of the GND pins are for connecting to u-blox C027 and other application boards. It enables communication alternatives using u-blox cellular and short-range technologies.” Pin 13 may be a better choice to drive a signal off the board because the signal is buffered by an AND gate. The data sheet for the AND gate doesn’t show that it has much drive capability, though, but it is likely still more than the M8P module. I haven’t checked.
Pin 9 and pin 14 are routed through gates to the same receive pin on the M8P module, but we really can’t use them I think since the RTCM data is coming in on that pin as well from the radio (on a stock unmodified board, at least).
Well, I had a great afternoon! I finished the safety cutoff so that I can kill the mower from the RC if necessary and if it loses communication with the RC for 20 seconds, it kills itself. Then I started tuning. I got pretty good results after a while. I still can improve, however. @WickedShell, I see 220 mSec in the GPA2.DELAY file which is from a run that lasted close to 2 hours. Near the end, there is an anomaly with a 280 mSec. I was probably driving back into the shop in manual mode at that point, but I don’t guess that should have affected the GPS. I am attaching the .bin file here for any comments from anyone. I had some earlier logs where it went to 250 mSec several times.
