I have a longstanding issue with a link where sometimes it logs "lost connection, no beacons received" losing the connection, which is then re-established and the same problem repeats for some time (e.g. 5 minutes) and then the issue goes away for many hours (connection is stable).
I think the loss of beacons is caused by local interference, a local AP transmitting beacons at the same rate and the same time.
After some time these timeslots drift and the problem is gone.
Is there some way to tweak the timeout on this condition, as it seems very short (a couple of seconds only), or to "dither" the transmission of beacons?

I don't know if it's possible to tweak beacon timing. However, if the beacon interference is really the problem, then this would mean whole channel would be in state of high interference (during periods without beacon interference, payload interference would be high). If the problematic link doesn't show high interference (low SINR), then I think this is not the actual problem. IMO more likely is an unrelated interference (e.g. microwave oven operating sporadically). But that's hard to determine.

The AP I connect to sends 4 different SSIDs. When I monitor the situation, I see that one of them is temporarily not available while the other 3 are. Which one it is, slowly varies over time (most of the time all 4 are visible).
This leads me to the theory that there is a synchronized interference that precisely blanks the beacon transmissions and not the other traffic on the channel, and given that I think it is most likely to be another AP that is local (thus much stronger than the remote of the link that is 8.5km away), not some random carrier etc.
All this is on 5 GHz (LHG5) so not a microwave either.
The displayed SNR of the link is 38-42dB but that likely is determined mainly from data transmissions.

I think this issue could be resolved by using a dithering beacon interval, or even by a settable interval (so I could set it e.g. to 210ms instead of 200ms).
But MikroTik has no DTIM setting (that has been discussed before).

I think it is most likely to be another AP that is local (thus much stronger than the remote of the link that is 8.5km away)

You might be correct about it. But I imagine you should be able to detect such a local WiFi interferer using plain WiFi gear. But then I also imagine that there might be equipment transmitting at WiFi frequency in certain intervals but completely different modulation etc., so it might be undetectable by normal WiFi gear but would show on specialized equipment (e.g. frequency scanner scope). BTW, transmitter transmitting NV2 protocol is not detected by 802.11-compliant wifi gear so it presents a big uncorrelated interference to them. If it's about some non-wifi gear interfering it might not trigger DFS as the transmission signature doesn't match radars even remotely. Or you're operating on non-DFS frequencies and AP doesn't check it at all (knowing you my bet is on this possibility)

If the timing of the interferer is not driven by very precise clock, then the solution to your problem might be a few weeks away (drop in ambient temperature might change Tx period of transmitter enough to stop breaking your link).

I don't have the required equipment to precisely diagnose the situation, especially not mounted at the point where it occurs.
And as the LHG5 is an "old" N-type, the actual interference from a typical modern ISP-supplied router cannot be detected on it anyway (being AC).
But I am not that interested in what it exactly is, as there will be no way to get it removed anyway.
I'm most interested in workarounds. The problem has been present for a long time, I just decided to post about it again.
In the past it was no issue because then we had BFD and the BGP would just quickly drop the link and fall back to another in such cases.
Now with RouterOS v7 under test here at home I don't have BFD (despite having whined about it for over a year now...) and it is really irritating because e.g. open winbox sessions drop because BGP does not switch quickly enough when that link is occasionally failing.

How secure is the LHG reinforced/installed?
I had a similar problem on a unit whose mast was wobbling in the wind.

It is very secure, no problems due to that!

But I am not that interested in what it exactly is, as there will be no way to get it removed anyway.

If you know your enemy, you can fight it better. Without knowing it you are fighting blindly.

I feel your pain regarding inability to properly diagnose the problem.

Remember it is an unlicensed band. And ever more users that are within 10-100m from the antenna will have installed a shiny new 2/5 GHz WiFi router
from their ISP (you know, the ones that have supported AC wave2, 802.11k/r/v, MU-MIMO for a couple of years now) and this has increased the general
noise level on the band quite a lot. This link is running on 5520 MHz (10 MHz bandwidth) which is kind of less used by indoor routers, but still used a lot.
There is NOTHING I can do against that, even when I now who is doing it and where they are. They are legal users of the band on a secondary basis, like me.
And if it is something else (radar etc), there is nothing I can do either because these are the primary users of the band. I have to make room for it (DFS).

Of course a bandscope would be nice, but hey it is not Ubiquiti, it is MikroTik. We are waiting for it.

Note that the link is between MikroTik dishes (or actually a LHG5 dish and a RB912UAG-5HPnD AP with sector antenna) but the suspected interfering routers are not MikroTik and are not powered by the same source.
However, such frequencies are derived from crystal oscillators, which in such equipment will not be trimmed to the correct frequency, and will be in the order of 20-50ppm of accuracy.
So they will drift relative to eachother and there will be periods where they are on top of eachother followed by long periods where they are not. Exactly what I am observing.

At the moment I am working on config changes to reduce the number of SSIDs. It is possible, but to complete it requires cooperation from others.

Indeed this system was configured before I understood the possibilities of assigning VLAN via RADIUS (these AP are using WPA2-EAP with RADIUS)...
So there is a separate SSID per VLAN even though this is not on wifiwave2. I am now migrating it but I need contact with all 3 users of "alternate SSIDs" to get rid of them.
That should improve the channel loading but I think it does not change the problem and it removes my way of diagnosing it.
Remember that the local APs do not see the beacons from the AP I am connecting to! It is 8.5 km away with my dish pointing it, while these APs are in the living rooms and metering closets of homes next to me. The wellknown "hidden terminal" problem that defeats attempts at "clear channel assesment" rules.

As an example, here is the pattern of the log messages about no beacons:

aug/24 14:28:23 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 14:29:03 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 14:29:08 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 14:29:19 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 14:29:24 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 14:29:51 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 14:30:01 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 14:30:20 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
8月/ 24 14:30:41无线信息4 e: 5 e: 0 c: 82:男朋友:F8@wlan1: lost connection, no beacons received
aug/24 14:30:48 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 14:30:53 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 14:31:22 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 15:58:14 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 15:58:41 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 16:17:18 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 16:17:40 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 20:14:12 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 20:14:40 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
aug/24 22:38:38 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
02:07:03 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
02:07:19 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
02:07:33 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
02:07:43 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
02:08:13 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
02:08:33 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
02:50:32 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
02:53:31 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
02:53:41 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
08:18:49无线信息4 e: 5 e: 0 c: 82:男朋友:F8@wlan1: lost connection, no beacons received
08:19:09 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
08:19:14 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
08:20:08 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
08:20:18 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
08:20:32 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
08:20:38无线信息4 e: 5 e: 0 c: 82:男朋友:F8@wlan1: lost connection, no beacons received
08:21:07 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
08:21:40 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
08:21:59 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
08:22:25 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
09:00:47 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received
09:01:54 wireless,info 4E:5E:0C:82:BF:F8@wlan1: lost connection, no beacons received

You can easily see the "clustering". Between those moments, there is a solid connection.

I cannot use NV2 because the AP has a mix of MikroTik and Ubiquiti clients, and both of them do not implement the other's protocol.
So it has to operate in plain 802.11 mode to be compatible.
But remember: the AP has no way of seeing the interfering devices, and the interfering devices have no way of seeing the AP.
That is the "hidden terminal problem". As the devices also do not connect eachother, no protocol will fix that. Something like NV2 works only when having an AP and some clients that connect to it, on an otherwise clean channel.

I have now reorganized the configs to use only a single SSID on each AP (there are four APs on this site, it is the first site in the "photos of towers and masts" topic).
Let's see if there is any difference in behavior...

OK. You mean they are really not seeing each other ... then there is normally no "same channel (CCA detected) interference, except disruptive style like "adjacent channel interference) which requires some signal strength to be disruptive.

Please go read about the "hidden terminal problem" first.

wireless interface advanced winbox TAB provides some interesting parameters that maybe can help you in this

Distance
Hw Retries
Frame Lifetime
Disconnect Timeout
On Fail Retry Time

and others

i hope that can help

Please seeviewtopic.php?p=953696#p953696for how I solved my issue

wireless interface advanced winbox TAB provides some interesting parameters that maybe can help you in this

I had already experimented with those before but there was no difference. there seems to be no parameter that sets the timeout for "no beacons received".
Also disabling station roaming made no difference (tried earlier this week) and I am not running any scanning on it.

Going back to 1 SSID (from 4) also has not changed anything...

A radio channel can carry only a single uncorrupted packet at a time. So when a terminal (does not matter if it is an AP or station) transmits at the same time as the AP I want to receive, but it is hidden (the terminal does not receive the AP and the AP does not receive the terminal, but my station receives the station stronger than the AP I am connected to) the "hidden terminal problem" occurs.
It is not possible to solve this in an uncoordinated situation. Only when there is a single AP connected to multiple stations on an otherwise clear channel you can solve it using solutions like NV2, but that is not the situation.

You have a basic misunderstanding about the hidden terminal problem. When you are not prepared to go off and read some theory about it, I give up on coming back to it again and again.

Again, any concerns about incompatible channel widths (and the problem that they do not mutually detect eachothers presence) is not relevant in this case because there is no way that the AP I am connecting to is going to receive the APs that cause the local interference, and vice-versa.
I can receive the remote AP only because I have a directional antenna towards it.

This is the common situation for anyone that sets up a Pt(m)P link over larger distances in an environment where the same band is used for indoor networks.
The indoor networks are invisible to the remote AP and the indoor networks do not receive the remote AP.
The indoor APs just key up to send their beacons and they are not away they are trampling the reception of the beacons from my remote AP.

It could be solved by "dithering" the remote AP beacons (sending them at irregular intervals e.g. using a 10ms random offset from the regular 100ms interval), or by setting a nonstandard interval that is not a multiple of the standard rate. But it does not look like RouterOS provides the parameter required for that.

... the signal is actual weaker than from a simple omnidirectional antenna, even at its peak direction, because of EIRP legislation ...

This is not true. If antenna gain (= gain over theoretical monopole antenna) is properly taken into account and transmitter properly implements regulatory limits, then electrical field strength (measured in Volts per meter) of transmitted signal will be exactly the same in both cases in direction of nominal antenna gain ... and EIRP is an indication of such measurements.

It is true that most of benefit of using highly directional antennae (in case of limited EIRP) comes from improvement of Rx signal. But this comes with cost of increasing interference levels as well if interferer lies within antenna beam. Things get worse if interferer doesn't use directional antenna and thus does not benefit the increased Rx sensitivity and thus misses co-channel transmitter.
What @bpwl suggests (slight change in antenna direction) might help if interferer is actually not in direction of main beam but rather in direction of a side beam (all antennae have sone, highly directional antenna tend to have more of them) with lower gain and by changing direction it might be possible to get interferer out of that side beam. If the interferer is in the main beam, then I'm afraid nothing can be done apart from moving link to another frequency channel.

As to problem by @pe1chl: I don't think changing beacon periodicity would (semi)permanently cure the problem. Beacons are interfered also by payload frames, the amount of interference then depends on airtime utilization of interfering device ... could be either AP or station of another wireless network (if interference is due to beacons of foreign network, then interfeter can only be AP in which case flow control of foreign AP might do it's job of avoiding transmissions during beacon airtime of PtP link).

Note that using "the direction of the interferer" is not practical in my (very typical) case because I have a single wanted signal in one direction combined with a "cloud" of local transmitters in many different directions, some of them the same as the direction to the wanted signal.
The relative strength of the interfering signal is determined by the distance to my antenna and the gain of the antenna in that direction.
So even when the antenna has a 30dB lower gain in that direction, that can be offset by the interferer being so much closer that its local field is 30dB stronger.
It is nothing special, it is the typical situation when trying to setup a long PtP link (8.5km in my case, so not extreme) from a residential area with many users.
When I do a scan on my INDOOR devices (a hAP ac2 and a 4011) I get ~40 APs in the scan, about 8 of them covering my frequency of 5520 MHz.
(note that this is not only APs operating on exactly that frequency, but all of the APs with some frequency in 5500-5580 in some layout like Ceee eCee ... eeeC)
And that is only indoor. It is not feasible to do this scan on my outdoor link because it is N-type and of course all APs by now are AC.

Of course actual use of airtime would also cause interference, but when looking at the time-of-day of the interference I do not suspect it is the main contributor.
(In that case I would expect a correlation with typical internet peak usage, say 1800-2300 hours, while in fact interference bursts also occur in the middle of the night at the same chance as other times, see the log above)

I have always believed that "loss of beacons" occurs on the radio air. I observed a loss of beacons between two devices at a distance of 200 m. Part of the Fresnel zone was blocked by trees and I thought they were the cause. Wyz4k pointed out that there is another reason. AP may not transmit beacons, but in case of point-to-point mode then all clients would register the error, as in our case only one client registers it means the problem is only on his radiotrace. Or the client may not receive beacons because his radio track is busy scanning the air. This can easily be fixed by turning it off or setting a short scan list.
This option should definitely be tried to exclude it.

In wiki.mikrotik it is stated that this error is caused by: "Most likely weak signal, remote turned off, strong interference, some other RF related issue that makes communication impossible".
So immediately discard all the service frames, etc. This problem is purely physical.
Analysis of the logs shows that the problem occurs briefly at different times for 5-10 seconds for 1-4 minutes. It is very similar to a swinging obstacle on the radio band (usually a tree top). Only a strong enough gust of wind causes the connection to break.
In any case, standard measures to improve radio channel quality should help.
And here you need to start by analyzing the trace, building a vertical profile of the trace and comparing the available installation options for signal enhancement and interference reduction.
Also change the place of installation so as to protect the device by natural obstacles from interference. And practice shows that using only one way is not always effective, you need to use the complex.
The main way to increase the signal to interference ratio is to use an antenna with high gain. The effect that is achieved by the antenna is not achieved by anything else. If you can not replace the antenna, you can use other ways. Move the antenna and use an additional shield from interference..
The cheapness of Microtik wifi devices is due to the very low shielding from interference. Therefore, those who have encountered such problems use additional shielding. Buy ready-made or make their own.

In wiki.mikrotik it is stated that this error is caused by: "Most likely weak signal, remote turned off, strong interference, some other RF related issue that makes communication impossible".
So immediately discard all the service frames, etc. This problem is purely physical.
Analysis of the logs shows that the problem occurs briefly at different times for 5-10 seconds for 1-4 minutes. It is very similar to a swinging obstacle on the radio band (usually a tree top). Only a strong enough gust of wind causes the connection to break.

I know this in my case is not the cause. The signal is OK at about -72dBm and the S/N is around 40dB.
Also, before this week I had 4 SSIDs running on a single AP. I observed that when I saw "no beacons received" and I immediately switched to scanner mode, I saw the other 3 SSIDs but not my own. This has lead me to the theory that it is interference with local beacon signals from APs that send the beacons at nearly the same rate.
After some time the beacon becomes visible again and another one might disappear.
However, in an attempt to improve channel efficiency I have now reduced the config to 1 SSID and of course I can no longer do this test.
(它没有changed anything to the problem, by the way)

Experiment: A 802.11n device does see the ac-only mode 802.11ac AP's here, with a scan from the 802.11n device.

Interesting, I did not know that... as the LHG is set to 10 MHz I normally do not see those, but now that I have set it to 20 MHz indeed I do see the AC mode APs.
When scanning the entire band I see 116 APs with signals up to -60dBm, so 12dB stronger than my wanted signal.
Limiting the scan to 5520 MHz 20 MHz BW I see 18 APs with signal up to -64dBm.

Maybe as an experiment I'll change the actual BW to 20 MHz to see how the connection is (that is something on the TODO list anyway).

Once you have determined that "strong interference, some other RF related issue that makes communication impossible" is your case, then use standard methods to combat interference.
You have a very low level of useful signal. The standard signal level is -67 in the 10 MHz band and -64 in the 20 MHz band. It turns out that it would be optimal to use mANT30 + Sleeve30 kit for mANT30.
If there is no possibility to use other equipment, you will have to modify the LHG.
The main problem with the LHG is that it has very high sidelobe levels, almost to 0 dB.因此,安装的位置是很重要的。It is necessary to hide the antenna behind some obstacles (walls, roofs, corners of buildings, etc.).
You also have to use a anti-noise shield
For experiments you can use a large kitchen pan of suitable size (40cm). Or cardboard tape and aluminum foil. This is to make sure you get an acceptable result.

No amount of directivity will completely solve the problem. I see APs that I know are directly in the direction of the beam (some people put their address in the SSID...) as well as very close ones like my neighbors "behind" the dish. I am familiar with that kind of patterns (I am a radio amateur) and I know that it is possible to improve it a little but not to completely get rid of the interference.
In our network we also use the "ISO" type of dishes from UBNT and they indeed are better. But I also have requirements on the physical size and look of the dish, to avoid problems with placement permission. My LHG is a LHG5 XL which is about the maximum I can place here.

Then the most I can advise, try to make an additional screen out of the grid, paint it white. it will not change the appearance. There is a similar option in the above photos.
Be sure to check the condition of the antenna on the LHG board itself often the element can be crooked. sometimes you can get +2 dB. It is better to use HP version of the board which has additional shielding/heatsink as on the photo. The board should also be additionally shielded.Is the LHG mounted on the wall or on a mast?

On the side of the access point you have a sector antenna, they have a fairly narrow diagram in the vertical plane. Usually they are mounted with a few degrees slanted down toward the ground. Are you the farthest customer (8.5 km) of this antenna or not? Check the angle of the antenna and see how much you can change it. I tend to think that the oscillation of this antenna is the main cause of the problem. Since you write that the problem occurred a long time ago.

PS The message is displayed in the log at the loss of signal after 5 seconds or 50 beacons

Everything is mounted very sturdy. The antenna on my side is on a sturdy metal pole (6cm at the bottom, tapering to 4.5cm where the LHG is. It is the HP model, the is no LHG5 XL N-type that is not HP.
It does not move unless there are very high winds, and the issue does not correlate with high winds. Also, that would not explain 5-second interruptions over several minutes intervals and then normal communication again.
The AP side is as photographed in the first reply to the "Photos of towers and masts" topic and while it vibrates at little in high winds it normally is rock solid.
The downtilt angle has been carefully adjusted. I know that is very critical.

Now I realize that I'm telling you the plain truth...
And yet, sometimes it's exactly what we forget.
I would try to change the angle of inclination of the sector antenna by 0.5-1 degrees while observing the signal level at the client, if there is a clear increase in the level set a new value.
When installing the antenna at a height of 220 m, the tilt angle should be around 1.3-1.5 degrees for a distance of 8-9 km. To tilt the LHG to this angle you need a plate with a thickness of 2.5-3 mm. It is placed under the lower mount between the pipe and the antenna. I use a piece of polyethylene water pipe. Sometimes I reduce the interference in this way by putting 2-3 pcs, the interference level drops faster than the useful signal.
When adjusting the antenna, it is also necessary to move it up and down over a distance of about 1 m, selecting the position with the maximum signal. At the end try to move the antenna a little to the left to the right, observing the level of interference and signal level, choosing the optimum position. After all, for LHG XL deviation from the maximum 3,5 degrees gives a decrease in signal level by 3dB, and the next 3.5 degrees almost 15-17dB

PS我从未见过的井斜的灯塔ces mounted on the wall, only if the mast, hence I assume that is related to the fluctuations of the antennas.

This has already been done long ago... and let me assure you: there is no movement like that in this tower. When there is 5+ bft winds there is vibration, but not such that it would permanently tilt over long intervals.

I have now done some experiment that aligns with my own observations: remember before we had 4 SSIDs (for different users to connect to different VLANs) and I had replaced this with a single SSID just because that is more efficient. But when the 4 SSIDs were present, I had observed that one could drop out while the others did not.

Now that the VLAN assignment is done via RADIUS (this is for 3 users, there is also a "default") I had brought back the 4 SSIDs to one.
But now I have again added a second SSID and configured the two wlan interfaces in the same bridge. So it does not matter which one I connect, it provides the same function.
In my client LHG I have configured a "connect list" with these two SSIDs.

Now I am going to wait to see if at some point the main SSID gives "no beacons received" and the connection switches over to the secondary SSID (second in the connect list)...
(as usual, the connection now did not yet fail. but that should happen within half a day or so)

The problem of the lack of beacons is related to physical problems, Without changing the physics you will not get a change.
The problem involves the transmitting device, the receiving device, and foreign devices causing interference. The problem only occurs when all three factors coincide. That is why I said that the solution must be complex.
You have to try to reconfigure the antennas...

Let's calculate your experiment.
The beacon is missing, the connection is broken, the registration of the device on the new SSID started, which takes 20 seconds. - 2 minutes and half of your failures will not be detected, you just will not see them in the log.
我可以假设下的问题发生ing way: signals from another access point, working on the same channel, in a small period of time begin to exceed the level of beacons from your access point. When such exceedance occurs for less than 5 seconds you do not know about it, in those rare moments when the interference exceeds the useful signal for more than 5 seconds there is a message in the log. The useful signal and interference are periodic with close parameters.
To analyze the problem it is better to set the signal level monitoring, for example through the dude.

Notwithstanding your stubborness I can now report that my experiment works!
A few minutes ago I got the "no beacons received" error and the LHG automatically connected to my second SSID.
It happened just before I was viewing the log window. I started background scan and indeed only the second SSID is visible. Connection is stable.
Signal is around -71dBm, SNR 44dB. In my experience that is enough at 10 MHz bandwitdh, connection are appearing below -80dBm.
A couple of minutes later the first SSID again erratically appears in the scan window. Later it is stable again.

This confirms my hypothesis of systematic interference with the beacons, likely caused by a local AP (hidden to the remote) transmitting beacons at the same rate.

I guess that by setting bandwidth to (not so widely supported) 10MHz, you're effectively preventing adjacent APs from properly detecting your PtP link as strong co-channel interference worth avoiding. Since other APs don't avoid it (neither during channel reselection nor during checking for free Tx window), you may be harming your link way more than that 3dB higher signal strength due to narrower bandwidth used. I think it would be worth to try is using 20MHz changes the situation (either for better or worse).

Yes, that is another experiment I want to try. Also because the newer (AC-type) dishes for whatever unclear reason do not support 10 MHz bandwidth, so we need to tell people all the time to buy the N type, and that way we preclude any migration to AC. Which at some time has to be done.
Unfortunately it is already difficult to allocate frequencies to the 4 APs at that tower that are not used by weather radar with this 10 MHz width. Increasing the width makes that only more difficult.

What settings are you working with?
Standard
Guard interval
Basic rate
Signal strengths Tx/Rx on channels Ch0 Ch1

"hypothesis of systematic interference with the beacons"

I think you can verify this hypothesis with the "Wireless Sniffer" of RouterOS. (In the LHG or some other ROS device.)

The scanner should do the same thing, right? When I do a scan I see the SSIDs of visible AP which is the beacon transmission.

Ok when I happen to see a reconnect I will do a wireless sniff to see if I can derive something...
When doing it in regular condition, I see both beacons, unfortunately a millisecond after eachother (it would be better when they were evenly spaced...).