A quick Google search will bring up several options for receivers based on the u-blox F9P dual frequency module but finding receivers based on the single frequency M8T receiver is more difficult. I am a regular user of the CSGShop M8T based receivers. Other than some often-counterfeit options available on Ebay or similar sites, CSGShop is the only reliable source I am aware of for M8T based receivers. CSGShop appears to have recently changed their name to GNSS OEM, but I haven’t got used to their new name yet so for this article I am going to continue to refer to them by their original name. I have been very happy with these receivers, have been recommending them for several years, and will continue to recommend them. However, I recently received a single frequency RTK capable receiver from Uputronics based on the u-blox M8 chip for review that is worth considering as an alternative.
The u-blox M8T module is based on the u-blox M8 chip combined with a crystal oscillator, flash, and several other discrete components. The photo below shows a u-blox receiver module with the cover removed. The chip in the middle of the board is the M8. In this case the module is an M8N but should look nearly identical to the M8T.
The Uputronics receiver does not use the M8T module but instead builds its own module starting with the M8 chip combined with a TXCO (temperature controlled crystal oscillator) with specs very similar to the M8T and adds the necessary discrete components. It is running similar or identical firmware to the M8T and like the M8T provides raw observations.
The price for a CSGShop receiver sent to the U.S is $79 +$10 shipping. The Uputronics receiver sent to the U.S is $41 +$11 shipping. It also appears to be available in the U.S from AirSpy.US for a couple dollars more but would presumably have faster shipping. CSG shipping times do tend to be quite long, sometimes taking several weeks to the U.S. so for some users this could be a significant advantage.
Here is a photo of the two receivers with the Uputronics receiver on the right.
So how do they compare? Functionally they should be very similar since they are both based on the M8 chip and firmware. However, there are still some fairly significant differences between them. First of all, as you can see in the photo, the Uputronics is quite a bit larger despite most of the board being empty. This is because it is designed to fit as a hat onto a Raspberry Pi. The large connector in the foreground is designed to connect directly to the GPIO bus on the Pi. The CSGShop receiver in the photo has a USB interface connector but it is also available with a UART connector instead. The Uputronics board has the UART connections through the Pi connector. For someone just getting started with precision GPS, I prefer the USB interface since it can easily be plugged directly into a PC, but with a little work the UART connection can be translated through an FTDI module to USB and then also plugged into the PC. For connecting to a Pi, or Arduino or other embedded application, the UART interface is usually preferable.
After the interface connector, the most noticeable difference between the two receivers is the lack of non-volatile memory on the Uputronics board. Often, the easiest way to configure a u-blox receiver is to connect to it through the u-blox u-center app on the PC, set it up as desired and then save to flash. This is not an option on the Uputronics board so instead the receiver needs to be configured each time it is used. RTKLIB does provide an option to configure the receiver each time it is run so in principle this is only a minor inconvenience. Unfortunately, the receiver defaults to 9600 baud and this normally need to be increased to 115K baud to provide enough bandwidth for the raw observations. This makes it a two step process, first running RTKLIB at 9600 baud to configure the receiver settings and baud rate and then a second time with the baud rate set to the higher rate. It is not difficult to write a python script to take care of this two step process but it does add unnecessary complication for the beginner user. Fortunately Uputronics says they plan to change the default baud rate to 115K in the near future which will simplify this step.
[Update 9/15/20: See Clive’s comment in the comment section below for a link to instructions for permanently changing the baud rate to 115K. This makes things much easier since the rest of the settings can easily be handled with a .cmd file from within RTKLIB.]
Since the Uputronics board is designed to be attached directly to a Raspberry Pi, I chose this configuration for testing. For comparison purposes, I also connected a CSGShop M8T receiver by USB cable to the Pi4 I used for the experiment as shown in the image below.
I used the STR2STR application in RTKLIB to configure the Uputronics receiver and to stream both receiver outputs wirelessly over TCP/IP and a cell phone hot spot to my laptop where I ran two real-time solutions using RTKNAVI. I hope to write another post in the near future describing the details of configuring the Pi but for now the best I can do is refer you to a slightly out-of-date post I previously wrote to describe logging the results to a file on the Pi. I could have also run the real-time solutions on the Pi using RTKRCV but I will leave this to a future post as well.
So, now we have the two receivers up and running, let’s do a performance comparison. For this, I did my typical drive around the neighborhood with each receiver connected to its own antenna mounted on the roof of the car and used a u-blox F9P receiver at my house with a survey grade antenna on the roof as base station.
I had tested an earlier version of this board in a similar experiment and had got nearly identical results with both receivers so had expected the same for this experiment. Surprisingly, the Uputronics board performed significantly worse than the CSGShop board as seen in the image below. The Uputronics solution is on the left.
In addition to a much higher percent of float solution points on the Uputronics solution, it also has many more missing samples. At first I suspected a communication problem but when I looked closely at the raw observation files I see that this is not the case. Here’s an example from the raw observation file from one of the missing epochs in the solution. The fourth column is the phase observation and the fifth column is the quality metric value from the receiver. The fifth field in a rinex file is normally an older rarely used SNR field but the demo5 version of RTKLIB reports the quality metric for u-blox receivers instead. Any phase observation with quality metric over 5 is discarded during the RTKLIB raw to rinex conversion which is why the fourth column is mostly blank in this example.
I ran the experiment a couple more times to make sure this was not a fluke and got similar results. The only significant difference between this experiment and the previous one I had done on the earlier version of the board was that in the previous experiment I had not used the Pi, I had connected the UART pins through FTDI directly to my laptop. This made me suspect that the close proximity of the Uputronics board to the Pi was allowing it to pick up some electromagnetic interference (EMI) from the Pi.
There are only four pins on the GPIO interface between the two boards that are necessary for the receiver (+3.3V, Gnd, RX, and TX) so I soldered a few wires to a couple of headers to separate the two boards as shown below.
The electrical tape on the back of the Uputronics board was part of an intermediate experiment with the board still attached since I realized that the painted metal heat sink on the Pi CPU was actually touching the back of the Uputronics board. The tape seemed to help a little but did not solve the problem.
The purpose of this experiment was to physically separate the two boards but it also reduced the number of connections between them since the Uputronics board, in addition to the receiver, provides a real time clock that uses some additional pins. I’m not sure if it was because of the increased separation or the reduced connections, but re-running the experiment in this configuration got me back to where I was on the previous board where both receivers performed very similarly. Here’s the results from this experiment, again the Uputronics results are on the left.
The CSGShop still performed slightly better (97% fix vs 94% fix) but I think this difference is too small to be meaningful, especially since the two receivers were using similar but not identical antennas.
So, to summarize, I think this receiver is definitely worth a second look. It has a few shortcomings still, but hopefully these will improve over time, and the cost difference is probably significant enough to justify the extra effort for some users. I’m planning to use it myself in an upcoming project and will try to keep readers up to date with my experiences going forward.
9 thoughts on “Review of a new lower cost alternative to the u-blox M8T receiver – the Uputronics M8”
I am using 2 M8T GNSS modules from CSG Shop, I guess the same one from what was shown above.
Even in stationary conditions(i.e. both base and rover are stationary) with Kinematic calculations, I am not even hitting 5 meters of accuracy one would expect from a standard GPS. I am targeting for accuracy of 1 meter.
Following is the result I am getting while both my base and rover antennas are stationary around a meter apart.
I have linked the dropbox folder containing rtknavi.conf file and all test data
Looking forward to your suggestions. Thanks in advance.
Unless I’m missing something there’s no source data in there, so reproducing or analyzing that would be a challenge.
Have you tried post-processing the static base data against an established, perhaps governmental, reference station of some known provenance? Contemporary data from such a CORS would help analysis, and perhaps establish if the base or rover is contributing to the issue.
What type of antennas are used? How are they placed? Do they have clear sky views? Do they have ground planes to block near-in reflections from the ground or buildings?
The ANN-MS (Inpaq) antennas tend to expect to be on a flush metal surface, perhaps minimum of 10 x 10 cm
Hi nemoG. It’s always easier to analyze logged data rather than in real-time so if you are using RTKNAVI I would log the data first, then post-process it with RTKPOST for debug purposes. My first suggestion would be to look at the quality of the raw observations for both rover and base by plotting them with RTKPLOT. Make sure there are minimal cycle slips and/or missing samples and that the observation times overlap between base and rover. The most common causes of poor results are that the antennas are not in unobstructed, open sky environments, or the antennas are very low quality or lacking ground planes, or interference/EMI from nearby electronics. If your observations look good and you are still not getting good results, I would set the debug trace level to 2, then look at the log for clues to what happened. You did not include any raw observations in your link so I was not able to check.
Update… just spoke with the company .. all boards which have been sold over the past 6 months are hard set to 115 Baud rate.
I bought two Uputronics GPS Hats in 2021 and they are the new version 6.1 with flash memory and USB port. Making them the almost ideal device for RTK experiments. I use one with my RPi Zero WH (rover) and the other with a RPI 4 as base station.
This might naïve question for you , but I am new and trying to figure out a low cost solution for a robot navigation.
Can two of these receiver(one as a rover one as station) be used for RTK GPS system?
Hi Masoud. Yes you can use any two GNSS receivers for an RTK solution with RTKLIB as long as both receivers are able to output raw observations.
Baud rates should be fusible
Click to access MAX7-NEO7_HardwareIntegrationManual_%28UBX-13003704%29.pdf
The other thing here would be the ability to sustain 10 Hz and pulling all constellations
Hi Clive. I didn’t realize until just now that your comment includes a link to instructions on how to actually change the default baud rate permanently. That is very useful, I’ve updated the main body of the post with a reference to your comment. Thanks!