36
edits
Changes
Jump to navigation
Jump to search
Line 150:
Line 150: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 162:
Line 192: − + + + + + + + + + + + + + + + + Line 175:
Line 220: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − ==NMEA Sentences== − If you are using an NMEA GPS (as opposed to a Trimble using the TSIP binary interface), the RTCM/VOTER is looking for the following NMEA sentences: + + − $GPGGA+ − $GPGSV − $GPRMC − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − ==Garmin LVC==+
no edit summary
=RTCM/VOTER LED's=
=RTCM/VOTER LED's=
RX LED on the RTCM/VOTER will flash (same rate as ACT LED) if you have External CTCSS enabled, and the received signal has the wrong (or no) valid PL.
RX LED on the RTCM/VOTER will flash (same rate as ACT LED) if you have External CTCSS enabled, and the received signal has the wrong (or no) valid PL.
=Debug Options=
The VOTER/RTCM firmware supports some additional debugging information that can be turned on.
From the source code, the different Debug Options are listed as:
<pre>
1 - Alt/Main Host change notifications
2 - Ignore HWlock (GGPS only)
4 - GPS/PPS Failure simulation (GGPS only)
8 - POCSAG H/W output disable (GGPS only)
16 - IP TOS Class for Ubiquiti
32 - GPS Debug
64 - Fix GPS 1 second off
128 - Fix GPS 1 month off (WTF,O??)
</pre>
Not sure what they all do, but that is what they are. Here are the most common ones used:
*"Alt/Main Host change notifications" shows when the connection to the Asterisk server changes state.
*"IP TOS Class for Ubiquity" marks the IP headers from the RTCM/VOTER '''TO''' the network with ToS C0/DSCP 48 (UBNT shows this as 802.1p Class 6 (Voice <10mS
latency). Other sources show this as a Network Control TOS.) If you enable this, you also will want to have "utos=y" in your voter.conf to mark the packets from the network '''TO''' the RTCM/VOTER. We will probably change this option to mark the packets by default in a future version.
*"GPS Debug" will print NMEA or TSIP debug strings from the connected GPS.
The way this works is you add together the options you want to enable.
Want to enable GPS Debug and IP ToS, set debug to 48.
Just want to turn on GPS Debug, set debug to 32.
Just want ToS turned on, set debug to 16.
=GPS Issues=
=GPS=
The RTCM/VOTER will work with most GPS available. It requires either NMEA or Trimble TSIP binary data. It only receives data '''from''' the GPS (GPS TX), it does not send anything '''to''' the GPS.
The firmware is specifically written to talk to Trimble Thunderbolt receivers using Trimble's TSIP binary data interface, however, other Trimbles GPS receivers that talk TSIP are generally compatible.
==NMEA Sentences==
If you are using an NMEA GPS (as opposed to a Trimble using the TSIP binary interface), the RTCM/VOTER is looking for the following NMEA sentences:
<pre>
$GPGGA
$GPGSV
$GPRMC
</pre>
==GPS Lock==
==GPS Lock==
The GPS led will go solid regardless of the connection LED. That '''has''' to happen or it won't connect to the Asterisk server.
The GPS led will go solid regardless of the connection LED. That '''has''' to happen or it won't connect to the Asterisk server.
I also had crazy problems with poor signal on my GPS when I set it up sitting in a window, and once installed at site I had the GPS antenna maybe 6 ft from the VHF antenna, and after some troubleshooting found it was getting swamped with RF and loosing lock.
I also had crazy problems with poor signal on my GPS when I set it up sitting in a window, and once installed at site I had the GPS antenna maybe 6 ft from the VHF antenna, and after some troubleshooting found it was getting swamped with RF and loosing lock.
I found the debug setting of 40 useful in the RTCM, you can see a hex output of the GPS status.
I found the debug setting of 32 useful in the RTCM, you can see a hex output of the GPS status.
</pre>
==GPS Issues==
===Trimble Thunderbolt===
You may find your Trimble Thunderbolt is showing the incorrect date at the moment. It could be showing the year as 1997. This is due to the date in the Thunderbolt being reported incorrectly.
'''This can cause some of your voting receivers to not connect, if they are used with other GPS in your system.''' If you have '''ALL''' Thunderbolts, or '''NO''' Thunderbolts, you are probably fine. If you have '''ALL''' Thunderbolts, the date/time is probably wrong, but they will ALL be wrong, so they will connect.
GPS Time is a continuous counting time scale beginning at the January 5, 1980 to January 6, 1980 midnight. It is split into two parts: a time of week measured in seconds from midnight Sat/Sun and a week number. The time of week is transmitted in an unambiguous manner by the satellites, but only the bottom 10 bits of the week number are transmitted. This means that a receiver will see a week number count that goes up steadily until it reaches 1023 after which it will “roll over” back to zero, before steadily going up again. Such a week rollover will occur approx. every 20 years. The last week rollover occurred in 1999 and the next one will be in 2019.
The Thunderbolt manual states:
<pre>
The ThunderBolt adjusts for this week rollover by adding 1024 to any week number reported by GPS which is less than week number 936 which began on December 14, 1997. With this technique, the ThunderBolt will provide an accurate translation of GPS week number and TOW to time and date until July 30, 2017.
</pre>
</pre>
As such, the Trimble Thunderbolt has a firmware issue with the GPS Week rollover that manifested itself on July 30, 2017, causing the date to become incorrect.
We have added a brute-force fix starting in RTCM/VOTER firmware >=1.51. It fixes the Thunderbolts, we have not done extensive testing to see how it affects other TSIP receivers.
===Garmin===
====Garmin 18x LVC Wiring Issues====
If you have issues with your GPS 18x LVC not talking to the RTCM/VOTER, it may not be hooked up to the RTCM correctly.
The Garmin pin labeling is backwards to what you may think. See below. You probably need to swap pins 6 and 14.
<pre>
RTCM GPS 18x LVC
6 GRX <-- Rx Data 6 Green
7 GPPS <-- Pulse Output 1 Yellow
8 GND Ground 3 Black
8 GND Ground 5 Black
13 +5V -->Vin 2 Red
14 GTX --> TX Data 4 White
</pre>
Log into the RTCM and do 98 and you should see something like this:
<pre>
Current Time: Sun Apr 20, 2014 04:37:02.820
Last Rx Pkt System time: 04/20/2014 03:55:35.580, diff: 2487260 msec
Last Rx Pkt Timestamp time: 04/20/2014 03:55:32.064, diff: 3515 msec
Last Rx Pkt index: 160, inbounds: 1
</pre>
====Garmin and the RTCM====
Beware when buying newer Garmin GPS's to use with the Micro-Node RTCM.
The RTCM expects a 5V PPS signal.
Newer Garmin's (GPS 18X, 18X LVC, etc.) MAY NOT output 5V, and can cause issues. '''Check the Garmin datasheet'''.
The VOTER is designed to accept both 3.3V or 5V signals, and ''should'' work fine.
==No GPS/Mixed Mode==
You do not need a timing source to use an RTCM if you don’t want to vote. That’s called Mix Mode.
Having the PPS Polarity set to 2 tells the RTCM you do not have a GPS. That forces the RTCM to become a mix (non-voting) client. Turn it on, save it, and restart. A simple voter.conf would look like this:
<pre>
[general]
port = 667
password = BLAH
[1000]
Site1 = pswrd1,master,transmit
Site2 = pswrd2,transmit
</pre>
==Mixed Client Error==
"I am getting this error in Asterisk":
<pre>
<pre>
WARNING[2368]: chan_voter.c:4511 voter_reader: Voter client master timing source mobile1 attempting to authenticate as mix client!!
</pre>
</pre>
==Trimble Thunderbolt==
A mixed client error means the voter.conf file is expecting an RTCM to try and connect with a GPS IP packet (ie. has '''master''' in it in voter.conf), but the RTCM isn't
sending a GPS IP packet. So its a mismatch between voter.conf and Option 10 in the RTCM.
If you want to use a mix client (non-voted), make sure that receiver's configuration line in voter.conf '''does not''' have the '''master''' option set.
==GPS Debug==
To turn on GPS Debugging, set the Debug Option Level in the RTCM/VOTER to 32.
See [[#Debug Option]] levels for more information on how this works.
=Ubiquity ToS=
See https://help.ubnt.com/hc/en-us/articles/205231750-airMAX-How-is-QoS-and-prioritization-handled-by-airMAX-
So, if we set ToS/DSCP in the header to C0, then Ubiquity (and other gear watching ToS) ''should'' prioritize the packets. This sets the DSCP to 110 000 aka 48. UBNT shows this as 802.1p Class 6 (Voice <10mS latency). Other sources show this as a Network Control TOS.
There is an option in voter.conf to turn this on (utos=y). However, this only controls packets being sent from Asterisk '''TO''' the RTCM.
If you want to tag packets from the RTCM '''TO''' Asterisk, you need to set the RTCM debug option level to 16 (see [[#Debug Options]] for how this works).
At some point we should probably change the default behaviour of the RTCM firmware to mark the packets and use the debug setting to '''disable''' ToS. That change (if you wanted to compile your own firmware) would be:
<pre>
Change line 90 in IP.c
From:
#define IP_SERVICE ((AppConfig.DebugLevel & 16) ? 0xc0 : (IP_SERVICE_ROUTINE | IP_SERVICE_N_DELAY))
To:
#define IP_SERVICE ((AppConfig.DebugLevel & 16) ? (IP_SERVICE_ROUTINE | IP_SERVICE_N_DELAY) : 0xc0)
</pre>
This changes the conditional expression from if the debug level is 16 to mark the packets with DSCP 48 to if the debug level is 16, mark the packets routine (DSCP 0).