PROBLEM
The VarAC calling frequency is a single point of failure.
QRM on that frequency disables the mode! E.g., there has been a contest on 40m over the past few days and also some strong radars or RF dryers! Calling channel blocking is a HUGE problem. especially on the 40 meter band! This can disable the mode for long periods of time, making it unusable until the QRM ceases.
SOLUTION: MULTIPLE CALLING CHANNELS + A STANDARD CHANNEL HOPPING SCHEDULE
Calling Channels (0..n) Define multiple calling frequencies per band.
Timeslots (0..n) Switch channels on a schedule, e.g. 4 channel cycle, 15 mins per channel.
Synchronize The hopping pattern will restart at a predefined time, e.g. every hour.
Example: Four calling channels and 15 minute timeslots
Hopping schedule:
00:00 Calling channel 0
00:15 Calling channel 1
00:30 Calling channel 2
00:45 Calling channel 3
-> Repeat every hour.
The calling channels shall be used for beaconing and broadcasts. Connected modes shall not use the calling channels, but shall QSY immediately. Preferably QSY in advance for the connection (similar to calling and answering CQ -- see my feature request for Quick Connect + QSY).
What does this accomplish?
Persistent interference will only block part of the cycle, whereas now it blocks 100%.
Timing
This prefers *somewhat* accurate time - perhaps within a few minutes, depending on the beacon timing design. For example, the beacons need not be sent right at the beginning or end of the timeslot. However, if the timing is too loose, it wastes more of the timeslot. Normally, the timing can be tight, e.g. to within a minute.
In an unusual worldwide SHTF huge grid down, disaster situation, where most stations are off grid situation, timing could be set looser.
Synchronization
Reliable on-grid stations could transmit a clock in their beacons, then others could synchronize to it within a few seconds. For example, if they have Internet, then they can have accurate time and it can be verified. Or a voting system could be used, to discard clocks that are far off from the mean. In which case it requires no Internet at all.
NOTE: The proposed system does NOT require accurate synchronization to within 2 seconds. This is NOT restricted; it is NOT like the JS8 protocol! If you sit on one calling channel for an hour, you would receive all of the beacons and broadcasts on that channel! Similarly, your beacons and broadcasts would be received by all when they are receiving on that timeslot!
This means that a station without automatic frequency control can sit on one calling frequency and will still be heard periodically. For example, Calling Channel 0 could be the current main calling channel, which means in my 4 timeslot example above, beaconing and broadcast would be 100% backward compatible with older VarAC clients for the first 15 minutes of every hour.
OTHER BANDS
It could be interesting to automatically listen on other bands on a schedule, e.g. to cover the WARC bands, on a schedule. But Tx is a can of worms, unless people are using multiband resonant antennas. (E.g., I use an EFHW cut for 80m; it covers all bands 80-10 without an antenna matchbox - except 60m).
Intentional Interference
This would NOT resist intentional interference - if the hopping schedule is known and shared across users.
Perhaps during an emergency, EmComm groups could switch to a preshared faster / different hopping schedule in case of interference.
However, I recommend to define a simple and open standard for maximum interoperability between all users - and in the spirit of Ham Radio.
Q: Why not just manually change bands?
A: Although it is possible to switch bands, however it depends entirely on propagation, and there may be NO propagation on that day at that time, or that calling channel may also be blocked by QRM or even lack of an antenna for that band.
E.g., I use 20m by day and switch to 40m some time after nightfall - when the 20m band closes.
Furthermore, manual band changes creates an islanding problem!
Q: Won't it create islanding of isolated users on different calling channels?
A: No, because all of the users will be synchronized to the same hopping schedule, by the application's standard.
My suggestion is to maintain standard calling frequencies hopping schedule in the application.
The hopping schedule must be built in to VarAC so that everyone follows the same standard.
Thus everyone remains compatible because we all know who is listening where at what time.
If bad QRM is still an issue, the hopping schedule could be designed to move more often than 15 minutes, for example every 10 mins. But that may entail more beaconing.
Whatever is decided, it must be standard in the application so everyone is on the same standard! It must not be changed often and it must be distributed reliably to all VarAC stations.
Which is not to say that it needs to be hardcoded. The hopping schedule can simply be defined in a file.
But we don't want islands of people listening on different calling frequencies in an uncoordinated fashion, which is why I suggest coordinating calling channel hopping by time and having a standard hopping schedule built in to the application and distributed with it.
Limitations
This scheme does NOT detect blocking and move to a different calling frequency if the current timeslot is blocked. It hops on a set schedule. This means there is latency until the schedule reaches an open calling frequency.
Future Improvements
There may be other schemes that would be faster and achieve higher channel utilization. For example, using short timeslots, like JS8. However, that requires tighter clock synchronization. It is probably worth it though. For example, with five calling channels, hope every minute, and repeat the cycle every 5 minutes, instead of every hour. Then the latency is reduced to 1-5 minutes, depending how many channels are blocked (0-4). But the broadcast must complete faster than in one minute.
If a wide bandwidth could be listened to simultaneously, then the application could detect transmissions on multiple calling channels - similar to JS8. Then there is no need for a frequency hopping schedule. Simply call on the next available channel.