[App_rpt-users] RTCM [RX Packet Out of Bounds] ***Updated***
Chuck Henderson
rpt2 at chuck.midlandsnetworking.com
Sat Jun 16 05:47:50 UTC 2018
Kevin,
Here is what I see in your data. If your network latency is very low as you
say, then it looks like your GPS's don't all have the same time. LaPorte
and Crown_Point must be exactly the same as each other and Valparaiso is
probably within a millisecond, but lab is way off by about 60 milliseconds
(could be somewhere between 41 and 79ms), this is a problem and couldn't be
network latency or you would see that in a ping test. And all are about
200 to 280 milliseconds different than the NTP time reference that you are
using which is not a problem but just effects the debug display. Drain
time should be the time that audio is being removed from the buffer and
being sent to the transmitter which is sometime in the past as configured
by your buffers in the voter.conf. All change in 20ms jumps so a change of
20ms could just be a change of a fraction of a microsecond that incremented
from one 20ms buffer slot to the next one.
I would really suspect pps polarity in the RTCM config of either "lab" is
wrong, or pps polarity in all 3 of the other sites is wrong to account for
that kind of discrepancy.
Wrong PPS polarity should not keep it from working. Change the pps
polarity and wait a minute or two for it to resync and it should start
working again. If it doesn't then restart that RTCM after 99 saving the
new pps setting.
Most PPS pulses I have looked at are between 1ms and 100 ms long. if your
pps pulse is 50ms long then it would cause the time to be off by 50ms if
you have it set wrong. If the pps pulse is 500ms long then it probably
would not work at all if it is set to the wrong polarity because the time
would be half a second off and I am sure you don't have that much buffer
space. Do you know your pps pulse width? Is it the same in all of your
GPS's?
When I say pps polarity I am only talking about RTCM menu item 10 being 0
or 1.
I have never used the GPS's that you are using so I don't know anything
about how they behave. My experience is with the Garmin and with 3 other
brands that act exactly the same as the Garmins. They all have
configurable PPS pulse width.
On Fri, Jun 15, 2018 at 4:41 PM Kevin Babich <kevin.babich at gmail.com> wrote:
> Chuck,
>
>
>
> I setup the NTP client and enabled the service, as well as moved the
> MASTER to LAB. This is the output from VOTER DEBUG LEVEL 3:
>
>
>
> GPSTime (Lab): 06/15/18 15:02:39.000000000
>
> SysTime: 06/15/18 15:02:39.200000
>
> DrainTime: 06/15/18 15:02:39.160
>
> Got GPS (Lab): Lat: 4126.20N, Lon: 08654.13W, Elev: 229.90
>
> GPSTime (Valparaiso): 06/15/18 15:02:39.000000000
>
> SysTime: 06/15/18 15:02:39.260000
>
> DrainTime: 06/15/18 15:02:39.220
>
> Got GPS (Valparaiso): Lat: 4131.82N, Lon: 08702.05W, Elev: 301.2
>
> GPSTime (LaPorte): 06/15/18 15:02:39.000000000
>
> SysTime: 06/15/18 15:02:39.280000
>
> DrainTime: 06/15/18 15:02:39.240
>
> Got GPS (LaPorte): Lat: 4139.38N, Lon: 08645.96W, Elev: 329.2
>
> GPSTime (Crown_Point): 06/15/18 15:02:39.000000000
>
> SysTime: 06/15/18 15:02:39.280000
>
> DrainTime: 06/15/18 15:02:39.240
>
>
>
> In the Asterisk console, I restarted Asterisk by asserting the “reboot
> now” command and this is the output:
>
>
>
> GPSTime (Valparaiso): 06/15/18 15:07:04.000000000
>
> SysTime: 06/15/18 15:07:04.020000
>
> DrainTime: 06/15/18 15:07:03.960
>
> Got GPS (Valparaiso): Lat: 4131.82N, Lon: 08702.05W, Elev: 299.6
>
> GPSTime (LaPorte): 06/15/18 15:07:04.000000000
>
> SysTime: 06/15/18 15:07:04.020000
>
> DrainTime: 06/15/18 15:07:03.960
>
> Got GPS (LaPorte): Lat: 4139.38N, Lon: 08645.96W, Elev: 328.1
>
> GPSTime (Crown_Point): 06/15/18 15:07:04.000000000
>
> SysTime: 06/15/18 15:07:04.020000
>
> DrainTime: 06/15/18 15:07:03.980
>
> Got GPS (Crown_Point): Lat: 4121.15N, Lon: 08724.18W, Elev: 219.3
>
> GPSTime (Lab): 06/15/18 15:07:04.000000000
>
> SysTime: 06/15/18 15:07:04.220000
>
> DrainTime: 06/15/18 15:07:04.180
>
> Got GPS (Lab): Lat: 4126.20N, Lon: 08654.13W, Elev: 229.11
>
>
>
> Waiting an hour and testing again yields:
>
>
>
> SysTime: 06/15/18 16:23:30.200000
>
> DrainTime: 06/15/18 16:23:30.180
>
> Got GPS (Lab): Lat: 4126.20N, Lon: 08654.13W, Elev: 229.64
>
> GPSTime (Valparaiso): 06/15/18 16:23:30.000000000
>
> SysTime: 06/15/18 16:23:30.280000
>
> DrainTime: 06/15/18 16:23:30.240
>
> Got GPS (Valparaiso): Lat: 4131.82N, Lon: 08702.05W, Elev: 298.1
>
> GPSTime (Crown_Point): 06/15/18 16:23:30.000000000
>
> SysTime: 06/15/18 16:23:30.280000
>
> DrainTime: 06/15/18 16:23:30.240
>
> Got GPS (Crown_Point): Lat: 4121.15N, Lon: 08724.18W, Elev: 220.9
>
> GPSTime (LaPorte): 06/15/18 16:23:30.000000000
>
> SysTime: 06/15/18 16:23:30.280000
>
> DrainTime: 06/15/18 16:23:30.240
>
> Got GPS (LaPorte): Lat: 4139.38N, Lon: 08645.96W, Elev: 326.6
>
>
>
> It would appear the NTP activity is slowly (expected) netting the SysTime,
> however, the LAB (master) is still off. If the SysTime comes from
> Asterisk, then what gives?
>
>
>
> An unanswered question: What is DrainTime describing, and what drives the
> displayed value? I notice on yours, everything matches.
>
>
>
> Kindest Regards,
>
>
>
> Kevin Babich | N9IAA
>
> Valparaiso, IN 46383
>
>
>
> *From:* Chuck Henderson <rpt2 at chuck.midlandsnetworking.com>
> *Sent:* Wednesday, June 13, 2018 2:34 AM
> *To:* kevin.babich at gmail.com
> *Subject:* Re: [App_rpt-users] RTCM [RX Packet Out of Bounds]
> ***Updated***
>
>
>
> That is complicated and I don't remember. All the needed software is
> installed already with the allstarlink raspberry pi dial install that I
> used. I
>
> think I used 07-08-2017RAT_RC1.img but I can't remember for sure. I also
> can't remember exactly what I did to set up the time sync but I looked for
> clues something like
>
>
>
> man systemd-timesyncd
>
> timedatectl
>
>
>
> I had used ntpd in the past with x86 ACID but didn't need it for the DIAL
> version I am using now because this other method of getting the time was
> builtin and all I had to do was a google search and I landed on the exact
> files to edit to make it use my own dedicated ntp server which I have had
> running for many years. If it ever dies I will have to re-google how to
> rebuild it using current hardware. I quit trying to remember things that
> I can just ask "ok google".
>
>
>
>
>
>
>
> On Wed, Jun 13, 2018 at 1:22 AM Kevin Babich <kevin.babich at gmail.com>
> wrote:
>
> Chuck,
>
>
>
> How does one go about syncing the server in app_rpt?
>
>
>
> Kindest Regards,
>
>
>
> Kevin Babich | N9IAA
>
> Valparaiso, IN 46383
>
>
>
> *From:* App_rpt-users <app_rpt-users-bounces at lists.allstarlink.org> *On
> Behalf Of *Chuck Henderson
> *Sent:* Tuesday, June 12, 2018 11:50 PM
> *To:* Users of Asterisk app_rpt <app_rpt-users at lists.allstarlink.org>
> *Subject:* Re: [App_rpt-users] RTCM [RX Packet Out of Bounds]
> ***Updated***
>
>
>
> Yes, many GPS will sometimes be off by one second in the RTCM. If I have
> to power cycle any of my voters/RTCMs I usually then do a reboot via the
> RTCM menu so that the GPS is already up and accurate when the RTCM boots
> and this seems to eliminate the one second off problem, most of the time.
> Both Jim and I tried to fix this and neither of us could. When all set up
> to troubleshoot it the problem never happens. The software has a couple
> of code segments to try to make it work even when exactly one second off
> but I don't think that works all the time either.
>
>
>
> Also in looking at the code I see that SysTime does not matter at all. It
> is just a reference to look at in the debug output. Mine exactly matches
> because I also sync my Linux time to a GPS reference separately from the
> app_rpt voter code. But I tried disabling that and setting the date and
> time both wrong and the voter still works because it keeps it's own time
> that is referenced to the master and not dependent on the system time.
>
>
>
> So the master time does need to be the first time that the voter channel
> driver receives each second. Other RTCMs time must arrive later than the
> master arrives but before the buffer length later.
>
> The RTCM-GPS time can be any amount wrong as long as all RTCM-GPSs are
> exactly the same as each other.
>
> Start with much bigger buffers than you need and gradually reduce them.
>
>
>
>
>
> On Tue, Jun 12, 2018 at 10:03 PM Tim Sawyer <tisawyer at gmail.com> wrote:
>
> This may be a bit off topic but I've had problems with the BG7TBL units.
> One won't get a RTCM GPS lock with initial power on after it's been off for
> a while... like a day or more. The GPS Lock LED on the GPS comes on but
> doesn't on the RTCM. Subsequent immediate power cycle cures that. Another
> I've seen shifts it's time by one second after it's been running for some
> period.
>
>
>
> On the other hand I have one that works flawlessly. So I'm a little
> concerned about these. I don't know if there some incompatibility with the
> RTCM or if the BG7TLB units have inconsistent performance.
>
>
>
> Any thoughts on that possibly being repeated to the issue Kevin is having?
>
>
>
>
>
> On Tue, Jun 12, 2018 at 7:24 PM Chuck Henderson <
> rpt2 at chuck.midlandsnetworking.com> wrote:
>
> The server needs to have the earliest time of all GPS time receivers.
> Master RTCM should be on the same LAN switch as the server and all other
> GPS time receivers must be at least some fraction of nano seconds delayed
> from the master time. Your LAB time arrives at the server before the
> master time arrives and that is not allowed for in the software. I am
> surprised that it even works at all. It should not work.
>
> I also am surprised that the SysTime does not exactly match with the
> Master Time “Valparaiso” as I checked 3 servers of mine here and the
> SysTime always exactly matches the master GPSTime. Master GPSTime is the
> reference for SysTime.
>
> I am reviewing the source to see what a non master time arriving before
> the master time might mess up. I know it has never worked for me when I
> have tried using an even slightly delayed master time like putting a couple
> of store and forward ethernet devices between the master time and the
> server.
>
>
>
> On Tue, Jun 12, 2018 at 4:31 PM Kevin Babich <kevin.babich at gmail.com>
> wrote:
>
> Chuck,
>
>
>
> “Valparaiso” is the master, while “Lab” is closer to the server, it isn’t
> regularly online. The PPS Polarity is set to non-inverted, the only
> selection which works. We have more of the NOVUS GPSDO’s, I will try it to
> see if it remains in-sync with the other. Perhaps the BG7TBL oscillator
> has an issue. I know that one of his models had an issue with floating
> point math and didn’t report time accurately, I believe it was corrected in
> mine, but, maybe not.
>
>
>
> Kindest Regards,
>
>
>
> Kevin Babich | N9IAA
>
> Valparaiso, IN 46383
>
>
>
> *From:* App_rpt-users <app_rpt-users-bounces at lists.allstarlink.org> *On
> Behalf Of *Chuck Henderson
> *Sent:* Tuesday, June 12, 2018 3:35 AM
> *To:* Users of Asterisk app_rpt <app_rpt-users at lists.allstarlink.org>
> *Subject:* Re: [App_rpt-users] RTCM [RX Packet Out of Bounds]
> ***Updated***
>
>
>
> Kevin,
>
> Which one is the master? From the looks of it I would say that "lab"
> should be the master as it appears to be the first one to arrive at the
> server so must have the lowest network delay or they are inaccurate.
> Inaccuracy could be caused by having the PPS polarity wrong in the RTCM and
> are setting time based on the trailing edge of the pulse rather than the
> leading edge.
>
>
>
> I am also using a Raspberry Pi 3B (not plus)
>
>
>
> The master should be the first one to get a time packet to the server, or
> they should all be tied exactly.
>
> Chuck
>
>
>
> On Mon, Jun 11, 2018 at 8:46 PM Kevin Babich <kevin.babich at gmail.com>
> wrote:
>
> Chuck,
>
>
>
> A couple facts:
>
>
>
> The network has very low latency (sub ms) across all nodes on the VLAN.
>
> The site labeled LAB has a lab quality GPSDO, by NOVUS Power.
>
> The other sites utilize the GPSDO, by BG7TBL, as available on eBay, all
> are the 2016 vintage.
>
>
>
> Question:
>
>
>
> Is the reported system time exactly as reported by the timebase? If so,
> it would appear I have an issue with the accuracy of the GPSDO NMEA output.
>
>
>
> Here is an example of the output from my implementation:
>
>
>
> GPSTime (Lab): 06/11/18 20:16:57.000000000
>
> SysTime: 06/11/18 20:16:57.220000
>
> DrainTime: 06/11/18 20:16:57.180
>
> Got GPS (Lab): Lat: 4126.20N, Lon: 08654.13W, Elev: 233.71
>
> GPSTime (Valparaiso): 06/11/18 20:16:57.000000000
>
> SysTime: 06/11/18 20:16:57.280000
>
> DrainTime: 06/11/18 20:16:57.220
>
> Got GPS (Valparaiso): Lat: 4131.82N, Lon: 08702.06W, Elev: 299.5
>
> GPSTime (Crown_Point): 06/11/18 20:16:57.000000000
>
> SysTime: 06/11/18 20:16:57.280000
>
> DrainTime: 06/11/18 20:16:57.220
>
> Got GPS (Crown_Point): Lat: 4121.15N, Lon: 08724.18W, Elev: 218.6
>
> GPSTime (LaPorte): 06/11/18 20:16:57.000000000
>
> SysTime: 06/11/18 20:16:57.280000
>
> DrainTime: 06/11/18 20:16:57.220
>
> Got GPS (LaPorte): Lat: 4139.38N, Lon: 08645.96W, Elev: 324.6
>
>
>
> GPSTime (Lab): 06/11/18 20:17:19.000000000
>
> SysTime: 06/11/18 20:17:19.220000
>
> DrainTime: 06/11/18 20:17:19.180
>
> Got GPS (Lab): Lat: 4126.20N, Lon: 08654.13W, Elev: 233.38
>
> GPSTime (Valparaiso): 06/11/18 20:17:19.000000000
>
> SysTime: 06/11/18 20:17:19.260000
>
> DrainTime: 06/11/18 20:17:19.220
>
> Got GPS (Valparaiso): Lat: 4131.82N, Lon: 08702.05W, Elev: 293.7
>
> GPSTime (Crown_Point): 06/11/18 20:17:19.000000000
>
> SysTime: 06/11/18 20:17:19.280000
>
> DrainTime: 06/11/18 20:17:19.240
>
> Got GPS (Crown_Point): Lat: 4121.15N, Lon: 08724.18W, Elev: 217.5
>
> GPSTime (LaPorte): 06/11/18 20:17:19.000000000
>
> SysTime: 06/11/18 20:17:19.280000
>
> DrainTime: 06/11/18 20:17:19.240
>
> Got GPS (LaPorte): Lat: 4139.38N, Lon: 08645.96W, Elev: 324.1
>
>
>
> Results AFTER resetting the MASTER:
>
>
>
> GPSTime (Lab): 06/11/18 20:31:23.000000000
>
> SysTime: 06/11/18 20:31:23.220000
>
> DrainTime: 06/11/18 20:31:23.180
>
> Got GPS (Lab): Lat: 4126.20N, Lon: 08654.13W, Elev: 231.86
>
> GPSTime (Valparaiso): 06/11/18 20:31:23.000000000
>
> SysTime: 06/11/18 20:31:23.280000
>
> DrainTime: 06/11/18 20:31:23.240
>
> Got GPS (Valparaiso): Lat: 4131.81N, Lon: 08702.05W, Elev: 301.8
>
> GPSTime (LaPorte): 06/11/18 20:31:23.000000000
>
> SysTime: 06/11/18 20:31:23.280000
>
> DrainTime: 06/11/18 20:31:23.240
>
> Got GPS (LaPorte): Lat: 4139.38N, Lon: 08645.96W, Elev: 327.7
>
> GPSTime (Crown_Point): 06/11/18 20:31:23.000000000
>
> SysTime: 06/11/18 20:31:23.280000
>
> DrainTime: 06/11/18 20:31:23.240
>
> Got GPS (Crown_Point): Lat: 4121.15N, Lon: 08724.18W, Elev: 218.5
>
>
>
> Thoughts?
>
>
>
> Kindest Regards,
>
>
>
> Kevin Babich | N9IAA
>
> Valparaiso, IN 46383
>
>
>
> *From:* App_rpt-users <app_rpt-users-bounces at lists.allstarlink.org> *On
> Behalf Of *Chuck Henderson
> *Sent:* Monday, June 4, 2018 4:51 AM
> *To:* Users of Asterisk app_rpt <app_rpt-users at lists.allstarlink.org>
> *Subject:* Re: [App_rpt-users] RTCM [RX Packet Out of Bounds]
> ***Updated***
>
>
>
> Kevin,
>
> I just checked 3 of my RTCM's and got the following results.
> RTCM1:
> Current Time: Mon Jun 04, 2018 08:55:43.640
> Last Rx Pkt System time: 06/04/2018 02:55:56.040, diff: 21587600 msec
> Last Rx Pkt Timestamp time: 06/04/2018 02:55:56.040, diff: 0 msec
> Last Rx Pkt index: 1080, inbounds: 1
>
> RTCM2:
> Current Time: Mon Jun 04, 2018 08:58:20.300
> Last Rx Pkt System time: <System Time Not Set>, diff: -905657056 msec
> Last Rx Pkt Timestamp time: <System Time Not Set>, diff: 0 msec
> Last Rx Pkt index: 0, inbounds: 0
>
> RTCM3:
> Current Time: Mon Jun 04, 2018 08:58:48.060
> Last Rx Pkt System time: <System Time Not Set>, diff: -905629296 msec
> Last Rx Pkt Timestamp time: <System Time Not Set>, diff: 0 msec
> Last Rx Pkt index: 0, inbounds: 0
>
> I would not be concerned about the times. They are not important.
>
> A better thing to look at is in the Asterisk CLI issue the command
> voter debug level 3
>
> Then expect output like the following:
>
> GPSTime (South): 06/04/18 04:07:16.000000000
>
> SysTime: 06/04/18 04:07:16.000000
>
> DrainTime: 06/04/18 04:07:15.960
>
> Got GPS (South): Lat: 4020.80N, Lon: 08856.35W, Elev: 225.7
>
> GPSTime (North): 06/04/18 04:07:16.000000000
>
> SysTime: 06/04/18 04:07:16.000000
>
> DrainTime: 06/04/18 04:07:15.960
>
> Got GPS (North): Lat: 4030.79N, Lon: 08857.99W, Elev: 245.4
>
> GPSTime (East): 06/04/18 04:07:16.000000000
>
> SysTime: 06/04/18 04:07:16.000000
>
> DrainTime: 06/04/18 04:07:15.980
>
> Got GPS (East): Lat: 4030.02N, Lon: 08855.92W, Elev: 250.2
>
> sending KEEPALIVE (GPS) packet to client East digest 99479120
>
> sending KEEPALIVE (GPS) packet to client North digest dd455bb0
>
> sending KEEPALIVE (GPS) packet to client South digest 4a396b22
>
> GPSTime (East): 06/04/18 04:07:17.000000000
>
> SysTime: 06/04/18 04:07:17.000000
>
> DrainTime: 06/04/18 04:07:16.980
>
> Got GPS (East): Lat: 4030.02N, Lon: 08855.92W, Elev: 250.2
>
> GPSTime (South): 06/04/18 04:07:17.000000000
>
> SysTime: 06/04/18 04:07:17.000000
>
> DrainTime: 06/04/18 04:07:16.980
>
> Got GPS (South): Lat: 4020.80N, Lon: 08856.35W, Elev: 225.7
>
> GPSTime (North): 06/04/18 04:07:17.000000000
>
> SysTime: 06/04/18 04:07:17.000000
>
> DrainTime: 06/04/18 04:07:16.980
>
> Got GPS (North): Lat: 4030.79N, Lon: 08857.99W, Elev: 245.4
>
> sending KEEPALIVE (GPS) packet to client East digest 99479120
>
> sending KEEPALIVE (GPS) packet to client North digest dd455bb0
>
> sending KEEPALIVE (GPS) packet to client South digest 4a396b22
>
> GPSTime (South): 06/04/18 04:07:18.000000000
>
> SysTime: 06/04/18 04:07:18.000000
>
> DrainTime: 06/04/18 04:07:17.960
>
> Got GPS (South): Lat: 4020.80N, Lon: 08856.35W, Elev: 225.7
>
> GPSTime (North): 06/04/18 04:07:18.000000000
>
> SysTime: 06/04/18 04:07:18.000000
>
> DrainTime: 06/04/18 04:07:17.980
>
> Got GPS (North): Lat: 4030.79N, Lon: 08857.99W, Elev: 245.4
>
> GPSTime (East): 06/04/18 04:07:18.000000000
>
> SysTime: 06/04/18 04:07:18.000000
>
> DrainTime: 06/04/18 04:07:17.980
>
> Got GPS (East): Lat: 4030.02N, Lon: 08855.92W, Elev: 250.2
>
> GPSTime (South): 06/04/18 04:07:19.000000000
>
> SysTime: 06/04/18 04:07:19.000000
>
> DrainTime: 06/04/18 04:07:18.960
>
> Got GPS (South): Lat: 4020.80N, Lon: 08856.35W, Elev: 225.7
>
> GPSTime (North): 06/04/18 04:07:19.000000000
>
> SysTime: 06/04/18 04:07:19.000000
>
> DrainTime: 06/04/18 04:07:18.960
>
> Got GPS (North): Lat: 4030.79N, Lon: 08857.99W, Elev: 245.4
>
> sending KEEPALIVE (GPS) packet to client East digest 99479120
>
> GPSTime (East): 06/04/18 04:07:19.000000000
>
> sending KEEPALIVE (GPS) packet to client North digest dd455bb0
>
> SysTime: 06/04/18 04:07:19.000000
>
> sending KEEPALIVE (GPS) packet to client South digest 4a396b22
>
> DrainTime: 06/04/18 04:07:18.980
>
> Got GPS (East): Lat: 4030.02N, Lon: 08855.92W, Elev: 250.2
>
> GPSTime (North): 06/04/18 04:07:20.000000000
>
> SysTime: 06/04/18 04:07:20.000000
>
> DrainTime: 06/04/18 04:07:19.960
>
> Got GPS (North): Lat: 4030.79N, Lon: 08857.99W, Elev: 245.4
>
> GPSTime (East): 06/04/18 04:07:20.000000000
>
> SysTime: 06/04/18 04:07:20.000000
>
> DrainTime: 06/04/18 04:07:19.980
>
> Got GPS (East): Lat: 4030.02N, Lon: 08855.92W, Elev: 250.2
>
> GPSTime (South): 06/04/18 04:07:20.000000000
>
> SysTime: 06/04/18 04:07:20.000000
>
> DrainTime: 06/04/18 04:07:19.980
>
> Got GPS (South): Lat: 4020.80N, Lon: 08856.35W, Elev: 225.7
>
>
>
> Ignore the lines I marked in green and only be concerned with the lines
> that have "Time" in them.
>
> Notice that each RTCM has 3 timestamp lines that are mostly together and
> they should be within about 40 ms of each other and should also be within
> about 40ms of the other RTCMs set of lines for that second. (this is with
> no signals present and with a very low network latency between RTCMs and
> the server).
>
>
>
> If you find that one RTCM is many ms out of line with the others, I
> recommend rebooting that one and/or the master one.
>
>
>
> I also recommend not being logged into the RTCMs via telnet except to make
> setting changes. Having an active telnet session to the RTCM can have a
> negative impact on it's ability to maintain time sync lock. Having active
> output on that telnet session will have a negative impact on it's ability
> to maintain time sync lock.
>
>
>
> If the above does not solve your problem then try increasing your tx
> buffer setting to 1400 and see if that eliminates your problem. But do not
> evaluate if the problem is solved while you have an active telnet session
> to the RTCM.
>
>
>
> If you still have a problem then send the output of your "voter debug
> level 3" (with no signals present and no active telnet sessions to RTCMs).
>
> Chuck
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, May 31, 2018 at 7:30 PM, Kevin Babich <kevin.babich at gmail.com>
> wrote:
>
> Hayden,
>
>
>
> When running DEBUG = 32, I see the following, but, only on occasion, say
> every minute or so:
>
>
>
> 06/01/2018 00:22:12.240 Warning: GPS Data time period elapsed
>
> GPS-DEBUG:
> $GPRMC,002213.00,A,4131.82046,N,08702.05712,W,0.027,,010618,,,D*6D
>
> GPS-DEBUG: mon: 5, gps_time: 1527812533, ctime: Fri Jun 1 00:22:13 2018
>
>
>
> I suspect this has to do with the receiver losing lock. However, it
> doesn’t make sense as the receiver reports a strong signal and doesn’t show
> signs of loss of signal on the front alarm panel. The GPS antenna is
> designed with high RF immunity and is at a site with little activity.
>
>
>
> Kindest Regards,
>
>
>
> Kevin Babich | N9IAA
>
> Valparaiso, IN 46383
>
>
>
> *From:* App_rpt-users <app_rpt-users-bounces at lists.allstarlink.org> *On
> Behalf Of *Hayden Honeywood
> *Sent:* Thursday, May 31, 2018 5:56 PM
>
>
> *To:* app_rpt-users at lists.allstarlink.org
> *Subject:* Re: [App_rpt-users] RTCM [RX Packet Out of Bounds]
> ***Updated***
>
>
>
> Is the time in UTC? How far off is the system time?
>
>
>
> Have you done a full calibration of each board?
>
> What baud rate do you run on your GPS's?
>
>
>
> I tend to use 9600 baud and have had no issues with the GPS's I have used.
>
>
>
> There is various GPS debug tools available in the RTCM. They are
> documented here -
>
> https://wiki.allstarlink.org/wiki/RTCM_Client#GPS
>
>
>
> Can you possibly try injecting a 9.6MHz signal in place of the crystal on
> board? Perhaps you have a variant of James KI0KN's problem where his
> crystals were off frequency.
>
>
>
> I can't comment on that as I built all my boards and they have external
> frequency references.
>
>
>
> Regards
>
> Hayden VK7HH
>
>
>
>
>
>
>
>
> From: App_rpt-users <app_rpt-users-bounces at lists.allstarlink.org> On
> Behalf Of Hayden Honeywood
> Sent: Wednesday, May 30, 2018 5:34 PM
> To: app_rpt-users at lists.allstarlink.org
> Subject: Re: [App_rpt-users] RTCM [RX Packet Out of Bounds] ***Updated***
>
>
>
> What is your values in voter.conf for RX buffer (960) and in the RTCM
> client for TX buffer (480). Are all RTCM TX buffers set to the same value?
> Yes, 480. These values were based upon the math Jim provided, which is a
> function of maximum latencies on the network. We rarely have greater than
> 1ms to any host on the network.
>
>
>
> Are all the GPS's in a location where they cannot be swamped with RF? Yes,
> and they utilize PCTEL antennas with filtering for use in RF dense
> environments.
>
>
>
> Some users have had success with a dedicated RTCM as the master timing
> source (with no radio connected). Has it been suspected that an RTCM
> doesn’t have the horsepower to handle both functions contemporaneously?
>
>
>
> Regards
>
> Hayden VK7HH
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.allstarlink.org/pipermail/app_rpt-users/attachments/20180530/24a4675d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 30 May 2018 19:51:43 -0500
> From: "Kevin Babich" <kevin.babich at gmail.com>
> To: "'Users of Asterisk app_rpt'"
> <app_rpt-users at lists.allstarlink.org>
> Subject: Re: [App_rpt-users] RTCM [RX Packet Out of Bounds]
> ***Updated***
> Message-ID: <010001d3f879$8c2b3710$a481a530$@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hayden,
>
>
>
> Do you know what exactly “RX Packet Out of Bounds” refers to? I can infer
> its meaning, but, one can’t be certain. Any thoughts why the system time
> is always so far off? It has always been, since I began experimenting with
> the RTCM in 2012. This is consistent across many RTCM’s.
>
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and
> scroll down to the bottom of the page. Enter your email address and press
> the "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a message to
> the list detailing the problem.
>
>
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and
> scroll down to the bottom of the page. Enter your email address and press
> the "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a message to
> the list detailing the problem.
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and
> scroll down to the bottom of the page. Enter your email address and press
> the "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a message to
> the list detailing the problem.
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and
> scroll down to the bottom of the page. Enter your email address and press
> the "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a message to
> the list detailing the problem.
>
>
>
>
> --
>
> Tim WD6AWP
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and
> scroll down to the bottom of the page. Enter your email address and press
> the "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a message to
> the list detailing the problem.
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and
> scroll down to the bottom of the page. Enter your email address and press
> the "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a message to
> the list detailing the problem.
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and
> scroll down to the bottom of the page. Enter your email address and press
> the "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a message to
> the list detailing the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20180616/bd00deb7/attachment.html>
More information about the App_rpt-users
mailing list