iG GPS

That is the question I will address here.

Let us assume we are transporting RTCM3.2 MSM 4 over a UHF radio link and we are NOT going to repeat the signal.

With current constellations, tracking to 5 degrees elevation mask, in North America this is about 770 bytes-per-second, most of the time. More on this byte-rate later.

If you have a narrow-banded FCC license, which most of us do, then the only/most universal 9600 baud radio protocol alternative will be:

Satel, 9600, FEC OFF -> 1,100 bytes per second

Satel, 9600, FEC ON -> 830 bytes per second

FEC ON redundantly encodes an error correction code into the stream. So the receiver can detect and fix some bit errors, salvaging a message that would otherwise be destroyed by channel noise.

In a standard communication channel, this makes it so that the receiver does not have to ask to have a damaged message retransmitted. However, in the RTK model, a new RTK message is broadcast every second anyway. So if you miss a message, all you need to do is wait about 1/2 second and a new message will be available. This makes the cost of a missed message effectively zero.

RTCM 3.x Message Types

A typical RTCM3 stream will usually contain four message types:

• 1004; 1-second; extended L1/L2 RTK Observables, the main message
• 1006; 30-seconds; RTK Reference Station ARP plus HI, the location of the base
• 1012; 1-second; GNSS L1/L2 Observables, GNSS main message
• 1033; 30-seconds; Receiver and antenna information

1006 and 1033 are only important every long-once-in-a-while. Typically they are sent every 15 or 30 seconds so that a receiver need not wait too long to get them when first connected. Turning on a Rover, it will not FLOAT or FIX until it has received a 1006 message, thus if only sent once per minute then you might have to wait an extra minute to get a fix. If you send it every 15-seconds, then a recently turned on receiver would need only wait 15-seconds for the next message. 1004 and 1012 (or perhaps other similar messages) are the typical main payload and are sent every second.

It is probably sufficient for most RTK rovers to get a complete 1004/1012 pair every 5 to 10 seconds with absolutely no loss in accuracy or latency to the RTK result. There may be other main payload message types, but like 1004 and 1012 they only need be received occasionally.

So, what happens if the radio channel is noisy and only one out of 10 messages makes it to the Rover? In general, nothing happens. The rover continues to work just as if it had received every single message. There is no loss of accuracy, no increase in latency and most importantly no increase in HRMS or VRMS.

Number of Tracked SV’s. Maximum Byte Per Second Rates

FEC ON adds 25 to 30% overhead to the original message. Since the message is longer, there may be a higher probability that the message will be damaged in transit. So, a shorter message without FEC may have a higher probability of transfer than a longer message with FEC. But, generally this difference is negated as the longer message with FEC may be correctable.

The real issue is that at times during the day, the total number of tracked SV’s changes and the message which contains corrections for all of the satellites tracked at the base changes in length.

Here is the predicted number of satellites tracked for the CORS station here at my office:

This station is currently sending 770 bytes per second while using (sending corrections) for 37 satellites. (Note: I don’t include QZSS, IRNSS, SBAS SV’s in the correction stream.) Later today I expect that it will sending corrections for 42-satellites and the byte rate will approach 870 bytes per second.

Clearly, 870 bytes per second may be troublesome for a channel that can only support 830 bytes per second (FEC ON). 870 bytes per second will nicely fit into a 1,100 bytes per second stream (FEC OFF).

We often get calls from customers who complain that there rover works great every day until some hour and then the rover starts having issues. It might be that their daily failure is correlated to a time of day when there are usually a very high number of satellites available for tracking. (You can check this by listening to the broadcast frequency, if the radio broadcasts 100% of the time, then too much data.) A reasonable solution to this issue is to raise the elevation mask on the base, which will greatly reduce the number of tracked satellites AND to turn FEC OFF.

RTCM3 vs. SCMRX

If you are working with multiple equipment vendors, then RTCM3 is the safe bet for the most compatible messages. However, if you are working with all ‘mainline’ Trimble receivers then CMRx is a good alternative. If you are working with all OEM Trimble equipment (iG8 and iG9 receivers from iGage for example) then SCMRX (Scrambled CMRX) is a good alternative.

The difference between RTCM3 and SCMRX byte rates for my station using 38 SV’s at this moment is:

So, SCMRX is a lot better choice for the transmitted message type, if all equipment can utilize it.

For a community base, like SGU2, it is not reasonable to broadcast proprietary messages. RTCM3 should be useable by all receivers.

Repeaters

Using a store-and-forward repeater becomes very tricky. Repeaters typically have a 50 ms delay from when they receive the last character of a message until they start retransmitting the message. So the entire message must be transmitted in 475 milliseconds, instead of 1,000 milliseconds. The maximum effective byte rates for FEC ON and OFF is reduced to:

Satel, 9600, FEC OFF -> 495 bytes per second

Satel, 9600, FEC ON -> 394 bytes per second

It is probable that sCMRx, FEC OFF and an elevation mask of 8 degrees may be the only solution that provides 24-7 store-and-forward repeater viability.

But, what if you want to repeat RTCM3 MSM4 signals? Is there possible solution?

I know of two possible work arounds:

• Use an internet backhaul for the repeater, this makes entire message available to the repeater at the same time as the base, since the TCPIP connection will have very little latency and be relatively fast.
• Use a dedicated receive only radio to receive the corrections, then send them out a serial port to a dedicated transmit repeater radio for simultaneous transmission. This option requires that the Tx frequency be different than the Rx frequency, the wider the separate the better. Depending on the quality of the IF stages of the dedicated Rx radio and the input/output spacing you might need to add a duplexer, but that would have the benefit of only needed one antenna.

So, summarizing this section: Repeaters are going to be tough going forward with narrow banded radios and high SV counts.

Conclusion

FEC = OFF is the conclusion. If you are using TRANSPARENT at 9600 baud (wideband), same conclusion: FEC OFF.

I have been writing X-PAD FAQ’s every time I stumble over something interesting. Typically the items are very simple, but I think it is worth writing a bit about them to save others a bit of stumbling. Here is a quick synopsis:

• Viewing a very detailed log of field work is just a single click away in the MEASUREMENTS list: Viewing very detailed job log/history
• Entering CODE and DESCRIPTION on the SURVEY and STAKEOUT screens
• Importing SurvPC/SurvCE .LOC or .DAT localization files directly

All of the FAQ’s are in a single secure web [ folder ]

Step-by-step instructions for setting up a ground system for a single point or multiple points linked below:

Single Point:

Two-Point Arbitrary Bearing: