Hi, we are having trouble extending snyc in the following leg of our system:
1. 5700BH master out of micro to remote location
2. 5700BH slave receiving sync - going to cisco bridge and omni
3. Out of switch is a 5200BH master and 5200AP receiving sync via split sync cable from above 5700BH slave.
4. Signal received a short hop away by 5200BH slave going to Cisco Bridge and omni.
All of the above works fine, now the problem:
We wanted to come out of the 2nd switch with a 5200AP going in a different direction, with a different 5200 frequency.
We tried first to run a sync cable from the 5200BH slave to the 5200AP, setting the Frame Timing Pulse Gated to “enabled” and the AP to Sync to received signal Timing Port (just as we had done at the other location). Thiswould NOT work, would shut down the entire leg.
So we bought a Packetflux Sync Pipe, and prepared the cable with pins 1, 3 and 6. This would NOT work, would shut down the entire leg. The sync pipe itself is working, because we could see it in GPS status on the AP with the sync cable part unplugged.
What are we doing wrong???
We have been helped already from the great responses from this Forum, we are still in the learning mode obviously. Any help GREATLY appreciated as customers are waiting on this AP leg.
We had the same problem discovered that the gps antennae was trash. So you may need to get another one. You may have received a bad gps. The inexpensive thing to do is to swap out the cable first. Check voltage on the othr end and if the voltage is correct (I think it was around 5) then you may need to replace your gps antennae. It is rare but that is what we discovered just today on one of our systems. we even ordered a sync pipe as well but it is stuck on back order so we ordered another gps antennae and bam tht solved the prob.
-DesertAdmin
I’m catching up a bit on back forum messages… if you haven’t solved your problem yet, here’s a couple of hints.
Frank wrote:
We tried first to run a sync cable from the 5200BH slave to the 5200AP, setting the Frame Timing Pulse Gated to “enabled” and the AP to Sync to received signal Timing Port (just as we had done at the other location). Thiswould NOT work, would shut down the entire leg.
Assuming you said this correctly, that is, a 5.2Ghz BH SLAVE to a 5.2Ghz AP at the same site, this is likely your problem.
Collocating Backhaul Slaves and AP’s in the same band can be problematic. Without sync, they will somewhat work. With Sync (either with a sync cable, or with a SyncPipe or similar), they often will not work at all.
For purpose of Sync an AP and a BHM are the same and a SM and a BHS are the same (or mostly the same - there are some subtle issues when collocating AP’s and BH’s). The canopy system is designed such that everything on a site in the same band should either be an AP/BHM or a SM/BHS.
The reason for this is that sync causes the AP/BHM’s to transmit all at the same time, and then to shut up and listen for their SM/BHS’s to transmit. If you have an AP and a BHS at the same site, then the AP is transmitting while the BHS is trying to listen and vice versa. This prevents the AP from hearing it’s SM’s, and the BHS from hearing it’s BHM - even if you are on different channels in the same band, since they are close enough to interfere. Similar results can be caused by differing control slots, distance, and uplink/downlink percentages.
Without the SyncPipe and/or cable in place, the problem only showed up with the two were “randomly” in sync. With the SyncPipe and/or cable in place the problem is always there.
If this doesn’t describe your issue, feel free to correct my initial assumption.
-forrest
Would I be correct to say that the “remote AP” setup is only effective if the AP is on a different frequency band from the SM that is feeding it? I would imagine the problem is likely mitigated if the AP is facing a different direction from the BHS/SM.
This is a problem I think we are struggling with on one of our setups, and unfortunately the AP has to face the same direction as SM that feeds it. I had hoped that a sync cable would fix it (the SM feeding the remote AP has a terrible re-reg) but the AP couldn’t recieve sync… it would get and drop it very quickley. I had thought it might be a piece of faulty hardware but forrestc’s description makes sense too.
Up until now, we’ve only stocked equipment for two frequency bands… 2.4 for our AP’s and SM’s and 5.7 for our dedicated backhauls. If we plan to do the “remote AP” trick more in the future, we might have to invest in seperate 5.4/5.2/900 equipment I guess.
[quote=“SteveD”]Would I be correct to say that the “remote AP” setup is only effective if the AP is on a different frequency band from the SM that is feeding it? I would imagine the problem is likely mitigated if the AP is facing a different direction from the BHS/SM.
Yes
SteveD wrote: Would I be correct to say that the "remote AP" setup is only effective if the AP is on a different frequency band from the SM that is feeding it?
That is correct, regardless of how the remote AP gets it's Sync.
SteveD wrote: I would imagine the problem is likely mitigated if the AP is facing a different direction from the BHS/SM.
Depends on the specifics at the site. If you can get enough separation, it has been known to work.
SteveD wrote: This is a problem I think we are struggling with on one of our setups, and unfortunately the AP has to face the same direction as SM that feeds it. I had hoped that a sync cable would fix it (the SM feeding the remote AP has a terrible re-reg) but the AP couldn't recieve sync... it would get and drop it very quickley.
This is a pretty common scenario. And adding sync (either via cable or via a GPS receiver) to the mix actually makes it worse most of the time - although the symptom is pretty easy to pick up - "It kinda works without sync, and doesn't work at all with it".
SteveD wrote: Up until now, we've only stocked equipment for two frequency bands... 2.4 for our AP's and SM's and 5.7 for our dedicated backhauls. If we plan to do the "remote AP" trick more in the future, we might have to invest in seperate 5.4/5.2/900 equipment I guess.
We try to pay close attention to the bands feeding a site. Generally we try to use 5.2 (and probably 5.4 soon) on BH's under 10 miles, and then 5.7 for the longer links, and 2.4 and 900 for distribution.
-forrest
Although this is not generally a good idea. I do have one site where there is a 2.4 canopy on an omni on 2415 and an SM 4 feet below the omni receiving a signal from a 2.4 AP 5 miles away on 2457.5. The AP above the SM has been on a parasitic sync pipe since Jan and the SM is fed from a sync injector.
This has been up for a while without any issues and I will be setting up the same thing again in a new site, but I only do this because there is no alternative way to get in and out.
P.S. (No this one is not in a tree!)
Remote AP in the same band can work, however four things need to happen:
1. Max frequency separation - i.e. AP feeding the SM at one end of the spectrum, Remote AP at the other
2. Physical Separation - ideally 50’
3. Both AP’s are configured with same # control slots, max distance, and 50% downlink
4. Sync from the first AP is fed through the SM to the remote AP, or both AP’s on GPS - either CMM or SyncPipe.
Anything less than the above will yield unacceptable results.