There are several rules in the current GPS chipset about whether or not it can produce sync. If you have 4 they can definitely produce sync. Less than 4 is somewhat hit or miss depending on the exact orientation of the satellites, and often more miss than hit. I don't really have control over this algorithm so I can't be more specific.
If you can move that one slightly so it's getting on average 1-2 more sats tracked, then your problem should go away. -forrest On Fri, Oct 3, 2014 at 2:38 PM, Bill Prince via Af <[email protected]> wrote: > Monitoring Sync Events works. Had to wait 5 days for it to happen, but > the counter increment corresponds to a loss of sync we had yesterday. > > I found this in the AP event log (event of interest in blue): > > 09/27/2014 : 07:24:19 PDT : : Bridge Core : Loss of sync pulse from Power > Port! No other sync source available. > 09/27/2014 : 07:24:23 PDT : : Bridge Core : Acquired sync pulse from Power > Port. > 10/02/2014 : 12:21:45 PDT : : Bridge Core : Loss of sync pulse from Power > Port! No other sync source available. > 10/02/2014 : 12:21:51 PDT : : Bridge Core : Acquired sync pulse from Power > Port. > > We also monitor visible/tracked satellites on that SiteMonitor. > Interestingly, the satellites tracked at about that time was 4 (see marked > up graph below). I suppose it's possible that the tracked satellites went > to zero one minute (or less) after the SNMP poll, but it seems rather weird. > > Correct me if I'm wrong, but I thought the SiteMonitor only needed one > satellite to maintain timing after it acquired a 3D fix? > > > bp > > On 9/29/2014 10:12 PM, Forrest Christian (List Account) via Af wrote: > > Yes that value will increment when the injector detects a loss of sync and > also when it's restored. > > These are definitely good values to monitor, and I know at least one > customer which does as you suggest and monitors for a non zero value and > resets the value to zero to clear the error. > On Sep 29, 2014 7:23 PM, "Bill Prince via Af" <[email protected]> wrote: > >> Yeah. Not sure why I thought the index name was where I would get the >> value. The OID that shows in the UI for the Satellites Visible is: >> >> .1.3.6.1.4.1.32050.2.1.28.2.1 >> >> The OID for the actual value is >> >> .1.3.6.1.4.1.32050.2.1.28.5.1 >> >> >> So I was able to fix that part. What I'm wondering is how to know that >> We've had a loss in sync. There is something under Binary I/O called "1PPS >> Active". >> >> Seeing as we only poll once every 5 minutes, catching that going to zero >> seems slim to none. However, I am intrigued by the "Events" value. Does >> that increment every time the Syncpipe loses sync? In which case, I can >> zero it out, and set a threshold for whenever it is non-zero (see below). >> >> >> I may try that. >> >> >> bp >> >> On 9/29/2014 1:28 PM, Forrest Christian (List Account) via Af wrote: >> >> A little out of order: >> >> On the OID's .. you may have the wrong OID. There is an oid for the >> title strings, and an oid for the value. You may want to check the oid you >> are using. In addition, on the strings tab, there *are* strings which >> list the specific statellite and signal strength of all of the sats it is >> receiving a signal from. >> >> One more troubleshooting item is the 'pulse received' counter on the >> analog tab. It should increment once and exactly once per second. I've >> had good luck comparing this value over a specific time. I.E. at exactly >> 10 minutes, there should be exactly 600 more pulses. >> >> As far as fixing it: I'd move the syncpipe, then try a different >> one. If a second does the same thing, then we need to look at what else >> might be causing it. >> >> If you want to send in screenshots to [email protected] of the >> boolean/analog/string tabs from the sitemonitor, I might be able to see >> something. >> >> -forrest >> >> >> On Sep 29, 2014 1:40 PM, "Bill Prince via Af" <[email protected]> wrote: >> >>> >>> One of our many locations where we're using a Packetflux sync >>> pipe/injector seems to be losing satellite lock once every few days. >>> Typically it loses it for 2 to 4 seconds, but I've seen at least once where >>> it went 13 seconds. >>> >>> I've not been able to get useful information from the SiteMonitor >>> because the satellites tracked/Visible OIDs are returning a string with >>> "Sats in View" and "Num Sats Used" instead of the actual values. (is that a >>> bug or what? This is on F/W "Jul 29 2012"). >>> >>> However, I'm getting messages like this in the AP logs: >>> >>> 09/21/2014 : 07:49:00 PDT : : Bridge Core : Loss of sync pulse from >>> Power Port! No other sync source available. >>> 09/21/2014 : 07:49:04 PDT : : Bridge Core : Acquired sync pulse from >>> Power Port. >>> 09/23/2014 : 18:49:37 PDT : : Bridge Core : Loss of sync pulse from >>> Power Port! No other sync source available. >>> 09/23/2014 : 18:49:41 PDT : : Bridge Core : Acquired sync pulse from >>> Power Port. >>> 09/23/2014 : 18:49:55 PDT : : Bridge Core : Loss of sync pulse from >>> Power Port! No other sync source available. >>> 09/23/2014 : 18:49:59 PDT : : Bridge Core : Acquired sync pulse from >>> Power Port. >>> 09/24/2014 : 18:47:15 PDT : : Bridge Core : Loss of sync pulse from >>> Power Port! No other sync source available. >>> 09/24/2014 : 18:47:28 PDT : : Bridge Core : Acquired sync pulse from >>> Power Port. >>> 09/27/2014 : 07:24:18 PDT : : Bridge Core : Loss of sync pulse from >>> Power Port! No other sync source available. >>> 09/27/2014 : 07:24:20 PDT : : Bridge Core : Acquired sync pulse from >>> Power Port. >>> >>> Not sure what I might do here. This is with all the equipment up >>> against a concrete wall, so there is only a 180 degree view of the sky. >>> Maybe a little bit less than that because the wall is not flat, maybe about >>> 170 degree view of the sky. >>> >>> The APs are PMP450, and rarely get a GPS lock on the internal GPS. >>> Maybe I can try moving the sync pipe away from the wall or something. >>> >>> >>> -- >>> bp >>> >>> >> >
