Disconnects on all frequencies with and without timing

Products PTP
1

I am replacing a PTP230 link with the new PTP450.

PTP230:

Reflectors: Cambium metal reflectors

Distance: 8 miles

RSSI: -63dBm

SNR: 30dBm

Link Capacity: 100% 40Mbps down, 10Mbps up

Sync: Power port via CMM3

firmware: 11.2

When I replace the PTP230 radios with the PTP450 radios:

Distance: 8 miles

RSSI: -66dBm

SNR: 30dBm

Link Capacity: 100% 75Mbps down, 15Mbps up

Sync: Syncpipe (PTP450 doe not support power port timing, which is a real kick in the nuts, but digress)

firmware: 13.2

All looks good right?  Wrong.  When I put the PTP450 link under load the link disconnects.  From the master side, the "Reg" stats for the slave count up each time there is a disconnect.  The disconnects are worse when the traffic demand is higher.  If I remove all traffic from the link, the connection appears to stabalize.

Troubleshooting:

The PTP230 works perfectly with the same traffic loads.

Spectrum scans show that the channel used (5820Mhz) has a flat noise floor below -100dBm.

Trying different Frequencies provides no improvement (5480Mhz, 5820Mhz, 5840Mhz)

Using a uGPS provides no improvement

Replacing the master provides no improvement

Replaceing the slave provides no improvement

Replacing the cat5 cable provides no improvement

In conclusion, the prodect does not work.  I have replaced everything and tried everything.  The PTP450 link simply cannot bridge high traffic withou disconnecting.

2

Will did you ever get an answer from Cambium on this issue? 

I have a similar situation going on right now. 

3

Hi Brian and Will,

We are checking this out and will have a detailed response soon.

Ray

4

My issues are still occurring randomly, so any help you can provide would be awesome.

5

Workaround: avoid frequency scan on BHS. Put the tick on BHS only on the frequency set on BHM.

6

We are also having  exactly the same trouble please help as soon as possible ... waiting is pain full...

7

avoiding frequency scan does not helped

8
@Cambium_RayS wrote:

Hi Brian and Will,

We are checking this out and will have a detailed response soon.

Ray

 "soon".

I think Cambium's "soon" meaning is different than mine.

9

This issue is still relevent.  It was suggested to me by Cambium to upgrade to 13.4, which supposedly addressed this issue in part.  It seemed like it helped, though subjective, but didn't fix the PTP450.

The issue is present on both the 5Ghz and 3Ghz PTP 450.  I have a couple of them in production.  The only variable I notice is distance.  The further the link, the more often the disconnects seem to happen... but who knows.

Here is another interesting fact:  I hooked up a PMP450 at a distance of 5 miles using one AP and one client and had no disconnects using the same firmware.  The issue appears to be a firmware issue for certian.

Examples:

2 miles, -56dBm, 34SNR:  .3 disconnects per day

4.5 miles, -59dBm, 29SNR: .5 disconnects per day

10 miles, -64dBm, 29SNR: .6 disconnects per day

11 miles, -62dBm, 33SNR: 2.6 disconnects per day

10

For reference, I have 3 links that I can compare for this issue.  All are 3.65 GHz variant, all are set to 50% downlink data, using AES encryption, and 24-hour encryption refresh is disabled (we used to get disconnects from that in the old PTP100 radios).

Link 1: v13.3, 6.820 miles, -60.7 dBm, uGPS on timing port, session uptime 135+ days.

Link 2: v13.4, 11.577 miles, -64.9 dBm, self genrate timing, session uptime 30+ days.

Link 3: v13.3, 17.977 miles, -68.1 dBm, uGPS on timing port, session uptime 43+ days. 

I never have any disconnects or other issues with these links.  Quite solid.

Aaron

11

Hi archerman,

Thank you for reading this thread.  I want to match what you have as close as possible then.  I disabled our 24 hour refresh and set the encryption to AES.  However, my downlink data is at 80% because one of my links routinely goes over 60Mbps and I don't need upload speed.

The only other special settings I've changed have been the authentication key.  I currently have three of the 3Ghz variants on a single tower in different directions.  spectrum scans are clean.  I use 20Mhz channels and the default 2.5ms frame.  I've tried timing them with both a ugps and a packetflux syncpipe when I thought it might be a timing issue.  They are currently on the syncpipe after failing all my efforts with the ugps installed.

Can you think of anything else that might be different?  Are you timing your devices at all?

12

The encryption didn't affect it... worth a try.  I've since set encryption to none, but kept the 24 refresh disabled.

Maybe distance isn't the big factor.  I've included peak usage observations below.  If I leave a link without any traffic on it, it appears to run without disconnects.  If I bridge traffic over the link, it disconnects.  While watching the link status screen, refreshing every second or two, the SNR stays in the green the whole time, then the slave just disappears for about 30 seconds and then reconnects.  The "Reg" count then increments.  This seems to happen when there is a burst of traffic.  So all clues are pointing to traffic.

2 miles, -56dBm, 34SNR:  .3 disconnects per day (peak usage 30Mbps)

4.5 miles, -59dBm, 29SNR: .5 disconnects per day (peak usage 35Mbps)

10 miles, -64dBm, 29SNR: .6 disconnects per day (peak usage 45Mbps)

11 miles, -62dBm, 33SNR: 2.6 disconnects per day (peak usage 53Mbps)

13

Yah, it could be traffic related - during your disconnects/drops, can you see what level your traffic is at during those moments?  The max I ever see on any of the 3 links I referred to is about 6 Mbps.  I could try to visit one of those sites next week and try to flood it with traffic to see what happens.

14

I am graphing the ethernet interface on both sides with MRTG and I also graph the signal strength, but so far this is my only data.  I have a feeling that there is a bit more to it though.  I change my downlink % to 75 from 80 and went to 5ms timing and the disconnects got worse.  I'm not sure if this was just coincidence or if it means something.  I did the same on another link and it also got worse.

Lastly, I returned to my normal timing of 80%, but spaced out the channels for my two worst links.  They used to be 25Mhz apart and now they are 40Mhz apart.  That appears to have helped.  Again, these are emediate impressions and the issue is very intermitent, so I'll report back in a few days with my observations.

My gut tells me that the issue is related to PPS.  I think the session locks up on the slave , perhaps due to being overloaded, then the AP times out the session, it drops, then the slave reconnnects.  This is why I see reg increments and not re-reg increments.

For troubleshooting, I suppose I could install a mikrotik router in front of the master and monitor the actual PPS and bandwidth consumption.  I could even limit the PPS as to spare the PTP450... just getting tired.  I think I should restate that a PTP230 will saturate without disconnect.  I've had PTP230 links that flatline at 40Mbps downloads, with noticible packet loss due to the bottleneck of course, but no session drops.

15

I would get Cambium tech support involved at this point.  Give them all of the same info and let them try to duplicate it.

16

I opened a case last year.  I supplied all the CNUT captures multiple times.  I re-opened the case each time there is a firmware upgrade, which is the only suggestion ever offered to me.  The firmware upgrade to 13.4beta appeared to help greatly.  There seems to be promise that cambium could fix the issue if they wanted to.  They would never even acknoledge the problem until after a new beta firmware was released the actaully addressed disconnects, at which time they contacted me and asked me to try it.

I'm now on the general release of 13.4 and the disconnects continue.  They need to disappear.

They know it is an issue though.  They offered to sell me a PTP650 for cost because of the problems they couldn't figure out.  I took them up on it and it worked good for that one link.  But I have multiple PTP450 links.  I don't think Cambium cares about hte PTP450.

Ray commented on this thread in february promising to get back with us.  He never did, even though another user was obvioiusly waiting for attention on the same issue.

So yeah, Cambium is not interested in this.  From what I can tell, this is a general issue, but a lot of users are simply not pushing these radios.  If you're not going to transfer more than 50Mbps, why even upgrade from a PTP230?  In fact, why even have the product?  The PTP450 needs to deliver what

I'm posing this here, because it needs to be documented somewhere.

17

I feel your pain.  For us, the upgrades were from PTP100's, so it's worth it.  I've never used any of the 300 series equipment.

If you're thinking that distance isn't related, I will do a test today with some I have on the shelf here.  I think I have both 3.65 and 5 GHz here, so I will do both in the shop and let you know.  Today's job has been cancelled, so I have some spare time.

18

I am running a test right now with a pair of 3.65 GHz radios.  Downlink set at 75%.  Flooding the link with iperf data.  No disconnects so far at ~30 minutes in.

19

I've the disconnection issues (2-3 per day) with less traffic, the master is gps-synced using an RJ-12 cable from a PMP450 AP.

PTP450-GRAPHS.png
PTP450-GRAPHS.png1287×1156 621 KB

20

Well, sorry guys, I thought I would be able to find something to help.  I'm about 26 hours into flooding this test link with iperf data, and it's had a solid link the whole time - single registration for 1 day 2:43.  I have been pushing 40-50 Mbps both directions with no issues other than some slightly increased latency when pinging to the far radio of the link (both directions).  Sorry I couldn't help more.

Aaron