SNR and CCQ in WiFiWave2

RouterOS Scripting
1

Our company (a FttH ISP) recently started shipping hAP ax2 (we used to ship hAP ac2).

All routers are managed / provisioned from our own system, with the new ax2 we decided to implement wifiwave2 (because of significant better performance).

We’ve adjusted all provisioning code to support both traditional ‘wireless’ and ‘wifiwave2’…

But it seems that the WiFiWave2 API is missing information about clients Signal-to-Noise (SNR) and (TX)CCQ, or am I missing someting?

[.id] => *30
[interface] => wifi1
[ssid] => SSID
[mac-address] => F0:B6:1E:60:XX:XX
[uptime] => 12h43m54s
[signal] => -52
[tx-rate] => 864700000
[rx-rate] => 907400000
[packets] => 10408116,6375349
[bytes] => 5060034187,3146844269
[tx-bits-per-second] => 8984
[rx-bits-per-second] => 30680
[authorized] => true

We use these (SNR, TXCCQ) values to visualize the wireless performance of specific wireless clients.

2

It’s not that we necessarily need the SNR of TXCCQ values, but some value about connection quality would be highly appreciated.
And I’m sure that this is available since WebFig is able to visualize the performance (height and color in the clients graph).

3

Just checked with RouterOS 7.9 but no difference, still no information about wireless link quality..

[.id] => *1
[interface] => wifi2
[ssid] => Studios070-XXXX
[mac-address] => A0:92:08:CC:0B:B6
[uptime] => 21s
[signal] => -32
[tx-rate] => 1000000
[rx-rate] => 2000000
[packets] => 17,22
[bytes] => 2361,3536
[tx-bits-per-second] => 0
[rx-bits-per-second] => 0
[authorized] => true

It does still have this ‘signal’ but its an absolute value telling nothing about the noise floor, so not the actual SNR..

4

wifiwave2 is an implementation of drivers from the manufacturer of the chipset, rather than an in-house written driver (which wireless is).
So there are many small details that are missing or incomplete… this is only one of them.

We can only hope that over time, some things are coming back. But likely not everything will come back, as MikroTik likely want to avoid the situation that
the drivers are modified so heavily that it again becomes an enormous job to integrate a new release from the manufacturer…

5

(and given how the market is now, focusing on a chipset that you don’t know how long you can find, could be a big waste of time…)

6

Hi this makes sense! But it seems that the WebFig / Quickset interface has some more information than disclosed via the API.
The WebFig/Quickset interface shows additionally to the signal some colored bar-graph.

These bars do not simply seem to be a historical graph of the signal value, since the bars change over time while the signal value seems stable.

If indeed this additional information is available internally, then they could easily make it available through the API.

7

About a year later, I saw the following item in the 7.15rc2 changelog:

*) wifi-qcom - updated driver;

In general it’s been quite some releases / changes since 7.9 :slight_smile:

So I thought, lets see if this new driver gives some more details via the API, but the retrieved data via the API remained the same..

[.id] => *1
[interface] => wifi2
[ssid] => SSID
[mac-address] => XX:XX:XX:82:FB:00
[uptime] => 1m
[signal] => -48
[tx-rate] => 229400000
[rx-rate] => 229400000
[packets] => 273,317
[bytes] => 107865,67692
[tx-bits-per-second] => 0
[rx-bits-per-second] => 0
[authorized] => true

Is there an other way to determine the SNR/TX-CCQ or les specific, the wireless connection quality / performance?

I mean I can guess that we can make some ‘rules’ combining signal strength and tx/rx-rate to make an estimation, but sometimes the tx/rx rate is limited because of the chispet (like embeded / domotica equipment) or because a device is suspended / in sleep-mode.

8

As an ISP you buy hardware in bulk? Name your numbers, then contact your distributor or MT directly. Maybe the get interested.