UAH student Seth Schmidt question

[SethWSchmidt]

Jacobjhansen,

This is Seth Schmidt. I am a senior EE student at the University of Alabama in Huntsville, and our senior project is similar to yours. If we were to create a project similar to yours, but wanted a cheaper option than the Zed product that you showed here, do you have any recommendations or some system requirements for the RTK board needed for this project?

For example, would this product meet the requirements for this project?
https://www.sparkfun.com/products/15005

Thank you for your time and let me know if you have any questions,

Seth Schmidt
sws0011@uah.edu

[jacobjhansen]

Hi Seth,

We've seen great success with the ZED F9X series, however I'm not familiar with the NEO series. Upon reading the data sheet, it looks like the NEO product you linked would perform just fine in a base station scenario, but the data sheet does specify slightly worse performance than the ZED F9X series. However, it's hard to say exactly what performance would look like without testing. If you do a proper PPP survey, wait to post process the data with CSRS or OPUS, and then set up the NEO as a static base station, chances are you'll see pretty good performance.

Cheers,

[SethWSchmidt]

Thank you so much for getting back to us. This is so useful.

I noticed on your RTCM-Pi interconnect diagram, specifically on the X3 (ZED) block, you used both Rx/Tx and Rx2/Tx2, while the NEO has just one Rx/Tx. Do we need all four ports? It appears that the extra ports in your setup are involved with RXM-RAWX, and we are unfamiliar with what that is.

[jacobjhansen]

You won't actually need both UART channels, my configuration is designed to reduce configuration changes required to switch from PPP surveys to standard base station operation. Essentially, I always have one UART channel transmitting RXM-RAWX messages for PPP, while the other UART channel only outputs messages required for RTCM3 to a cloud NTRIP Caster. This allowed me to take PPP surveys or log RAWX data while still performing standard base station functions, which may not be required for your application.

With only one UART channel, you can instead just configure the transmitted UART messages depending on whether you're taking a PPP survey or transmitting RTCM3 messages. Or you can just implement better message filtering.

TLDR, you only need one UART channel, it just requires a bit more configuration or message filtering.

Hopefully that makes sense!

[SethWSchmidt]

That does! Thanks again for your help! I think we're going to go with the ZED series.

If you want to see our final result, I'd be happy to send our final presentation after finals.
Would you like to be put down as a reference?
Zero pressure to do either, but you were helpful so I wanted to offer!

Regards,
Seth

[SethWSchmidt]

I had one more question:

In the section where you discuss the obtaining of the PPP, you mentioned waiting 24 hours to get the raw data. Then, we convert the .ubx to a .obs. The next step is to wait 2 weeks, then send the data to a PPP processing center. My question is what is the 2 weeks waiting for, if we already have the raw data and have not yet sent the data to a PPP center?

Thank you,
Seth

[jacobjhansen]

Hi Seth,
I'm not an expert on the actual calculations behind PPP, so apologies on a non-technical answer here. From my understanding on the topic, the predicted orbits of satellites used in positioning are often off by a few meters, which leads to inaccuracies in calculations. To mitigate this, PPP services use ephemeris (or ephemeride?) data which essentially corrects the orbit data after the fact. And these ephemerides can take up to 2 weeks before they get properly updated.

Another thing recommended by others is to wait one day after a survey, get it processed by PPP, and start using it as a base station. Then after 2 weeks, re-process it by PPP, and update your basestation with the updated coordinates.

TLDR: If you turn in your survey data right away, you'll get decent accuracy from PPP. If you wait one day, you'll get better accuracy from PPP. If you wait 2 weeks, you'll get the best possible accuracy from PPP.

[mrsethalonian]

Thank you! That helped us a lot. We have another question as we begin physical testing (FYI this is Seth still, just on an alternate account non-school account).

The team and I have all the components now. We can successfully collect GNSS data from the ZEDs. However, we ran into issues when running the timeout serial command for the raspberry pi. When doing so, we get the following error (we did it once for 2 minutes, and then a second time for 24 hours):

We are not sure what the issue is. We are guessing either it is the command itself (above), or instead it could be an incorrect config.txt file for the pi. For the config.txt file, we found the file on the microsd card, opened it in notepad, and then added the bottom four lines to the bottom of the file:

Do you happen to know what this error is, and how to solve it?

Thank you for your time and help, and I hope you have a good day.

[mrsethalonian]

After doing some research, we figured out that the GPIO pins may need to be configured for UART, since by default the Pi only has one set of UART pins. Do you happen to know how to do this for the pins used in the design?

[jmagnuson]

Setting the dtoverlay for both UART4 and UART5 should be enough to enable them. Assuming the connections to the Pi header are correct (21/24 for RX4/TX4, and 33/32 for RX5/TX5), then it should just be a matter of verifying the serial devices used exist and are correct. I would check what /dev/ttyAMA* devices exist-- they could be getting enumerated as ttyAMA4 and ttyAMA5, for instance.