How have we implemented quasi-sync?
For the astute of you who are either familiar with quasi-sync, or have read the document referenced to within the "What is quasi-sync" page, you will realise that it recommends no more than 3-5 miles of equi-signal overlap area, otherwise the precise timing requirements cannot be met. You will have realised that both transmitter sites are some 55 miles apart, so the equi-signal overlap zone is likely to be massive.
What we must make clear however is that this is not intended to be a "perfect commercial grade" implementation of quasi-sync. There will be areas within which there is simply unusable mush, either due to insufficient signal strengths or due to vast timing difficulties. These are expected to be mainly around the Ashby/Swadlincote areas.
Within these areas however it is hoped that the undulating terrain will mean that the likelihood of the two signals being within 6dB of each other is very low, and computer simulations have confirmed this. Furthermore we do not intend to transmit CTCSS or any other such signalling which would exasperate the situation.
We therefore feel that the effects will be tolerable, and the varying nature of mobile communications means that even if a small patch of equi-signal is found, it will rapidly be passed.
Once this is on air then we can optimise these parameters by adjusting the fixed delay in one of the transmitters, to move the equi-time signal closer or further away from one or the other transmitter. We also can use directional aerials if needed to reduce the equi-signal area, or could simply seek to install a further transmitter/receiver at another site if required at a later date.
----
The audio from the receiver will be passed to a dsPIC, connected to a 1PPS GPS timing reference and 1mhz frequency reference. These references will be used to lock the sample rate of the ADC/DAC to exactly 48000hz, and be used to timestamp each outgoing audio packet. The receive audio packets will then have the instantaneous RSSI appended, and then sent onto the central server for processing. There could be, in theory, an infinite number of receivers, enhancing handportable reception in locations such as radio clubs, individual houses, areas of poor reception, etc, etc.
The central server will then correlate the timestamps received, then "validate" the signal by confirming the presence of valid CTCSS, and finally make a packet-by-packet voting decision, with a degree of hysterisis (3dB, to be optimised later) to avoid rapid changing. In case of change of audio stream, the old and new streams will be cross-faded to give a reasonably seamless transition, so there is not an abrupt change in background noise levels.
The output audio stream (complete with timestamps) will then be fed back to the transmitter sites (again, in theory, there could be additional transmitter sites at a later date). The transmitter site will then synchronise the output packets, with a carefully defined fixed delay (initially set at approx 200ms), which can be changed on a per-site basis in approximately 20.8uS increments or decrements, then the audio will be sent to the transmitter.
Each transmitter will be GPS synchronised in frequency using an external 10mhz (frequency adjustable in 0.1hz steps) source from the GPS receiver, giving exact time and frequency reference. Furthermore the DDS synthesizer will be carefully calibrated with the source audio, to give a deviation mismatch of less than 1hz at peak deviation.
The frequency offset of each transmitter will be carefully changed in order to avoid protracted periods of destructive standing waves for stationary reception, such as at traffic lights, for fixed base reception or other similar scenarios.
----
As can be seen, this is a considerably simpler approach than taken in past years, and this exact method and equipment has already been tested and proven on commercial radio systems.
Furthermore it is possible in the future for more transmitter and/or receiver stations to join in the network, thereby extending/infilling the coverage. Should any adjacent groups with an existing 2m repeater that is under-used be particularly interested in this project, the channel we are using is reasonably clear so that other repeaters could easily join the network.
Due to the data being timestamped and transferred via IP, any reliable connection, even an ADSL connection, could be used to interconnect the sites, since actual latency and jitter characteristics are irrelevant, as long as the end to end delay is less than the fixed delay (initially set at 200ms). 99% of IP circuits should meet these characteristics.
