Initially when I did testing in the office I was able tp get them connected straight of the box and did testing.
I went out to test feasible distances from the tower as well as signal information and throughput. For some reason the BHS would connect for a small amount of time and then disconnect and go back to scanning. It will then reconnect and then as soon as running a speedtest it seems it disconnects or will disconnect after a certain amount of time even if no speedtest is ran. I replaced both sides of the link while testing and also tried different firmware versions all with the same results.
I tried 16.0 which is what came on the units as well as 16.0.1, 16.1.1, 16.2.2 and 16.2.3 with the same issue.
Brought back to the office and now have the same issue. Will register and then disconnect and start scanning again.
Timing is being supplied through the audio port with a cnPulse being powered from the radio. I have also tried several different channels and have verified there is no interference.
Note that I have narrowed this down to only happening when the BHM is getting Timing through the Timing port. Same issue using a UGPS or a cnPulse.
When I am using a CTM-2 or CTM-5 for timing the BHS stays connected and performs as expected.
I have the cambium cable coming and was using a cable I made using the pinout information. The BHM reported 100% Sync pulses received just like it does through the power port.
I have double and triple checked and when timing is supplied from a UGPS or cnPulse through the timing port the Backhaul Slave will not stay connected.
The power is set to -30 because they are both here in the office about 20’ apart. Here is a screen shot of the signal information at that level when they are timed through the power port. During testing in the field they were both set to a +27. Note that regardless of the power level and whether in the office or the field and regardless of firmware, when receiving timing through the power port the backhaul slave stayed connected as expected. When receiving timing through the timing port with a UGPS or cnPulse the backhaul slave would not stay connected for more than a minute if that. I will be opening a ticket with cambium here shortly.
Also note that when the Backhaul Master was set to Generate sync everything worked properly. Just when timed through the timing port is when the problems occur.
Yes it does. I am surprised that no one else has noticed or mentioned it. Would be nice if someone else could verify that they are seeing the same issue. That would make it very easy to duplicate for cambium.
I really don’t think you’re going to get a response on this because I think very very few people use the uGPS/cnPulse with the PTP450 series. I’ve never used it and I don’t know any other WISP’s that I work with that use this config. There’s probably slightly more people using PTP450 + ethernet pulse injection, like PacketFlux. It’s easier and (in some cases) less expensive to use Packetflux then cnPulse.
ALSO, are you sure you need GPS sync on this PtP? Like what other PtP’s or PtMP are you sync’ing with? Again, if your collocating multiple PxP radios at a site, you might be better off just using Packetflux.
I’d have to agree with @Eric_Ozrelic on this one, sounds like your timing source.
I’ve had no issues deploying many PTP links using 450 and 450b’s, and sync them with Packetflux without any problem. They work shockingly well at some pretty incredible distances. I have a couple 19km+ links that achieve 256qam.
On a side-note, I did have an issue when the link was very strong, like -45 dBm… I would have to turn the transmit power down to +20dB on the master and slave before they would reliably re-establish link, in a timely manner, after a reboot. If I had the transmit power at +27dB, they could sometimes take over an hour to re-establish link!
I couldn’t understand it, but eventually I found that having a reduced transmit power seemed solve that issue.
Note that I have no issues when the unit receives timing through the power port like using a CTM or CMM. I would imagine that the same thing is true when using a Packetflux as I am pretty sure they inject timing through the power port. I have no issues when timing is received through the power port. The issue I have is when receiving timing through the timing port.
I have opened a ticket from support and this is what I have got back so far.
"As per the logs, the 450b BHM is having sync drifting with sync-source via aux-port/timing port, even though, 1PPS pulse received shows 100%. This drifting on the master side seems to cause the slave to not able to sync-up correctly during the registration.
Could you share the engineering logs with both settings sync via main-port or generated sync to compare?
There is a known issue with all 4 Data Channels configured. Thus, it is suggested to configure either 1 or 2 data channels for now.
"
I have tried with just using one or two data channels and have the same issue. I have sent engineering files back and I am awaiting a response back from support.
I assume that if you configure your units to receive timing from the AUX/Timing port (the audio port) that you would have the same issues as I have tried this with several sets and always have the same issue.
