Synchronizing a Beacon in JNOS
Starting up that beacon on time...
What is a synchronized beacon, you may be asking? And is there a big difference between an asynchronous and a synchronous beacon? A synchronized beacon transmits a text message, usually a public annoucement of some kind, exactly when you request it to be sent. It does this repeatedly at precise non-varying intervals until it is stopped, or until the machine is shut down, or reset; in theory, you could set your clock by it, or find your "way" to it.
The term, synchronized beacon, is also used here in a broader, more programmatic, sense to indicate that synchronized "events" take place in a larger time-scale context or broadcast schedule, either on a network, or on the host machine itself. For example, a top-of-the-hour broadcast might publicize all data related to station identification; at the next broadcast slot, perhaps weather related information; and at the end of the hourly cycle, information about events on the network. On a more local level, there may be events that occur before the beacon and some that occur after; for example, these might be specific server programs that manage data streams. The synchronized beacon always occurs as part of a larger broadcast sequence. It is dependent on events before, and fits precisley into a time-slot in exactly the same place again and again, like clockwork...
By contrast, an asynchronous beacon is unattached to events that might precede it or follow it. It is free-running. It is started after a timed period expires and continues on with no accurate reference to a clock, only a timer. Depending on transmission events happening on the network, it may slip cycles and drift with the "tide" of packets farther and farther way from any fixed reference. But this doesn't matter since it is not dependent on any prior events occuring on the host machine, and in turn, nothing depends on it.
How to Synchronize Beacon Broadcasts ...
Do we need synhcronized beacons in packet radio? And how precise can we be with the software available? Isn't a beacon just a beacon? Well, it depends on what you want to do with it. For 95% of the time, a simple asynchronous beacon works just fine! You start it up and let it "roll along" all day, and don't fuss with it.
But there may be times when you need better control over broadcasts, especially in emergency situations on a "closed" net. It might be possible to assign stations a specific broadcast time. If you don't hear from them in that assigned "window," then you know something is wrong. If you are working with mobile emergency units, you might want to assign their broadcasts to specific time slots so that they don't "step on" each other. I am sure you can think of several situations where it would be advantageous to manage beacon broadcasting more effectively.
So let's look at some of the options for JNOS...
- The Usual Case... Starting the Beacon Timer
Beaconing in JNOS is a pretty casual affair. The command sequence ax25 bcinterval <seconds> sets the beacon timer for all device broadcasts on the system. On my system, I use:
- ax25 bcinterval 1200
which beacons all devices every 20 minutes from some (random) time after the system was started. The beacon kicks in and transmits only after the timer has expired. The timer does not re-start until the transmission has taken place. So, here we have an unknown period of time during which no timers are running. There may be "collisions" or "wait states" depending on network traffic before the beacon even gets sent. Then we must add the actual transmission time itself which depends on how large the packet(s) is for the beacon. This may seem trivial, but at the end of the day, I have seen "slippage" as a great as a minute! If you were up for several days without a reset, these slipped cycles could really add up! You might be off by 10 or 15 minutes from what you had intended.
Now for casual use, this beacon cycle drift would never be a problem, and rarely do operators even notice it. But what if you needed to be precise about your broadcast times? Let's consider two cases. The first is starting a beacon at a precise time and letting it run with "drift." The second is starting a beacon at a precise time and replicating that start for each hour. In the first case, we might want to begin the beacon at the 20 minute mark, either top of the hour, 20 after, or 20 of. At the end of the day, we might notice that this time has moved to about 21 minutes after, etc. This may not prove too troublesome because we may be shutting down or doing a regular reset of the system.
In the second case, we use the JNOS AT timers to begin the transmission attempt, so the possible delays and wait states associated with on-the-air broadcasts do not interfere with this class of timer! If the AT timer is set for 20 after, it will always kick in at 20 after. There is no drift or slippage because these timers are independent, background events on the system, not effected by actual events on the network.- Starting a Beacon "on time"
As has been noted, when you start up your JNOS application, that is the point in time when the bcinterval timer begins counting down. That point in time could be any time at all. So you really can't synchronize this unless you issue another reset from the console. But, you can use JNOS scripts to automatically synchronize your start time no matter when you turn your machine on. How would you do this? You need two (2) JNOS scripts in the /jnos/scripts area. I call one do_syncbc and the other do_startbc. (You can of course name them as you wish.)
Synchronizer Script: do_syncbc
At exactly 20 minutes after the hour, this script calls do_startbc. The AT timers do not give you any control over the seconds, just the minutes, but that is reasonable enough accuracy. And here is that script:
Synchronizer Script: do_startbc
It has been my experience that the reset will pre-empt any previous beacon timer and will cancel it before it gets a chance to broadcast. Once in a great while it might transmit before the reset, but this rarely happens. So, I have included a command to send out the beacon as per ax25 bc <device>, which in my case here is hf.
And, you have no doubt noticed that this script only executes at 20 past the hour. Can we improve the "detection" process and have it synchronize more quicky? Yes, we can. Take a look at a more "timely" do_syncbc script:
Wider Synchronizer Script: do_syncbc
Now, we will run the script do_startbc three times! No matter where we fall in the cycle, we are guaranteed to lock "in-sync" with our intended 20 minute broadcast schedule. (If you were using 30 minutes, you would need only two lines in the script, one for 00 and one for 30.) And as noted, we should not be transmitting twice since the reset on the bcinterval timer usually "beats" the actual beacon transmission. Again, that is why I have included a kick for the beacon at these points on the cycle.
Using this method, you can expect very reasonable accuracy throughout the day with some slippage, ranging from a 30-60 second delay. This approach does not impose too much overhead on the timing systems and has performed well here for me over the past weeks. To use this method, locate the do_syncbc near the end of your autoexec.nos using the source command:
- source /jnos/scripts/do_syncbc
When each of these three do_startbc scripts has executed, they all dissappear in turn. We are not recursing or repeating them. And, of course, you may choose to start your beacon at any point in the hourly cycle. You might choose to beacon every 15 minutes so you would need to adjust your do_startbc script to synchronize around those points.- The "Ultimate" Precision Beacon
Suppose you are absolutely sure that you need to broadcast at regular, non-varying intervals with no accumulating slippage between transmissions. You need to use the JNOS AT timers exclusively! There is a recursive or repetitive feature for these timers which is activated when a "+" character is appended to the command line. This causes the timer to be run again and take a new ID number for that process. These numbers appear to be up to 5 digits in length, so in theory there would always be enough ID's. Here is a sample script that would "fix" the beacon to hard-coded times:
Sample Script for a Precision Broadcast: do_fixedbc
This setup attempts broadcasts at exactly the top of the hour, 20 after and 20 of. Broadcast transmissions are subject to the same "collision" rules as any other type of transmission, so the back-off timer will pause if the frequency is in use. However, these timers run on their own and will not be effected by network events as has been noted. Each "clock" will trigger at its set time, even if the broadcast starts late due to network congestion.
An observation: If you are relying on the system clock on the computer, and do not have an independent clock external to the machine, you no doubt have noticed that many IO operations actually slow the clock down by a few seconds each day. That is why many operators use something like netdate several times throughout the day to re-sync their clocks over the inet. (I typically get the time and date when first turning the machine on early in the am. The machine clock usually shows a delta of about 2-3 seconds from the previous query 24 hours ago.)
And, if you are using this fully synchronized method, you probably will not need to enable the bcinterval timer from the autoexec.nos since this script will be handing the transmissions. If you have other devices which you would like to beacon, then you will have to setup scripts similiar to the above for them. Remember, using this method, we are no longer employing the global beacon timer via bcinterval.
A final word of caution here... The effectiveness of using the JNOS AT timers in this particular application is dependent on how "robust" the at.c code is. The question is: will we run out of process ID numbers since we are recursing the timer routines and each invocation bumps the counter for a new ID number? I have looked at the code briefly, at.c, and it looks like it can generate about 64000 IDs, an unsigned interger in C. So even if you consumed 500 IDs per day, you would have well over 100 days of operation, and most sysops reset or re-start their machines at the end of the month after 30 odd days. At that time, all counters are reset anyway... So, I think you would be safe.- EOT...
This brief article has presented an alternate view of how to use beacon broadcasts for the *NOS community. I hope this may inspire you to do experimenting on your own and try some of these "methods" shown above. I have tried all but the very last one, the precision beacon timers script. They all have worked fine at my station. So, have fun, and keep on sending out those "fabulous" *NOS beacons...
(To find out more about how to automate beacons in general, please see Automating a Beacon in JNOS.)
(Courtesy KBNorton Computer Services)