The NV2 manual page in the Wiki reads:

Features that Nv2 DOES NOT HAVE YET:
synchronization between Nv2 APs

Just curious - What about sync between the cards located in the same AP?

When will this feature be available for testing?

also not made yet, in planning stage.

Sync need a precise master clock. jitter needs to be kept minimal.


To achieve this :

- the master clock needs to be stable and jitter free

- the master clock need to be distributed by a star network, not a daisy chained network (in a daisy chain, jitter rise at each node).


If sync at a same tower site can be important to avoid interferences, sync through different sites can be interesting as well to allow for perfect roaming without sync loss during roaming. The receiver always keep the same base clock frequency constructed from the received channel with a gold PLL, and just change the channel frequency during roaming, it does not need to resync. GSM and GPS networks are working like this. They are multichannel networks, with intantaneous roaming thanks to absolute synchronisation between transmitters.


Wifi devices would certainly need to be modified to allow for fast roaming, it is only implemented inside proprietary hardware today.

The most usefull use of fast roaming is VoIP use where it is not tolerable to have drops.

There is no reason absolute synchronisation could not be done with low cost WIFI networks. NV2 is a good start, synchronisation could be added to allow for fast or instantaneous roaming, like we can have on GSM or DECT networks.

For absolute synchronisation between different towers, it's possible to extract absolute time from a low cost GPS, and generate a very precise clock using a digital PLL, as soon as the local oscillator is precise enough (high end Quartz or rubidium oscillator). There are opensource design available for this.

Such design can keep sync to a few microsecondes even if GPS reception is lost during 24 hours. With GPS reception, precision is almost perfect, can be easily better than 10-12 with high end (low cost thanks to GSM) local quartz oscillator. A rubidium oscillator can keep precision to parts in 10-13 sourced from a GPS signal. Best hydrogen Masers can keep parts in 10-16 (used on Galileo sytem) !

I played with this a few years ago, it's very impresive to see a frequency counter with 12 digits showing 10.000 000 000 Mhz comparing a GPS time reference to a local rubidium or cesium atomic clock.

Perhaps it is even possible to replace the GPS unit by a NTP server, as soon as the NTP server get his time from a precise atomic synced clock and the network jitter is low enough.

Like the precise oscillators made by Rakon

I believe this one would be suitable for NV2 timing purposes http://www.rakon.com/Products/Public%20 ... X7050A.pdf


You could possibly have a mini-pci (or USB if it had low enough latency) GPS/Timing card that can be put into RouterBoards around the network, these could then act as timing nodes that the other nodes synchronize off.

Like the precise oscillators made by Rakon

They do no give short term stability.

Long term stability is nice, +- 1 ppm / year, but for Time references synced to atomic time through a digital PLL, short term stability (24 hours period), is the most important parameter.


Most GPS timing reference manufacturers are using a precision quartz in a small temperature tightly controlled enclosure, eventually double enclosure, or a rubidium oscillator for high end devices.

Nevertheless, it is possible that those new low cost devices are good enough for Wifi use, as they are used inside GSM and Wimax access points.

The local oscillator give short term stability (hours) and the atomic time source (GPS or NTP), gives long term stability. The digital PLL circuit smoothly adapt the output frequency of the local oscillator so that it keep in sync with the long term time reference.

The long term time source cannot directly give a precise sync, because of important jitter of the transmission channel. That's why a precise local oscillator is needed.

If sync at a same tower site can be important to avoid interferences, sync through different sites can be interesting as well to allow for perfect roaming without sync loss during roaming. The receiver always keep the same base clock frequency constructed from the received channel with a gold PLL, and just change the channel frequency during roaming, it does not need to resync. GSM and GPS networks are working like this. They are multichannel networks, with intantaneous roaming thanks to absolute synchronisation between transmitters.

Imho this all sounds very nice. But what about AP's and stations of 3rd party network you have no control off?
The biggest issue in Wifi is interference. If you are the only and sole user of the spectrum you have no problem. But in real world you see more and more parties using same freq's (even in 5ghz) and to fight interference from these time synch in your own network is not helping....

I think manufactures better invest their time and energy in making radio's such that links between designed units are more robuust.

The example of network wide synch on mobile phone networks counts, but only for these spectrums. Telcon provider owns the spectrum so he has no issues with competition. Free spectrum Wifi is just a jungle where setting your watch is not enough to keep in contact with the group.

I think manufactures better invest their time and energy in making radio's such that links between designed units are more robuust. The example of network wide synch on mobile phone networks counts, but only for these spectrums. Telcon provider owns the spectrum so he has no issues with competition. Free spectrum Wifi is just a jungle where setting your watch is not enough to keep in contact with the group.

That's perfectly true, but :

- carrier sense multiple acces is not the ideal solution because of the heavy collisions it can produce. it would be better if all carriers would have synced networks, so that they can share efficiently their bandwith with TDM (NV2 like) protocols, even if they are on the same channels.

- synched networks, even if privates, can certainly help giving a more stable wave at receive sites when there is more than one tower transmitting on the same channel with absolute sync and true TDM.

- i'm not sure that it is possible today to greatly improve the wifi technology we ever have with NV2 like protocols. The modulation used for Wifi is ever optimized. Wimax is better because it is using frequency hopping, but this is a totaly different technology.

Wimax products are expensives, i think there is some room for Enanced Wifi, even if proprietary, as soon as the price is kept low, as it is the case with Mikrotik products.

Syncing could be something doable on Wifi, without changing everything in the protocol. GPS are low cost devices today, and precision low cost miniature local oscillators are available as well.

- carrier sense multiple acces is not the ideal solution because of the heavy collisions it can produce.

try RTS/CTS. That is already a great improvement on CSMA.

it would be better if all carriers would have synced networks, so that they can share efficiently their bandwidth with TDM (NV2 like) protocols, even if they are on the same channels.

hmm, dreaming of the perfect world... in a free spectrum environment? Won't happen.... its ´free´spectrum. the word "free" means ´cowboy land´. Specially now big players are start to sell powerful domestic routers in 5Ghz band..... how do you ever see household synch with your AP's in a tower voluntary? 5Ghz is becoming what 2,4Ghz already saw; overcrowded. The only forward is to use smart technology and improving the standard so we can stay ahead of the crowd. Or look at Ruckus. They have a smart, patented, wifi system developed overcoming lots of present wifi issues. But now we are talking bucks here and it is not clear to me if it will work in wider outdoor environment.

- synched networks, even if privates, can certainly help giving a more stable wave at receive sites when there is more than one tower transmitting on the same channel with absolute sync and true TDM.

Not true IMHO. Towers at distance create a time delay on the other side due the travel time it takes for the radio wave to travel to this other tower. It's hard to get the waves at one tower synchronized, let alone two, let alone if there are more in reach..

Wimax products are expensives, i think there is some room for Enanced Wifi, even if proprietary, as soon as the price is kept low, as it is the case with Mikrotik products.

True, but putting options like GPS synch etc. in these cheap products won't keep them cheap.... At the same time Wimax stuff is dropping in price.

I have nothing against time synch embedded in units and a big fan of 802.11a/b/g/n products and their free spectrum usage. But IMHO it think the chosen route in nv2 together with MT's proprietary management protection protocol is a path I would like to see deployed in full. Time synch is more for licensed spectrum where it is known who is using what frequency and where.

If you can make units talk to each other, and to each other ONLY while even other radio's in same frequency are around then 802.11a/n still stands a change in the future. Time synch can help here and there, but more is needed.

Ok... Allow me to un-hijack this thread....

Normis,

Thanks for the quick reply! While the idea is being planned, I wanted to modify the request slightly, in a way that may be easier to implement within a single radio.

I would like to configure two wireless cards with Nstreme polling enabled, in whatever configuration. Then have an option to "bind" the nstreme polling of the two cards. So instead of just running an individual polling loop on both cards, both cards run in the same polling loop. Let me provide an example.

wlan1 has two stations, st1 and st2. wlan2 has two more stations, st3 and st4. Same or different channels, doesn't matter. Same or different bands, doesn't matter. As it is now, with nstreme polling enabled:

wlan1 poll -> st1 (simultaniously) wlan2 poll -> st3
wlan1 st1 reply (simultaniously) wlan2 st3 reply
wlan1 poll -> st2 (simultaniously) wlan2 poll -> st4
wlan1 st2 reply (simultaniously) wlan2 st4 reply

Over and over again. What I propose is an option to make this happen instead:

wlan1 poll -> st1
wlan1 st1 reply
wlan1 poll -> st2
wlan1 st2 reply
wlan2 poll -> st3
wlan2 st3 reply
wlan2 poll -> st4
wlan2 st4 reply

Over and over again.

Seems like it would be a really easy, quick code change.

What do you think?

I will add this :

adding physical clock connection between wifi cards, through a small coaxial cable, should be doable without heavy code and hardware modifications.

This would allow synchronization for same tower antennas.


Next, for remote synchronization, oem GPS devices today are not so expensive.

Sync is extremely valuable even in unlicensed spectrum.

It is THE key reason that many WISPs put up with the price and other problems of Moto Canopy gear. It makes a huge difference. Even if it did NOTHING else it allows APs on a tower to put their channels closer together, which increases the number of APs (and backhauls) you can put on the tower. That alone would be worth the price.

But it does much more than just that.

Yes it's certainly not for pleasure that Motorola put sync ports inside their products. They even have a GPS sync module for remote sync (SyncPipe).

But sync is seen in a lot of professional applications :

- Digital Audio and Video Networks inside recording studios and broadcast facilities

- GSM phone networks

- Satellite GPS (and GLONASS, GALILEO)

If we have two adapters in the same board running NV2, are they synchronized?

If we have two adapters in the same board running NV2, are they synchronized?

You are talking about poolling synchronisation. I think that in a NV2 domain, all stations are automatically synchronized, so that they talk in a TDMA fashion.


But we are talking here about wave synchronization, so that radios on the same tower, or on different towers, have the phase of their transmision synchronized.

This is low level sync. NV2 pooling sync can be considered high level sync.


Low level sync needs specific hardware support : a hardware sync link between cards, or remote sync through very precise local oscillators helped from an atomic time source like a GPS or a NTP server.

This level of precision cannot occur through a software sync on the PCI bus with actual hardware.

Just to make sure I'm absolutely clear in understanding this, a 433 with two 5GHz cards cannot synchronize tx between the two cards?

I can see the absolutely accurate time source with two different AP's. I'm talking about two cards in one board. This is too complicated?

Same problem with two cards in the same box. They need to be physicaly linked by a sync bus. Generaly this is done by a coaxial cable.

For GSM networks, the time source is generaly a GPS unit with a 19.6608 MHz sinus output.

In the scientific area, sync is generaly achieved by a 1 PPS output, a digital time code, or a 10 MHz or 100 MHz sinus output.

100 MHz clocks are used on high end equipements, like hydrogen maser atomic clocks, where the ultimate precision sync transfer is needed (about parts in 10EE-15)

Can anyone from Mikrotik comment about GPS sync support for wireless AP's? We are 100% Mikrotik but the need for GPS Sync and the availability from UBNT is forcing our hand. We will be moving from MT to UBNT unless MT can show us some movement in that direction. Would like to have a comment asap as we are going to be make a very large purchase next week that will be going UBNT's direction.

I still don't see why many of you are so frantic about getting Wifi AP's time synchronised.
Imho this is a selling tool which in real world is not that interesting as it looks..... for the free wifi bands.

It works definitely very well on all licensed bands like cellular phone, satellite etc. Its even critical for some of these. But because we talk about licensed frequencies interference from other 2nd ´unknown´ radio owner is not around. So synch is basically only used within same operators radio network so they can use their limited radio channels more affective and it is fully controllable by operator itself.

The moment you expect same for operators working in a free band like 2,4 and 5Ghz Wifi things are different. Most situations where more than 1 operator uses un-licensed band in a region or even on the same tower, they are also each other's competitors. Good change they also work with different make devices. How do we think we can manage to synch all? It's already explained synch has to be done with hard coax cabling between units. So now we need to hook up with competitor's devices? Good luck!

And what about all these private 2,4G and 5Ghz AP/routers?

Don't hang your hopes on time synch of wifi AP only. Theoretically it looks nice, at first sight. But it only needs one other AP sending in same channel that is not synced to put you back to where you were...... interferences.. And lets be honest, this will happen and its not even illegal!
But yes, if you are the only one on the tower and region and you want many sending/receiving units in one tower it could be making a big advantage.

Anyway, if I understand well synch is also something that probably is more down to the chipset developer like Atheros. Personally I think it would be cheaper and easier to develop better receiver filters to keep interferences out of the door.

So now we need to hook up with competitor's devices? Good luck!

No, sync can be achieved remotely, through GPS or even NTP if an IP link is available. Every provider GPS or NTP linked to atomic time can be synched. This works like this for GSM networks.

And yes it needs radio chipset support, or external sync devices, but in this last case a hardware sync cable to the radio chipset is needed, so a sync input is needed. Not sure this is available on actual standard chipsets.

If there is only two or three providers, perhaps it can be usefull for them to try to sync themself rather than competing on the band without smartness.

Anyway you are right, it's not easy or even perhaps usefull in most normal cases for 2.4 Ghz.

But for licenced bands, and for uses where a provider is alone, for realtime roaming inside buildings, for VoiP, even at 2.4 Ghz, this can be usefull.

Professional VoIP access points (DECT) are all synched, so that you can roam from access point to access point without loosing receiver sync. Commutation is instantaneous, the receiver don't need to loose time to resync.


Wifi is not only 2.4 Ghz. Some manufacturers are producing 180-250 Mhz, 700 Mhz, 900 Mhz, 3.65 Ghz, 4 Ghz transmitters for licenced, military or governement use.

Anyway, syncing is certainly a good thing to propose for a low cost manufacturer, because actually to get this you need to buy higher cost hardware.

If you don't need it, don't use it. If you need it, then connect the GPS or NTP external synching unit, and you are synched.
Using a modular sync device approach would not rise the price of hardware too much. Only a sinus analog sync input is needed on radio devices.
To lower the cost even more, the RJ45 input could be used to carry the sync signal from an external sync box. CAT5 or CAT6 cable is enough to carry a sync 10 MHz signal on a few meters lenght. 4-5 or 7-8 RJ45 pair could be used, (the ones carrying DC power), leaving pairs 1-2 / 3-6 for fast Ethernet or half Gigabit data path.

So now we need to hook up with competitor's devices? Good luck!

No, sync can be achieved remotely, through GPS or even NTP if an IP link is available. Every provider GPS or NTP linked to atomic time can be synched. This works like this for GSM networks.

Well, units still need to synch with each other in the transmitting or receiving phase. Otherwise they could be in opposite phase running or there must be a protocol which is depicting all industry devices every 0,000 second of each minute units start with sending.

If there is only two or three providers, perhaps it can be usefull for them to try to sync themself rather than competing on the band without smartness.

Ok, but that need some slave-master config. Because it needs to happen each time the ´master´ has had a hickup.
Lets say provider one is first and than provider 2 decides to synch with 1. Ok. Now comes no-know provider 3. If he is not going to synch he might ruin everything. So the software must be made so intelligent it ´listens´ first if adjacent radio is running as slave (which must be the default) and in such case one of them has now to switch to ´master´ mode whereafter all others (also no. 3 provider) automatically should follow as ´slave´.
This master/slave config needs to be become industry wide standard, even for consumer products. Otherwise a domestic router close to our professional tower can still disrupt everything...

And what about distant units anyway? I believe a 5Ghz radio wave travels roughly 30 mtrs per µs. (If I remember well). If the synced phase changes every 1 µs (I presume?) than a unit at 15 or multiply of this meters away is in full opposite synch! In situations where many radio's use same frequency this might make things worse!

Anyway you are right, it's not easy or even perhaps usefull in most normal cases for 2.4 Ghz.

and 5Ghz. Within one or two years 5Ghz is as common as 2.4Ghz, even for consumers...

But for licenced bands, and for uses where a provider is alone, for realtime roaming inside buildings, for VoiP, even at 2.4 Ghz, this can be usefull.

Professional VoIP access points (DECT) are all synched, so that you can roam from access point to access point without loosing receiver sync. Commutation is instantaneous, the receiver don't need to loose time to resync.

We fully agree on this!

Wifi is not only 2.4 Ghz. Some manufacturers are producing 180-250 Mhz, 700 Mhz, 900 Mhz, 3.65 Ghz, 4 Ghz transmitters for licenced, military or governement use.

Yes, but we are mainly talking 2,4 and 5Ghz here. The others are not yet supported by MT or hardly in use in a ´free-`licensed radio networks like we discuss mainly in this forum.

Do not confuse phase adjustment, frequency adjustement for channels in the same synchronisation domain, and synchronisation to different sync domains.

Phase adjustment can be very fast, frequency adjustment as well if the two channels are synched to a same time reference.

Imagin two transmitters with two differents frequencies, and one receiver. If the two transmitters are synched to a common time reference, then switching from one channel to the other one in the receiver can be instantaneous, with a synthetised receiver. You don't need to resync, just ask an new frequency, based on the actual internal time reference.
Internal time reference is extracted from the previous chanel, or received by an external precision clock (atomic time).

Eventually a small phase adjustment is needed at channel switching, but not more.

So for a receiver, if transmitters are synched to a common clock, it's faster to synchronize when roaming because you can rely on the internal reference, extracted from the previous chanel lock.

This explain why there is a precision local oscillator inside mobile phones, this is to keep sync during roaming.


Syncing to different synchronisation domains is longer to achieve.


When you are roaming between GSM access points, the frequency of each access point is different, but the sync domain is the same, so even if phase and frequency are different seen from the receiver to each transmitter, fast roaming is easy.


Synching with asbolute phase is only needed for transmitters on the same tower, and yes it need a common sync feed. Not really difficult because on the same tower.

The good thing with sync, is that you can use more advanced receivers, with real time roaming, without adding heavy costs on the receiver side.

This was the goal with GSM networks : low cost and realtime roaming receivers.

I still don't see why many of you are so frantic about getting Wifi AP's time synchronised.
Imho this is a selling tool which in real world is not that interesting as it looks..... for the free wifi bands.

It works definitely very well on all licensed bands like cellular phone, satellite etc. Its even critical for some of these. But because we talk about licensed frequencies interference from other 2nd ´unknown´ radio owner is not around. So synch is basically only used within same operators radio network so they can use their limited radio channels more affective and it is fully controllable by operator itself.

Well the biggest issue right now is self interference on a single tower. With the poor quality of filters in current wireless cards it isn't possible to even collocate three of your own AP's running 10Mhz channels without causing self interference. A few years ago running 802.11 that and relatively low throughput this wasn't a huge issue but now with NV2 and other TDMA based protocols trying to push 40M through an AP it is a huge problem.

I would be happy if MT could come up with at least a stop gap sync for collocated AP's until they can come up with a full blown network wide sync.

I still don't see why many of you are so frantic about getting Wifi AP's time synchronised.
Imho this is a selling tool which in real world is not that interesting as it looks..... for the free wifi bands.

It works definitely very well on all licensed bands like cellular phone, satellite etc. Its even critical for some of these. But because we talk about licensed frequencies interference from other 2nd ´unknown´ radio owner is not around. So synch is basically only used within same operators radio network so they can use their limited radio channels more affective and it is fully controllable by operator itself.

Well the biggest issue right now is self interference on a single tower. With the poor quality of filters in current wireless cards it isn't possible to even collocate three of your own AP's running 10Mhz channels without causing self interference. A few years ago running 802.11 that and relatively low throughput this wasn't a huge issue but now with NV2 and other TDMA based protocols trying to push 40M through an AP it is a huge problem.

I would be happy if MT could come up with at least a stop gap sync for collocated AP's until they can come up with a full blown network wide sync.

Second this. As customers and bandwidth increases you'll see more problems with
self interference. With low density installations you can live without sync.
We work around this problem using different bands (including licensed).

Well, you guys almost got me over. I have to consume things a bit.

But beside of this I am realising that my choice of using many towers in relative small cells (but with their needed backhauls) hasn't been such a poor decision after all compared to that few communication towers the competition uses with some times over 100 antenna's in them! (Might be all different band but Wimax and 5Ghz Wifi are not that far apart. And I am sure the big telcos use powerlevels for their stuff we can only dream off.... Even if their used bands are miles away fm 5Ghz it probably still has an effect on our relative low end receivers.... ) I've been jealous at these tower users.. but actually I am growing a big smile!

I am also not so much against synch. I only couldn't understand this enthusiasm fm you guys for it. But after all your explanations you almost got me on the same boat.....

What chadd said about the poor quality filters in the present radio cards is hitting the nail on its head. I also wish manufactures of these would do better.
Why make cards most of us use for outdoor that support freq's only allowed for indoor use?
If manufacturers of radio-cards AND of the antenna's we use would more focus on the bands most of us really use than that would probably give reception already better characteristics in most situations.
A bit effort in improving the filters, hand in hand with synch, would create cards you'll lick your fingers off for....

Seems difficult to get more selectivity on receivers without sensitivity loss.

What could be interesting is adjustable filters, but i'm afraid by the cost. This is available on high end HAM receivers, but there is infinitely more room inside the enclosures to do this...

What could be done perhaps is optimized cards :


- very selective cards, with less sensitivity, for professionnal short range and high density networks

- less slective cards, with better sensitivity, for general use.


Frequency hopping could greatly help as well, this is often used when link reliability is a primary concern.

Seems difficult to get more selectivity on receivers without sensitivity loss.

What could be interesting is adjustable filters, but i'm afraid by the cost. This is available on high end HAM receivers, but there is infinitely more room inside the enclosures to do this...

What could be done perhaps is optimized cards :


- very selective cards, with less sensitivity, for professionnal short range and high density networks

- less selective cards, with better sensitivity, for general use.

I don't know. Are selectivity and sensitivity not two different, non related things?
Sensitivity is just how sensitive something is for what it is made for. So in radio this is just how weak a signal a receiver still can use. Most cards are doing pretty ok in this since they can even hear the background noise.

Selectivity is more like how focussed can be something to what it should do. In radio terms this would mean the more selective a radio is the better he will only hear that signal he should listen to and discard anything else.
This is the portion were probably still a lot can be gained. This is what a good filter should do, filter out all signals outside the frequency band a radio is told to listen too.

By having a good filter removing all ´non-desired´ frequencies it also lowers the background noise on the receiver. But ´noise´ that is in the frequency the radio has to listen to is still around at the same level as before. Here some higher layer filtering is required that more looks to what the signal is carrying instead of the signals itself. This is done with mac filtering (accept and connect-to list), encryption. But it should also be able to filter out signals coming for non digital source for instance. Microwaves, remote controls, etc.
For instance I already noticed that the use of the management protection key or the nv2 encryption already makes links more stable as compared to same links without any encryption. We just put another layer of filtering on the data stream that hits the processing unit.
(This is now beyond radio wave interferences off course. So a bit off topic.)

Imho sensitivity and selectivity are two things important to radios but are not necessary counter productive related to each-other.
A very selective radio can actually also be very sensitive. Military ´listening stations´ use very selective and very sensitive radio's plus off course very sophisticated filters to reduce the crap.

Frequency hopping could greatly help as well, this is often used when link reliability is a primary concern.

How would that help if all channels in a band are already in use?

In this case frequency hopping can help because you can send more power, as you are using multiple channels.

If using ten channels, you can send ten times more power, staying in the regulatory domain limits.


And it's easier to find gaps to transmitt if your are watching ten channels, than if you are watching only one channel.


Some low cost (civilian) 2.4 GHz radio transmitters in the RC world are using frequency hopping (Futaba FASST protocol).

You can use hundred transmitters at the same time on the band, with only 20 channels, and there is no interferences.

In this case frequency hopping can help because you can send more power, as you are using multiple channels.

If using ten channels, you can send ten times more power, staying in the regulatory domain limits.


And it's easier to find gaps to transmitt if your are watching ten channels, than if you are watching only one channel.


Some low cost (civilian) 2.4 GHz radio transmitters in the RC world are using frequency hopping (Futaba FASST protocol).

You can use hundred transmitters at the same time on the band, with only 20 channels, and there is no interferences.

hmm, I am afraid I have to spend some more of my scarse time to read in on this. I think I don't understand.. Is "frequency hopping" not something that the radio swaps to another channel all the time? I don't understand how power is increased this way. Half a Watt is half a Watt. But obviously I am a ´dummy´ in freq. hpping! But I am eager to learn!

Yes half a watt is half a watt, but if the spectrum is larger as it is the case with frequency hopping, then relative power on each channel (mean power) is smaller.


Under FCC regulations, frequency hopping systems fulfilling certain requirements in the 902-
928 MHz band are allowed to transmit using up to 1W output power.

This document outlines the basic principles of frequency hopping :


http://focus.ti.com/general/docs/lit/ge ... er=swra077

When I first started in the business 8+ yrs ago I built our first network using Raylink "raytheon" FHSS gear. It did have advantages because you could co-locate many AP's on the same tower just by setting them to different hop sequences. FHSS was about bullet proof when it came to interference mitigation but it was limited to 2Mbit over the air that = ~1.2Mbit real TCP throughput so while it was fine 8 yrs ago we quickly outgrew the limited capacity of the FHSS system.

I wouldn't think it would be too difficult for MT to do tower based sync of multiple AP's but who knows I guess. I do wish they would give us some hint of what they are working on and a time frame.

Yes half a watt is half a watt, but if the spectrum is larger as it is the case with frequency hopping, then relative power on each channel (mean power) is smaller.


Under FCC regulations, frequency hopping systems fulfilling certain requirements in the 902-
928 MHz band are allowed to transmit using up to 1W output power.

This document outlines the basic principles of frequency hopping :


http://focus.ti.com/general/docs/lit/ge ... er=swra077

I understand the limitations.

But i'm quite sure it should be possible to design better protocols, using frequency hopping or similar technics, to get better link reliability and speed keeping a low cost.

Frequency hopping was used primirily on very expensive military radios, and we see it today on civilian RC transmitter or even low cost talky walky systems.

any update from MT on gps sync is very welcome!

seems not avoidable when there is a busy tower on Nv2.

Please update us un the planning stage.

Regards
Ros

any update from MT on gps sync is very welcome!

seems not avoidable when there is a busy tower on Nv2.

Please update us un the planning stage.

Regards
Ros

The way I see sync being used is to use the frequency more effectiantly. If you have 25mhz of 3.65ghz. You have to use 3 of 5mhz channels. Thats not effeciant. Sync will work for this.

To solve your issue. Use RF shielding. That will work better for you than sync will. Plus you can use it now.

do you have any advice on wich ids the best product to rf shield the APs?

regards

use the Y shield from lessemf.com. Install on the sides and back of antenna. So the rf cant blast over to the other antenna. Grounding this shield is required.

dallas - i bought a can of this y shield ... but havent used it for anything yet. do you have any pics or useful tips?

Just dont paint it in the front of the antenna. Every time you put on a layer. It doubles the shielding. Paint right to the ground of the antenna. You know right where the N connector is. Because that is your ground of the antenna. Then make sure that is grounded. Thats it.

Can anyone from Mikrotik comment about GPS sync support for wireless AP's? We are 100% Mikrotik but the need for GPS Sync and the availability from UBNT is forcing our hand. We will be moving from MT to UBNT unless MT can show us some movement in that direction. Would like to have a comment asap as we are going to be make a very large purchase next week that will be going UBNT's direction.

If you need GPS sync now then there's no reason not to use UBNT for layer 2 and Mikrotik for layer 3. For fancy sites I use UBNT radios with Cisco routers since there's things RouterOS can't do. I'd rather see Mikrotik focus on routerboard/routeros and UBNT focus on radio/antenna systems. It's very common for me to plug a UBNT radio into a Routerboard at a customer site. Yeah, there's two devices instead of all-in-one, but then again I'm not stuck making a decision like you have to make now because I have the flexibility of both. IMHO those are their strengths and trying to make either do everything for everyone will only make for a weaker product (lack of focus) or extremely expensive product in the long run.

Yeah, I know there are fanboys for both sides that think you have to go all one or the other and that the other is crap (like all the "cheap plastic" comments MT fans made of UBNT products in the past and then MT comes out with similar products in plastic), but that's simply not true. Picking the strengths of each results in a far more robust and flexible system for both you and your customers. Then you're not banging down the door of MT to get GPS sync out the door ASAP because even when they do, UBNT will still have had it in the field longer and have worked out many of the bugs and "real world" application complaints from their users.

I believe Mikrotik has done a very good job on ap to clients and there really is no reason why they can't. My opinion is there ap to client is more powerful than any other manufacture. You just need to know how to set it up right. If you do that, its very powerful.

..........
If you need GPS sync now then there's no reason not to use UBNT for layer 2 and Mikrotik for layer 3. For fancy sites I use UBNT radios with Cisco routers since there's things RouterOS can't do. I'd rather see Mikrotik focus on routerboard/routeros and UBNT focus on radio/antenna systems. It's very common for me to plug a UBNT radio into a Routerboard at a customer site. Yeah, there's two devices instead of all-in-one, but then again I'm not stuck making a decision like you have to make now because I have the flexibility of both. IMHO those are their strengths and trying to make either do everything for everyone will only make for a weaker product (lack of focus) or extremely expensive product in the long run.

Yeah, I know there are fanboys for both sides that think you have to go all one or the other and that the other is crap (like all the "cheap plastic" comments MT fans made of UBNT products in the past and then MT comes out with similar products in plastic), but that's simply not true. Picking the strengths of each results in a far more robust and flexible system for both you and your customers. Then you're not banging down the door of MT to get GPS sync out the door ASAP because even when they do, UBNT will still have had it in the field longer and have worked out many of the bugs and "real world" application complaints from their users.

I would be very cautious about the long term mixing of components from different manufacturers, while at present i use XR5 with 433Ah's but what would be the result if say XR5 component build was changed, could we find it would not work properly with Mikrotik proprietary wireless protocols?

its not compatible with mikrotik nv2 and ubnt tdma.

its not compatible with mikrotik nv2 and ubnt tdma.

What is not compatible with mikrotik nv2 and ubnt tdma?

while at present i use XR5 with 433Ah's but what would be the result if say XR5 component build was changed, could we find it would not work properly with Mikrotik proprietary wireless protocols?

it doesn't matter what components you have on the wireless card. most wireless cards support Nv2 in RouterOS. only very old atheros chipsets, like the 5211, could not work with Nv2. so basically you can say that card design and manufacturer doesn't matter. what matters is that it's an Atheros chip that RouterOS recognizes.

There are opensource design available for this.

Where?

I absolutely need this nv2 sync between mikrotik units on the same tower. I am using 3.65ghz. I am using sectors and 5mhz channels. In order to use the bandwidth more effectiantly. I want to use 20mhz channels and use nv2 sync. Or I could use more sectors and have a bunch of 5mhz channels. Anyways for 3.65ghz nv2 sync support is needed. Hopefully before the end of this year. Please mikrotik, whats the status so far?

I would like to vote for NV2 sync for the main feature for 6.0 beta.

I would like to vote for NV2 sync for the main feature for 6.0 beta.

Not exactly what you want but I started today my first synch dual antenna AP system.
Two antenna's on one radio card transmitting and sending in full synch. Both covering a sector. Use of one dual chain ´n´ card with both connectors in use in 802.11a band.

If manufacturer now would make triple or quadruple chain cards...... (802.11n specification is open for it) then you could at least have a tower with 4 sectors all in synch. and using only one freq.! Due the 4 separate antenna's that all get the full chain power in transmitting and each ´listens´ in ´his´ sector this would be a nice feature!

I would like to vote for NV2 sync for the main feature for 6.0 beta.

Not exactly what you want but I started today my first synch dual antenna AP system.
Two antenna's on one radio card transmitting and sending in full synch. Both covering a sector. Use of one dual chain ´n´ card with both connectors in use in 802.11a band.

If manufacturer now would make triple or quadruple chain cards...... (802.11n specification is open for it) then you could at least have a tower with 4 sectors all in synch. and using only one freq.! Due the 4 separate antenna's that all get the full chain power in transmitting and each ´listens´ in ´his´ sector this would be a nice feature!

I want to wireless to be synced through the ethernet cables with a timing source. The source really dont matter as long as there is a master and the rest of the mikrotiks are slaves. I would use 802.11n cards with nv2.

Hello Dear Mikrotik guys

What is the status of NV2 time synchronization? When you guys think the roadmap target date is to do this part?

Thank you

I am soon going to be ready to use this. Please mikrotik start working on this for routeros 6.0 please.

I would like to vote for NV2 sync for the main feature for 6.0 beta.

I agree

do you have any real proof that this technology is as efficient as it seems in theory?

do you have any real proof that this technology is as efficient as it seems in theory?

I can explain a very common situation that the sync would help everyone out. Would you like me to describe it to you?

do you have any real proof that this technology is as efficient as it seems in theory?

I also have a question about NV2 Sync performance, for example in a classic 4 sector AP, A= North, B= East, C= South, D= West, will just each AP transmit at a time or could it 2+2, that is north+south transmit and east west listen and then east west transmit and north south listen, if it's only one AP at a time if say for example have 50 clients per sector will the time required to poll each client slow down the overall performance.

do you have any real proof that this technology is as efficient as it seems in theory?

I also have a question about NV2 Sync performance, for example in a classic 4 sector AP, A= North, B= East, C= South, D= West, will just each AP transmit at a time or could it 2+2, that is north+south transmit and east west listen and then east west transmit and north south listen, if it's only one AP at a time if say for example have 50 clients per sector will the time required to poll each client slow down the overall performance.

No. All Aps transmit at the same time. E.g. with wimax you've a 5ms frame. First part
of the frame all APs send. Second part is for cpes to transmit. You've to divide the 5ms
frame on a fixed basis for the whole network. E.g. 75% down/25 %up.
As aps only listen in the second part they dont see/disturb each other.
So sync takes the advantage of dynamic up/downrate on a tdd network but
reduces interference and increases frequency usage.
Additionally this scheme changes the way cpes have to behave. They cant send/resend
frames at will. They have to wait for a slot they are allowed to use.

So if there is enough frequency sync makes things complicated and less flexible.

No. All Aps transmit at the same time. E.g. with wimax you've a 5ms frame. First part
of the frame all APs send. Second part is for cpes to transmit. You've to divide the 5ms
frame on a fixed basis for the whole network. E.g. 75% down/25 %up.
As aps only listen in the second part they dont see/disturb each other.
So sync takes the advantage of dynamic up/downrate on a tdd network but
reduces interference and increases frequency usage.
Additionally this scheme changes the way cpes have to behave. They cant send/resend
frames at will. They have to wait for a slot they are allowed to use.

So if there is enough frequency sync makes things complicated and less flexible.

Ok - with sync as you say reduces interference and frequency usage but will it increase or decrease throughput from the AP's because of the usage of sync and what about Ptp links if using the same band as the AP's, which will be transmitting at the same time will it cause extra interference to the ptp's.

No. All Aps transmit at the same time. E.g. with wimax you've a 5ms frame. First part
of the frame all APs send. Second part is for cpes to transmit. You've to divide the 5ms
frame on a fixed basis for the whole network. E.g. 75% down/25 %up.
As aps only listen in the second part they dont see/disturb each other.
So sync takes the advantage of dynamic up/downrate on a tdd network but
reduces interference and increases frequency usage.
Additionally this scheme changes the way cpes have to behave. They cant send/resend
frames at will. They have to wait for a slot they are allowed to use.

So if there is enough frequency sync makes things complicated and less flexible.

Ok - with sync as you say reduces interference and frequency usage but will it increase or decrease throughput from the AP's because of the usage of sync and what about Ptp links if using the same band as the AP's, which will be transmitting at the same time will it cause extra interference to the ptp's.

It decreases max throughput in one direction as you've to make a fixed up/down ratio.
If you do ptp on the same band you've to seperate it enough to avoid interference or
you've to sync it.

Hi Guys,

It decreases max throughput in one direction as you've to make a fixed up/down ratio.

Why's that? Explain.

Imho, if radio's are synch'd, this is done outside the actual data transporting process. So why should that influence the throughput?

And by the way, I already use some synch with MT. dual chain cards in legacy mode.
Now, if cards are going to be developed with 3 or 4 chains. (The ´n´ standard is ready for it!) you can indeed make one 3 or 4 sector AP in full synch coming from one card.

It's not what you want but its a good step in the direction.

@WirelessRudy

Do you actually know what GPS sync is? If you do, how are you syncing using RouterOS, because from my point of view its not possible unless you had access to the source and recoded the NV2 (TDMA) protocol to support it.

The throughput in one direction will drop. The simple reasoning is that when running in a sync'd mode you can't transmit at will, you only transmit when allowed. So you will see an drop in PtP throughput based on that.

HOWEVER, and this the Mikrotik guys should already know...

GPS transmit sync may be difficult to implement well, but the theory is quite simple. At an AP cluster, right now the way it sits is that you can have APs transmitting when a different AP is listening to a client. So the listening device 'hears' a hot signal from the nearby AP thus causing an increase in noise, which causes more error which forces the listening AP to use lower modulations.
By syncing the AP you ensure that you don't ever get a hot signal from a nearby sync'd AP.

So in a sync'd AP cluster the total aggregate throughput of the entire site is vastly increased and scales better as you add more sync'd units.

It show why some of us want it so bad, take 4-5 antennas say 5 GHz place them all on a tower and then run a transmit test simutaneously on all the units. For those of us that are limited to the UNII-3 band (5.725 - 5.825), that means at best no channel seperation, only different channels. I can promise you that not a single one of the antennas will achieve its maximum datarate (ie. the throughput achived without any other APs transmitting).

Cheers

Hi Guys,

It decreases max throughput in one direction as you've to make a fixed up/down ratio.

Why's that? Explain.

Imho, if radio's are synch'd, this is done outside the actual data transporting process. So why should that influence the throughput?

And by the way, I already use some synch with MT. dual chain cards in legacy mode.
Now, if cards are going to be developed with 3 or 4 chains. (The ´n´ standard is ready for it!) you can indeed make one 3 or 4 sector AP in full synch coming from one card.

It's not what you want but its a good step in the direction.

You have to have a fixed timeslot for all APs to send and a fixed timeslot for all cpes
to send. You cant dynamically give an AP or cpe 100% of the time for sending.
The size of this timeslots have to be the same on all towers/aps. Any ap/cpe sending
outside the ap/cpe timeslot would cause interference.

@WirelessRudy

Do you actually know what GPS sync is?

Lets bounce this back. Have you any idea what interference in radio technology is? Before you start discussing a solution you'd better investigate in the source of a problem.

If you do, how are you syncing using RouterOS, because from my point of view its not possible unless you had access to the source and recoded the NV2 (TDMA) protocol to support it.

Well, explain to me how one card, with two chains both connected and working with their own antenna and serving clients cannot be synch'd if the tdma is done by this card only? It cannot be anything different than full synch. Only for units attached to this card though. But full synch. And it works like a charm...

The throughput in one direction will drop. The simple reasoning is that when running in a synch mode you can't transmit at will, you only transmit when allowed.

NV2 is already taking care of that. Stations are only allowed to send when AP tells them they can. And AP adjusts its sending-receiving upon need. That's one of the major principles of TDMA anyway.....

.....the theory is quite simple. At an AP cluster, right now the way it sits is that you can have APs transmitting when a different AP is listening to a client. So the listening device 'hears' a hot signal from the nearby AP thus causing an increase in noise, which causes more error which forces the listening AP to use lower modulations.

Well, what you prescribe here is "interference". All you need to do is sufficient channel separation and physical antenna separation and off course use proper gear. But then that issue is solved. Doing such you get the full throughput belonging to the bandwidth and mode you selected. I'm doing this for years. No need for synch to get me that....

So in a sync'd AP cluster the total aggregate throughput of the entire site is vastly increased and scales better as you add more sync'd units.

Not true. It only eliminates possible interferences of nearby units. You don't need synch to fight that. To state "the total aggregate throughput of the entire site is vastly increased"
is only a possible result in case without synch interference is really an issue. If this is not synch won't bring any improvements. So you statement is a bit bold imho.

It show why some of us want it so bad, take 4-5 antennas say 5 GHz place them all on a tower and then run a transmit test simutaneously on all the units. For those of us that are limited to the UNII-3 band (5.725 - 5.825), that means at best no channel seperation, only different channels. I can promise you that not a single one of the antennas will achieve its maximum datarate (ie. the throughput achived without any other APs transmitting).

Here you go. Your UNII-3 band is only 100Mhz wide. So several antenna's working in this band on one tower are prone to induce interferences on themselves just due the close proximity of all working channels. That is a nice example synch might indeed give improvements. But I would like to underline might. Only if without synch indeed interference is your problem.

Bottom line:
- With the use of a duo chain card you can already do small scale synch.
- Synch is only needed if their are not enough free frequency channels left on a tower so some units have to work in the same or close adjacent frequencies. Only then synch will be a solution. But if that is not the case.... no need for synch. The industry has done without for years.....

Imho synch is overrated and proper use of the available technologies can give good results. Only in very congested towers synch will bring improvements.

Hi Guys,

It decreases max throughput in one direction as you've to make a fixed up/down ratio.

Why's that? Explain.

Imho, if radio's are synch'd, this is done outside the actual data transporting process. So why should that influence the throughput?......

.

If all the Ap's are transmitting at once rather than i thought 2+2 in a 4 sector cluster, then for example a sector with 20 clients will have to wait till for the sector with 70 clients are polled,etc - this has time delay has to effect throughput.

Imho synch is overrated and proper use of the available technologies can give good results. Only in very congested towers synch will bring improvements.

Sync is a solution for a problem you run into very fast in urban and suburban
areas as bandwidth demand raises. In rural areas you may never need it as spectrum
may be enough.
You may avoid it by getting additional frequency. E.g. running with licensed ptp
to our main towers saves a lot of frequency. One licensed ptp link eats 2 times 56Mhz
of spectrum. Doing this in 5.x would reduce the chance to get a free channels on these
towers. Even then as we do smaller links in 5,8 we'll need to sync very soon.

As bandwidth usage increase will go on we all will have to learn that frequency
is a very limited resource. We've paid for some 3,5 GHz Spectrum. So we're very
eager to make the most out of it...

Hi Guys,

It decreases max throughput in one direction as you've to make a fixed up/down ratio.

Why's that? Explain.

Imho, if radio's are synch'd, this is done outside the actual data transporting process. So why should that influence the throughput?......

.

If all the Ap's are transmitting at once rather than i thought 2+2 in a 4 sector cluster, then for example a sector with 20 clients will have to wait till for the sector with 70 clients are polled,etc - this has time delay has to effect throughput.

No, AP with only little stations associated just has a shorter interval of serving each station compared to AP with many stations. As long as sending/receiving stays in pass the AP with little stations is not loosing througput compared to the situation where it would work on its own. (So no other AP's around.)

Since TDMA is also capable of setting the frame length this needs to be in synch too. If one AP would send in long frames while the other is in short, the time slots differ and they will run out of pass very soon. So slots have to stay the same. And for best performance frames have to fit.

Imho synch is overrated and proper use of the available technologies can give good results. Only in very congested towers synch will bring improvements.

Sync is a solution for a problem you run into very fast in urban and suburban
areas as bandwidth demand raises. In rural areas you may never need it as spectrum
may be enough.
You may avoid it by getting additional frequency. E.g. running with licensed ptp
to our main towers saves a lot of frequency. One licensed ptp link eats 2 times 56Mhz
of spectrum. Doing this in 5.x would reduce the chance to get a free channels on these
towers. Even then as we do smaller links in 5,8 we'll need to sync very soon.

As bandwidth usage increase will go on we all will have to learn that frequency
is a very limited resource. We've paid for some 3,5 GHz Spectrum. So we're very
eager to make the most out of it...

I completely agree.
The problem is only that sync will only give a solution in limited cases where all other approaches might really not work any longer.
And then it is limited in such that when spectrum becomes scarce this is usually not because YOU, as operator eats it all. To solve now your problems on a tower you need to cooperate with other spectrum users, not seldom your competition but nowadays can also be the domestic owner of 5Ghz equipment.

So it is like I said before. It is a nice feature, but don't put too much money on it.

The discussion is interesting enough though. Please go on, we are still learning....

From
http://people.freebsd.org/~sam/FreeBSD_ ... 090921.pdf

page2
"TDMA requires a slot assignment protocol and a synchronization algorithm to ensure time slots do not
collide as the clocks drift. Implementing TDMA purely in software is feasible but can use significant
resources to guarantee the real-time constraints. Also, software-based TDMA implementations usually
perform worse than those with hardware assistance."
What is hardware assistance?

From
http://people.freebsd.org/~sam/FreeBSD_ ... 090921.pdf

page2
"TDMA requires a slot assignment protocol and a synchronization algorithm to ensure time slots do not
collide as the clocks drift. Implementing TDMA purely in software is feasible but can use significant
resources to guarantee the real-time constraints. Also, software-based TDMA implementations usually
perform worse than those with hardware assistance."
What is hardware assistance?

Interesting document. I need to read it a couple more time before I can consider it to be consumed. But I think with ´hardware assistance´ they mean the internal clock of the chipset. They use this clock and the station is adjusting the time difference with the AP each frame. So the slot assignment protocol and synchronization algorithm are synch'd with the AP but based upon the internal clock of the station. That's how I read it.

Hardware assistance I would take as refering to an external accurate clock source. Typically clock sources on mainboards, or any electronic device are now using a crystal oscillator, but variation in the crystal, temp, and other effects can cause time drift. To humans a clock being off by 1-2 seconds is not a big deal, but when syncing communications its a killer. That is why a all sync'd transmit systems I've used have GPS clock timing which is accurate to I believe 15 nanoseconds.

Now using one chain of a dual chain radio card to drive one antenna, and a 2nd chain to drive a 2nd antenna (in different directions), is no where near what many of us are asking for.

Spatial multiplexing is used to allow multiple simultaneous transmissions in 802.11n it is designed to increase throughput so as the recieving antenna recives all the streams within a short time period and recombines them. I do not believe 802.11n emplys spatial-division multiple-access. If I am wrong then what you are doing may work in small scale deployments, but if I am not wrong, then that means you are achiving nothing useful as the radio card can't transmit to multiple different users simultaneously.

If you look at the 802.11n MCS data rates you'll notice it still using QAM64, the bandwidth increase comes from a shorter guard interval, the availability of 5/6 coding rate, frame aggregation to reduce overhead, and spatial multiplexing. I am not really counting the 40 MHz channels as an improvement as many of us were already using Atheros 40 MHz channels.

The shorter guard interval, and the coding rate are hugely affected by noise/interference, and by going your route you are eliminating spatial multiplexing from the equation.

Reducing noice is key to achiving higher stable throughput. I achive this by shielding all my AP antennas with aluminium shields, radio card isolation, maximum available channel/antenna seperation, and cavity filters. That is about the most I can currently do with RouterOS, adding GPS sync is one more way to reduce the self-interference that results on busy AP clusters.

Cheers

Hardware assistance I would take as refering to an external accurate clock source. Typically clock sources on mainboards, or any electronic device are now using a crystal oscillator, but variation in the crystal, temp, and other effects can cause time drift. To humans a clock being off by 1-2 seconds is not a big deal, but when syncing communications its a killer. That is why a all sync'd transmit systems I've used have GPS clock timing which is accurate to I believe 15 nanoseconds.

Now using one chain of a dual chain radio card to drive one antenna, and a 2nd chain to drive a 2nd antenna (in different directions), is no where near what many of us are asking for.

Spatial multiplexing is used to allow multiple simultaneous transmissions in 802.11n it is designed to increase throughput so as the recieving antenna recives all the streams within a short time period and recombines them. I do not believe 802.11n emplys spatial-division multiple-access. If I am wrong then what you are doing may work in small scale deployments, but if I am not wrong, then that means you are achiving nothing useful as the radio card can't transmit to multiple different users simultaneously.

If you look at the 802.11n MCS data rates you'll notice it still using QAM64, the bandwidth increase comes from a shorter guard interval, the availability of 5/6 coding rate, frame aggregation to reduce overhead, and spatial multiplexing. I am not really counting the 40 MHz channels as an improvement as many of us were already using Atheros 40 MHz channels.

The shorter guard interval, and the coding rate are hugely affected by noise/interference, and by going your route you are eliminating spatial multiplexing from the equation.

Reducing noice is key to achiving higher stable throughput. I achive this by shielding all my AP antennas with aluminium shields, radio card isolation, maximum available channel/antenna seperation, and cavity filters. That is about the most I can currently do with RouterOS, adding GPS sync is one more way to reduce the self-interference that results on busy AP clusters.

Cheers

Well, you're obviously not a good reader or don't understand what is written.

"Hardware assistance" in the mentioned article is not an external source. The assistance comes form the internal oscillator (=hardware) and all TDMA does do is adjusting the internal clock drift every cycle towards the clock of the AP and in doing so it arranges the station to be in synch with AP. So this is done without any GPS synch which indeed most vendors TDMA stuff doesn't have yet. Still it works!

"Spatial multiplexing blah blah blah..." Where did your read I use the dual chain card in ´n´ mode? I use both chains, but in ´a´ mode and thus both chains are working, have clients associated and they all communicate with AP in full synch. One through antenna A, another through antenna B.
In such I have a full synch 2 antenna setup, working in 802.11a

And I am not claiming I've found the way to synch towers. I mentioned that what I was doing is small scale (but still for 35 clients on one AP!) synch. I do save frequencies this way as well as hardware, power consumption and heat production in the box. And this way I can reach more clients with better signals than I would ever be able to do in a one-card+one antenna setup.
And what I can do with a dual chain card, if the manufacturers start building triple and quadruple chain card the same can be done and suddenly you can build a full 4 sector a/b/g AP of a mast working with only one frequency and in full synch!

If I for myself overlook what advantages GPS synch might bring against what costs and its flaws and compare that to the chance triple or quadruple chain cards might be produced (at lower costs and wider usages probability) I'm not even so sure what will make it first....

I know Ubiquity is coming on the market with sync units. They are good in ´feeling´ what is in fashion and have a smart developing department to bring sleek products in the market that appeal to what the bulk of illiterate Wifi users think they need.
Wireless operators that take the time to investigate in radio technology in the field of Wifi and want reliable top performing stuff usually are not the ones buying their stuff.
But, its said before, best quality is not always making best business.

I'd like to believe you found a way to sync, but I am extremely skeptical.

Using 802.11a in NV2 mode @ 20 MHz with ROS v5.7 outdoor with RX/TX signals of ~-65 I am able to achieve a one way TCP throughput of 33 Mbps on a test link I setup.

If what you are doing with a dual chain card in legacy 802.11a mode works as you claim, then I think it would be worthwhile to share this in a video of a bandwidth test to two clients. You should get ~33 Mbps simultaneously to both clients if both antennas are transmitting different data simultaneously to the different clients (on the seperate antennas of couse).

I would also like to see 4x4:4 cards just as you, but I wouldn't be using them to drive 4 antennas in different directions.

Cheers

Skeptic is my trademark when it comes to new things! So we can shake hands on that.

Apart from that, I haven't got time to set up a test to show how its done.
I have on this moment in my network one AP with some 34 clients where I use this dual chain legacy mode setup. Some get the best signal from one chain, the others from the other. In two case the difference is indeed such that if I disable the chain it works off that clients drops off completely.
Almost all of these clients have rb133C's and only some 411's and they are all ´live´!
I can't start a test to proof my arguments because to run bandwidth tests I have to setup bandwidth generating units behind these CPE's that are 100% working on one chain only. These CPE's aren't even capable of running 30Mb anyway...
But I simply don't have the time to do that plus cooperation of these clients etc. etc.

And my aim is not to promote this way of using cards like it is THE solution..
I merely finger pointed that we can already do some sync in single card units with two antennas.
Specially in a environment where spectrum is already scarce this might be a way to lower the amount of channels you'd use yourself as alternative of using splitter and amplifiers. This has been my main reason. Not capacity. My users will never need the full capacity in throughput of the wireless part anyway, hence I can even use safely 10Mhz channels because these still full-fill basic client needs.

i would really appriciate sync betwenn AP´s.
It will bring more throughput and higher density of APs on towers with less interference.

by the way for three sectored tower, like wirelsrudys implementation , you can use ubnt SR-71A with 3x3 Mimo.

i would really appriciate sync betwenn AP´s.
It will bring more throughput and higher density of APs on towers with less interference.

by the way for three sectored tower, like wirelsrudys implementation , you can use ubnt SR-71A with 3x3 Mimo.

I don't think sync will bring more throughput?

It decreases max throughput in one direction as you've to make a fixed up/down ratio.
If you do ptp on the same band you've to seperate it enough to avoid interference or
you've to sync it.

by the way for three sectored tower, like wirelsrudys implementation , you can use ubnt SR-71A with 3x3 Mimo.

Some has to check whether ubnt SR-71A is working on 3 chains in legacy mode.
I only have experience with MT cards.
Maybe we use a flaw in MT that is made unable in other cards? Like before, you could only choose between antenna a or b in legacy mode...

The Compex mpcie WLE300NX is 3x3mimo too.
You will choose A/N mode and set all three chains in HT.
if look at registration table you can see under signal at each client chain0 / chain1 / chain2 - rx and tx values

The Compex mpcie WLE300NX is 3x3mimo too.
You will choose A/N mode and set all three chains in HT.
if look at registration table you can see under signal at each client chain0 / chain1 / chain2 - rx and tx values

Whow, this opens a new idea...
I am in the process of setting up a new tower, which should have two 90º sectors and most clients in 5km range. I only have 3 or 4 that are more than double the distances away.
The problem is that they have therefore marginal signal (-80 range) compared with rest that are all in -50 to -65 range.
I can now on 3rd chain a directional antenna that has a footprint thrown at these distant clients to bring them into better signal ranges so the NV2 protocol works perfect!

(It's pity I don't need a 3 sector AP! I really would like to try that out! )

Hi all.

I see that this conversetion is quite contrary... Yes we need GPS Sync, No we don't. I think that any new feature is good if product price remains the same (or just a little higher), so the solutions for both sides would be that MT implements Sync in separate device (like RadWin) or create it as add-on (we can add it to RB like DoughterBoard on boards which would support it). With solution like this we would have good MT products without Sync with great prices like they are now, and we still have the option to put Sync on when and if we need it.

I am bringing GPS Sync back to the front.
It will become my most important issue.
We have over 4000 RB411's and RB711's on hundreds of AP's.
I need GPS Sync to allow more customers on my crowded towers.
Please MT, make it a priority for RouterOS 6

I am bringing GPS Sync back to the front.
It will become my most important issue.
We have over 4000 RB411's and RB711's on hundreds of AP's.
I need GPS Sync to allow more customers on my crowded towers.
Please MT, make it a priority for RouterOS 6

Yes. For sure it is needed with high density usage. I see

I am bringing GPS Sync back to the front.
It will become my most important issue.
We have over 4000 RB411's and RB711's on hundreds of AP's.
I need GPS Sync to allow more customers on my crowded towers.
Please MT, make it a priority for RouterOS 6

Yes. For sure it is needed with high density usage. I see this when
uplink modulation goes down on crowded towers. It is expensive to
solve this. First we move backhaul to a different band. Then we add
a different band for access.
ROS6 alone would not help. It does need complete new hardware.
UBNT failed to do this with SW.
MT has to go the path of going deeper into wireless chip design. Not
sure this is what MT is willing to do as it will increase pricing.

ROS6 alone would not help. It does need complete new hardware.
UBNT failed to do this with SW.
MT has to go the path of going deeper into wireless chip design. Not
sure this is what MT is willing to do as it will increase pricing.

Yes, that is correct. But they could create it like add-on for RouterBoards. In this scenario they keep RB cheap but everyone have an option to add Sync support.

ROS6 alone would not help. It does need complete new hardware.
UBNT failed to do this with SW.
MT has to go the path of going deeper into wireless chip design. Not
sure this is what MT is willing to do as it will increase pricing.

Yes, that is correct. But they could create it like add-on for RouterBoards. In this scenario they keep RB cheap but everyone have an option to add Sync support.

This would make it even more expensive as less people would buy the GPS addon.
Dont understand my wrong. I would buy it. But I do not expect that it will happen.
I wait for some minor wireless features (like ATPC) for a long time now. They did
not happen. So will GPS.
And I like the way MT does it more. Better dont do it than announce and sell it even if
it does not work. You soon see an announcement of the competitor. And after a year
you will read the wining people who did not get their toy or did not get it working
like expected. But they sell it like sliced bread.
I decided to combine cheap MT gear for small fast cells with expensive wimax gear for
coverage. So the overall price is a mix, I get a working solution now and the combined
bandwidth of both worlds.

I am bringing GPS Sync back to the front.
It will become my most important issue.
We have over 4000 RB411's and RB711's on hundreds of AP's.
I need GPS Sync to allow more customers on my crowded towers.
Please MT, make it a priority for RouterOS 6

My priority is to focus on each antenna and does it have maximum co-location signal attenuation from its location on the mast and it has be mentioned that a Sync AP sector with good co-location signal attenuation will not as high as a throughput as a single AP Sector with the same good co-location signal attenuation because the sync AP has to wait for its turn to transmit.

Is it enough (accuracy wise) to get a standard GPS 1PulsePerSecond output into an RB through its serial port, or would the timing pulse need to be "directly injected" into a modified wifi card capable of accepting such an input?

We used to use the old Proxim Multipoint gear (1990s) and all they had was a gps board out-putting 1PPS to the main board for sector sync.

Ged

Is it enough (accuracy wise) to get a standard GPS 1PulsePerSecond output into an RB through its serial port, or would the timing pulse need to be "directly injected" into a modified wifi card capable of accepting such an input?

We used to use the old Proxim Multipoint gear (1990s) and all they had was a gps board out-putting 1PPS to the main board for sector sync.

Ged

It is not only getting sync signal to the board. You've to keep sending in an exact timeframe. So you have to change behavior of wireless card to an extent it might not allow. As I understand UBNT has to do a lot in SW which is done by HW normaly. This kills performance to an extent it might be worse than accepting some interference.

Gesendet von meinem GT-N7000 mit Tapatalk

What is the status of NV2 time synchronization? When you guys think the roadmap target date is to do this part?

any news on that topic?
When AP time synchronisation will work?
We realy need this!

What is the status of NV2 time synchronization? When you guys think the roadmap target date is to do this part?

any news on that topic?
When AP time synchronisation will work?
We realy need this!

Why you need this? NV2 works now very well in very noisy environment. If you have problem with nv2 --> try 5.21rc1

I have no problems with NV2, but we are going to buy frequencies and then we have 2x 10MHZ channels.
If we have 4 sectors we have to use the same frequency twice or may be three times.
Thats the point when syn support is needed.
By the way if you have running 4 antennas on different frequencies your throughput will increase significant with sync support.
All major systems (Wimax, LTE, etc.) using this to eliminate interference.

I have no problems with NV2, but we are going to buy frequencies and then we have 2x 10MHZ channels.
If we have 4 sectors we have to use the same frequency twice or may be three times.
Thats the point when syn support is needed.
By the way if you have running 4 antennas on different frequencies your throughput will increase significant with sync support.
All major systems (Wimax, LTE, etc.) using this to eliminate interference.

Try 3-4 sectors on the same chanel with nv2. I think - there is no problem. Throughput will be slightly lower...
Try using narrower sector antennas and clients with directional parabolic antenas...

UBNT has sync support. But it really does not work - I think it's "an impasse"

UBNT has sync support. But it really does not work - I think it's "an impasse"

How have you tested it doesn´t work?

UBNT has sync support. But it really does not work - I think it's "an impasse"

How have you tested it doesn´t work?

I dont. But people from forum:
We ran. It's great. Until there connected people ... latency up and throughput down . http://forum.ubnt.com/