- App_rpt-users - lists.keekles.org

Allstar Pushover Module
by Justin Harris 25 Jun '18

25 Jun '18

I have created a relatively simple python application that runs on your Allstar node to send notifications over the pushover service. I'm not sure if anyone has done this already but it was a fun project to work on. Feel free to try it out and let me know if you have any issues as there will likely be bugs. The concept is simple. When your node comes online you a notification. If there are any connects or disconnects you will receive a notification. Multiple nodes on a single device are supported, additionally multiple pushover accounts are supported. https://bitbucket.org/suidnet/allstar-pushover Take care, Justin Harris KG7FKJ

1 0

Echolink Call Drops
by 2E0SIP 24 Jun '18

24 Jun '18

Hi All, I'm currently investigating an issue where echolink users appear to unkey and then rekey in the archive files, but in reality they have remained keyed up. As far as I can tell there's no drop in audio during this event. Here's the output of the text file created by the archivedir option, showing the Echolink user Key and Unkey: 20180625001717,RXKEY,3936347 20180625001717,TXKEY,MAIN 20180625001717,TXKEY,47920 20180625001721,RXUNKEY,3936347 20180625001721,TXUNKEY,47920 20180625001721,RXKEY,3936347 20180625001721,TXKEY,47920 20180625001732,RXUNKEY,3936347 20180625001732,TXUNKEY,47920 20180625001735,TXUNKEY,MAIN During this event the Echolink user remained keyed up. Where should I start looking to troubleshoot this in more detail? Thanks Matthew

2 1

Connectivity issues
by Bryan Fields 23 Jun '18

23 Jun '18

We've seen some interesting connectivity issues for ATT users recently. The most recent was some sort of ALG proxy on anything destined to udp/4569. This appears to intercept registration traffic and then selectively forward it on. I'm at a loss as to why this is happening. Last weekend ATT stopped allowing one of the subnets for the stats server in their routing table too. That was a bit easier to troubleshoot and easier to reach someone on their backbone with clue. The stats server isn't a critical part of the network either. If you're having any issues, please try registration on port 4566. I'll stress again, this really isn't an AllStar issue, it's a crappy ISP breaking the internet issue. There's not much the admin team can do if your ISP isn't going to route packets properly :( -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

2 3

DMR Gateway Available for field day weekend.
by Mike 22 Jun '18

22 Jun '18

Good FD Weekend HAM's I am making available for the whole field day weekend, NODE 29999 is connected to DMR Gatway Talk Group 91 WorldWide You may use it on echolink node 155783 / KB8JNM-L and on ASL node 29999 It will be in full transmit as I have time to monitor directly. Be glad to pass that on to someone for the night shift so we can keep it open for the duration. But if not, it will be bumped to rx only while I sleep. Please be on your best behavior to keep a good example going for ASL on these gateways of high traffic DMR channels. This node now supports over 100+ streams.(4core 8gb) But limited to 25 on echolink. So if you want to just connect via echolink to it and listen, GREAT ! You may view the allmon at http://29999.link/allmon/link.php?nodes=29999 Please use it in the best interest of promoting amateur radio. Have a great weekend ! 73, ...mike/kb8jnm

1 0

dadhi_test results.
by Pierre Martel 22 Jun '18

22 Jun '18

did a test on a vps I have on linode. was wondering if this sounds good for you :[/usr/sbin]: sudo ./dahdi_test Opened pseudo dahdi interface, measuring accuracy... 99.997% 99.993% 99.997% 99.997% 99.984% 99.998% 99.991% 99.607% 99.993% 99.603% 99.608% 99.990% 99.613% 99.995% 99.998% 99.613% 99.992% 99.997% 99.988% 99.995% 99.999% 99.991% 99.985% 99.603% 99.996% 99.995% 99.998% 99.999% 99.995% 99.995% 99.612% 99.999% 99.893% 99.643% 99.525% 99.998% 99.994% 99.594% 99.999% 99.991% 99.998% 99.999% 99.615% 99.995% 99.996% 99.998% 99.996% 99.994% 99.995% 99.997% 99.980% 99.993% 99.999% 99.984% 99.999% 99.993% 99.998% 99.992% 99.985% 99.997% 99.999% 99.603% 100.000% 99.996% 99.996% 99.611% 99.998% 99.994% 99.994% 99.995% 99.996% 99.994% 99.605% 99.998% 99.999% 99.994% 99.997% 99.991% 99.997% 99.992% 99.996% 99.995% 99.999% 99.997% 99.980% 99.996% 99.999% 99.994% 99.996% 99.995% 99.996% 99.604% 99.998% 99.993% ^C --- Results after 94 passes --- Best: 100.000% -- Worst: 99.525% -- Average: 99.931304% Cumulative Accuracy (not per pass): 100.000 this was while connected to another 2 node and some activity on the repeaters. IS this a keeper? I am also planning to use that vps as an xlxD server and running an ambed server at home (got 3 trancoding channel possibility here.) If it is possible to link from allstar dstar and dmr that would make a nice bridge between all those mode.. I just need a second pair of dongle to also get fusion. If anyone have experience in such thing let me know. I will need some hint. Dont need to be taken by the hand...

3 6

EchoLink Timer settings?
by Russell Thomas 22 Jun '18

22 Jun '18

I've noticed when I connect to my EchoLink node on Allstar from my phone or with IAXRPT android app that both will disconnect after a few minutes if no audio. are there settings to control this? On a computer hosted echolink traditional node this doesn't happen. any ideas? 73, Russell Thomas, KV4S Cell: 205.202.1701 DMR: 3101393 D-Star: KV4S AllStar: 47923 EchoLink: KV4S-L (1003254) HamShackHotline: 614 Web: http://KV4S.com

3 3

Report on Tues's Net - Please read - of interest to everyone
by Mike 21 Jun '18

21 Jun '18

Thanks for your interest, And your participation last Tues. I am breaking this little report down into sections. This is the first. You have to know that the interest in the topic of discussion is much higher than anyone might have predicted. _What happened During the net last Tues.._ Let me say that this was originally configured for 60-70 nodes to connect. Should not have been_any_ issues. That is what I was expecting with the unknown of personal/Pi nodes that are quite numerous now if you have not looked. Being a repeater or a personal Pi, ...it's a stream of the same size . A guideline for connecting was published. Those that connected in advance adhered to it. I made one balancing move in the beginning before the net and nobody even knew it happened. This was to keep nodes on par with their potential bandwidth. I had some options to balance even further. At some point near the beginning of the net, about the time Steve/N4IRS was having issues with the digital input and time-out on his own node, ...well...some took that as a node drop-out and began to switch connections from the planed path. At this same time, we had a influx of connections (while net was ongoing) LATE COMERS ! Expected some, but there were many. And most were not adhering to the connection plans. Within that part of the mess, a node had been connected up who came with 50+ nodes in a private network. I could not identify this node for the duration of the net. No way to see who is spewing large chucks of iax data on our network. It's not going to show in your allmon. This unidentified network normally runs with all their elemetry "OFF" (found out later) Most of you know how telemetry works in the iax2 and know your connected brings that data to your network. Same as they will receive yours. But this one node had telemetry data beyond belief and in loop. They don't know it, it's turned off on their systems. With most of our nodes are using telemetry, it became a additional overload load for Allison just trying to speak it. And the telemetry list stacked-up beyond comprehension. And very quickly. With all of the cpu activity and iax activity, I could not get a command in edge-wise. At this point I don't know where the iax data is coming from or that it is a major factor in the eventual overload of 29999. I had figured that much of it was coming from one node because it was the same stuff over and over. It's a funny story how I discovered the who but I'll save that for some other dicussion. I have some very strong feelings about this - 'running a large network without any telemetry and connecting to other large networks"you better be sure your network is clean, but I'll keep that under control for now. Everyone should realize that when you connect to others, you bring any problems your system has to the network you connect to. Even if it is not noticeable to you when connected to anything. I take full responsibility for this failure. But I want to share some of the blame on some others. Those that will not get with the plan,_especially when late._ And those that will not stick to the plan making matters worse. Contingency's were in place but you can not make changes when everyone is moving to who knows where. And that iax data stream kept me from changing anything anyway. I needed some direct communication with Mike and Steve to make them aware of things during the net process and pause them until we made adjustments. But this came about very suddenly and snowballed. . Normally we would account for some of these late connections but there was a large number of them. -- Most of you can match that from what you seen and heard to understand this better. But on my next note to group, I will post my plans for the next net. They are very strong. I will post by Saturday/Sun. _Then some new thoughts for discussion going forward in this new age of personal connectable network systems_. We have twice as many nodes now as just 3-4 years ago. It's still growing at that rate++. The older days when repeater systems were the dominate bunch are over. Repeater nodes were pretty much predictable. Personal nodes are not. _We need to have this discussion before we grow to big for it and things get to messy to keep the good perception we recieve from others at this point.._ Watch for my next post on this issue and you will see clearly how I am going to deal with these issues going forward. It may be just one example of many to follow of how to avoid these problems in the future. And know that every one of these issues will be fully addressed in the next net. Since we can no longer judge the size of interest and participation with any real degree of accuracy anymore. Thanks for reading the whole thing ! I welcome responsible comments at this time. But I would ask you to wait and see the plan going forward. These nets that 'anyone produces' are going to get larger and we need a plan. It is my desire to involve as many going forward as we can. Because others will need the practice of knowing how to properly configure and run such a net structure that continues to grow. And it is growing rapidly. The more that have a feel for this, the better we all are. Myself included. ...mike/kb8jnm

2 1

No kernel in install
by Ross Boulet 21 Jun '18

21 Jun '18

I downloaded the iso from http://dvswitch.org/files/ASL_Images/Intel-AMD/Stretch/ASL_1.01-20180417-am… When I try to run the install, I eventually get an error saying "No installable kernel was found in the defined APT sources. Am I missing something? -- Ross Boulet AG5RB (formerly K5BOU) -

3 2

ASL Pi hardware requirements ?
by Mike 21 Jun '18

21 Jun '18

Well, the time has come for me to eat some Pi topped with ASL sprinkles, I have a goal of using it for the TXr on a my revised split site 6m repeater, So, I have ordered a bunch of different Pi's to taste but I don't see the min requirements for the hardware, Will the image run on a Orange Pi zero w512mb (I would think it does) or does this need 1gb perhaps it's there and I just overlooked it speed reading....LOL The different flavors have not yet arrived so I have plenty of time. ...mike/kb8jnm

4 5

Re: [App_rpt-users] RTCM [RX Packet Out of Bounds] ***Updated***
by Kevin Babich 20 Jun '18

20 Jun '18

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(a)chuck.midlandsnetworking.com> Sent: Wednesday, June 13, 2018 2:34 AM To: kevin.babich(a)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(a)gmail.com <mailto:kevin.babich@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(a)lists.allstarlink.org <mailto:app_rpt-users-bounces@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(a)lists.allstarlink.org <mailto:app_rpt-users@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(a)gmail.com <mailto:tisawyer@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(a)chuck.midlandsnetworking.com <mailto:rpt2@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(a)gmail.com <mailto:kevin.babich@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(a)lists.allstarlink.org <mailto:app_rpt-users-bounces@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(a)lists.allstarlink.org <mailto:app_rpt-users@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(a)gmail.com <mailto:kevin.babich@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(a)lists.allstarlink.org <mailto:app_rpt-users-bounces@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(a)lists.allstarlink.org <mailto:app_rpt-users@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(a)gmail.com <mailto:kevin.babich@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(a)lists.allstarlink.org <mailto:app_rpt-users-bounces@lists.allstarlink.org> > On Behalf Of Hayden Honeywood Sent: Thursday, May 31, 2018 5:56 PM To: app_rpt-users(a)lists.allstarlink.org <mailto:app_rpt-users@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(a)lists.allstarlink.org <mailto:app_rpt-users-bounces@lists.allstarlink.org> > On Behalf Of Hayden Honeywood Sent: Wednesday, May 30, 2018 5:34 PM To: app_rpt-users(a)lists.allstarlink.org <mailto:app_rpt-users@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

3 4