As I prepare to start my new business as a solo operator, I've been giving a lot of attention to Javad GPS. Mainly because it's half the price of Trimble (which is all I've ever used) and seems to be technologically superior.
However, in this part of the country, all anyone uses it Trimble. As a result, the MNDOT VRS and my local city both use Trimble CORS stations.
The question is, if I invest in an all-Javad setup, will I be able to use VRS or the city base? The city bases uses regular radio link, as well as cell phone dial-up radio links. I suspect the answer is no, because I think the Javad unit only receives CMR signals, while the GLONASS from Trimble requires CMR+ or CMRx.
Am I right about this, or do I have it all wrong?
Good question. I believe I read that Trimble blocks the GLONASS component of CMR/CMR+ from other manufactures, so you may be out of luck with anything other than Trimble.
RTCM is the true "open" format. Do your network providers not use RTCM?
> There is no blocking of GLN in CMR+, no users of any brand (that add it as an option in their rovers) has any problem. Leica, Altus, Topcon, etc (even the Chinese brands), all add CMR+ and RTCM stock.
When I was setting up my Hipers I found this doc from Topcon that said ...
Trimble's GLONASS observation extension to the CMR / CMR+ format is proprietary and
has not yet been published.
http://www.hayeshelp.com/gps/documents/topcon/rtcm3_v_cmr.pdf
Maybe I misunderstood, or maybe it's not true (Topcon taking an unfair shot at Trimble), but I took that to mean that CMR/CMR+ only supported GLONASS with Trimble equipment. After reading that, I never tried CMR with a non-Trimble brand, so I'll take your word for it.
Good to know about VRS. Sounds like I'll be able to use that.
But the local base is not part of the MNDOT network, and I'm guessing that with its Net R5 radio, it can only transmit in Trimble formats? I guess maybe I'll just have to ask the city.
Here is another reference to the problem (although this is from 2007, so it may longer be a problem):
When GLONASS observations are broadcast via CMR / CMR+ from receivers manufactured by Topcon or NovAtel, Leica Geosystems receivers consider both GPS and GLONASS observations. In the case where GLONASS observations are broadcast from Trimble CMR RTK networks and receivers, the Leica Geosystems receivers consider only the GPS observations for a phase fixed solution.
No they do NOT play well together, I discuss this topic in detail in a couple of my GNSS education classes that I teach. Take a look at these two white papers if you are wondering(I can email them to you if you cant download them):
http://www.ion.org/publications/abstract.cfm?articleID=9276
http://acc.igs.org/biases/glonass-phase-biases_jog11.pdf
Have a look at the CHC Navigation X91+ receivers; they will work with the proprietary CMR and CMR+ formats from Trimble. More importantly the unique interchannel bias will match perfectly with that of Trimble's so you wont loose accuracy as you will when mixing brands. Best part is that the price is the same as JAVAD(half of Trimble's).
Yes, it is true that no other manufacturer can read Trimble's, L2C, L5, GAL, and BDS messages in their CMR format (only GPS L1/L2) - (CHC uses the same OEM board as Trimble so the prior statement doesn't apply to CHC and to TDS). Also, even if you use RTCM3 their are tracking differences between brands, in some cases a whole quarter cycle difference in how L2C is tracked and 5 cm difference in GLONASS. So don't be fooled by a vendor telling you that our brand works with x brand... you need to dig deeper. Until our state RTK Networks stop endorsing their favorite brand and adapt truly vendor neutral software (say like Geo++'s GNSMART) you will need to match their internal interchannel bias for the best accuracy. That's why I'm such an advocate of CHC Navigation in that they have the X91 for Trimble VRS networks and the X900 for Leica networks.
Disclosure: YES I represent both Geo++ and CHC Navigation, but I have been preaching the importance of open industry standards and interchannel bias for years before working with them.
Allen,
As stated above... if you have access to a RTCM 3.1 mount point you should be fine. The RTCM 3.1 format carries allot of information and was designed to handle allot of information from RTN corrections. Lance brought up a good point about bias and depending on how the RTN network software performs the RTCM ver 3 for RTN should include information for this issue. You would need to ask the administrator for MNDOT about this issue for the network software running everything.
Yes when you are running a standard rover and base setup the biases should not affect anything but in RTN it will if not handled properly.
I would like to add to Lance's comment in that since The Leica 1200 Plus series (really since their firmware 7) Leica allows the user to set what manufacturer brand is being used for the RTN and what manufacturer brand antenna is being used in the RTN or standard setup. This allows the unique biases to be considered when mixing Leica with other manufactures.
Gavin,
This is very interesting.
From what I'm getting here, if the CMR+ correction is broadcast from Trimble equipment, everything but GPS is "proprietary". Other manufactures have created their own versions of CMR+ that mimic Trimble's format, and include GLONASS and other info. Does your RTN use trimble equipment and software to broadcast? If not, you are probably broadcasting a "cracked" version of CMR, which was designed to work with other brands. This is from a page that was updated as recently as 2013, so this doesn't seem like an outdated concept.
http://lefebure.com/articles/rtk-correction-data-formats/
CMR+ - The second generation of Trimble's CMR. It features a more compact message structure than CMR had. The GPS portion of this protocol was originally Trimble proprietary, but was later released and has become a widely used standard. No GLONASS specifications were released by Trimble, but other manufacturers have extended the format to include GLONASS information as well. Unfortunately the GLONASS portion isn't as standardized as the GPS portion is. Compatibility between receiver manufacturers when using GLONASS is a crapshoot.
A + B + C + D etc - Do they play nice?
I'll play the devils advocate (cuz, I like stirring a hornets nest sometimes to get the conversation more spirited and lively)... If you know me you'll know that I enjoy doing this and in no way am I picking on any one...
If RTCM3 is our "Gold Standard" for interoperability then we could do away with all the special "proprietary" messages that each vendor has insisted on embedding within RTCM3 so that their equipment will run better on their base/network:
RTCM# Link
4080 Navcom Technology, Inc. ( http://navcomtech.com)
4084 Geodetics, Inc. ( http://www.geodetics.com)
4089 Septentrio Satellite Navigation ( http://www.septentrio.com)
4091 Topcon Positioning Systems ( http://www.topconpositioning.com)
4092 Leica Geosystems ( http://www.leica-geosystems.com)
4093 NovAtel Inc. ( http://www.novatel.ca)
4094 Trimble Navigation Ltd. ( http://www.trimble.com)
4095 Ashtech ( http://www.ashtech.com)
The issues of interchange bias and signal tracking are not yet standardized within RTCM3 leaving ambiguities which each rover's manufacture may correctly or incorrectly implement these differences by reverse engineering each brands bias they want to support. As referenced above that Brand L (and a couple other brands) now support a limited list of these within their newer firmwares. Only problem with this approach is that these bias's are not brand specific, they are board and firmware specific, so there is no guarantee that this will resolve your issue (although we all feel good about things like this when we see that our particular vendor has taken this into account).
I've ran multiple tests mixing equipment on various networks and rover brands when I worked at prior employers and there is quite noticeably differences in performance from one brand to the next when you operate them off of another brands base/network, and I continue to demonstrate this during equipment demos. In fact a very popular DC platform would give an error message that the base station position wasn't being transmitted by the network so it would not store vectors... the message it was looking for was in the propriety message group.
The ION white paper I reference above shows that when they ran a Brand A rover with a Brand A base they achieved a 43% fix rate (while moving in a challenging urban environment), but when they used Brand A rover with Brand B base they achieved a 1% fix rate! that's not what I would call interoperability (btw they used RTCM3).
Last point for augments sake, is that manufactures are still developing their own proprietary standards vs. fully endorsing RTCM3, Ashtech has a new ATOM format, Trimble with CMRx, Navcom/Deere with NCT, etc. and the last two even ship systems which can ONLY use their proprietary format... Thus the reason why most RTK networks supply CMR and NCT corrections in addition to simply endorsing RTCM. While each proprietary standard has it's advantages, IMO these advantages are lost unless they are fully documented including tracking bias so that others who wish to utilize the format do not have to reverse engineer their solution.
IMO: public funded networks should insist on vanilla RTCM only and leave proprietary messages for "private for profit networks" if they so choose... but if they did, companies like CHC Navigation wouldn't be so successful in demonstrating the advantages of their Leica Bias and Trimble Bias product offerings.
A + B + C etc - Do they play nice?
Read the second post ... I was the first to suggest looking to RTCM. That is a nice practical solution, but does not address the problem he might have with his city base station, and doesn't really answer the question about whether or not JAVAD and CMR+ are really compatible.
I'm not on a "crusade" or grinding a "brand axe", and I have no idea what I said to make you think that. The OP asked a specific question about CMR+ and GLONASS from a Trimble based RTN. There are several sources on the web that says IF the RTN provider is Trimble based, then the GLONASS signal in CMR+ is "proprietary". Are you broadcasting solely using Trimble based equipment/software? If not, your experience and request that I drive across the country so you can say "I told you so" does not seem relevant to the question, but I do appreciate it when RTN providers take the steps necessary to get the various brands working with their network, so kudos for that.
If the RTN is not Trimble based, then the manufacture might use a modified version of CMR+ that includes GLONASS. Regardless, I've seen nothing to support that Trimble has voluntarily "unlocked" their CMR+ format so that all other manufactures can get the full benefit. I see nothing wrong with having an honest discussion about this.
And, FWIW, I checked and CMR+ is NOT LISTED as a supported format by JAVAD on the Triumph data sheet, so there might be a reason for that.
A + B + C etc - Do they play nice?
No problem, I appreciate the knowledge you share here. And I probably was more interested in understanding the CMR+ format more in an "academic" way than a practical way.
RTCM v3 -or- RTCM v3.1
Has our GNSS Industry moves forward,there are new and improved RTCM 3.1 messages, The RTCM Committee recently ratified RTCM v3.1, New Rinex Format, new Network RTCM v3.1 messages, 1024, 1025, 1026 and other new (Geoid model) message types. Understanding and comprehension of the new messages and how they can impact NTRIP RTK Rover performance are important. Does your GNSS receiver, HH data collection and Post-Processing SW keep up with these important upgrades???
-BbB B-)
RTCM v3 -or- RTCM v3.1
Message from the RTCM Commitee Chairman and Hemisphere GNSS CORE/Technical Support Team:
Please let people know that they are welcome to come as a guest for a couple of SC-104 meetings ... we are interested in hearing what people have to say. Furthermore, they should participate. If Lance Andre, (or other fellow BeerLeg's), conduct as much testing as he seems to imply in the blog then he should have some very appropriate inputs to the committee.
-BbBB-)
Contact RTCM
Radio Technical Commission For Maritime Services (RTCM)
Postal Mail Address:
1611 N. Kent St., Suite 605
Arlington VA 22209, USA
Telephone: +1-703-527-2000
Telefax: +1-703-351-9932
E-Mail
information@rtcm.org
http://www.rtcm.org/contact.php
