So, I am hoping someone can point me to where to make Ardupilot set the serial port to 19,200 and I won’t need the Arduino Due in the middle.
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).
Referring to the Application Board user guide
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
Index Parameter Name
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.
I will work on this again next week as I just received some upgraded antenna that I want to try out.
Regarding the list of UBX messages can any of then be ignored to save on bandwidth? Some of them from memory do not contain any position data
Also which messages could not be sent from U - Center?
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
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
Nice write up.
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
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).
I hope that make sense???
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.
My file upload is not completing. It stops at various % completion. Made it to 96% one time, 92% another… The file is located here as an alternate: https://www.dropbox.com/s/npd16lxub50tdb1/2018-05-12%2023-25-39.bin?dl=0
Glad you had a good day and made progress.
Hopefully I will start testing late next week when my new antennas turn up
Are there any particularly important Mission Planner Params that need to be set for this to work
I have played with so many parameters, that I’m not sure! I will send you my parameters and try to point out ones I specifically worked with.
I still don’t have a good compass working. I have tried the internal one and I have a module with an M8N GPS and compass. I didn’t really want to connect the GPS right now since I have the C94-M8P and didn’t want to confuse myself with a second compass that was not RTK. But, the power and ground are only in the GPS connector and not the I2C that is where the compass connects. I moved the power and ground to the I2C connector and I don’t think it is working. I just disabled it for now.
I am getting BAD AHRS sometimes even when I have a good GPS signal. I’ve got to dig into that. I wonder if it is that I am losing data from the C94-M8P but I really detected that.
I took video from my pickup truck as I followed the mower across the field (in Auto). That was pretty cool. I had a busy day today with my hay fields and didn’t get to touch the project until just before dark. We have rain forecast for the next several days so I may catch up on making some things more permanent!
I will work on sending you some info on how I have the parameters set and I’ll send links to the videos. I’ll put them on YouTube.
I look forward to hearing how things go for you!