Ill watch Kenny’s video, thanks for all your help!
@SJohnson I have caught up on the posts from the last day or so above. In some of my videos, I was configuring my Ardusimple boards manually in UCenter as I was using a baud rate on UART2 on both boards that was different from the 460800 that configured by Ardupilot if you set GPS_AUTO_CONFIG=1. I think you are trying to do the same. But, it was a great day when I realized that my Adafruit Feather LoRa boards supported 460,800 baud and so I was able to got back to GPS_AUTO_CONFIG=1 and let Ardupilot set it all up.
I just looked at the manual on the XBEE SX module that you are using, and found good news! That module supports 460,800 baud. So, I think you can simplify your setup considerably, unless I am missing something. You will need to set the buad rate on the XBEE SX to 460,800 using the XTCU utility. I have not used an XBEE module before but that is what I see mentioned on the web. I assume you are familair with that to make changes to the XBEE.
I am NOT talking about changing the over-the-air transmission rate. That is independent of the rate that the module uses to talk to the SimpleRTK2B. The command I see referenced is BD. According to page 82 of XBee/XBee-PRO SX RF Module User Guide, Rev. B (hzyundi.com), you can set it to 460,800 using a value of 9. Again, I’m not sure how the software works, but hopefully you are.
If you can set your XBEE up to 460,800 baud, then life gets much simpler. We can let Ardupilot do all the work and stay out of Ucenter.
Are you familiar with configuring the XBEE?
1 Like
Well Kenny, I am sorry to say that I am not familiar with configuring an X-Bee radio, but I wasn’t familiar with most of this before I started, but I can learn. I will download the XTCU utility and start looking at it. I assume the matching radio in the base station can stay configured at 115,200 even though the receiving radio will be at a baud rate of 460,800.
I did discover something else yesterday after I watched your video on configuring the moving base and rover RTK2B GPS boards. I noticed that after you let Ardupilot configure your boards, you did the reboot, and then showed the status of both GPS units, the rover showed RTK Fixed. As you mentioned in the video, this was because both boards were the same baud, the RTCMv2 data generated by the moving base will be sent to the Rover GPS (even thought the moving base is not yet connected to the base station. So I set my boards up in the same manner. I just removed the radio from the rails on the moving base and let Ardupilot configure the boards and did my re boot. Much to my surprise I did not have an rtk Fixed indication on the rover GPS. It tells me that one or both of the cards is not configured right or something is just broken. I did have my wire attached between the boards. I probably need to redo that configuration in Adupilot to see if I get the same answer. I did put the moving base board back on U-Center and the baud rate of UART2 was changed to 460,800, which tells me the configuration did take place (I had it set at 115,200).
Thanks for the information on the X-Bee radio baud rate change. This will make my life easier (and for everyone else that is going down this path). I will definitely jump in and learn how to reconfigure X-Bee radios.
My hat also goes of to @Yuri_Rage for his ability to see through problems and help everyone. His help in getting through this problem has bee amazing.
1 Like
Steve, let’s not worry about the XBee radio for now (remove it) and just get the two boards working with the autopilot in a moving baseline config, first.
Set the following:
GPS_AUTO_CONFIG=1
GPS_DRV_OPTIONS=1
Attach a copy of your saved parameters when this is done, and let us know what indications you see.
In the meantime, you can see about getting the XBees configured for 460800 (both of them).
1 Like
That sounds like a good plan. It looks like we are in a thunder storm most of the day here in East Texas, getting some much need rain and I don’t think my satellite antennas could even see the sky. We needed the rain, but it will make my grass grow. I’ll get you the information very soon.
Well Yuri I checked the parameters you ask me to set and they were both already set to 1.
GPS_AUTO_CONFIG=1
GPS_DRV_OPTIONS=1
Here is a screen grab after the reboot today.
Here is a picture of the boards hooked up with the wire connecting between them.
Here is also a copy of the saved parameter file.
Rover Paramater list 071422.param (15.0 KB)
The moving base is plugged into GPS1
The Rover is plugged into GPS2
The crossover wire is connected from (GPS1) moving base’s pin labeled RX2 to the (GPS2) rover’s pin labeled TX2.
I don’t see any smoking guns in the parameter file.
Have you updated the F9Ps to the latest firmware? 1.32 is current, but you at least need to be up to 1.13. They usually ship with 1.10 onboard, which has known issues.
How many satellites are in view?
How long are you waiting after powering on?
We can also try setting GPS_DRV_OPTIONS=0 with the present configuration to see if that makes a difference.
It may also be useful to go back into uCenter and revert both boards to default. I’m pretty sure Kenny shows that in his video.
1 Like
Shouldn’t that crossover wire be reversed?
(GPS1 Tx to GPS2 RX)
@swebre, nope!
ArduSimple’s pin labeling is counterintuitive. The pins are labeled to be coincident with the ones on the XBee radios, such that the XBee TX pin aligns with the SimpleRTK2B board’s TX2 pin, and likewise for the RX pins. Kenny discovered this a while ago, and it’s quite maddening!
1 Like
Interesting. Never mind. Carry on!
Well Yuri I updated the Firmware on both boards to 1.32 and reverted both boards back to default settings.
The result after that was no change, they both still showed 3D dgps.
I set the GPS_DRV_OPTIONS =0 and the the rover GPS2 showed RTK Fixed
At his point I will have to pull both boards off and set the UART2 baud rate to match the radio, plus I will have to turn off Auro config. Or maybe I only have to configure one board if GPS2 is getting it’s correction by other means. Because when I removed the jumper between the boards, it had no affect (it still showed RTK Fixed) The wire has been off now for at least 30 minutes
I can re install the radio back on GPS1 (the moving base), if you think it can work that way.
I am pretty sure it will make GPS1 change to RTK Fixed.
There has constantly been 24-27 satellites in the sky.
The heading does change when i move the board that has the GPS antennas mounted to it and it seems to point the correct direction.
My Firmware on the Cube is version 4.1.3 (could that be causing problems)?
That is progress!!! DO NOT install the radio yet!
Leave the configuration as is with GPS_DRV_OPTIONS=0 and see what GPS2_RAW.yaw shows.
Yes, drop down the GPS2_RAW section and look for the yaw value.
Let me explain. What we are doing is proving that you have ANY kind of valid moving baseline configuration. And you do!
We used GPS_AUTO_CONFIG=1 to make sure the GPS modules are “talking” to the autopilot in a predictable manner. Setting GPS_DRV_OPTIONS=0 ignores the crossover cable between the modules and routes RTCM3 through the autopilot.
Using MAVLInk inspector, we see that GPS2_RAW.yaw now shows a valid value of 19135, which indicates a heading of 191.35°. Something works!
Next, we should get the crossover cable working properly. Set GPS_DRV_OPTIONS=1, reconnect the cable, and see what happens. If you do not get a valid yaw indication like we just saw, reverse the TX2 and RX2 connection between the boards.
I set GPS_DRV_OTIONS=1, put the cable back on the way we had it. Everything went back to 3D dgps on both GPS units. I then disconnected the RX to TX wire and put on the TX to RX wire. It made no change. Now there is no RTK fix and the heading seems to be pointed the wrong way.
I noticed some comment on the blog about serial3 and serial4 options. Mine are both showing zero. It seemed like they were 768 or something like that when GPS Yaw was being tested. I am grasping at straws here!
Don’t mess with those. That was a DMA developer debug setting that is no longer relevant for the use case.
There is no need for straw grasping. Things are beginning to work.
I think the next step is to revert both boards to default in uCenter and then try again (still without the XBee).