Community discussions

MikroTik App
 
Frizz
just joined
Topic Author
Posts: 6
Joined: Wed Mar 07, 2007 1:04 am

GPS wireless sync

Wed Mar 21, 2007 1:10 pm

here come some early replies to your requests:
GPS Wireless Sync


not possible at all, special professional grade hardware is needed. the GPSes that attach to serial port have precision of ~1 sec. The special hardware device will have ~40uSec.

The gps hardware that works with Motorola canopy or Skypilot gear does not look that special at all....

I do understand gps sync is quite hard to implement with a polling protocol instead of a time slotted one.

But what about implementing the capability of receiving on a channel and trasmitting on another that would achive the same result of gps sync but is a lot easier to implement?



What I'm talking about here it is not receiving and trasmitting on a channel at the same time (that of course is not possible with only one card); It is about quickly changing the channel before trasmitting while listening all the time on the receiving channel.

Depending on the atheros driver this could be quite easy to implement and would have the same benefits of gps sync that is:
eliminating colocation interference and allowing channel reuse
this is something wisps very badly need to scale and support hundreds of subscribers on a single site.

Please check out this post for further explanation:
http://forum.mikrotik.com//viewtopic.php?t=14337
 
User avatar
stephenpatrick
Forum Veteran
Forum Veteran
Posts: 702
Joined: Fri Aug 20, 2004 12:26 pm
Location: UK
Contact:

Wed Mar 21, 2007 7:08 pm

AFAIK there are 2 areas where GPS sync useful

- within base site: all sector antennas transmit at once - improves frequency reuse and avoids interference between antennas

- between base sites: adjacent base sites sync so they transmit at the same time, again avoiding interference between them.

GPS-sync is used in GSM/3G base stations as well as WiMax now for exactly these reasons - particularly between base sites.

Comments welcome -

Regards

CableFree Solutions
 
believewireless
Member Candidate
Member Candidate
Posts: 231
Joined: Wed Jul 06, 2005 6:30 pm

Thu Mar 22, 2007 10:26 pm

A 1 sec GPS sync is fine. It is used to kept time drift from happening and sync sites in distant locations.

It is used to sync up the clock on the motherboard with the GPS signal to ensure the time has drifted in the past second.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26322
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Fri Mar 23, 2007 9:03 am

why can't you just use NTP?
 
User avatar
stephenpatrick
Forum Veteran
Forum Veteran
Posts: 702
Joined: Fri Aug 20, 2004 12:26 pm
Location: UK
Contact:

Fri Mar 23, 2007 1:20 pm

A 1 sec GPS sync is fine.
That's "GPS router clock sync", not "GPS wireless sync".
As normis says, NTP = simplest/cheapest.

IMHO the discussion on GPS wireless sync is the most interesting technically and the main thread "beta feature request" has some great comments so far.

Regards

CableFree Solutions
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26322
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Fri Mar 23, 2007 1:24 pm

besides, time syncing with GPS is already supported:
http://www.mikrotik.com/testdocs/ros/2.9/system/gps.php

we are talking about wireless sync
 
nuclearcat
Member Candidate
Member Candidate
Posts: 115
Joined: Fri Jun 02, 2006 1:52 pm

Fri Mar 23, 2007 4:35 pm

I guess, for proper GPS Sync also it will need not Atheros zoo (each card have own bugs, specs and etc), if will need specially designed SoC, where is everything inside. I dont think it will be possible on known miniPCI hardware...
 
User avatar
stephenpatrick
Forum Veteran
Forum Veteran
Posts: 702
Joined: Fri Aug 20, 2004 12:26 pm
Location: UK
Contact:

Fri Mar 23, 2007 7:05 pm

IMHO that needs looking at a little more closely:
If this is implemented, a few sensible assumptions
- use cards all from the same vendor/type - not a mix/match
- airside settings on each radio are similar or the same (modulation rate)
- radios are on a common PCI bus - variants of the PCI bus clock at 33, 66 and now 133MHz
http://en.wikipedia.org/wiki/PCI_bus
so that if say 3-4 radios are told in software to "transmit" at a given instant, that command can be issued to the radios within say a microsecond it would be "near synchronous" enough to make this work.
In such systems there are normally "guard times" where neither end of the link is supposed to transmit, to allow for small discrepancies like this.

I think the raw technology does exist; highly likely that miniPCI atheros cards on a shared PCI bus can be made near-synchronous in TX timing; probably down to the MT developers to work out how to read the GPS time accurately from the module, and then tweak the Nstreme/radio drivers to send fixed-length frames in strict "send - receive" timeslots.
And no doubt if it can be made to work well, the results worth the effort.

Hope some of that's some use -

Regards

CableFree Solutions
 
nuclearcat
Member Candidate
Member Candidate
Posts: 115
Joined: Fri Jun 02, 2006 1:52 pm

Fri Mar 23, 2007 7:22 pm

First thing as i heard, from RF engineers, frequency synthesizer even is unstable(drifting depends on voltage and temperature), and some of them changing it to some much more expensive component, and thats give miracle results. Info unconfirmed, but looks like that it correct.

This is just cheap miniPCI wireless cards, do not expect from them precision, which is required to use high precision timing technologies.

Even you use same hardware, voltage and temperature can be different.
 
User avatar
stephenpatrick
Forum Veteran
Forum Veteran
Posts: 702
Joined: Fri Aug 20, 2004 12:26 pm
Location: UK
Contact:

Fri Mar 23, 2007 10:55 pm

Those are all relevant points - cheap "CM9 clones" or worse would be a bad choice for a system expecting any precision.
I'd assume that high quality cards, such as the latest Ubiquity ones would be used at the base stations.

That being said, other GPS-sync'd systems like MOTO canopy aren't exactly expensive devices -
Interesting topics. I guess any effects like these would be found out on a prototype GPS-sync'd setup if/when it's put together ...

Regards

CableFree Solutions
 
nuclearcat
Member Candidate
Member Candidate
Posts: 115
Joined: Fri Jun 02, 2006 1:52 pm

Sat Mar 24, 2007 3:37 am

All of them IMHO use cheap quartz oscillator(cheap cards and expensive cards).

Maybe GPS can be possible with (sure on wireless card):
http://en.wikipedia.org/wiki/OCXO
and smth called TCXO.
http://www.meinberg.de/english/specs/gpsopt.htm
By the way in GPS they use them, u can see that on link.

As i know, Ubiquiti support person sometimes visiting this forum, maybe this company have to try to make sample card with OCXO/TCXO (if that possible). There is rumours, it will help a lot with PtMP setups.
 
TomKolb
newbie
Posts: 32
Joined: Thu Jul 14, 2005 3:51 am

Quality GPS equipment

Fri Apr 13, 2007 6:58 pm

We use a lot of Canopy gear that we GPS sync with 3rg party GPS receiver hardware. It comes from a great company called PacketFlux at http://www.packetflux.com/ that costs 139.95. I bet these guys could provide the hardware design if Mikrotik can find a way to utilize it.
 
User avatar
jp
Long time Member
Long time Member
Posts: 609
Joined: Wed Mar 02, 2005 5:06 am
Location: Maine
Contact:

Sun Apr 15, 2007 4:28 am

Maybe it would be easier for MT to have a "packetflux port" to utilize the hardware moto and it's third party competitors have already tested and standardized on. "packetflux port" is pretty sexy sounding.
 
User avatar
nest
Forum Veteran
Forum Veteran
Posts: 822
Joined: Tue Feb 27, 2007 1:52 am
Location: UK
Contact:

Sun Apr 15, 2007 3:26 pm

The cheap WiFi cards may use poorly designed / cheap oscillators that drift like anything dependent on temperature and some unknown random factor like the phase of the moon :roll: , but that will surely only control the Transmit and recieve frequency? (I'm more of an RF Engineer than a software/hardware one so feel free to shoot me down)

IMHO what is more important is can a card be told to transmit at a certain instance in time, and in which case how long after that "transmit now" data command does it actually do it? If the card has a known but fixed lag time from command to actual transmit, that can be calibrated out so that all the cards all transmit at exactly the same time. If the specific card transmits whenever they feel like it (and that time period constantly varies due to some problem with their design), I can't see how you calibrate that out! :-(

Obviously using good quality cards of same make/model/batch all help to ensure the lag time is near identical, but even so, a calibrate value could be introduced?

The downside then is you are now having to devote ever more processing time to making the OS hit the cards with the "transmit now" command at the right time, whilst the OS is also doing other stuff. You now have a requirement for demanding the highest interrupt priority.

If you are talking about the Routerboards, I guess this would be easier to control. If you're talking about using a PC, good luck!!

I have been involved in the past with the design of a software package that required highly accurate timing on a PC running DOS and we used the highest priority interrupt on the PC to control this, but found that many bad implementations of LSI Chipsets got the original IBM Specification wrong and so the timing was always impossible to set correctly, even though they ran other software fine. (As the other software like Windows did not need such granular control over accurate timing)

We also had to add a calibrate value to correct timing errors as the motherboard oscillators were cheap and terrible. In the end, we had to go over to using an external ATA board we designed and made in-house which had it's own oscillator and WAS accurate. More expensive solution, but at least it was reliable and worked in the end.

GPS-Sync is an excellent feature set to aim for. So good luck with this!

Who is online

Users browsing this forum: orionren and 68 guests