Add support for operating Unicore modules (e.g., UM980).

[geofis]

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.

José.

[tomischmid]

I also think it would be great if an inexpensive receiver like the one from Unicore could be used for a base station.
I own a UM982 and use it to steer my tractor. There is a discussion thread: https://discourse.agopengps.com/t/is-the-um982-an-f9p-killer-for-aog/13960/250
There is also a Telegram group that deals with the base station: (https://t.me/Centipede_RTK)
Your knowledge could be helpful

[geofis]

Hi @tomischmid,

Thank you for sharing your experiences! I've browsed through the discussion thread and found the insights interesting, even though my primary focus is on ground deformation monitoring. I will create an account on the Discourse group soon to continue following the discussions more closely. Regarding the Telegram group, while I'm not a user of the platform, I'm certainly interested in any significant developments or insights shared there that could be relevant to regarding the use of Unicore modules.

The updates that often come from China are incredibly fast and unexpected. Recently, I noticed that one of the brands manufacturing hardware compatible with Meshtastic (an off-grid LoRa network) has included a dual-frequency chip at nearly cost price (I estimated the chip costs around 3 dollars). It's not designed for use as a base station, but it certainly astonishes with its vast capabilities and low prices.

[Stefal]

To add the full support for a Gnss receiver inside RTKBase we need two things:

• A way to detect and configure the receiver
• Raw messages support in RTKLib

As long as RTKLib doesn't support the UM980 binary messages, I can't do anything.
Right now we can only use it configured to output rtcm3 messages, as you already did.

[geofis]

Hi @Stefal

Thank you for outlining the requirements for integrating a GNSS receiver into RTKBase. I understand the limitations regarding RTKLib's current lack of support for UM980 binary messages. However, this may soon change because there are libraries, such as those from SparkFun, that do support Unicore's binary format. In the meantime, I also wonder about the feasibility of supporting Unicore receivers through RTCM messages, since "at least for me" this is already operational. This could be a viable interim solution until native support is possible.

Regarding the detection and configuration of the receiver, I agree this is a challenging aspect, especially considering UART connections for end-users and lifespan of development boards. Perhaps a model from gnss.store might offer a way forward, since they attach a USB via the I2C port. However, there remains a significant hurdle: manufacturers of UM9* development boards do not provide information on the lifespan of their boards. This lack of transparency could pose issues for long-term support and reliability.

I look forward to exploring these possibilities further and contributing to RTKBase's growth and adaptability.

[messplay]

Hello, can you share the converter program to rinex that you use for unicore?

[geofis]

Hello,

Yes, I can share it. Please, give an email address.

[EliuPineda]

You can download here
converter3-0-7.zip or
https://drive.google.com/file/d/1XaesKrsLxrCIEO5RGc21b4w1U36l2d8e/view?usp=sharing

[messplay]

Hello,

Yes, I can share it. Please, give an email address.

thank you very much

[messplay]

You can download here converter3-0-7.zip or https://drive.google.com/file/d/1XaesKrsLxrCIEO5RGc21b4w1U36l2d8e/view?usp=sharing

thank you very much

[geofis]

Oops, sorry, I didn't initially intend to share the executable as I was unsure about the legal implications.

However, I'm sharing it now - a version of Converter that appears to be from June 2023.

Additionally, for what it's worth, I'm also including the most recent firmware I have for the UM980.

Please, follow this link:

https://drive.google.com/drive/folders/1nMwsTC2bJnTUD6gzOcQ0CwUNKpPvmtGZ?usp=drive_link

[messplay]

Greetings, thank you in advance for such a quick collaboration, I take this opportunity to consult you since you have more experience in the UM980, does this module have the option of changing the Datum (just like the zed-f9p has) or does it always work in wgs-84?

[EliuPineda]

Hi @messplay check this reference commands manual, I found it is posible, search for "datum code". @geofis can correct me if I am lost.
unicore-reference-commands-manual-for-n4-high-precision-products-v2-en-r1.2.pdf

[geofis]

Thank you @EliuPineda and @messplay for your posts. As @EliuPineda mentioned, it is indeed possible to use a "different Datum" in the UM980. If I remember correctly, for the ZED-F9P, under the DAT (Datum) option, it's possible to configure datum using various possible parameters, or by using a list of several Datums available. This seems equivalent in the UM980 with GPDTM.

My experience has been quite limited in this regard with the UM980, and it seems that in this receiver, IHO codes are used for datum, or offsets are applied.

However, I think it's preferable to perform these types of transformations in post-processing, mainly because it allows for more parameters to be defined and the epoch to be introduced (e.g. using HTDP https://www.ngs.noaa.gov/cgi-bin/HTDP/htdp.prl?f1=4&f2=1).

[messplay]

Greetings friends, here I am asking more questions, first of all thank you all, you have been really helpful, I hope in time to be able to return the courtesy. Moving on, my question is:

1. What ASCII or Binary (raw) messages should an application record so that they can later be converted to Rinex using the Unicore application?

[EliuPineda]

There is a command that is not specified in docs but works and you can use, is RANGEA COM1 1 for ASCII and RANGEB COM1 1 for binary, when I started to use UM980 I used OBSVM but did not work, even I have a script in which I am working on python to convert the observations to Rinex in real time. Please @geofis correct me if I am lost, I believe @geofis knows more than me, but I like respond questions about I know :)

[geofis]

Hello @messplay, @EliuPineda,

As @EliuPineda pointed out, the commands RANGEA COMX 1 (the "A" for ASCII, X being the chosen COM port) and RANGEB COMX 1 (the "B" for binary) could be used for capturing observables (in this example, at sampling rates of 1 second). Logically, binary files are smaller than ASCII ones, but ASCII files are more easily interpretable by high-level parsers. In addition to these, there is also RANGECMPB COMX 1, which offers a more compressed binary format, but I don't prefer it for long-term data storage (I'll explain more below).

Now, referring to OBSVM*. The command OBSVM[A,B] COMX 1 (again, with "A" for ASCII and "B" for binary) would also do the job of collecting observables, in an uncompressed Unicore format. There is also OBSVMCMP[A,B].

The most significant differences I've found between OBSVM* and RANGE* are:

• The messages collected with RANGEB and RANGECMPB can be parsed as a .gps file format of Novatel (is the UM980 a clone of Novatel just in a different packaging?). A very important detail that might be useful for you @EliuPineda: if you need to track observables in real time with RTKLib (e.g., demo5 from @rtklibexplorer), just configure RANGEB or RANGECMPB output messages and specify the #nov format in the str2str command formation. If you need to use convbin, just specify the input format with the -r nov flag, or simply rename the file to a .gps extension. Also, keep in mind that Sparkfun has a C++ parser that might be useful for you @EliuPineda, in case you want to check it out. The capability of the RANGEB command to deliver messages that can be parsed in real-time using str2str presents a significant advantage, offering potential for seamless integration with @Stefal's rtkbase.

• RANGEB (not RANGECMPB, at least in my tests) allows separation between multiple signals (both in L2 and L1, specifically L1C, not just L1C/A). This might be relevant in geodesy for the future, and this is why I prefer RANGEB over RANGECMPB for storing data, but I'm not absolutely sure of this advantage btw.

All the above messages can be converted to RINEX using the converter tool (the RANGECMPB require marking Rangecmp>Range tick in converter).

Finally, ephemerides cannot be collected with a single command, but must be selected by constellation. This I find to be a good feature, as it allows for easy separation of one from another. For this, you can use the commands *EPHB COMX 30, and thus collect them in binary format every 30 seconds. The converter tool will process them correctly.

Unfortunately and inexplicably, as @EliuPineda correctly notes, the RANGE* log command family does not appear in the NebulasIV command guide, but they are in the Novatel guides. The fact that they do not appear in the NebulasIV guides does cause me some confusion, but as far as I have seen, the messages generated by RANGE* and OBSVM* are similar.

I created example files in passive collections with an antenna placed in a window, all of 90 seconds, testing different log commands: OBSVMA, OBSVMB, RANGEA, RANGEB, RANGECMP. They are hosted here:

obsvma.log
obsvmb.log
rangea.log
rangeb.log
rangecmpb.log

I hope this info is a help to you and anyone else working with these powerful and cheap Unicore modules.

[messplay]

You people are simply amazing.

[Jef239]

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.

It's not true for forest!

Check by gnss.store on winter forest - Unicore is Win!!!
ByNav m20 Fix=499 Float=250 Autonome=30
ByNav m21 Fix=748 Float=31
Unicore um980 Fix=779
Ublox f9p Fix=728 Float=48 DGNSS=3

Check by gnss.store on summer forest - Unicore is Win!!!
UM982_1 63.7% fix
UM982_2 58.3% fix
F9P_1 42.4% fix
F9P_2 40.9% fix

Tracks on google map: F9P UM982

[Jef239]

• Raw messages support in RTKLib

For what?

I made support for UM980 (ELT0229) and UM982 (ELT0219) in UM980_RPI_Hat_RtkBase

I use original RtkBase 2.5.0 and make some changes

• UnicoreSettings.sh fill settings.conf
• run_cast.sh execute UnicoreSetBasePos.sh for setting precise position into receiver
• run_cast.sh also can start TCP-server instead of NTRIP-server for rtkdirect
• detect and configure in the procedure configure receiver in install_script.sh
• NmeaConf - program for Unicore and ByNav configuration
• UM980_RTCM3_OUT.txt - configuration for UM980
• UM982_RTCM3_OUT.txt - configuration for UM982

PPP is work!

Limitation:

• only 115200 yet
• only RPI
• button "Detect/configure" don't work yet
• base coordinates cannot be kilometers away from the real ones

It's interesting for you?

[geofis]

I concur with @Jef239. I've recently conducted tests to achieve kinematic positioning using a UM980 as a base and two rovers, another UM980 and a ZED-F9P. For this setup, I mounted two antennas on the roof of a car: one for the UM980 (link to antenna) and the other (ANN-MB) for the ZED-F9P. I opted not to use an antenna splitter to prevent potential damage to the receivers. The testing context was predominantly open fields (usually agricultural areas) and occasionally under forest canopy, but not urban environments. The RTK-fix proportions for the UM980 were consistently higher than those for the ZED-F9P. Impressively, I achieved over 70% fixed solutions in RTK (even considering limited connectivity at times) and incredibly, up to 86% in PPK, even at distances exceeding 25 km from the base. In contrast, the ZED-F9P only reached up to 50% in RTK and no more than 70% in PPK. The use of L1+L2+L5 frequencies is simply unmatched, which is why I think the UM980 outperforms the ZED-F9P.

However, I've observed certain scenarios, like urban canyons, where the ZED-F9P seems to surpass the UM980. This might be addressed in the UM980 by reducing the solution's reliability (e.g., adjusting the CONFIG RTK RELIABILITY setting). Nevertheless, I want to make it clear that, especially in non-urban settings and with default configurations, the UM980 is superior.

I hope to find time in the future to publish the results and comparisons of my tests in this same issue. As a preview, I can unequivocally say that the performance of the UM980 is truly impressive, decisively outshining the ZED-F9P. These are the results of the PPK processing for the ZED-F9P and the UM980:

ZED-F9P

UM980

[Jef239]

The use of L1+L2+L5 frequencies is simply unmatched, which is why I think the UM980 outperforms the ZED-F9P.

This is not the only reason. And perhaps not even the main one. Unicore has less quartz oscillator noise and less code and phase noise.

However, I've observed certain scenarios, like urban canyons, where the ZED-F9P seems to surpass the UM980.

Urban canyons, winter
ByNav m20 Float=104
ByNav m21 Fix=103 Float=1
Unicore um980 Fix=93 Float=1 DGNSS=10
Ublox f9p Fix=90 Float=14

There is multipath in the urban canyon. And it is changing quickly. To catch slips in such conditions, you need an INS into receiver. Therefore, Bynav M21 wins. And UM981 should also win.

[Jef239]

I made support for UM980 (ELT0229) and UM982 (ELT0219) in UM980_RPI_Hat_RtkBase

Now i release version 1.0.1

Limitation:

• only Raspberry PI
• base coordinates can not be kilometers away from the real ones

All other work well.

@Stefal, you can copy my code in main RtkBase.

[messplay]

Greetings to all, I have a question, I have carried out the process to convert rinex files, using the RANGEB command, however, I see in the header, when I do the conversion that the files are not taking the date and time range of the measurement, they would have Any suggestions on what it could be? Or any suggestions in the configuration, attach the first lines. Attached the log file.
data0.zip

 3.00           OBSERVATION DATA    M                   RINEX VERSION / TYPE

G = GPS, R = GLONASS, E = GALILEO, C = BDS, M = MIXED COMMENT
UnicoreConvert Unicore 20240528 195848 UTC PGM / RUN BY / DATE
UnicoreRoof 001 MARKER NAME
GEODETIC MARKER TYPE
Unicore-001 Unicore HPL EVT OBSERVER / AGENCY
Unicore#001 GEODETIC Unicore UB4B0 REC # / TYPE / VERS
Ant001 ROVER ANT # / TYPE
-1346588.1925 -5818855.2240 2234939.4413 APPROX POSITION XYZ
0.0000 0.0000 0.0000 ANTENNA: DELTA H/E/N
G 8 C1C L1C D1C S1C C5Q L5Q D5Q S5Q SYS / # / OBS TYPES
R 0 SYS / # / OBS TYPES
C 8 C1C L1C D1C S1C C3C L3C D3C S3C SYS / # / OBS TYPES
E 12 C1B L1B D1B S1B C5Q L5Q D5Q S5Q C7Q L7Q D7Q S7Q SYS / # / OBS TYPES
J 0 SYS / # / OBS TYPES
1.000 INTERVAL
1980 1 13 0 0 1.0000000 GPS TIME OF FIRST OBS
1980 1 6 0 0 0.0000000 GPS TIME OF LAST OBS
0 RCV CLOCK OFFS APPL
END OF HEADER

1980 01 13 23 59 0.0000000 0 3
E13 23000066.515 120866165.061 6 -1553.873 38.890
E14 13685621.717 71918426.615 8 -142.193 51.180
E19 20569019.255 108090925.020 6 2067.003 41.590
1980 01 13 23 59 1.0000000 0 3
E13 23000367.989 120867748.526 6 -1559.377 39.130 23000384.096 90258446.992 5 -1164.502 35.190
E14 13685650.068 71918576.426 8 -148.948 51.220 13685658.671 53705463.954 8 -111.238 48.420
E19 20568620.673 108088830.606 6 2061.521 41.660
1980 01 13 23 59 2.0000000 0 4
E13 23000664.181 120869309.769 6 -1563.512 38.980 23000681.444 90259612.853 5 -1167.671 35.360
E14 13685679.327 71918728.039 8 -154.648 51.150 13685687.432 53705577.172 8 -115.468 48.500

[Jef239]

using the RANGEA command

it's not RANGEA, may be you use RANGEB?

Probally, you need RECTIMEB

[messplay]

using the RANGEA command

it's not RANGEA, may be you use RANGEB?

Probally, you need RECTIMEB

Hello Jeff, if you are right, I have already corrected the post (thank you), it is indeed RANGEB, in that case I only have to include RECTIMEB in the port and would the time be recorded for the rinex file?

[Jef239]

in that case I only have to include RECTIMEB in the port and would the time be recorded for the rinex file?

I don't know exactly, but RECTIMEB includes information about day. If I wrote a converter, I would use RECTIMEB. So, you can try :-)

P.S. BTW, I wrote my own converter in RINEX, but it is not for Unicore.

[messplay]

Thank you in advanced , I have a new question when I tried to procces with RTKLIB I received a message that say "no nav data" How can I activate this option?, I saw that novatel have a command RAWEPHEMB, I dont know if will be usefull, So my friends I want to obtain .nav datas of the UM980 to I tried to pass my file for https://www.trimblertx.com/UploadForm.aspx but I received this message "The observation data in the uploaded file is missing L2 observables. The service supports only multi-frequency receivers that track on both the L1- and L2-frequency bands."

PD I solved the "1980" problem filter the time in the RTKLIB Attaching my new file
data0.zip

[Jef239]

want to obtain .nav datas of the UM980

it's GPSEPHB, BDSEPHB, BD3EPHB, GLOEPHB, GALEPHB, GPSUTCB, BD3UTCB, BDSUTCB, GALUTCB

[kanokc]

Hi,

I use @Jef239 UM980_RPI_Hat_RtkBase on RPi 3+ and USB UM980 to successfully setup my base station (TH-Kukot in rtk2go).

I'm trying to make this setup an NTP server but looks like the UM980 is not sending NMEA messages by default. How to set this?

[kanokc]

GPGGA 1 respond as "$GNGGA ..." , please try using chrony to create the NTP server as a test

Test with gpsmon --nmea shows the UM980 provides GNGGA sentence but chrony still have ? at GNSS

[Jef239]

However chrony still list my GNSS source as ?

GGA has only time. May be chrony wait for date? Try add "GPRMC 1".

[kanokc]

However chrony still list my GNSS source as ?

GGA has only time. May be chrony wait for date? Try add "GPRMC 1".

Yes. I've checked with ChatGPT and it suggests using RMC and it works now.

[Jef239]

Yes. I've checked with ChatGPT and it suggests using RMC and it works now.

Also may be need "GPZDA 1" - timezone information.

[Stefal]

To all UM98x users in a base station, do you enable the sbas messages?

[Jef239]

To all UM98x users in a base station, do you enable the sbas messages?

YES. rtcm1107 enabled

[kanokc]

Since there is no mention of UM98x in 2.6.0 release note, I still need @ Jef239 installation script for my station. @Jef239 How do I upgrade to use RTKbase 2.6.0? Thanks.

[Jef239]

Since there is no mention of UM98x in 2.6.0 release note, I still need @ Jef239 installation script for my station. @Jef239 How do I upgrade to use RTKbase 2.6.0? Thanks.

In 1-2 days, version 1.5.1 will be ready, based on RtkBase 2.6.0. After this, it will be tested in 2-3 days. Estimated - wait until Wednesday, July 17th.

[Jef239]

Since there is no mention of UM98x in 2.6.0 release note, I still need @ Jef239 installation script for my station. @Jef239 How do I upgrade to use RTKbase 2.6.0? Thanks.

UM980_RPI_Hat_RtkBase now upgraded to 2.6.0 in the dev branch. Tag is v1.5.1

[kanokc]

Hi @Jef239,

I uninstalled and reinstalled it and found that the web service could not start.

2024-07-18 08:35:05	notice	192.168.1.92	SYSTEMD	rtkbase_web.service: Main process exited, code=exited, status=1/FAILURE	notice
2024-07-18 08:35:05	info	192.168.1.92	PYTHON	ModuleNotFoundError: No module named \'gevent\'	info
2024-07-18 08:35:05	info	192.168.1.92	PYTHON	from gevent import monkey	info
2024-07-18 08:35:05	info	192.168.1.92	PYTHON	File \"/usr/local/rtkbase/rtkbase/web_app/server.py\", line 31, in <module>	info
2024-07-18 08:35:05	info	192.168.1.92	PYTHON	Traceback (most recent call last):	info
2024-07-18 08:35:05	info	192.168.1.92	SYSTEMD	Started rtkbase_web.service - RTKBase Web Server.	info
2024-07-18 08:35:05	info	192.168.1.92	SYSTEMD	Stopped rtkbase_web.service - RTKBase Web Server.	info

sorry for using the thread for reporting the issue. I'm not sure this is for @Jef239 or @Stefal

[kanokc]

Hi @Jef239,

I uninstalled and reinstalled it and found that the web service could not start.

2024-07-18 08:35:05	notice	192.168.1.92	SYSTEMD	rtkbase_web.service: Main process exited, code=exited, status=1/FAILURE	notice
2024-07-18 08:35:05	info	192.168.1.92	PYTHON	ModuleNotFoundError: No module named \'gevent\'	info
2024-07-18 08:35:05	info	192.168.1.92	PYTHON	from gevent import monkey	info
2024-07-18 08:35:05	info	192.168.1.92	PYTHON	File \"/usr/local/rtkbase/rtkbase/web_app/server.py\", line 31, in <module>	info
2024-07-18 08:35:05	info	192.168.1.92	PYTHON	Traceback (most recent call last):	info
2024-07-18 08:35:05	info	192.168.1.92	SYSTEMD	Started rtkbase_web.service - RTKBase Web Server.	info
2024-07-18 08:35:05	info	192.168.1.92	SYSTEMD	Stopped rtkbase_web.service - RTKBase Web Server.	info

sorry for using the thread for reporting the issue. I'm not sure this is for @Jef239 or @Stefal

It was from an incomplete install due to bad WiFi signal. Reinstall with better WiFi and now working.

[geofis]

I think that this pull request might be of interest to those visiting this issue.

[Stefal]

I think that this pull request might be of interest to those visiting this issue.

Interesting ! Thanks for the heads up !

[Jef239]

Since there is no mention of UM98x in 2.6.0 release note, I still need @ Jef239 installation script for my station. @Jef239 How do I upgrade to use RTKbase 2.6.0? Thanks.

Now i am released version 1.6..0 in UM980_RPI_Hat_RtkBase (based on RtkBase 2.6.0)

[Stefal]

Hi!

Did anyone tried the latest release or build from source a fresh RTKLib to compare the rtcm output from the UM980 and the binary to RTCM conversion from RTKLib?

[Jef239]

Did anyone tried the latest release or build from source a fresh RTKLib to compare the rtcm output from the UM980 and the binary to RTCM conversion from RTKLib?

I don't understand why you need to convert to RTCM3 when you have RTCM3 output by the receiver. I'd be glad if you could tell me this secret.

[Stefal]

There are several reasons:

• When I started to create Rtkbase, I was a complete newbie. Using str2str features was way easier to have a control on the rtcm messages, I didn't had to write extensive code to control the rtcm output settings of the F9P.
• You can swap the receiver without any modification in the Rtkbase code, as long as str2str understand it.
• RTKLib manage some rtcm messages that the F9P can't.
• With the raw messages, you can get more information from the receiver, without mixing various format in the same stream. Example : I'd like to add gnss chip temp, adc gain,... on the rtkbase UI
• With the ubx feed, I could connect U-Center to it and get some interesting info.

If I had to restart RTKBase from scratch today, perhaps I would take another direction, because times have changed: now there are several interesting new receivers arriving on the market every year, and their binary support by Rtklib is often long overdue. I think I will I'll mix native support and rtcm3 as appropriate.

[Jef239]

I probably should have asked the question a little differently, that is, why require a native protocol when connecting new receivers?

In my opinion, the converter is bad because:

1. It does not always work correctly
2. Sometimes the receiver gives less information in the binary protocol than in RTCM3
3. The converter gives a delay. It needs to receive a group of packets to the end, then convert them. In native RTCM3, the transmission is immediate.

I didn't have to write extensive code to control the rtcm output settings of the F9P

It is approximately equal to the code for controlling the native output. The rest is done by the message filter in str2str

You can swap the receiver without any modification in the Rtkbase code, as long as str2str understands it.

You still need to write detection, configuration, and speed change. But str2str does the setting of coordinates and antenna type during conversion, and without conversion, you have to do it yourself.

RTKLib manages some rtcm messages that the F9P can't.

Ephemeris?!!!!!!!!!!! This is a feature of the F9P. That is, a very compelling argument, but only for the F9P.

without mixing various formats in the same stream.

Mixing is not scary, str2str discards everything unnecessary when specifying the #rtcm3 output and message types.

With the ubx feed, I could connect U-Center to it and get some interesting info.

The same with Bynav M20 and Unicore UM980, despite the fact that they have an RTCM3 stream.

I think I will mix my own support and rtcm3 as needed.

I would be glad if you used our developments.

Conclusions.

1. I was afraid that there are some things that I do not know and that exclude RTCM3. For example, the need for native data archive for some purposes. But in general, nothing scary.
2. You are right, for F9P, due to the lack of ephemeris output in RTCM3, a native protocol is needed. And I forgot about it. For the rest - it is not needed.

[shjalilian]

hi, tnx for creating this chat, I am searching for a command line converter to convert static data of um980 to rinex3.02. Can anyone help?

[Stefal]

I'm working on the UM980 support. If you want to test it, you can install the unicore_um980 branch, like that:

cd ~
wget https://raw.githubusercontent.com/Stefal/rtkbase/unicore_um980/tools/install.sh -O install.sh   -O install.sh
chmod +x install.sh
sudo ./install.sh --all repo --rtkbase-repo unicore_um980

[shjalilian]

I'm working on the UM980 support. If you want to test it, you can install the unicore_um980 branch, like that:

cd ~
wget https://raw.githubusercontent.com/Stefal/rtkbase/master/tools/install.sh -O install.sh
chmod +x install.sh
sudo ./install.sh --all repo --rtkbase-repo unicore_um980

tnx for reply, I want to run in windows.

[Stefal]

I'm working on the UM980 support. If you want to test it, you can install the unicore_um980 branch, like that:

cd ~
wget https://raw.githubusercontent.com/Stefal/rtkbase/master/tools/install.sh -O install.sh
chmod +x install.sh
sudo ./install.sh --all repo --rtkbase-repo unicore_um980

tnx for reply, I want to run in windows.

Sorry, this answer was not for you.

by the way, your message is not related to this issue, and not related to RTKBase.

[Jef239]

I'm working on the UM980 support.

I will be glad to share any parts made in ELT_RTKBase. And especially - my knowledge.

[Averyy]

I'm working on the UM980 support. If you want to test it, you can install the unicore_um980 branch, like that:

cd ~
wget https://raw.githubusercontent.com/Stefal/rtkbase/unicore_um980/tools/install.sh -O install.sh   -O install.sh
chmod +x install.sh
sudo ./install.sh --all repo --rtkbase-repo unicore_um980

I set this up to try out and works pretty well! I'm using a UM980 let me know if there's anything I can do to help. It detected everything in Main Service correctly (except the base coordinates which I think will update/correct themselves). It's only been running a few minutes.