search

Stefal / rtkbase

Your own GNSS base station for RTK localization with a Web GUI
GNU Affero General Public License v3.0
492 stars 122 forks source link

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

Open geofis opened 11 months ago

geofis commented 11 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

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 commented 10 months ago

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 commented 9 months ago

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

geofis commented 9 months ago

Hello,

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

EliuPineda commented 9 months ago

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

messplay commented 9 months ago

Hello,

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

thank you very much

messplay commented 9 months ago

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

thank you very much

geofis commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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:

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 commented 8 months ago

You people are simply amazing.

Jef239 commented 8 months ago

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 commented 8 months ago
  • 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

PPP is work!

Limitation:

It's interesting for you?

geofis commented 8 months ago

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 image

UM980 image

Jef239 commented 8 months ago

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 commented 6 months ago

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

Now i release version 1.0.1

Limitation:

All other work well.

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

messplay commented 6 months ago

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 commented 6 months ago

using the RANGEA command

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

Probally, you need RECTIMEB

messplay commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

want to obtain .nav datas of the UM980

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

kanokc commented 6 months ago

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?

Jef239 commented 6 months ago

I'm trying to make this setup an NTP server

NTP or NTRIP?

UM980 is not sending NMEA messages by default.

Add "GPGGA 1" to receiver_cfg/UM980_RTCM3_OUT.txt before "saveconfig" line and do "Configure" operation from web-interface

kanokc commented 5 months ago

Hi,

I'm trying to make this setup an NTP server

NTP or NTRIP?

I'm trying to make RTKbase a time source for clock sync for other devices in my home.

UM980 is not sending NMEA messages by default.

Add "GPGGA 1" to receiver_cfg/UM980_RTCM3_OUT.txt before "saveconfig" line and do "Configure" operation from web-interface

GPGGA 1 was added and reconfigured. Confirm with gpsmon that GPGGA sentence is received. However chrony still list my GNSS source as ?

#? GNSS                          0   4     0     -     +0ns[   +0ns] +/-    0ns
^* 192.168.1.90                  3  10   373   20m  -1068us[-2859us] +/-   59ms
^- ntp2.ku.ac.th                 2  10   377    38    +45us[  +45us] +/-   52ms
^? rtkbase.localdomain           0  10     0     -     +0ns[   +0ns] +/-    0ns

ntpshmmon provide nothing

kanok@rtkbase:/etc $ sudo ntpshmmon
ntpshmmon: version 3.22
#      Name  Seen@                 Clock                 Real                 L Prc
^C
kanok@rtkbase:/etc $
EliuPineda commented 5 months ago

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

kanokc commented 5 months ago

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

MobaXterm screenshot

Jef239 commented 5 months ago

However chrony still list my GNSS source as ?

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

kanokc commented 5 months ago

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 commented 5 months ago

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

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

Stefal commented 5 months ago

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

Jef239 commented 5 months ago

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

YES. rtcm1107 enabled

kanokc commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

Stefal commented 4 months ago

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

Interesting ! Thanks for the heads up !

Jef239 commented 3 months ago

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 commented 6 days ago

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 commented 6 days ago

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 commented 3 days ago

There are several reasons:

Jef239 commented 3 days ago

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.