Ahh.. ok thanks for the background..
I dont run much of any thing in dfs bands so not aware of those types of issues.


On 06/01/2018 09:47 AM, Eric Muehleisen wrote:
TX power and antenna gains are set correctly. I'll give you some context. I spent a month working with Cambium support last year on why a brand new 450i AP, with no SM's registered, would go into constant DFS. No rhyme or reason. Up to 10 times per day. Firmware 15.1.1. The ticket was left unresolved.

BTW, I took Sean's advice and downgraded an couple AP's from 15.1.1 to 15.0.2 and the false detection's have completely stopped. If you'd like to know just how rampant the issue is, just search the Cambium forums for 450+DFS. You'll get an idea of how bad things have gotten.

On Fri, Jun 1, 2018 at 8:02 AM Dave <[email protected] <mailto:[email protected]>> wrote:

    Ok, So DFS?
    If your antenna/dish gains are set correctly in each link at each
    end setting correct power level should be a breeze.
    Reflections from your own link can cause events to occur if this
    is not set correctly. Also, Ensure there are no other overlapping
    links or nearby radios on the same or near channel.

    2cents



    On 05/30/2018 03:56 PM, Eric Muehleisen wrote:
    This is interesting. I definitely want to be in compliance, but I
    also know that these detection are 100% false. We have redundant
    AP's on the same tower mounted at the same height pointing the
    same direction, but 20mhz apart, and they don't trip DFS. It's
    like there is a magical packet or multipath event that causes
    this. We may have to give 15.0.2 a try.

    On Wed, May 30, 2018 at 3:48 PM Darren Shea <[email protected]
    <mailto:[email protected]>> wrote:

        I’ll vouch for Sean’s experience on these – we also had to
        roll back a bunch of DFS 15.1-15.1.3 APs to 15.0.2 to deal
        with a ridiculous level of false radar detections. I haven’t
        yet tried 15.1.5 on any of those, but there wasn’t any
        indication they dealt with that in release notes.

        nDarren

        *From:*Af [mailto:[email protected]
        <mailto:[email protected]>] *On Behalf Of *Sean Heskett
        *Sent:* Wednesday, May 30, 2018 3:45 PM
        *To:* [email protected] <mailto:[email protected]>
        *Subject:* Re: [AFMUG] Epmp vs 450 - DFS events

        15.0.2 is the least finicky with DFS.  above that cambium
        changed the code to be more restrictive to meet new FCC rules
        (or something like that)

        On Wed, May 30, 2018 at 2:41 PM, Eric Muehleisen
        <[email protected] <mailto:[email protected]>> wrote:

        If someone has the holy grail on what firmware for reducing
        DFS on 450. I'd love to hear it. We are on 15.1.1 and the
        false DFS hits are killing us lately. See attached. This is
        one AP for the past couple days. It's been terrible around here.

        DFS_450.png

        On Wed, May 30, 2018 at 3:35 PM [email protected]
        <mailto:[email protected]> <[email protected]
        <mailto:[email protected]>> wrote:

            ​For ePMP it depends on the version number. 2.6.2.1 had
            very stable DFS performance and for APs where we saw
            issues, we have left

            it there. Some links are working fine on the latest
            firmware though.​

            On Wed, May 30, 2018 at 3:50 PM, George Skorup
            <[email protected]
            <mailto:[email protected]>> wrote:

            My experience is exactly the opposite here. ePMP seems
            more sensitive to DFS events. By far.

            On 5/30/2018 12:25 PM, Gino A. Villarini wrote:

            Anyone noticed that apparently the Epmp radios are less
            prone to DFS events? Im assuming most are false caused by
            RF interference, but I see way less events on Epmp than
            on 450� Will have to do a side by side study.�

            �

            /*Gino A. Villarini*/

            President

            Metro Office Park #18 Suite 304 Guaynabo, Puerto Rico 00968

            *Error! Filename not specified.*


--

--

Reply via email to