I am stuck. My Facet L-Band is not producing sub meter accuracy and I am at a loss as to why this is. Some Background: My Keys are expired so the unit will not get L-Band correction data. However, my understanding is that it should still be able to act as a Base Station provided that I keep it stationary and determine its location using either of the two methods described in the various tutorials found at Sparkfun. Method one is to use a CORS station to adjust observed logged data using RTKLIB or Emlid Studio. The other method is to use a correction service like OPUS or CSRS. First I set up over a local Geodetic Disk found on the NGS Map. I took the NAD83 coordinates and converted them to WGS84(G2139)/IRTF20 with adjustment for tectonic movement using the HTDP tool - just like the tutorial said. This is my known location I am using as a Reference Point. Next I set up the FACET as a Base station as per the tutorial (firmware v4.0, Logging enabled for the NMEA5+RAWX2 messages. I logged at least 4 hours of data. I then post processed this data using RTKCONV to get a RINEX OBS file for a period that trimmed the first 5 minutes and the last 5 minutes to ignore the startup and shutdown corrupted readings. I sent this file to OPUS and to CRCS 12-24 hours post logging. OPUS always aborts every single RINEX file I’ve sent it (I’ve done this experiment at two different Sites and many logging sessions). The CSRS always produces a result, but it is always 1-2 meters off of what the Reference Point Coordinates should be. Using the second method, I download CORS correction data from the CORS site closest to me (There are only 3 CORS stations total in my State of NH) and use that data as the “Base” to correct the logged data from the “Rover” using Emlid v1.8 software (which appears to be a software wrapper around the RTKLIB software). The result is 1-2 meters off of the Reference Point Coordinates. The result from Method One and Method Two are also off from each other by 1-2 meters as well. These 1-2 meter results are consistent at two Geodeditc Site locations and with data logged for 2 or 4 hours. I don’t know why OPUS pukes out any RINEX file I give it but CSRS does not. I have not post processed the log file other than converting the ubx file to RINEX. Should this file be transformed or post-processed in some other fashion? The only issue I am aware of is the lack of a FACET L-Band Antenna type to specify for OPUS or CSRS. I have been using the SFEFACET Antenna figuring they are close enough. Am I wrong about this? Any suggestions would be welcome.
Very detailed post 
I’ll mention my first impressions in the hopes that it might help start the conversation.
I looked and NH does have huge gaps in CORS Coverage. Wow.
Obviously, OPUS needs effective base data that coincides with your logged data.
You are not alone with having problems with OPUS not accepting RINEX conversions. Many discussions on the internet and I’d expect you’ve already read many of them.
Just for giggles, let’s focus on CSRS for now-
Do the CSRS results agree with each other for 2 or more survey missions at the same control point ?
Do you have logs that are now at least 2 weeks old that you can re-submit to CSRS ?
If you get CSRS results that are in agreement for 2 or more survey missions, I’d start to have some confidence in your CSRS calculated position. Then you can dig deeper into the published “known” coordinates for the marker, the datasheet, and the coordinate system conversion to help point you in the right direction.
Side Notes:
I looked for a few minutes and didn’t see any 1’st or 2’nd order points that were GNSS observable, but the metadata isn’t extremely clear on the Order Classification.
I believe I saw a post that the FACET Antenna was successfully modeled recently.
Are your field procedures repeatable? IE: using a 1-piece rod, tripod, bubble level, accurately measuring the Height of Instrument (HI) for the ARP, etc?
L-band correction is a must. Without L-Band correction data, your Facet receiver won’t be receiving the corrections it needs for high accuracy.
Thanks for the feedback. I deleted my previous efforts since I was contending with other issues and did not have log for at least 3 hours as recommended. So I have only one 4-hour “mission” to the one site. My log is about 48 hours old at this point. I was planning on re-submitting to see if there’s any noticeable improvement. I don’t know what a “first order or second order” point is. I used the CORS station P776 which is the closest at 60km away. There’s one in VT at 50km but I haven’t tried that one. The one in Concord is actually not functional. My Reference Point is PID OD0139. The other Reference Point is PID BBBR89 but I only did a 2-hour log there on a bipod on a windy day. How can I tell if they are “first or second order”? The 4-hour log was set up on a CRAIN tripod and I used a tape measure to base of tripod and the tribrach height to ARP was measured more accurately and is fixed. I used the optical plummet and the bubble to plumb and level. I pointed the FACET magnetic North. This is a standard setup for me. I haven’t been back to either to get a second log. I’ve read many, many posts about OPUS and it appears no one really knows how to properly prep a file to satisfy OPUS’ hidden requirements. Since I don’t really know what the program does I just treat it as a black box. I expect more from NOAA, but it IS government after all.
My understanding is that without L-band corrections the unit should function the same as the FACET without L-band. Further, I should be able to use it as a base station if I post process the logged data using a local CORS Reference Station data for the same time frame of the logged data. In the alternative, I should be able to use a service like OPUS or CSRS to use my log file to find an accurate location. Is any of this incorrect?
It looks like that’s a 2’nd order Benchmark used for Vertical Control only. +/- 3 Meters horizonal from a hand held GPS.
There is no NGS Datasheet for this site. I’d be afraid to put a lot of effort here if using this site to ground truth your equipment/procedure.
Looking around that area on the NGS explorer map, you really are in a spot with poor survey control.
Can you use Station AJ5830 for validating 2 missions w/ CSRS ?
https://www.ngs.noaa.gov/cgi-bin/ds_mark.prl?PidBox=AJ5830
Good find. I’ll try that AJ580 location. The two PID locations I gave actually are what NGS Maps calls “OPUS Shared Solutions” and claim high accuracy (i.e. Shared Solution) My understanding is that these user contributed Reference Points have been vetted by NOAA/NGS. I agree that when I look at a PID location I do read the positional accuracy and avoid the ones that don’t have high precision. I just don’t understand all the jargon in those data sheets…yet. Thanks. I’ll be back, but it may take some time to get that data since these spots are out in the open and need to be babysat thru the whole time. Not Fun.
So one of the quick and dirty ways is to look at the legend/symbology
Then read the datasheet carefully.
I hope this helps
Yes it helps. Didn’t notice the legend key before. Thank You!
TLDR: You need to submit to OPUS RINEX files with observations on even 0.0000000 and 30.00000 intervals. This is a known requirement and there are a few tools to help you. I like Emlid Studio, RTKLIB/RTKCONV can take care of it with the proper options, and SparkFun has a tool also.
I ran into this a couple years back, here’s my post and @sparky 's helpful answer (ignore the screen shot the forum quoting function shows below, go click and read when you have time, it’s a long thread.)
I’ve successfully processed 100’s of RINEX files from Facets using OPUS.
OPUS needs the observations on even 30-second intervals (eg. seconds=0.0000000 and seconds=30.0000000). Open your RINEX in a text editor and check that the observations are on even 30-second intervals. I doubt that they are, because the ublox F9P in the Facets rarely output observations on exactly even 30-second intervals.
Looking in the RINEX file, each observation epoch’s data is preceded by a date time header, you need to have observations with headers on the even 0.0000000 and 30.0000000 intervals. It’s ok (but not awesome) if you have extra data, extra data just slows down the upload to OPUS and the OPUS pre-processing.
Here are headers from April 23, 2023, at 21:17:30 and 21:18:00 UTC to help you understand the RINEX files:
…
23 4 23 21 17 30.0000000
…
23 4 23 21 18 0.0000000
…
When converting from UBX to RINEX, you need to ensure the output RINEX has the observations on even 30-second intervals.
The easiest way do to this is to use Emlid Studio to convert from UBX to RINEX with the time rounding option. You can also do this with RTKLIB too, though Emild Studio is simpler to use.
You can search the internet for “ubx rinex time rounding” and you will find 100’s of posts on this topic.
The observations in the “raw” UBX files are often off the even 30-second intervals by a few milliseconds, and thus they are off by a few milliseconds in the RINEX if you don’t use the time rounding options. OPUS then rejects the file, as it finds no valid observations it can use. This is an endless source of problems for new users of devices build around ublox chips.
On the antenna topic, the last I saw, the L-Band Facet is in the queue at NGS for antenna calibration. IIRC there are a few posts in this forum on this topic. The NGS queue is long. Using the SFEFACET antenna at OPUS and correcting the vertical would be a decent workaround.
Tony.
Thank You for your reply! You nailed it with that quote. I’ve been attempting to sort this out in earnest since June. Still not there, but getting closer, contrary to what the AI on this website is telling me. (Site AI: Your question has been answered. Me: Umm…nope. Dum dum)
I did as you suggested using Emlid’s time rounding function and IT WORKED! The first time I have ever gotten an OPUS solution! I am ecstatic. I had previously been made aware to trim my data file to remove the first and last 5 minutes of data (the equipment setup and teardown of the logging activity) and to to use the “30-sec interval”, and more recently the GPS-only data requirement. Turns out my data set had an extra .004 seconds on the timestamps which was the reason the data was rejected (producing a totally unrelated OPUS error message, BTW).
The overall result is still off horizontally by a meter or so, but within an inch or so off vertically. BUT, the coordinates of the Survey Mark I am using as indicated by OPUS is ALSO off of what the NGS has published, so I will definitely consider that suspect and do this exercise at another Survey Mark on two different outings as has been previously suggested. This weekend is looking good for that.
I had been using RTKLIB to pre-process the data since Emlid does not have the Sparkfun Antennas as a choice for antenna type (why would they). I have been unsuccessful in figuring out how to to do the “Time Rounding” with RTKLIB despite going thru an extraordinary number of blog posts over at “rtklibexplorer”. If you can shed some light on what options need to be configured that would be great!
Thanks so much for taking the time to respond and digging up the past posts you made. I had literally looked thru the entire section of posts on this site under (GPS/GNSS>Enclosed Products) to no avail. As great as this site is (and I think it really is), there is room for improvement.
Thanks again for putting the wind back in my sails!
Good to hear things are moving in the right direction!
Check out the -TADJ option for RTKCONV. I’ve gotten it to work for me for OPUS but not consistently, probably due to late night user mistakes by me.
I use the rtklibexplorer fork of RTKLIB. The rtklibexplorer community does a lot of work with ublox devices and seems to be much more active with development and bug fixing.
Regarding the 1-meter inaccuracy in the horizontal coordinates, be very careful use the same datum in all your work. I stick with “NAD83(2011) epoch 2010.0” horizontal datum because it suits my work. Ditto for the vertical NAVD88 datum. I do my best to avoid the complexities of HTDT and WGS when ever possible (different people use different datums to best suit their work.). The OPUS solution should give you coordinates in that NAD83 horizontal datum, and hopefully the datasheet for your survey mark does too. If not, I’d wonder why and try a different survey mark.
The rtklibexplorer blog is worth a couple hours and a pot of coffee to read through. Some of the earlier blog entries are now more historic and not current specific info, but it’s all good background and education. The Emlid and ublox user forums are also good sources of info.
Tony.
I took have played with the TADJ option a bit, but not getting results I expect.
Because Sparkfun logs data results in WGS coordinates l, I’ve sort of adopted that and IRTF. But I’m inclined to take a second look at the NAD83 as you suggest only because it seems to still be the one many folks are holding on to.
I am right now doing a field outing collecting data at PID AJ5830. The location is somewhat protect off-road and it is a nice clear day so hopefully I can do a long run-time data log.
With DGPS and 200 point average I currently am getting [.976, .128, .082] meter [Lat,Lon,Ell H] compared to the NAD83(2011) data sheet numbers. Unadjusted for Tectonic shift to today. I’m a little concerned that the adjusted numbers will be even further off since running the NGS NCAT tool seem to do that.
Hopefully my field outing will provide a solid data log.
IRTF/WGS reference frames are tied to the whole planet (hence the “w” for world in WGS). The North American tectonic plate moves around on the planet. Thus IRTF/WGS coordinates for a physical location in the ground in NA change over time as the plate moves.
The NAD reference frame is tied to the NA tectonic plate. Thus NAD coordinates for a point in the ground (in NA) are mostly very stable, with some exceptions (like the coast of California as the Pacific plate drags it around.)
Be careful assuming what coordinate system the NMEA emitted from the Facet are in. If it has a RTK fix using RTCM from a CORS station, the NMEA coordinates will be in the reference frame of the CORS station. All the CORS stations I’ve used in the US are NAD83. If I set up a local base, the NEMA output from the rover is in whatever frame I used to configure the base.
More generally, solutions using DGPS, SBAS/WAAS, L-Band, RTK(local base), RTN (RTK with network CORS), etc. are all in the reference frame of the provider of the supplemental correction/observation data. If the Facet changes solution types, say from DGPS to L-Band to RTN solutions, the reference frame could change with no notice! I see this in the field when I lose RTK fix and float and the FACET drops down to WAAS, my coordinates jump a meter or so.
WGS84 and NAD83 were pretty much identical in 1984. In 1984, a point in the ground in NA had practically the same numerical coordinates in WGS84 and NAD83. But not today!
Today they are about 1-2 meters apart. Whenever someone posts “my coordinates are a meter off” I figure they probably have a coordinate reference frame issue.
Yes! This. Thanks for the erudite explanation. I kind of understand the overall reference frame stuff, but I was only starting to suspect and understand there was something going on with reference frames local to the equipment.
My goal is to get a reliable Base/Rover setup to get inch-level accuracy for topo mapping where there is no cell reception. The first step was a proof of concept to see how good a location fix I can get using my Facet as a base station with only DGPS (no Lband correction, no CORS correction) with long run data logging and then post processing using OPUS for a inch level location fix. Then I’d be confident that a Base/Rover setup with known base location would result in achieving my goal.
Right now I am using both Facet internal data logs and location data provided by SW maps in the field. Both of those seem to present a blind spot re reference frames. I read in one of the tutorials that the Facet uses WGS84(G2139) for data logging so that is my baseline. I don’t really know what SWmaps does to display their data.
Today, right now in real time during this field outing, I am seeing close to meter accuracy using DGPS Facet, and comparing the SWmaps coordinates numbers with NGS given NAD83(2011) epoch 2010.0 coordinates as well as with the HTDP adjusted coordinates in WGS84(G2139) coordinates. My hope is the OPUS adjusted data log will get me to where I need to be as far as matching the published NGS Survey Mark location.
Many hours left to go, but so far this looks promising. Your guidance has been tremendously helpful.
UPDATE: I logged 24+ hours of data. I waited 24+ hours after logging before submitting to OPUS & NRCan/CSRS. I used Emlid primarily to process files, but I was also able to get RTKCONV to work by setting the “Receiver Options” to -TADJ=1.0 (Case matters) I obtained 5 different “solutions” as follows:
(1) Emlid “Static Processing” using CORS Station P776 (50km away)
(2) Emlid “Static Processing” using CORS Station VTSP (44km away)
(3) NRCan/CSRS using all satellites w/30 second interval on exact 1-sec boundaries (Emlid 24O file)
(4) OPUS using only GPS satellites w/30 second interval on exact 1-sec boundaries (Emlid 24O file)
(5) OPUS using only GPS satellites w/30 second interval on exact 1-sec boundaries (RTKCONV obs file)
RESULTS: All solutions provided 5-inch or better accuracy except #5. I think that was because the OPUS solutions don’t always use the same three CORS stations. #5 was WAY off - about 2 meters!
THOUGHTS: I am so thrilled that I am consistently getting OPUS to not only accept the data but to provide a solution as well. I did go back and read your thread on “OPUS Post Processing” under a different heading (i.e. “development boards” vs “enclosed products” - which is why I did not find it previously) That allowed me to set up RTKLIB to get what is actually a lot easier with Emlid. But, the payoff will be when I use the Antenna specific data once NGS gets their act together. It’s only been 2+ years!
I also think I understand how reference frames and Datums are handled. It appears solutions generated by using the CORS with “Static Processing” provide results in NAD83(2011) at the OLD DATE (2010). NRCan/CSRS gives results in ITRF2014 at the date of the log file (call it TODAY’s date). So the tectonic plate action is built into it, whereas the NAD83 solution provides a historically accurate position for 2010, but you would need to compute TODAY’s position using the HTDP tool. This was totally counterintuitive to me and is one reason all my other past solutions were so far off. I was looking at solutions in NAD83 as if they were for TODAY’s date.
I’m so lucky you turned me onto PID AJ5830 as it is convenient to get to and somewhat protected and I was able to leave my setup for 24 hours without worrying it would walk off. Of the two other candidate PIDs, one was obliterated by a new power pole placement and the other may have been obliterated by construction renovation, but I want to double check since it was 2 years ago when I last attempted a quick search. In the meantime I’ll do a few more data runs on OPUS with truncated files to get a feel for how the accuracy degrades with the shorter data sets. Then I may be able to get away with 3-4 hour sessions that require baby-sitting.
It sure has taken a long time to get this far, but I have to give thanks to everyone who has helped and makes this community forum really work. It truly is impressive. I can finally say this thread can be closed.
On the previous forum infrastructure, the “development boards” vs. “enclosed products” sub-categories didn’t exist. It appears that when the forum was migrated to the new infrastructure, some older topics were mis-categorized.
There are many threads on the Facets that are in the “development board” sub-category and I find I need to just read both sub-categories.
Glad to hear things are working out for you. Good job processing your data multiple ways and comparing results.
I’d say for #5, something else isn’t right. There’s no way two OPUS solutions for the same static observation (your 24hr occupation) would be 2 meters off only because OPUS chose different CORS stations. Anyway, I’ve never been confident in my UBX to RINEX conversions using RTKLIB and -TADJ, and for some reason the Emlid conversion (w/ rounding for OPUS) always works for me.