The system as it stands right now consists of two sites Fremont Peak and Presson Hill. Both operate on the same frequency pair.
147.180 + PL 94.8
This week was historic for the Salinas Valley Repeater Group, on Thursday 9/24/2026 we put our first simulcast system on the air! Over the last 7 years, I’ve been wanting to convert SVRG’s linked system to simulcast. But why simulcast you ask? These systems are hard to build, maintain, and are complex to design. Well let me list out some of the advantages and disadvantages of a simulcast system and you’ll see why I’ve wanted to bring an open VHF simulcast system to the amateur radio community.
Seamless coverage – users experience better coverage as they move between repeater sites, since all sites transmit the same signal at the same time
Single frequency – no need to program or scan multiple frequencies/channels for the same system, simplifying radio programming and user operation
Simpler user experience – users just talk; there’s no need to select a specific repeater, figure out what channel to be on and understand which site they’re nearest
Efficient spectrum use– Allows SVRG to reduce its spectral footprint and free up repeater pairs in the already frequency congested greater bay area.
That being said there are some Trade-offs worth knowing:
Simulcast requires precise engineering (GPS timing, phase alignment studies, link reliability) and is more complex/costly to design and maintain
Linked repeaters (voted or non-simulcast linked) systems are generally simpler and cheaper to deploy, more forgiving
Linked systems can be easier to expand incrementally site-by-site
All that said, the goal was set. Simulcast was the path forward for SVRG, but how would it be built? Our first experiments were with the Motorola DSM-II T1 based simulcast system developed in the 90’s. After building a test system of 3 sites and mulling over the installation requirements, rackspace constraints, T1 circuit emulation TDMoP, 48v DC power systems. It became quickly apparent that a DSM-II based simulcast system would not be feasible for the system we wanted to build.
So where do we go from here?
DSM-II is off the table, so I started to look into the Motorola MLC-8000 and Micro-Node RTCM. The MLC-8000 requires a 5Mhz 1PPS composite signal that the TRAK-9100 produces (very costly) and the Micro-Node RTCM requires hardware modification to use for simulcast as it requires a 9.6MHz non standard clock, so that’s out too.
Our solution was to design our own simulcast hardware! Dub’d the SV-180, our simulcast board connects to ASL3’s linking and voting platform like the RTCM. More to come on that in another post.
What are our future plans for SVRG and its simulcast system?
As of right now our plan is to convert all VHF systems to simulcast on 1 frequency pair (excluding Meadow lakes VHF). This in and of itself is going to be a bigger challenge to work out than the engineering required to design our own simulcast controller and build out a system over multiple counties.
Due to the frequency congestion on the VHF band in our area and with our plan being very aggressive, coupled with the fact that there is no perfect frequency pair for us to land on. We ask for understanding that while we continue to test and develop this repeater system.
In the last post I said I’d tell you more about the SV-180.
Most AllStarLink voted and simulcast systems run on the VOTER board Jim Dixon designed around 2011, or the RTCM, its production version from Micro-Node. It was a good design for its day and it’s still very good at what the name says: voting, which is picking the best of several receivers. Simulcast transmit is a harder job, and the RTCM was never really built for it.
The audio timing comes from the board’s own quartz crystal. GPS checks that clock once a second, and if it has drifted too far the board drops sync, but nothing steers it back onto frequency. AllStarLink’s simulcast guide says a transmit board must be fed an external GPS-locked 9.6 MHz signal, and warns that the internal clock’s jitter can make the PL tone warble.
It’s 2011 hardware: a 16-bit microcontroller with 16 KB of memory and 10 Mb/s Ethernet. You set it up from a text menu over telnet or a serial cable. There’s no web page and no encryption.
What we could do with newer parts and a fresh design
Starting over with a modern processor let me fix those issues and build somthing that better fits our needs.
The whole audio clock tree is built from the GPS reference’s 10 MHz, so the boards audio clock tree runs at exactly 8,000 samples a second.
Everything is on a web page: live status, settings and an event log. There are setup wizards for receive level, transmit deviation and RSSI calibration. You update the firmware from the browser, and the board keeps the old version in case the new one doesn’t work out.
WireGuard is built in, so audio and management traffic are both encrypted.
It reads status from the site’s GPS reference (several common models work), and it can pass a serial port through to the network so you can manage other equipment at the site remotely.
Support for an internal GPSDO.
The SV-180 back panel: timing connections, GPS antenna, 12 V power, the radio connector and Ethernet.
What the SV-180 does
There’s one SV-180 at each transmitter site, sitting between the network and the radio. The ASL3 server sends audio to every site as a stream of packets. The SV-180 doesn’t play a packet the moment it shows up. It buffers it, times it, then launches the audio at an exact moment set by GPS time. Every site does the same thing, so every site transmits in phase at the same instant. The board has two audio buffers one is for a jitter buffer, the other is our launch delay value, settable in 5 ns increments.
It also listens to the repeater’s receive audio and squelch signal, and a DSP routine measures the signal-to-noise ratio of whoever is talking and sends that value to the voter to select the best signal.
The server sends audio to every site over the microwave / IP network. At each site, GPS gives the SV-180 a 10 MHz and 1PPS reference, so all the repeaters transmit in phase.
How the timing works
Any IP network has jitter, whether it runs over microwave or fiber. Packets take a different amount of time every trip, and sometimes they show up in bursts. If each site played audio the instant it arrived, no two sites would ever line up and the repeater would sound like a box of angry bees.
So the SV-180 keeps when audio arrives separate from when audio plays. A small buffer soaks up the network’s hiccups, and the audio then plays out against the site’s GPS clock. A GPS-disciplined oscillator uses the satellite timing signals to keep a local oscillator extremely accurate, and it hands the SV-180 two things: a very stable 10 MHz and a pulse once per second. With those, a unit on one mountaintop and a unit on another agree on the time without ever talking to each other.
How close is close enough? On the bench, two SV-180s fed from the same GPS reference lined up to within a nanosecond.
From prototype to production
The first SV-180 firmware ran in July 2026, and the hardware has been through three revisions since.
Rev A was the first prototype: a carrier board for an off-the-shelf processor module, with our audio, GPS and radio circuits around it. All it had to do was prove the idea could work.
Rev B took what I learned on A and put it into a second board, still built around the plug-in module. I hand-assembled five of them and validated them in early September. Two went to Fremont Peak and Presson Hill for real-world testing while I designed and finalized rev C.
Rev C is the first production board. The plug-in module is gone, the processor and Ethernet are part of the board itself, and the boards are now machine-assembled. The first C1 was running in October and matched the timing of the B1. Rev C boards have since replaced the rev B boards in the field.
Inside an SV-180: the rev C board, with the GPS timing module.
Writing firmware for a board nobody has built
When the board is brand new and something doesn’t work, you can’t tell whether the bug is in the code or in the copper. This was my first real venture into hardware engineering, and I learned that early. Luckily most of my problems turned out to be in the code. There were a few small mistakes in the codec circuit on rev A that could have caused a codec failure!
Putting several transmitters on one frequency on purpose means managing interference instead of avoiding it. This post touches on the theory behind simulcast, and how coverage and timing are tuned in a real system.
Simulcast is controlled interference
Every mobile radio already deals with interference from its own signal. At a single site, the signal reaches the radio by a direct path and also by reflections off buildings and terrain. The reflected copies arrive a little later and at a different strength. This is ordinary multipath, and receivers handle it every day.
Simulcast adds more of the same. A second site on the same frequency is, from the radio’s point of view, one more source of “reflections”: its direct path and its own reflections all land on top of the first site’s. This is co-channel multipath interference. The job of simulcast design is to keep that interference under control, so that where two sites overlap the radio still recovers clean audio or data.
What the receiver does with it
A receiver amplifies what arrives at its antenna, mixes it down to an intermediate frequency, and demodulates it. When two or more signals are on, or very nearly on, the same frequency, they go through the mixer together and come out combined. Distortion is added along the way. What the radio finally produces depends on how its demodulator handles that combined signal. Everything else in simulcast design exists to make sure that combination still demodulates cleanly.
Carrier frequency and phase
A mixer produces the sum and the difference of the signals fed into it. Put two transmitters at 147.000000 MHz and 147.000001 MHz, only 1 Hz apart, and the receiver sees a 1 Hz difference product. That is heard as a rolling fade, sometimes called “mobile flutter”.
Being frequency-locked is not the same as being phase-locked. To a receiver, a small change in phase looks just like a change in frequency, so a slow phase drift between sites also shows up as a rolling fade, and there is little that can be done about it at the receiver.
Hear this your self
You can reproduce the effect on a bench with two audio signal generators. Set one to 440 Hz and the other to 441 Hz at the same level, and mix them into a single speaker. The combined tone swells and fades once per second, because the two waves drift in and out of step, adding together and then cancelling. The beat rate is simply the difference between the two frequencies. Two carriers at 147.000000 and 147.000001 MHz beat at the same 1 Hz as the two tones.
This analogy has a limit. In the radio the beat happens to the RF carrier, before the audio is recovered. An FM receiver ignores changes in signal level, so the listener doesn’t hear a smooth swell. They hear the audio flutter and break into noise each time the two carriers cancel. Try turning one generator down: the fade becomes shallower. That is the capture effect at work, as described below. When one signal is much stronger than the other, the weaker one can barely pull it down.
Note: the demo needs both tones summed into one speaker or one channel, not one tone in each ear.
Audio timing: the 30-degree rule
The decoded audio from each transmitter has to reach the radio within 30 degrees of phase of each other. Turning that into a time depends on the audio frequency. Using 1,000 Hz as the reference:
360° ÷ 30° = 12, so the budget is one twelfth of a cycle.
A 1,000 Hz tone has a 1 ms period.
1 ms ÷ 12 ≈ 83 µs.
Audio frequency
Period
30° timing budget
200 Hz
5 ms
420 µs
1,000 Hz
1 ms
83 µs
2,000 Hz
0.5 ms
42 µs
The higher the audio frequency, the tighter the budget.
The same effect applies to data. For digital modulations, the limit is expressed as delay spread, and refers to the bit-error-rate versus delay-spread curves in TIA TSB-88. These show the error rate climbing as the delay spread between sites increases, with some modulations tolerating much more spread than others.
Capture effect and overlap
An FM detector will capture the stronger of two signals when their levels are different enough. It locks onto the stronger one and largely ignores the weaker. The narrower the deviation, the less capture effect there is.
This defines where timing matters. An overlap area is a place where no single transmitter is strong enough to capture the receiver. Only there does the delay between sites need to be managed. The thing that matters is the delay difference inside the overlap areas, not the distance between the transmitters.
The speed of radio adds up
Radio travels at about 5.4 µs per mile. That sounds quick, but the miles add up: 10 miles is 54 µs and 20 miles is 108 µs. Compare that with the 83 µs budget at 1 kHz. A path-length difference of 20 miles is already too much if the receiver is in an overlap area.
What matters is the difference in arrival time at the radio, not the distance to either site.
Example
Path lengths
Arrival difference
Result
Two sites, mobile close to one
20 mi / 2 mi
97.2 µs
OK only if the near site captures the receiver
Two sites, mobile roughly equidistant
20 mi / 22 mi
10.8 µs
OK both in capture and in overlap
Three sites (C, A, B)
40 / 10 / 5 mi
189 µs (C–A), 27 µs (A–B)
A radio might be in overlap with all three. Avoid this by controlling coverage.
The three-site case is closer to the real world. A pair of nearby sites can be well matched while a distant site’s signal arrives far too late. The is answer is to control where each site’s coverage goes, so a radio isn’t left in overlap with a far-off site.
Flutter in the overlap zone
SVRG’s analysis. This section works out the effect out from basic two-signal FM theory, and the second figure comes from a simple computer simulation, not a field recording.
Drive through an overlap area where both sites are strong and the audio can take on a rapid, rhythmic flutter: a fast chop or warble, not hiss. It speeds up as you speed up and goes away when you stop. With our two test sites setup you can clearly hear this effect driving north, toward one site and straight away from another site to the south, along the hwy 101 corridor in Morgan Hill.
This is the “mobile flutter” from the carrier section, but here the motion makes it, not the transmitters. Even with both carriers locked to exactly the same frequency, a moving radio hears each one shifted slightly by the Doppler effect. Driving toward Site N, its signal arrives a little high, by the car’s speed divided by the wavelength. Driving away from Site S, its signal arrives low by the same amount. At 30 mph on 147 MHz each shift is 6.6 Hz, so the receiver sees two carriers 13.2 Hz apart. That is no different from two transmitters 13 Hz off frequency: the combined signal fades in and out 13 times a second.
Driving toward one site and away from the other. Each site’s signal is Doppler-shifted the opposite way, and the two add and cancel in a pattern that stands still on the road. The level curve is computed for two signals 1 dB apart.
There is a second way to see the same thing. Where two signals cross, they add in some places and cancel in others, and that pattern stands still on the ground. When the two signals come from opposite directions, the cancellations (nulls) are half a wavelength apart: 1.02 m at 147 MHz, 0.34 m at 445 MHz. The car simply drives through them. At 30 mph, 13.4 m/s ÷ 1.02 m gives the same 13 nulls a second.
Band
Null spacing
5 mph
30 mph
60 mph
147 MHz
1.02 m
2 Hz
13 Hz
26 Hz
445 MHz
0.34 m
7 Hz
40 Hz
80 Hz
The table is the fastest case, with one site straight ahead and the other straight behind. If the sites are not on opposite sides of you, the nulls are farther apart and the flutter is slower. Drive across the line between two sites instead of along it, and both signals arrive from the side: neither is Doppler-shifted much, and the flutter should all but stop. The same standing pattern is why a handheld user in an overlap can sometimes clear up the audio by moving a foot or two.
Why it is a flutter, not hiss. An FM receiver’s limiter strips off changes in amplitude, so the dips themselves aren’t heard as long as the signal at the bottom of each dip stays well above the noise. With both sites strong, it does. Two signals 1 dB apart dip about 19 dB, and two signals 0.3 dB apart about 29 dB; a strong signal 20 or 30 dB down is still a usable signal. What the limiter can’t remove is the phase of the combined signal, which swings quickly each time the two carriers pass through opposition, and that swing is what reaches the audio. When the two signals also fade on their own and trade places as the stronger one, the combined phase can slip a full turn, which is heard as a sharper pop.
Audio timing decides how bad it sounds. If both sites’ audio arrives at exactly the same moment, both carriers carry identical modulation and the phase swing at each dip is brief and small. In the simulation below, with the levels 1 dB apart, the receiver’s tone comes through clean, dips and all. If the two sites’ audio arrives a time τ apart, the modulation itself rocks the carriers’ relative phase back and forth, by about 360° × peak deviation × τ. At 2.5 kHz deviation and 80 µs, the narrowband delay limit in the design criteria above, that is ±72°. Whenever the slow 13 Hz rotation brings the two carriers within 72° of opposition, the audio pushes them through cancellation again and again, and the waveform is torn up. That covers 144° of every 360°, about 40% of each flutter cycle. The simulation agrees: measured in 1 ms slices, 43% of the audio falls below 20 dB SINAD, in a burst around every dip.
A quarter of a second of the drive in the figure above, simulated. The only difference between the two audio traces is the timing of the two sites’ audio. Shading marks where the 72° swing reaches cancellation. Model: same carrier frequency at both sites, no noise, no independent fading, ideal FM detector. SVRG simulation, not a field recording.
So the motion sets the rhythm, and the alignment sets the damage. A difference in deviation between the sites rocks the phase the same way, most at low audio frequencies: a 10% mismatch on a 300 Hz tone at full deviation is about ±48°. The case simulated here is the worst corner of an overlap area, with the delay right at the design limit and the two signals within about a dB. It shows why delay and deviation are worth matching as closely as the equipment allows, and why it pays to know where the overlap areas fall.
Design it on the computer first
A coverage-prediction program for simulcast has to calculate time-delay interference as well as signal level. Design criteria:
Modulation
Capture ratio
Maximum delay
Wideband analog FM
10 dB
80 µs
Narrowband analog FM
15 dB
80 µs
P25 C4FM (DAQ 3.4)
15 dB
30 µs
P25 LSM (DAQ 3.4)
15 dB
70 µs
With those two numbers, a prediction can mark each place as either captured by one site (more than 15 dB stronger than the others, so delay doesn’t matter) or in overlap (where the arrival-time difference has to be within the delay limit). Because narrower deviation gives less capture, deviation is one of the inputs that moves the overlap areas.
Antenna downtilt: a trade-off
Tilting a site’s antenna down clearly raises signal levels close to the site. It reduces the areas of overlap interference, but at a cost. High sites lose some of their wide-area coverage, so talk-out is reduced in some places. Simulcast from high sites is often difficult, and much of the reason for choosing a high site goes away once its coverage has to be pulled in.
You can’t tune a simulcast system by driving around. You need to model it in software.
Software modeling: delay spread
Salinas Valley Repeater Group uses its own in house modeling software to calculate and map the delay spread for our simulcast system. A delay spread map lets us visualize the differential delay or ‘delay spread’ within the designed coverage area of our system.
The map pictured shows an area in Santa Cruz County that will be out of our phase budget so the resulting signal in this area will have distortion artifacts.
reference sources
Joe Blaschka Jr., PE, ADCOMM Engineering Company, “Simulcast – Theory or why we do the things we do,” Simulcast Forum XX, Las Vegas, 2016.
Joe Blaschka Jr., PE, ADCOMM Engineering Company, “Simulcast – Propagation and Tuning,” Simulcast Forum XXII, Orlando, 2018.
Both presentations are published by Simulcast Solutions in its Simulcast Forums / Case Studies collection: simulcastsolutions.com
