strange timing issue

I’ve got an 900AP on a water tower that when set to recieve timing from BHS, the carrier freq. is unstable. It fluctuates from -50’s to -80’s. This is what I’m seeing from an SM about a half mile away. The SM will register briefly and the drops. If I set te AP to generate it’s own sync, the everything works. Any help would be appreciated.

Motorola claims this works… but from what we’ve seen, upgrading to “real” (ie CMM Micro) timing. This will always dramatically increase your range and get rid of those disconnects.

The reason for this is due to the slight delay that the SM or BH can have for the sync replication. This gets worst as the Jitter on the device goes up. I wouldn’t recommend doing this unless you have around -50db!

Sounds like self interference.

Make sure any and all 900AP’s within 10 miles of each other (yours or another provider’s) are configured with the same:

- DL%
- Max Distance
- Control Slots

jerico is correct that a dedicated timing source is the way to go, however it won’t help you if your 900AP’s are self interfering.

A single AP sync solution is the PacketFlux SyncPipe.

Would the AP’s that were on a non-overlapping freq. also cause interference? Or could it be multi-pathing off the water tank itself?

Yes. Non overlapping is relative. They will still self interfere - especially if they are not configured the same.

the reason it works better when it’s generating it’s own sync is that the timing is more randomized.

Possible multipath, but I doubt it.

Be careful if you use different timing units… CMM and CTM do NOT time exactly the same (hook it up to and expensive scope and you’ll see what I meen)

Sorry but I don’t know if the packetflux is same as cmm or ctm or totally diffrent. The CMM is very close to the GPS pulse, but the CTM is slightly late. This will cause 2 towers within range to interfere.

Also… Stay away from sync devices that “propagate” sync based on it’s own clock when it losses GPS… the problems are harder to see due to the fact that they don’t show up on the AP log… Again, I’m not sure how the packetflux works in this regard. (CMM doesn’t propogate where as the CTM does)

jerico wrote:
Be careful if you use different timing units... CMM and CTM do NOT time exactly the same (hook it up to and expensive scope and you'll see what I meen)

Sorry but I don't know if the packetflux is same as cmm or ctm or totally diffrent. The CMM is very close to the GPS pulse, but the CTM is slightly late. This will cause 2 towers within range to interfere.

Also... Stay away from sync devices that "propagate" sync based on it's own clock when it losses GPS... the problems are harder to see due to the fact that they don't show up on the AP log.... Again, I'm not sure how the packetflux works in this regard. (CMM doesn't propogate where as the CTM does)


This would be good to know as we use the CTMs at our large tower sites and Packetflux units everywhere else. Been having more interference issues lately but I believe it's not due (at least not solely) to timing but to new equipment put up by someone else.

Here’s kinda what I’ve got going on. I have a cmm micro syncing 3 out of 6 AP’s. The other 3 AP’s are generating their own sync. It’s worked out for us so far, but with the addition of the sixth AP, I think it’s time to sync all of the towers.

I really appreciate you all taking the time to help.

Thing about Canopy is that it’s ability to “work” in hostile environments masks how good a properly built and configured Canopy network can run. There is a tendency to leave a working network alone even if it’s not operating at 100% efficiency.

Wait till you see the overall network performance improvement when you sync everything. It will be like a whole new network.

jerico wrote:
Be careful if you use different timing units... CMM and CTM do NOT time exactly the same (hook it up to and expensive scope and you'll see what I meen)


There is around 30us of slack in the Motorola Canopy frame.... compare a CMM and a CMM Micro for instance. The CMM micro is about 3us behind the original CMM2. As long as your settings on all AP's/BHM's are the same, and you have a large enough max distance set, you should not have any problem with *any*of the sync products interacting.

jerico wrote:
Sorry but I don't know if the packetflux is same as cmm or ctm or totally diffrent. The CMM is very close to the GPS pulse, but the CTM is slightly late. This will cause 2 towers within range to interfere.


The sync pulse out of all of the SyncPipe products, and the new SyncInjectors (Rev C) are within 1us of the CMM timing. The older SyncInjectors are slightly behind.

jerico wrote:
Also... Stay away from sync devices that "propagate" sync based on it's own clock when it losses GPS... the problems are harder to see due to the fact that they don't show up on the AP log.... Again, I'm not sure how the packetflux works in this regard. (CMM doesn't propogate where as the CTM does)


I hate to say this, but even the official CMM's do this to some regard (meaning generate inaccurate sync). In developing the SyncPipe, one of my first concerns was that the prototype SyncPipe timing was *way* off of the CMM micro. The CMM micro was providing sync, even though it did not have a good 3d fix, and as such it was a few hundred microseconds off.

The way the GPS module in the official motorola products work is that it won't provide sync until it thinks it knows where it is in the world. The problem is that it takes forever to get to this point, and sometimes the first guesses are off anyways, so it is occasionally inaccurate for the first few minutes (or even days) after it starts providing sync. I've seen this several times.

The GPS module in the CTM and the PacketFlux products will generate sync even when it doesn't have a 3D lock, but it will be accurate enough, even with view of a limited view of the satellites, since it still is receiving a timing signal from the GPS constellation which it then can correct since it has an accurate 3d position.

Neither one is reallly better or worse. They all should interroperate when operating correctly and have a good, accurate 3d lock. I wouldn't worry about anything less than a few microseconds of clock skew.

That said, I'm in the process of designing a piece of inexpensive test equipment which will allow you to test clock dispersion to catch some of the more interesting problems related to clock skew.

-forrest (aka forrestc@packetflux.com)
so it is occasionally inaccurate for the first few minutes (or even days) after it starts providing sync. I've seen this several times.


Thanks Forrest - that explains instabilities I have seen after cold starts.