Converting GLONASS RTCM MSM messages to RINEX with RTKLIB

I’ve recently had a few questions about using RTKLIB to convert the newer RTCM Glonass MSM messages to RINEX so I thought that would make a good topic for a post.

First, I’ll include a little background for those not familiar with the details of RTCM messages. Until fairly recently, most receivers reporting raw observations in RTCM format were using the older legacy RTCM messages (e.g. 1004 and 1012), but over the last few years, it has become more common to use the newer MSM formats for RTCM messages since they support more constellations, are better standardized, and include a little more information. This RTCM cheat sheet from Snip is always a good place to look up info on RTCM messages. Here is a quick quote from that page, but I’d suggest clicking on it for more info.

An overall intent of the MSM message development effort has been to have more uniform and more modernized set of messages that can employed with any GNSS system (not just GPS and GLONASS).  To that end, seven new basic message types were defined (see the table below).  And then each of these was applied to each separate GNSS system.  So for example; an MSM7 style message for QZSS is nearly identical to an MSM7 style message for GPS, only their message ID assignment numbers vary.  The seven basic messages each have more informational details than the one that precedes it.

For the most part, RTKLIB supports all of the different forms of the MSM messages, but there is one significant exception. To translate the GLONASS phase observations into RINEX format requires knowing the frequency of each satellite signal. This is straightforward for the other constellations since all satellites in those constellations use the same frequency. However each GLONASS satellite is on a separate frequency. That information is available in the legacy GLONASS messages and in the GLONASS ephemeris messages, but not in all flavors of the MSM messages. Specifically, it is part of the MSM5 and the MSM7 GLONASS messages but not the others.

Until fairly recently, RTKLIB was not able to extract the frequency information from any of the MSM messages and would fail to include GLONASS phase observations for any of the MSM messages (1-7) if GLONASS ephemeris messages were not also present. Last year, I added a feature to the demo5 code starting with the b33a version which fixed this problem for the MSM5 and MSM7 messages, but the other messages will still fail to produce phase observations in the RINEX file. Also, at this time, the official RTKLIB code does not support GLONASS phase observations for any of the MSM messages unless ephemeris messages are also present.

There are several ways to get around this limitation. If you are using MSM7 messages and the official RTKLIB code, switching to the demo5 code will fix the problem. If you are using MSM4 or any of the other MSM messages that don’t include the extended satellite info, then configuring the receiver to output MSM7 format messages, or the older 1012 RTCM messages, or enabling GLONASS 1020 ephemeris messages will fix the problem. If you are unable to re-configure the receiver then it will be more difficult to get around this issue. One reader has reported success by appending downloaded ephemeris messages to the raw RTCM observation file. Since RTKLIB accepts wildcards in file name inputs, it shouldn’t be necessary to actually combine the files, simply specifying a filename with wildcards that will include both files should be sufficient. Note that the ephemeris file does not need to be current but this will only work if it includes all of the GLONASS satellites in the observation file and is not so far out of date that any of the GLONASS satellite slots have been replaced with another satellite with a different frequency. This does not happen very often so updating the ephemeris file should only need to be done quite infrequently.

Eventually it would be nice if RTKLIB were able to translate all of the GLONASS MSM message but it is a non-trivial fix to provide a continuously up to date version of the necessary satellite frequency information. In the meantime, these workarounds should help get around this limitation.