I hope to see soon GPS synk from MT, it's no a option.

Local only is a waste of time. Syncing multiple towers is critical.

I do not completely agree on that.
I have one tower that has 5 backhauls and 5 AP's. Its amidst a valley with many more towers from me and others.
This tower of myself needs 5 x 40Mhz channel and 5 x 20Mhz channel. Each available channel will also receive some signal from distant radios.
I can make the whole thing work by using high to very high gain antennas to create narrow beams and very high signals (-35 to -45dBm range) and by using the professional dome or carrier class antennas from RF elementes for my AP's that are all shielded pretty much from co-tower interference and remote channel interferences. Clients are fit with antennas that at least receives -70dBm but preferrably below -65. But sometimes we need to change frequencies just because some tool decided to use same as me or very close to it. It's a hell of a puzzle to find a new frequency. I always also need to look at the other end not to interfere with radio's on my other towers....(And some clients are 'looking' at one tower but get signal from another tower at the same strength if it was an omni-cpe)

If I could use sync only in this tower it would make my life much easier because I could basically use just 2 (1x 40 and 1x 20Mhz band) or 4 frequencies instead of the 10 different ones I need now. If I could do one other tower of mine the same again I would free a lot of spectrum. Since I have 60+ radio's all in theoratical 'hearing' range where the competition adds another 40 or so spectrum is short. Off course it would be better to have more towers of mine sync'd but I can't do them all anyway since some are inter connected to at least two other towers of mine so I still need to play with the frequencies.
But the puzzle would become much simpler by one fully sync'd tower, much but less simpler with 2 towers, more but even lesser with 3 etc. etc.

Are there any products currently available in the fixed wireless market today local sync only? I think every form of fixed wireless sync in use today is GPS based. There must be a reason for that.

Maybe I should rephrase that. Anything other than GPS based sync as an end-game is a waste of time.

Local only is a waste of time. Syncing multiple towers is critical.

I do not completely agree on that.
I have one tower that has 5 backhauls and 5 AP's. Its amidst a valley with many more towers from me and others.
This tower of myself needs 5 x 40Mhz channel and 5 x 20Mhz channel. Each available channel will also receive some signal from distant radios.
I can make the whole thing work by using high to very high gain antennas to create narrow beams and very high signals (-35 to -45dBm range) and by using the professional dome or carrier class antennas from RF elementes for my AP's that are all shielded pretty much from co-tower interference and remote channel interferences. Clients are fit with antennas that at least receives -70dBm but preferrably below -65. But sometimes we need to change frequencies just because some tool decided to use same as me or very close to it. It's a hell of a puzzle to find a new frequency. I always also need to look at the other end not to interfere with radio's on my other towers....(And some clients are 'looking' at one tower but get signal from another tower at the same strength if it was an omni-cpe)

If I could use sync only in this tower it would make my life much easier because I could basically use just 2 (1x 40 and 1x 20Mhz band) or 4 frequencies instead of the 10 different ones I need now. If I could do one other tower of mine the same again I would free a lot of spectrum. Since I have 60+ radio's all in theoratical 'hearing' range where the competition adds another 40 or so spectrum is short. Off course it would be better to have more towers of mine sync'd but I can't do them all anyway since some are inter connected to at least two other towers of mine so I still need to play with the frequencies.
But the puzzle would become much simpler by one fully sync'd tower, much but less simpler with 2 towers, more but even lesser with 3 etc. etc.

Are there any products currently available in the fixed wireless market today local sync only? I think every form of fixed wireless sync in use today is GPS based. There must be a reason for that.

Maybe I should rephrase that. Anything other than GPS based sync as an end-game is a waste of time.

Radwin has a local solution where gps can be added.

thats why aside GPS sync and NTP is PTP introduced to fill gap between.
usually nodes in Telco - support Both GPS and PTP for obvious reasons. and control nodes and routers - rely on SNTP aswell.
(https://en.wikipedia.org/wiki/Precision_Time_Protocol meant. other PTP protocols exist, but Wastly less popular, as i can see)

I wasn't real sure what you were meaning by PTP, but I see that it's just an updated version of 1588. 1588 is fairly common.

yep. 1588v2 as most widely-used and efficient version of PTP.
and yes its "fairly common"(in fact - MORE than GPS sync in telco), but NOT supported by RouterOS aswell as GPS sync, yet.

What legal and political issues? Most equipment can use GPS and GLONASS.

you must be new to Telco(outside NA), then.
in many installations - both having Navstar enabled or even having GPS-enabled devices in infrastructure - is crime.
same ~ about GLONASS in NATO-controlled countries/regions.
its also somewhat not EMI-resistant much(atleast civilian channels) to be used in surprisingly big portion of installations.
so, no, GPS isn't "magic bullet" or even thing you can rely on. its simply to use(if you had support for or had Rights to use it), but its only advantage, which not worth it, basically, cuz 1588v2 imply same 10ns sync accuracy without all that headache.

thats why aside GPS sync and NTP is PTP introduced to fill gap between.
usually nodes in Telco - support Both GPS and PTP for obvious reasons. and control nodes and routers - rely on SNTP aswell.
(https://en.wikipedia.org/wiki/Precision_Time_Protocol meant. other PTP protocols exist, but Wastly less popular, as i can see)

I wasn't real sure what you were meaning by PTP, but I see that it's just an updated version of 1588. 1588 is fairly common.

yep. 1588v2 as most widely-used and efficient version of PTP.
and yes its "fairly common"(in fact - MORE than GPS sync in telco), but NOT supported by RouterOS aswell as GPS sync, yet.

What legal and political issues? Most equipment can use GPS and GLONASS.

you must be new to Telco(outside NA), then.
in many installations - both having Navstar enabled or even having GPS-enabled devices in infrastructure - is crime.
same ~ about GLONASS in NATO-controlled countries/regions.
its also somewhat not EMI-resistant much(atleast civilian channels) to be used in surprisingly big portion of installations.
so, no, GPS isn't "magic bullet" or even thing you can rely on. its simply to use(if you had support for or had Rights to use it), but its only advantage, which not worth it, basically, cuz 1588v2 imply same 10ns sync accuracy without all that headache.

If GPS in devices in your jurisdiction is a crime, I think you have bigger issues ahead of you than ROS. GPS and GLONASS are supported in most every mobile phone.

GPS\GLONASS is used fairly extensively in the mobile wireless infrastructure as well.

What legal and political issues? Most equipment can use GPS and GLONASS.

you must be new to Telco(outside NA), then.
in many installations - both having Navstar enabled or even having GPS-enabled devices in infrastructure - is crime.
same ~ about GLONASS in NATO-controlled countries/regions.
its also somewhat not EMI-resistant much(atleast civilian channels) to be used in surprisingly big portion of installations.
so, no, GPS isn't "magic bullet" or even thing you can rely on. its simply to use(if you had support for or had Rights to use it), but its only advantage, which not worth it, basically, cuz 1588v2 imply same 10ns sync accuracy without all that headache.

That's a stupid statement.
GPS is used in 80% of the world new cars, 100% of the worlds smartphones are using GPS, 99% of worldwide shipping uses GPS, there are hundreds of thousand GPS navigation devices sold of the last years.
Al in all I would guess a couple of billions of GPS equipped devices must be around on the globe, and you refer to a crime of using these? From what world are you?
I can travel to most countries in the world with my smart phone (Includig Russia and China for instance) and nobody asks me if my GPS enable smartphone has a license to use it...... So your comment in that respect to 'Hammy' is really weird....

Also; the statement the PTP protocol is use widely in wireless industry is a bold one. I'd gather ubnt is market leader in the WISP section but can't find no trace of it using PTP. They work with GPS sync.
I didn't go into looking other brands (MT is a small player but also no PTP, nor GPS.) but the PTP protocol isn't hardly so common as your statement would make the inocent to believe.

I think you must be new to Telco (world wide), then.....

then again, you must be new to telco.
anway, using (groundless/unbacked)"arguments" such as "anyone use/know", "for sure", "definitely", "of course", "unboubtely" is as useless as listening to them. you had opinions(but more like perception/expression from you Personal experience in lifetime, work), like most of us - do, but thats not change reality itself. sadly or luckily, nvm.
as for examples, some facts:
all Chinese and Russian telco and ISP, service providers - switched to using 1588v2 long ago(from GPS), same about notable part of middle east of ISP's and far east/pacific countries drifting toward "Chinese"style of 1588v2 adoption.
its include both RF links, fiber(including long-range), satcom and some other applications.
other companies(that include some of NA installations and other affiliates)dropped GPS sync use cause of EMI issues.
anyway, its pointless to argue with someone failing to accept that there is simpler solution with similar performance(despite smaller footprint/overhead both in terms of silicon or software/firmware)/accuracy, just because "he just desperately want something from vendor and and find best way to achieve that to promote/troll such features, aswell as bl other, more convenient option).
personally i wish you luck with Navstar usage, but similarly how how threat 1588v2, i give no fuck bout it, just like other Free World countries do.

The main question remains: is mikrotik planning to develope hardware with any kind of sync? If yes is it possible to know the developing status about this hardware?

Normis please give us an answer.

Thank you Giuseppe

can we're strip emotions or personan offences and talk bout topic and facts:
1588v2: no need for extra-silicon, simpler code, no IP and political issues, less "blackboxed" things in solution
gps sync: "simplicity" (ony When/IF someone invest TREMENDOUS efforts into implementing support of it)
same 10ns accuracy, same usage, comparable adoption(some sites - used both).
so far, all BTS/base stations, fiber backbone, p2p and p2mp RF links - used 1588v2 as far as i can see, including those with GPS-sync enabled hardware and firmware and disabled GPS sync.
you opinions - maybe differ from mine aswell as experience, but thats not give you "supernatural" and exclusive ability/super-power to both opress others or dictate/manipulat mikrotik devlopers about their priorities and roadmap.
if you like - mikrotik products - fine. if you don't - there is plenty of other vendors on market.
you had you opinion, you shared it, you heard. and even had feedback(sometimes "nicer" than mine and less polar), but there is NO need(in my opinion) to out-cru/shot about again and again and again, trolling others.

can we're strip emotions or personan offences and talk bout topic and facts:
1588v2: no need for extra-silicon, simpler code, no IP and political issues, less "blackboxed" things in solution
gps sync: "simplicity" (ony When/IF someone invest TREMENDOUS efforts into implementing support of it)
same 10ns accuracy, same usage, comparable adoption(some sites - used both).
so far, all BTS/base stations, fiber backbone, p2p and p2mp RF links - used 1588v2 as far as i can see, including those with GPS-sync enabled hardware and firmware and disabled GPS sync.
you opinions - maybe differ from mine aswell as experience, but thats not give you "supernatural" and exclusive ability/super-power to both opress others or dictate/manipulat mikrotik devlopers about their priorities and roadmap.
if you like - mikrotik products - fine. if you don't - there is plenty of other vendors on market.
you had you opinion, you shared it, you heard. and even had feedback(sometimes "nicer" than mine and less polar), but there is NO need(in my opinion) to out-cru/shot about again and again and again, trolling others.

Still more emotions that facts......

can we're strip emotions or personan offences and talk bout topic and facts:
1588v2: no need for extra-silicon, simpler code, no IP and political issues, less "blackboxed" things in solution
gps sync: "simplicity" (ony When/IF someone invest TREMENDOUS efforts into implementing support of it)
same 10ns accuracy, same usage, comparable adoption(some sites - used both).
so far, all BTS/base stations, fiber backbone, p2p and p2mp RF links - used 1588v2 as far as i can see, including those with GPS-sync enabled hardware and firmware and disabled GPS sync.
you opinions - maybe differ from mine aswell as experience, but thats not give you "supernatural" and exclusive ability/super-power to both opress others or dictate/manipulat mikrotik devlopers about their priorities and roadmap.
if you like - mikrotik products - fine. if you don't - there is plenty of other vendors on market.
you had you opinion, you shared it, you heard. and even had feedback(sometimes "nicer" than mine and less polar), but there is NO need(in my opinion) to out-cru/shot about again and again and again, trolling others.

Still more emotions that facts......

The whole thread is based on ... nothing. MT never did GPS and never built a radio. UBNT hired a crew of radio experts from Motorola to do this radio. It is far superior to standard WiFi based radios. You get most out of small channels and it performs very good with other radios near by as it has better neighboring channel rejection.

UBNT hired a crew of radio experts from Motorola to do this radio. It is far superior to standard WiFi based radios. You get most out of small channels and it performs very good with other radios near by as it has better neighboring channel rejection.

To what are you actually referring? A specific radio? Or just their radios in general? And what is the connection to the sync issue in making this last remark?

UBNT first tried GPS sync on their AirMax radios and failed. They hired away some of the Motorola crew and got GPS sync right with their AirFiber line.

Cambium does GPS sync on Atheros chips as does Radwin. I know others have as well. Mimosa is doing it with Quantenna chips.

UBNT hired a crew of radio experts from Motorola to do this radio. It is far superior to standard WiFi based radios. You get most out of small channels and it performs very good with other radios near by as it has better neighboring channel rejection.

To what are you actually referring? A specific radio? Or just their radios in general? And what is the connection to the sync issue in making this last remark?

Airfiber as said in $subject. The other radios are atheros based.

UBNT first tried GPS sync on their AirMax radios and failed. They hired away some of the Motorola crew and got GPS sync right with their AirFiber line.

Cambium does GPS sync on Atheros chips as does Radwin. I know others have as well. Mimosa is doing it with Quantenna chips.

thats basically all of them, enumerated, plus portion of cellphone infrastructure gear/stations manufacturers.
so as you can see "GPS sync" isn't "magic bullet", or widely-adopted in telco/it.

UBNT first tried GPS sync on their AirMax radios and failed. They hired away some of the Motorola crew and got GPS sync right with their AirFiber line.

Cambium does GPS sync on Atheros chips as does Radwin. I know others have as well. Mimosa is doing it with Quantenna chips.

thats basically all of them, enumerated, plus portion of cellphone infrastructure gear/stations manufacturers.
so as you can see "GPS sync" isn't "magic bullet", or widely-adopted in telco/it.

That's an awfully large percent of units shipped in our industry.

UBNT first tried GPS sync on their AirMax radios and failed. They hired away some of the Motorola crew and got GPS sync right with their AirFiber line.

Cambium does GPS sync on Atheros chips as does Radwin. I know others have as well. Mimosa is doing it with Quantenna chips.

thats basically all of them, enumerated, plus portion of cellphone infrastructure gear/stations manufacturers.
so as you can see "GPS sync" isn't "magic bullet", or widely-adopted in telco/it.

That's an awfully large percent of units shipped in our industry.

how much "afwully large" was translated to "common people's math" ?
"7%"? "12%"? i don't think its bigger than 20%. ~avg
and several GPSsyn-enabled/aware devices/solutions - installed/used without it as i explained above/before for reasons told before aswell and some others.

thats basically all of them, enumerated, plus portion of cellphone infrastructure gear/stations manufacturers.
so as you can see "GPS sync" isn't "magic bullet", or widely-adopted in telco/it.

That's an awfully large percent of units shipped in our industry.

how much "afwully large" was translated to "common people's math" ?
"7%"? "12%"? i don't think its bigger than 20%. ~avg
and several GPSsyn-enabled/aware devices/solutions - installed/used without it as i explained above/before for reasons told before aswell and some others.

I would guess well over a third, possibly even a half.

However, I'm done with this GPS vs. 1588 thing.... it's taking away from the core issue of Mikrotik not having sync.

However, I'm done with this GPS vs. 1588 thing.... it's taking away from the core issue of Mikrotik not having sync.

Besides, it is not even true. PTP (1588) is only a way to distribute time sync over ethernet, and those installations
contain a reference clock that itself is usually synchronized to GPS. So you can call a PTP installation GPS synced as well,
PTP is only a distribution mechanism not a synchronization source. Similar to a distributed PPS line.

I think in this tread we have some confusion amongst some of us.
Let me explain.
In fact, we have different timings happening on radio network to what is our objective:
1. Ordinary time. Useful for log registers and schedulers, scripts etc. As long as there is a clock in a device it is nice it would reflect the time we see on our watch! Special in troubleshooting its handy that you can compare different units on a time base to see what happened. Accuracy needed is seconds....
2. Send/Receive timing in ordinary 802.11 networks. The RTS/CTS protocol. A very rudimentary timing sync for nodes in a network. The nodes have to negotiate amongst each other whose turn it is to speak/listen. No real time needed, not a real timing sync.
3. Send/Receive timing in TDM (tdma or airmax or nv2 etc.) networks. Here an AP sets a send/receive schedule for itself and each connected node. This way the 'hidden node' issue is avoided and better use of the spectrum capacity can be made by separating each node's sending or receiving from the others. "One after the other gets his turn". It becomes important that nodes in a network become synchronized but the (proprietarily) protocol guarantees such. We have a master-slave network where the master depicts when and how long the client can send or receive, each at its assigned time.
4. Send/Receive timing in multi AP networks where frequency or interference avoidance is needed. By having all radio's on a tower that work in the same frequency band sending and receiving at the same time we reduce (up to elimination) interference between radio's in the same tower. Off course we need some master clock that now has to be connected to each of the other units to give a 'zero' ("Z") time signal and the difference to it very precisely. Even after long time all connected units must still run in the same sync. Hence the update of "Z" that can happen at an almost continuously basis.
It now becomes possible on a same tower to use several radios working on the same frequency but in different direction to serve different distant nodes. We need less spectrum and the overall quality of the network (clearer signal) also goes up! Win-win...? No;
There is one side effect; In tdma networks we have several options;
a. Variable, but fixed, time slots. Depending on the latency versus throughput and distance of node we have to set a certain length of the time slots. So they can be different for different AP/BH radio's.
b. Variable adapted times slots. If have seen some examples of technologies where the time slot actually can get change upon need of the network.
If we want a tower to be fully sync, all radio's need to adept to the same scheme. And since the radio that for whatever reason needs the longest time slot it predicts the sync for all others The overall outcome might be that for some PtMP networks (or PtP) the latency goes up (a bit...)

5. Send/Receive timing in multi AP/multi tower networks. For same reasons as 4. we might want to sync even between towers. If all AP's in a region would transmit at the same time clients that receive signals from different AP's will benefit.
This will have a new complication. If these towers are interconnected with radio backhauls in the same radio band and taking part in one of the tower’s sync it automatically will be in counter sync on the other tower.
To solve this, we can start working with ABAB sync over radio backhaul towers but if all these towers have AP's and in between them are clients that can 'hare' two or more the risk is now a client becomes in full counter-sync with some other AP network. If clients are now in close proximity but one connects to tower 'A' and the other to 'B' they could start interfering with each other, special if the frequencies are the same or close.
To arrange such a network properly becomes a complicated task.

1. a simple clock will do, each unit on its own a time stamp from the NTP protocol is sufficient.
2. no clock is needed. Abait that the radio itself creates some time related energy pulses (the frequency) nothing more is needed.
3. A precise clock is needed to sustain a coherent time slot with a protocol that guarantees all nodes are in sync with the master (AP). Since each clock can vary in speed each node also needs to be continuously updated by the master. The tda protocol takes care of that. This could also be done by GPS or the 1588 protocol but since actual time is not needed, only sync, the tda is good enough and doesn't need any further hardware. (I don't know if the 1588v2 is better or worse than tda but since most vendors are still developing or using any form of tda I presume it’s a winner...)
4. To sync between different hardware devices there need to be some interconnectivity between units on the tower with one master. This master not only needs to set a "z" hour time stamp to each unit, it also needs to update it continuously to guarantee all units stay in sync. At the same time, it also needs to override each radio's own tda settings. Since all tda's timeslots on all radio's need to have the same length and therefore start/stop this very important.
To transport the sync, signal a protocol like 1588v2 can be used or any other proprietary. The master is best equipped with a very precise clock and since usually only one master is needed, and a radio that sits on a tower usually also 'sees' several satellites a GPS sync'd clock seems to be the best way to go. (And most vendors do so... Other earlier mentioned GPS 'issues' are virtually of no importance.)
5. If we now also need to sync between towers we have to guarantee the time stamps and hour "Z" are the same on both. We can do that with the 1588v2 protocol but if the towers are only interconnected by radio backhauls it might be more reliable to only transport the start cycle and the tda scheme to be used to send over the radio where the actually timing than is done by a GPS updated clock that guarantees that the time cycles between towers are of the same length.
(GPS is now probably more reliable than 1588v2 because the radio link can be interfered o hammered by all kinds of issues that if towers would be dependent on this sync only would make a mess a soon as packages get distorted, corrupted or delayed. The change two GPS clock in relative close proximity are going to run out of sync of each other is very, very small...)

Bottom line is; Sync within a tower, or between towers, is a spectrum saver and will also benefit the overall quality of the network but isn't the holy grail on itself. Imho several technologies are needed in combination to fight nowadays challenges to make and keep a good network running. That GPS is a tool of choice to sync AP’s and towers can be seen by the many vendors that are using it or are preparing their hardware to do so.

However, I'm done with this GPS vs. 1588 thing.... it's taking away from the core issue of Mikrotik not having sync.

Besides, it is not even true. PTP (1588) is only a way to distribute time sync over ethernet, and those installations
contain a reference clock that itself is usually synchronized to GPS. So you can call a PTP installation GPS synced as well,
PTP is only a distribution mechanism not a synchronization source. Similar to a distributed PPS line.

yep. regardles how its carried - over fiber, copper, RF or open air lazer links - its "just works".
similarly GPS/Navstar is "distribution mechanism" and their atom clocks(still less accurate than Galileo or GLONASS had) and sofware - ARE Source.
but thats my point actually: with PTP support - anyone SO "desperately wanting" GPS syn usage for their (respected)reasons - can simply plug ting/inexpensive device into Mikrotik and have their GPS syn working,without reshuffling and doing lot of work on HW and FW lefls by MT team.

as for "practical side" of question/suggestion: one of MikroTik partners, Qualcomm - one of biggest supplier of cellphones infrastructure components(or even complete solutions, made from) and most of base station chipsets, they supply(as well as stations itself)support all 3 kind/networks of satellite sync. same apply to relevant part of SDK(which isn't part of Atheros stuff, MT may be familar with, i fear).
so talking from implementation side - it wouldn't be big deal for them and long time ago. but apparently they consider it redundant (or simply filter-out cause "cost/profit"ration(in both sense of)), maybe.
as you can noticed, perhaps - there Already "GPS" package in RouterOS, and aside positioning - it HAD support time sync aswell.
so i think whole topic kind redundant, thus(no offense !), caze anyone wanting syncing - would Already have plugged GPS receiver and configured dat package to working state.
maybe im wrong, of course. anyone can.

Just to add some ideas / reading :

http://www.ieee802.org/3/time_adhoc/pub ... 1_0509.pdf

Just to add some ideas / reading :

http://www.ieee802.org/3/time_adhoc/pub ... 1_0509.pdf

thats quite short and quite old article which despite highlight basic issues and conclusions about sync and PTP, referenced only for obsolete version of 802.1AS and PTP IEEE 1588v1. IEEE1588v2 had Much better parformance and had Resolved most of issues restricted its usage as main PTP for both 3G, LTE and 5g networks aswell as long-link fiber and open air laser links
original IEEE1588 was dated 2002, updated/improved IEEE1588v2 was standartidised in 2008, ie ~ only year before this paper released and not really widely-adopted at time of reserarch apparently, but quite common/standard thing nowdays.
https://en.wikipedia.org/wiki/Precision_Time_Protocol
there several 'grades' of precision/sync and different kind of protocols established for different purposes of in result. for most basic needs there was NTP, SNTP, then PTP derrivatives and for "science-grade" sync there several more obscure protocols, most of which never really standartdised or interoperable with counterpart(most never adopted outside country or even outside particular company/lab).
IEEE1588 aside data telecom- used in medical equiment, in broadcasting(not only in SMPTE), in commodities manufacturign and whatever else you need time(ie anywhere).
similarly - most popular IEEE1588-related articles - refering ot obsoleted IEEE1588v1 version of it, like this NI page for example http://www.ni.com/newsletter/50130/en/
IEEE1588v2 had Much better performance, again.
so far 10ns accuracy seems more than enough even for long links in my opinion.

We waited a really long time for synchronization... now we are planning to build new areas with ubnt radios and mikrotik routers. We tried a lot and ubnt just works better in noisy enviroment. It is somehow funny.... when ubnt started we told ourselves that we dont want to use cheap hardware. Situation has somehow changed... ubnt no longer cheap but mikrotik is...

We waited a really long time for synchronization... now we are planning to build new areas with ubnt radios and mikrotik routers. We tried a lot and ubnt just works better in noisy enviroment. It is somehow funny.... when ubnt started we told ourselves that we dont want to use cheap hardware. Situation has somehow changed... ubnt no longer cheap but mikrotik is...