Facet v4.0 Data Logs not being accepted by RTKConvert or Emlid Studio or OPUS

GPS/GNSS Enclosed Products
1

Facet v4.0 seems to have changed how data logging works or is configured. Here is how I set it up:

FacetDataLogSetup
FacetDataLogSetup734×1013 42.4 KB

I used the Facet in Rover mode and got a 26MB long .ubx file that appears to be a text file with a lot of $G…* strings. This file can be read by u-center and the data plots out correctly on the u-center map tracker. It also is accepted by the WAY program from KernelSAT. But what I need is to convert this data to RINEX in order to have the OPUS software from NOAA process it. I have tried the RTKConvert program, the Emlid Studio program and the Rinex Wizard from KernelSAT. All reject the file for unknown reasons (cryptic, non helpful error messages reported). I suspect a Facet setup issue as prior versions of Facet firmware presented a different data logging setup menu. Is there some hidden menu to configure the data logging feature to make it OPUS compliant? P.S. I set the Measurement rate to 1Hz as per OPUS and have read pretty much all the Sparkfun related articles including HOW TO BUILD A DIY GNSS REFERENCE STATION and many of the posts here on the Forum.

P.P.S. I found some hidden menus on the Facet when configuring using the Serial Port over USB Method and not the WiFi configuration menus. Here is a screen shot of those menus:

SparkFun RTK Facet L-Band v4.0
** Bluetooth SPP broadcasting as: Facet L-Band Rover-20AE **
Menu: Main

  1. Configure GNSS Receiver
  2. Configure GNSS Messages
  3. Configure Base
  4. Configure Ports
  5. Configure Logging
  6. Configure WiFi
  7. Configure Network
    p) Configure User Profiles
    r) Configure Radios
    P) Configure PointPerfect
    s) Configure System
    f) Firmware upgrade
    x) Exit
    2
    2

Menu: GNSS Messages
Active messages: 7

  1. Set NMEA Messages
  2. Set RTCM Messages
  3. Set RXM Messages
  4. Set NAV Messages
  5. Set NAV2 Messages
  6. Set NMEA NAV2 Messages
  7. Set MON Messages
  8. Set TIM Messages
  9. Set PUBX Messages
  10. Reset to Surveying Defaults (NMEAx5)
  11. Reset to PPP Logging Defaults (NMEAx5 + RXMx2)
  12. Turn off all messages
  13. Turn on all messages
    x) Exit
    x
    x

So my question now becomes how should this be set up to log a file that can be converted to RINEX in a way OPUS will accept it?

2

I think you’re looking for this section of the guide :slight_smile: Creating a Permanent Base - SparkFun RTK Product Manual (the very next section covers converting the ubx logs to rinex)

3

I found the GNSS Messages in the Message Rate menu. My mouse was messing up and was failing to “click” when pressed sometimes. In any event, there is still a discrepancy when selecting the Nmea/Rxm 7-message combo. The serial method set the rate to 1 while the WiFi method sets the rate to 4 for the NMEA-GSV message. All other rates are set to 1 using both methods. Don’t know if this matters.

Regardless, I am still not seeing the binary Rxm messages being logged. I’m beginning to suspect that the file “SFE_Facet_LBand_Settings_0” which is resident on the SD card is being used upon reset as those message settings are different and the Rxm message rates are set to 0. I’ll have to check into when that file is actually used. Baby steps.

4

I think I figured it out. According to the Configuration Methods > Configure With Settings File: " If there is a discrepancy between the internal settings and a settings file then the settings file will be used." Turns out I was placing the SD Card into the Facet AFTER I updated the settings. So when the Facet was subsequently turned on it adopted the (wrong) settings that were on the SD card. That is why it appeared that the new settings were not being updated.

I fixed that issue by ensuring the SD Card is inserted into the Facet when doing any updating. I let the Facet run overnight and log data. This morning I was able to finally get a proper RINEX file and also get it converted properly using both the RTKLIB converter and the KernelSAT converter. OPUS kept kicking back the file, but one version of a converted file was accepted but processed using the IGS Ultra rapid Orbit. I also sent it to the Canucks CSRS service. The two answers were close (within 5 meters). I will re-submit in a day and see if the results improve. I will also try logging data again at a so-called “Control Point” i.e. an NGS Brass Disk in the ground). Unfortunately the one used by OPUS has been obliterated (I looked for it last year). Getting closer…Anyway, thanks for your help pointing me in the right direction!