When you think to develop some like NV2 with GPS sync (NV3)?

One competitor, using atheros chipset, already do that.

If I do not have any hope to see that on the future, I'm forced to slowly move the AP to other competitors tecnologies.

Other competitors interface and CPE sucks, but 120 client on same AP and with frequency reusing......

Yes. Subscribe to the issue

I hope on one plublic reply.

When you think to develop some like NV2 with GPS sync (NV3)?

One competitor, using atheros chipset, already do that.

If I do not have any hope to see that on the future, I'm forced to slowly move the AP to other competitors tecnologies.

Other competitors interface and CPE sucks, but 120 client on same AP and with frequency reusing......

I know 2 and a third trying to do. The first is expensive and we use it only for business. But the second with the now better interface is affordable and we start to use it.

When you think to develop some like NV2 with GPS sync (NV3)?

One competitor, using atheros chipset, already do that.

If I do not have any hope to see that on the future, I'm forced to slowly move the AP to other competitors tecnologies.

Other competitors interface and CPE sucks, but 120 client on same AP and with frequency reusing......

I know 2 and a third trying to do. The first is expensive and we use it only for business. But the second with the now better interface is affordable and we start to use it.

I'm try some Changium but at the end I'm forced to put one RB951 for the lack of features...

.. 120 client on same AP and with frequency reusing......

what? ..where is that jewel?

Do not be excessively entusiast, the routing feature sucks, is only good to do Layer 2 link between backhaul and CPE, for have a good Layer 3, as I'm wont from MikroTik, you MUST use one RouterBoard at the end...

The trick are on the using GPS for sync all AP.
On this way you can also reuse frequencies, have more prerformant TDMA, and unbalance rx/tx.

Do not be excessively entusiast, the routing feature sucks, is only good to do Layer 2 link between backhaul and CPE, for have a good Layer 3, as I'm wont from MikroTik, you MUST use one RouterBoard at the end...

The trick are on the using GPS for sync all AP.
On this way you can also reuse frequencies, have more prerformant TDMA, and unbalance rx/tx.

+1

Do not be excessively entusiast, the routing feature sucks, is only good to do Layer 2 link between backhaul and CPE, for have a good Layer 3, as I'm wont from MikroTik, you MUST use one RouterBoard at the end...

The trick are on the using GPS for sync all AP.
On this way you can also reuse frequencies, have more prerformant TDMA, and unbalance rx/tx.

Most time there is an additional Device at the customer site. For residentials we have a box with telephony/DECT included which does all the tasks. Companies usually connect their own firewall. So we dont need advanced features at the customers site.
These software based tdma (airmax/nv2) protocols suffer from cpu speed. The faster the wireless cards/rates are the more work has to be done by the cpu. As standard 802.11 protocol is handled by the wireless chipset we will see nv2/3 cant keep up with the packet rate the chipsets produce. One competitor announced special additional chips to handle the load.
I guess MT has to invest in HW-Design or it will fall short handling the speeds 802.11ac produces.
I see SXT SA gets >250MBit/s on a 40MHz Channel with plain .ac. Doing additional TDMA processing with the 720MHz atheros cpu may be too much to assemble the packets just in time for the next timeslot.

..The trick are on the using GPS for sync all AP.
On this way you can also reuse frequencies, have more prerformant TDMA, and unbalance rx/tx.

If I understand well ..gps sync means accurate time sync, so radios can send/receive in sync (eventually unbalanced ..say .. 30/70%).

But.. what if I have a single board with 4 radio onboard each one driving its sector ..I wonder it wouldn't need any 'time sync' to drive its 4 onboard radio..

Surely I'm wrong, but please tell me why

GPS sync is more accurate than NTP sync...

my bad, I'm a big idiot
Every radio talk to ANOTHER ..and they need to be in perfect time sync.. (holiday need.. sorry)

if I have a single board with 4 radio onboard each one driving its sector ..I wonder it wouldn't need any 'time sync' to drive its 4 onboard radio..

I think this is the easy way to use the same channel on the same tower, no gps sync, just software sync, MT guys is this possible?

if I have a single board with 4 radio onboard each one driving its sector ..I wonder it wouldn't need any 'time sync' to drive its 4 onboard radio..

I think this is the easy way to use the same channel on the same tower, no gps sync, just software sync, MT guys is this possible?

And the other tower? GPS sync syncronize all tower...

And the other tower? GPS sync syncronize all tower...

Uan is megl che nient

Mikrotik, now it´s time to get the GPS sync working!
When?
How?

Yes, it will be nice have APs in the sync for transmit. But this can be done without GPS. We need to have the same time on all towers but this time do not must be in sync with world time (UTC). And this is work for PTPv2 protocol (precise time protocol - IEEE1588).
If you have infrastructure where the towers have uplinks builded on the fiber Ethernet or full duplex radios, then can be very precisely synchronized the APs without GPS. PTPv2 protocol is capable with normal hardware a microsecond precision which probably is sufficient (with network cards and Ethernet switches with PTPv2 hardware support then is precision about 20 nanoseconds).
So we can have (gor example) one CCR1036 in the region, it have links to the towers (fiber, metalic, full duplex radios) and it runs as grandmaster clock for this region (PTPv2 server), the APs synchronize as PTPv2 clients to the master's time. This CCR can be synchronized with normal NTP. It is not important, that CCR do not have exactly correct world time but the APs with PTPv2 supports will have the same time as master.
Ofcourse, if the towers uplinks use normal half duplex wifi links then PTPv2 will not be more precise that NTP.

So Mikrotik, please take look on the software PTPv2 implementation for unixes: http://ptpd.sourceforge.net/

Yes, it will be nice have APs in the sync for transmit. But this can be done without GPS. We need to have the same time on all towers but this time do not must be in sync with world time (UTC). And this is work for PTPv2 protocol (precise time protocol - IEEE1588).
If you have infrastructure where the towers have uplinks builded on the fiber Ethernet or full duplex radios, then can be very precisely synchronized the APs without GPS. PTPv2 protocol is capable with normal hardware a microsecond precision which probably is sufficient (with network cards and Ethernet switches with PTPv2 hardware support then is precision about 20 nanoseconds).
So we can have (gor example) one CCR1036 in the region, it have links to the towers (fiber, metalic, full duplex radios) and it runs as grandmaster clock for this region (PTPv2 server), the APs synchronize as PTPv2 clients to the master's time. This CCR can be synchronized with normal NTP. It is not important, that CCR do not have exactly correct world time but the APs with PTPv2 supports will have the same time as master.
Ofcourse, if the towers uplinks use normal half duplex wifi links then PTPv2 will not be more precise that NTP.

So Mikrotik, please take look on the software PTPv2 implementation for unixes: http://ptpd.sourceforge.net/

It is much simpler to put GPS into the AP. Providing an exact ether sync to all APs every component on the path (switch, wireless bridge, ...) has to be part of the sync solution.