I still have similar issues to this day with my two SXT 5nD r2 P2P lines (currently running RoS 6.46.3):
#Wireless network radar software#
If only there would be some table of observed radar events and some of the values the hardware has returned and how the software has acted upon them, it could be possible to research what is going on. Solving the issue is complicated by the lack of debugging tools and tracing information. Thus the same software algorithm could still behave differently in different AP designs. When the radar is quite local and causes a large signal on the channel where it is operating, this may overwhelm the receiver and cause detected radar pulses on more than one or even on all available channels. Quality of the radio front-end could also be part of the issue. Maybe they sometimes tweak the software after having some difficulty getting it type-approved in some country, and when the thresholds were lowered the users suffer. Probably the hardware (the radio) has some detection of pulses that results in some interrupt that is associated with a couple of register values like amplitude and duration of the detected pulse, and the software has to evaluate those, apply decision levels and/or do some filtering (ignore a single pulse but act on repeated pulses), and the quality of that software varies between manufacturers and software releases. I think it is a matter of combination of hardware and software. I am comparing putting up a MikroTik and a Ubiquiti access point at a high tower (see photos of towers) and then seeing the MikroTik chasing all around the channels and never staying on a channel for more than a few minutes before detecting radar again and choosing a different channel (with associated DFS wait), and the Ubiquiti finding radar on maybe a couple of channels but staying on other channels just fine without detecting any radar.Īnd this is not a MikroTik-specific issue either! In the past I used TranZeo equipment as well, and they sold a couple of different hardware designs all under the same TR5a label, where the first design worked absolutely stable under all firmware releases and the second one on the same location after some firmware release just would not link anymore, only radar detected all the time. Often I see people comparing stuff without context and without taking all variables into account. If you compare UBNT on 5180 with mikrotik on 5260, then obviously you will see DFS in action on mikrotik but not on UBNT. When the same happens to radar, it will render even more channels unusable due to radar detection.Ĭomparison with UBNT doesn't necessary mean anything. Much weaker of course but still well detectable. When 3 of them are operational and one is doing a scan, I see the other 3 at different channels than where they are transmitting, we have locations where 4 AP's are connected to 4 sector antennas facing outwards and placed about 6 meters apart, the local mobile station (GSM/UMTS/4G) which is on a different frequency band but still affects the receiverĭuring another experiment I saw that there is quite strong breakthrough of image frequencies in the MikroTik AP's.Į.g. it receives something else than radar, e.g.
it actually receives a radar on a single frequency but due to receiver overloading it "sees" it on all channels In my opinion, it is just mis-detectiong radar due to one of the following: Router will stay for more than a few minutes before hopping to another channel. The problem is that on a 45m mobile base station or a 220m broadcast tower there is not a single frequency where a MikroTik I know that, but I also know the frequency of the weather radar and we have already been warned to stay away from there.
0 kommentar(er)
