Read our latest newsletter and learn more about:
- our first outdoor Wi-Fi 6 CPE: SXTsq 5 ax
- ROSE Data Server Maintenance Parts
- how to mount two CSS318-16G-2S+IN switches side-by-side
- New YouTube videos, ROSE Data Server reviews, and so much more!
Finally, an ax CPE. Let’s hope we get a Disc 5 ax and a DynaDish 5 ax as well.
will be LHG 5 ax and LHG XL 5 ax first as they have the same board with SXTsq 5 ax.
SXTsq 5 ax very nice device with ROS level 4 …
I see that LHG XL 52 ac is discontinued on web site. I hope LHG XL 52 ax is here soon.
No new 5G devices…
Ok, Newsletter launched… Good! Thanks!
Will we now go back to releases in the testing chain?
Kudos on the quick spare parts reaction.
Two thumbs for that !! 
Has any progress been made in compatibility of station-bridge mode between older n/ac and newer ax products? Even if just plain 802.11 (not nstreme/nv2) it would be really helpful. Replacing all CPEs on the roofs doesn’t happen overnight, work at height has become very expensive, and the 5GHz spectrum is too crowded to keep n/ac and ax networks running concurrently for a long time.
Also, there is so much interference that higher gain (narrow beam) LHG ax client devices would be welcome. Disc… not with the cracking plastic front (I’ve seen some units where it fell off completely, exposing the board inside to rain). SXTsq ax maybe in AP mode as a narrow sector… It’s not 2010 when the 13dBi LocoM5 was introduced and back then it actually worked well over long distances (though even then they exaggeated by saying things like “15km range! 150Mbps throughput!” of course not both at the same time and combined throughput in both directions if you are lucky).
Testing is fun, but for production I would be much happier with some kind of long term supported ROS 7 release…
How about, and hear me out, a 6ghz ax AP? 
The rather skimpy content in the newsletter does suggest MT is working on software 
Any chance we’ll see OFDMA on the 'ax products? I can’t see any mention of this feature in change logs.
Almost a year ago I posted (http://forum.mikrotik.com/t/ofdma-on-the-schedule/176424/1) and got zero responses.
OFDMA is part of 802.11ax standard. Why do you doubt it is not already there?
And as such it only works when both AP and station are ax (won’t do any good if station is ac only).
And will only be able to do something when interference is reasonably strong (not much stronger than received useful signal … so it doesn’t overwhelm receiver’s pre-amplifier AGC) and when it only interferes with part of channel used by AP/station. Tests, mentioned by @syadnom in the other topic, indicate that the second condition is likely met, but doesn’t say anything about the first condition.
OFDMA is OPTIONAL in 'ax. In many many products it must be forced on. There are some backwards compatability issues/erata when it’s on for older clients so many vendors just don’t implement it at all because they don’t want to ‘fix’ it.
In my testing, introducing noise on band edges between the mANT-ax and a hAP ax3 (40Mhz) halves throughput, that implies that it’s not interfering with RUs and instead with a 20Mhz carrier and that very strongly implies that OFDMA is not on.
With OFDMA, noise should cause throughput to scale fairly linearly with noise overlapping. ie, overlap 10% of the band, see 10-15% reduction in throughput. You’re only killing 10% of the RUs off at full power and then some OOBE ‘curtains’ getting the adjacent subcarriers.
yes, all stations must be ax to get the best experience.
However, the strong interference isn’t really correct. every RU has individual modulations, so -75 noise on 10% of the band could still mean MCS4 modulation on those RUs and MCS10 on the others. So when the AP has a full scheduler, it can send data on those RUs as well. So even in low or moderate noise on part of the band you get serious benefits.
Also note that OFDMA/RUs are scheduled by RU not timeslot (or rather data is scheduled into RUs which are the ‘shelves’ in the ‘UPS truck’ that is the tx transmission), so you can fill 10 RUs destined to client 1 and another 5 to client 2 and 7 to client 3 and so on simultaneously. Ie, instead of a small icmp ping taking up an entire transmit frame, it lives in a single RU so data for other clients can also be sent at the same time. This has a massive benefit to latency for clients and airtime utilization.
For me, I need a product that can dodge noise. I don’t expect noise immunity, just dodging the noise enough to have a linear affect instead of crushing it.
Also note that link puncturing comes up a lot and is basically the opposite of what people think. It’s the AP scheduling around known noise/services at the AP, so that clients don’t contribute to self-induced noise and the AP doesn’t make noise for the other-AP clients. Ie, if you have a 160Mhz 'ax AP and inside of that channel there’s a 20Mhz 'ac AP nearby, you puncture the 160 to remove the 20 (probably 30 for OOBE…) for both AP tx and CPE tx. This is how this feature works for a WISP that can’t afford to give up the existing channel of their 'N or 'AC gear, just overlap right over the top and puncture for the legacy gear. This is optional in wifi6, but it looks like other vendors (ubiquiti in particular) isn’t implementing it on anything until their wifi7 product comes out. It would be great to see mikrotik implement this but I doubt it’ll come in the wifi6 gear.
Just enable OFDMA and we’ll have a product we can work with. Ultimately, I think we need wifi7 models for some of these features to ‘just come with it’ since wifi7 REQUIRES support for OFDMA and link puncturing, they are not optional features.
I was talking about AGC of Rx preamplifier. The gain is automatically set according to strongest signal received (in worst case in the whole band, in best case in actual Rx frequency window). Strong interference will cause AGC to reduce gain and thus reduce useful signal level entering DAC … which in turn reduces SINR for the whole array of RUs. Yes, indeed the direvtly affevted RUs will get “eradicated”, the rest will suffer.
right, wifi6 doesn’t have per-RU output control. We’re waiting ofr wifi8 for that I think. Regardless, it’s a big benefit today because wifi6 (at least on qualcom) has a pretty wide range for optimal SNR, so cranking up the output 5dB is usually pretty tollerable.