Let's talk about each of these status. Used pulses are pulses which were received from the GPS and a pulse was generated for. These should be happening once per second, no more no less. If you were to write down (or clear) them at an exact time, then look at the count an exact period of time later, they should increment exactly with a synchronized wall clock. 60 seconds? 60 counts. 1 hour? 3600 counts.
Ignored pulses are pulses which the syncinjector saw as arriving way too early. Once it receives a pulse, it ignores any for a half of a second. If a second pulse comes in during this time, this number will increment. The purpose of this is to ignore bounces and similar on the GPS line. This looks so low that you can ignore it. Early and late pulses aren't ever going to increment right now due to various reasons. They're on my list of features to tighten up and fix. The intent is to count pulses which are actually received and used, but are earlier or later than expected. The problem was getting an accurate enough timer in the processor to be able to get a useful count, meaning one which actually detects what we're looking for without a lot of false counts. The 1PPS active timeout right now is 5 seconds. If the unit does not see a pulse for 5 seconds, it will turn that signal on. The count column on the right shows how many times this happened. Your numbers show that it never has seen a sync loss. I can state with confidence, that for every used pulse count, the injector did definitely create a pulse on the power line. The counting is actually done in the code which generates the pulse, right after the pulse has been created. I have run many many many tests here which watch for missed pulses, and they just don't occur. That isn't to say that the GPS didn't put a pulse out, but if the used pulses increment, you're getting a timing pulse. That's why looking at the numbers of used pulses and making sure it exactly matches what you are looking for is very useful. On Thu, Jan 21, 2016 at 11:58 AM, Josh Luthman <[email protected]> wrote: > I know I have two APs that are having interference issues. Changing the > channel brings/fixes the problem. This site was put up a year ago and my > problem didn't arrive until last week. > > I want to start by making sure my sync is proper and working. According > to SNMP the radios are happy. The GUI shows that CMM sync is good (it's > configured for CMM3). > > I'm looking at the SiteMonitor and I'm not sure what all to look at, but > here are some numbers: > 12 Radio 1 Sync 2 4 1 1 0 0 > 13 Radio 2 Sync 2 5 1 1 0 0 > 14 Radio 3 Sync 2 6 1 1 0 0 > 15 Radio 4 Sync 2 7 1 1 0 0 > > 26 1PPS Active 2 18 1 0 0 1 > > 42 2D Fix 3 15 1 0 0 5 > 43 3D Fix 3 16 1 0 0 7 > 44 DGPS Fix 3 17 1 0 0 5 > 45 1PPS Active 3 18 1 0 0 1 > > > 31 Radio 1 Sync 3 4 1 1 0 0 > 32 Radio 2 Sync 3 5 1 1 0 0 > 33 Radio 3 Sync 3 6 1 1 0 0 > 34 Radio 4 Sync 3 7 1 1 0 0 > > 19 Sats in View 2 12 13 0 > 20 Num Sats Used 2 13 12 0 > 21 Used Pulses 2 14 27387145 0 > 22 Ignored Pulses 2 15 159 0 > 23 Early Pulses 2 16 0 0 > 24 Late Pulses 2 17 0 0 > > 37 Sats in View 3 12 13 0 > 38 Num Sats Used 3 13 12 0 > 39 Used Pulses 3 14 27387188 0 > 40 Ignored Pulses 3 15 157 0 > 41 Early Pulses 3 16 0 0 > 42 Late Pulses 3 17 0 0 > > String values list out the satellites, I'm going to assume that's not > relevant. To my eyes that looks good, but I really don't know what I'm > looking for in terms of potential problems. The stats are 317d old. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > -- *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 [email protected] | http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>
