My apologies in advance if some of these issues have already been discussed in the repo's issues or feature requests. Likewise, I want to congratulate @Stefal and the other contributors to rtkbase. This software is, for me, a great example of what can be achieved by joining forces to achieve "Accuracy for the Masses."
Unicore Communications GNSS modules seem to have been groundbreaking in 2022-2023. Specifically, the UM980 module is a triple-frequency receiver with 1408 channels. Other modules, such as the UM982 (dual antenna for heading) and the UM981, have similar features. Although their RTK solution algorithm (based on the GNSS SoC-Nebulas IV) is good, it seems that the ZED-F9P outperforms it. But the ability of the UM980 to observe multiple frequencies and track various signals is unparalleled in terms of cost-effectiveness. Many electronics retailers are assembling boards with this module (many in China, but also SparkFun, GNSS store, among others). In fact, as far as I know, some or many of the GEODNet bases use the UM980.
In the notifications I receive from rtkbase, I read that there are plans to support Septentrio modules, so it might be interesting to consider these modules as well. If the decision is made to expand support to Unicore, I can help (with my basic knowledge) in this regard. I have conducted some experiments with the UM980, and it seems to have great potential. On the other hand, rtkbase is a great piece of software, and Unicore receivers can make a good pair with it.
Recently, I finished assembling a DIY receiver based on the UM980. Specifically, I built a receiver ready to be used in the field: waterproof, with a long-lasting battery, charged with a solar panel, etc. I posted a sneak peek of the receiver capabilities here and here. I intend to use this receiver as a moving base since, as a rover, it does not outperform the ZED-F9P in obtaining RTK-fix solutions. Since I have already built several receivers based on the ZED-F9P, constructing one based on the UM980 wasn't challenging for me. However, the software part required a specific solution, and that's why I thought of using rtkbase for it. The software part needed a specific solution, and that's why I thought of rtkbase for it.
I started my solution as something personal and slightly hardcoded, which I placed in my rtkbase fork (https://github.com/geofis/rtkbase) in the "unicore" branch. The development I did consists basically of the following. The main service, when started, configures the receiver using a command file (.cmd file) to make it work primarily as a base for obtaining coordinates and date/time and to collect raw observations in a file. The command file configures the module to transmit RTCM3 messages from COM1 (UM980 has 3 COM ports), specifically MSM messages, as well as navigation messages from each constellation (excluding position and/or antenna messages). This way, the main service sends RTCM3 messages to the preferred TCP port, although I chose 5015 (default) to not break the dependency on gpsd/chrony (see more below). UM980's COM1 is connected to the Raspberry's USB port through an FTDI, so you need to use something like "ttyUSB0" in the rtkbase main service. Additionally, the output format must be configured as rtcm3 in the main service. I added the -b flag to str2str to be able to relay back with the module and send it commands, although this undoubtedly poses vulnerabilities.
On the other hand, the command file also configures the module to transmit the NMEA GPRMC message through COM1. This is useful for fixing the system time with gpsd/chrony, very useful in my case, as I will use this equipment as a mobile base where internet connectivity could be null.
Finally, the command file configures the module to transmit raw observations through COM2 (connected to the Raspberry's UART, "ttyS0"), to be used by the file-saving service. This is the main difference from the original rtkbase, because in this case raw observations come out through another port and cannot be collected from TCP to create the file of raw observations. However, I am convinced that the ideal solution would be to send messages in Unicore's native format to TCP so that rtkbase could process the streaming with rtkrcv and generate a PPP solution (just as it does with U-Blox). Still, RTKLIB (the original and demo5) does not recognize the Unicore format. The files generated by Unicore modules can be in two types, ASCII or binary, and are converted to RINEX with a Unicore tool called "Converter" (only for Windows, but it works with Wine from Linux as well).
Although Unicore Communications support does not compare to U-Blox's, the module is extremely cheap for all it offers. Finally, I reiterate that I am willing to support a functionality for rtkbase. I am not an expert in Flask, although I understand it, but I offer my support as far as my knowledge reaches.
My apologies in advance if some of these issues have already been discussed in the repo's issues or feature requests. Likewise, I want to congratulate @Stefal and the other contributors to rtkbase. This software is, for me, a great example of what can be achieved by joining forces to achieve "Accuracy for the Masses."
Unicore Communications GNSS modules seem to have been groundbreaking in 2022-2023. Specifically, the UM980 module is a triple-frequency receiver with 1408 channels. Other modules, such as the UM982 (dual antenna for heading) and the UM981, have similar features. Although their RTK solution algorithm (based on the GNSS SoC-Nebulas IV) is good, it seems that the ZED-F9P outperforms it. But the ability of the UM980 to observe multiple frequencies and track various signals is unparalleled in terms of cost-effectiveness. Many electronics retailers are assembling boards with this module (many in China, but also SparkFun, GNSS store, among others). In fact, as far as I know, some or many of the GEODNet bases use the UM980.
In the notifications I receive from rtkbase, I read that there are plans to support Septentrio modules, so it might be interesting to consider these modules as well. If the decision is made to expand support to Unicore, I can help (with my basic knowledge) in this regard. I have conducted some experiments with the UM980, and it seems to have great potential. On the other hand, rtkbase is a great piece of software, and Unicore receivers can make a good pair with it.
Recently, I finished assembling a DIY receiver based on the UM980. Specifically, I built a receiver ready to be used in the field: waterproof, with a long-lasting battery, charged with a solar panel, etc. I posted a sneak peek of the receiver capabilities here and here. I intend to use this receiver as a moving base since, as a rover, it does not outperform the ZED-F9P in obtaining RTK-fix solutions. Since I have already built several receivers based on the ZED-F9P, constructing one based on the UM980 wasn't challenging for me. However, the software part required a specific solution, and that's why I thought of using rtkbase for it. The software part needed a specific solution, and that's why I thought of rtkbase for it.
I started my solution as something personal and slightly hardcoded, which I placed in my rtkbase fork (https://github.com/geofis/rtkbase) in the "unicore" branch. The development I did consists basically of the following. The main service, when started, configures the receiver using a command file (.cmd file) to make it work primarily as a base for obtaining coordinates and date/time and to collect raw observations in a file. The command file configures the module to transmit RTCM3 messages from COM1 (UM980 has 3 COM ports), specifically MSM messages, as well as navigation messages from each constellation (excluding position and/or antenna messages). This way, the main service sends RTCM3 messages to the preferred TCP port, although I chose 5015 (default) to not break the dependency on gpsd/chrony (see more below). UM980's COM1 is connected to the Raspberry's USB port through an FTDI, so you need to use something like "ttyUSB0" in the rtkbase main service. Additionally, the output format must be configured as rtcm3 in the main service. I added the
-bflag tostr2strto be able to relay back with the module and send it commands, although this undoubtedly poses vulnerabilities.On the other hand, the command file also configures the module to transmit the NMEA GPRMC message through COM1. This is useful for fixing the system time with gpsd/chrony, very useful in my case, as I will use this equipment as a mobile base where internet connectivity could be null.
Finally, the command file configures the module to transmit raw observations through COM2 (connected to the Raspberry's UART, "ttyS0"), to be used by the file-saving service. This is the main difference from the original rtkbase, because in this case raw observations come out through another port and cannot be collected from TCP to create the file of raw observations. However, I am convinced that the ideal solution would be to send messages in Unicore's native format to TCP so that rtkbase could process the streaming with rtkrcv and generate a PPP solution (just as it does with U-Blox). Still, RTKLIB (the original and demo5) does not recognize the Unicore format. The files generated by Unicore modules can be in two types, ASCII or binary, and are converted to RINEX with a Unicore tool called "Converter" (only for Windows, but it works with Wine from Linux as well).
Although Unicore Communications support does not compare to U-Blox's, the module is extremely cheap for all it offers. Finally, I reiterate that I am willing to support a functionality for rtkbase. I am not an expert in Flask, although I understand it, but I offer my support as far as my knowledge reaches.
José.