Can anyone offer any insight help? Here is the post link…
48 “COMMUNICATION LOST”, The SM cannot be reached by AP polling, resulting in SM disassociation Check for quality of radio connection.
There’s some sort of interference issues occurring that’s causing the SM to de-register.
@Eric_Ozrelic, I really do appreciate your reply! So I went ahead and swapped the radio and same issue happens, it took 2 hours to do it but it did. Not one SM gets kicked off the AP… the only thing that is happening is that the AP will have a notification of connection lost and connection restored, lasting 1 second and some times 20 seconds… the SMs do not disconnect from the AP. Could interference be the culprit in this? Its almost like if you had a bad patch cable between a lan port poe of a force 300 antenna and the WAN port of a router. I am truly stumped. Maybe it is the line from the shack to the radio… ive tried bypassing surge suppressor and tried a different poe.
Thanks!
Edit I forgot to mention that the one thing that is not happening is the logs are not showing the 48 communication lost or the other logs I posted in the other thread. Customers are saying it is not working like it use to. Literally have not done or changed anything… it is a remote, rural tower… im not sure where the issue lies.
Update
So after 3hrs one of the SMs disconnected and reconnected from AP… nowhere in the logs does it show the disconnect, never got a cnmaestro alert…
I don’t think swapping the radio is going to resolve this issue. I’d try the following:
- Run an SA on the AP and more importantly, the client, and see if there’s anything interfering
- Make sure the client doesn’t have a WiFi router or other wireless devices on or near the radio’s channel
- Try changing the channel on the AP
- Try reducing the channel width of the AP
- Try using a band that allows for higher EIRP (avoid DFS bands)
@Eric_Ozrelic, thanks again for your reply… I ran a SA on my west sector and it shows the east sector in the detailed interferer information, is the frequency reuse not working? I am running a 20mhz channel on the back to back sectors… I did try different frequencies on the back to back sectors and problem still existed, the frequencies had plenty of separation, I have good horizontal separation… I believe lol.
edit This why I tried to swap the radio because stated above did not change anything.
Yes, you will most likely see the opposite sector on an SA and interferer list. This is normal. Even with some distance between AP’s, the amount of energy coming out the back of the radio and/or reflecting off near by surfaces will show up on an SA or scan. ePMP (and other AP’s like PMP450), don’t know how to distinguish between one another from an energy perspective (they can see each other from a frame perspective). The keys in GPS sync are to make sure that the clients don’t hear the AP facing the opposite direction, and that the AP’s are using a common time source so that they transmit at the same time.
Just follow Cambium’s GPS sync guide to make sure your using the appropriate settings. Check the logs for loss of sync.
If using back to back frequency reuse, and any of your sync’d radios goes into internal sync mode, this will cause major issues… like poor modulation, and de-registered clients.
If I understand correctly, he’s having AP ethernet to the Internet issues, not AP to SM issues… isn’t he?
@ninedd, this is what I am seeing, the only thing left is to replace the line going to AP… thoughts?
update Now I am not so sure… I logged into my west sector and the session time is going on 15 mins for 6 of the SMs, one is showing no device name and 0.0.0.0 for IP, and one SM is 5hrs session time. I logged into the east sector and I have 4 going on 20 mins session time, 2 going on 1 hour and 4 going on 5.5 hrs… My east sector customers I have not heard a peep from but my west facing customers are all experiencing service issues. I have a third sector on the tower, my busiest, its north facing, 90% of the SMs are going on 7 days session and the other 10% are on 18hrs but because of some needed rebooting.
I thought his problem is the AP dropping SM’s but the SM’s think they are still registered ? Which would be classic interference at the AP ( SM’s still see the AP but interference causes the AP to not see the SM’s and drop them) or a firmware bug (this has been a thing with several versions of firmware).
I’m confused after reading another thread started about what appears to be the same issue and appears to be SM’s disconnecting but then he states that SM never lose connect and the AP loses Internet ? So yeah… confusing.
On the interference angle. Is the SA still not GPS sync aware ? It would be 1000x more useful if the SA didn’t see sources that are in sync with it and could only see sources that are not in sync with it… I’m willing to bet that most sources of self interference in a synced system is the SM of another AP which without a sync aware SA you have no way of knowing about since the AP for that SM is indistinguishable from the SM and likely a far stronger source. Also, a sync aware SA would make it instantly obvious if any of your AP’s were out of sync because any AP showing up on the SA would be out of sync with the AP you’re running the SA on (or if that AP seen ALL the other AP’s then it is the one out of sync).
The 0.0.0.0 thing is a known firmware bug in one of the 4.5 releases, not sure if it’s fixed or not in the most recent release/beta.
The “session time” on the “Monitor Wireless” page of the AP being shorter for some SM’s than others has nothing to do with the AP’s connection to the internet. The session times is how long that SM has been connected to the AP and as far as I know there is no situation where the ethernet cable or internet connection of the AP would cause some SM’s to disconnect while others did not (unless the Ethernet cable is generating noise that is interfering with the AP’s ability to see the SM’s which while possible I suppose seems highly unlikely).
The most common cause of SM’s being dropped by the AP is interference from somewhere causing the AP to not see the SM’s or firmware bugs (there have been firmware versions where randomly dropping SM’s was a problem but not sure if that is an issue in the 4.5.x versions)
1 Like
IMHO - YES. If your access point is losing connectivity through its ethernet to the internet (which would also obviously interrupt internet for all its SMs too) then yes, I would replace cable to the ap, connectors to the ap, power supply to the ap, jumper cables from the poe to the switch… and I would probably change which port on the switch I was plugged into.
I’m not aware of any recent firmware that would cause an AP to be unreachable over its ethernet. To me, that’s a hardware problem. Either something wrong with that ethernet on the access point, but much more likely to be a connector, a cable, a power supply, or a switch port in my opinion.
Just a tip, have you checked broadcast values?. Also 48 code for disconnections not always means interference. Today I got a long series of 48 codes and it happened to be the cell range after upgrading to 4.6RC29.
So this is what I was reading… if this is the correct description of the symptoms, then ‘the SMs do not disconnect from the AP’ - it’s just the AP on its ethernet that loses connection.
If this is accurate, then that’s not interference over the air, because ‘the SMS do not disconnect from the AP’.
At this point, I think the OP should just start a new post and try to describe as clearly as possible the issue (that’s singular! not multiple confusing or tangent issues!) along with any relevant details and things he’s tried.
2 Likes
First of all I really appreciate everyone’s replies and suggestions/insight! I will do as you suggested Eric, and start a new post. Sorry for the “all over the place” posting, thank you.
How far apart horizontally are your access points? Better question: can you touch the two antennas that are back to back at the same time?
If your SMs are dropping off then check that your hold off timer is long enough, we set to at least 7200. Check that your gps firmware is fully up to date and that your sync source is se the same for all APs in your network. We dont use the onboard gps unless we have to, instead we are using Packetflux’s sync injector and a sync box jr at each tower. If you have to use onboard gps, make sure you have the square puck, that it is attached above and behind your antenna, the face is pointed south (north if your in SA) and that it is sheilded from cellular towers.
Things to check is that your guard interval, frame size and channel size is the same on every AP on that tower and any tower that can hear that tower. Double check that your frequency reuse pattern follows the manual, this is very important as if you dont then you will never know that your SMs are stomping on each other.
1 Like
@Douglas_Generous thank you for your reply. No I would have to reach to one or the other to touch when on tower.
We are using the 90 degree epmp 3000 sector that has puck that goes in top of antenna shell. Is this not ideal?
Each radio says gps firmware is up to date, I have also considered the packetflux synch as many as yourself on the forum suggested as well, will look into it.
All of my radios are set on the default 1000 hold off timer, I will try your suggestion of 7200 or more. And I will double check the settings mentioned in your last paragraph.
While we are on subject of gps synch, the radio in question, west facing, is going between tracking 16 satellites to 20 satellites and then drops back to 16, while the east facing radio is at 21-22 satellites tracked consistently. Both radios have 22 satellites visible.
Thanks!
On top works but is not ideal. The proper orientation for the puck is on a verticle plane with the cable out the bottom facing south (north if below the equator).
The number of tracked doesnt matter after 4, just redundant tracking incase one fails to pass crc check (which happens)
Its a good policy to have your antennas so you cant touch the two that are back to back. On a standard DMX70 we stand them off 1m on larger towers we go 2m between the antennas and this works well. It ensures your not in the void behind another antenna and are actually in the -30dB zone. Our only exception has been parabolic dishes, they tend to have enough isolation to be pointed from the same mount as long as you vertically space them, which 1m works for some 2.5m for others. The f300-25 needs 2.5m vertical space if they are less than 100degrees look point or less else 1m is good.
I have been using Packetflux since the old canopy days and when I struckout on my own, they were the first call I made. They are nice to have a dual voltage power injector. We feed ours from a 24v battery set and a power supply. Anything that needs 48(56)v we either upconvert or use 48v battery and down convert for lower voltages. This works so well that our issues with our towers (save SM dropping) are almost non-existent. Plus a 100Ah 24v battery supplies a busy tower for over 24hrs and we have close to 56hr on a small tower. One of these days I should publish the layout and schematic for our tower boxes.
1 Like
Thank you for your response… so what the cambium data sheet shows is to put the puck into the designated spot inside the top off the sector antenna… so you are saying it would work better doing what you suggested?
Is this setting on all sectors on the tower or if set to one it needs to be at 7200 on the sector that is in frequency reuse? Does it have to be the same on all sectors on neighbouring towers as well?