Transmit Queue & Scheduling

How RTTYApp decides what to transmit, in what order, and when. This covers the queue, the two schedule files, $reload, and what the date/time stamps actually mean. Written for channel operators who want to go beyond the basics — if you’re setting RTTYApp up for the first time, start with the Getting Started guide.

The actual transmit queue is the list in the main window. Nothing transmits except what is in that list. The schedule files on disk are just a way to load lines into it.

Once per second, RTTYApp looks at the top line of the list and decides whether to transmit it now, wait, or (if it’s a command) act on it. When a line is sent, it is deleted from the top; the next line becomes the new top. That’s the whole engine.

Both live in the data directory and are plain text, one entry per line.

On startup and on every reload, schedule_temp.lst is read first, then schedule.lst. So the list ends up as:

How an incoming SMTP article enters the queue (on mail-fed channels that aren’t in AutoStart mode): the arriving article is inserted at the top of the queue, so it transmits next. Its file name is also appended to the bottom of schedule_temp.lst, so the article rejoins the persistent rotation the next time the schedule reloads. Net effect: a fresh bulletin jumps the queue immediately, then recurs in arrival order.

In AutoStart mode the behaviour differs — the arriving file is appended to the bottom of the queue and is not written to schedule_temp.lst.

Every line in the queue has the form:

where <name> is either a file name (bulletin.txt) or a command ($reload). The timestamp is always present in the queue, but it gets there two different ways depending on what was written in the schedule file:

RTTYApp computes a timestamp for it. It starts a running clock at “now + 10s” and, for each successive entry, advances it by the estimated time to transmit that file (file size × seconds-per-character at the current baud). So bare files get staggered timestamps that approximate “when each one will actually go out.” A bare $reload is treated the same way — it’s a single token, so it too gets a computed timestamp and becomes a normal timestamped line in the queue. (This is the part that’s easy to forget: the reload command is just another timed entry.)

The timestamp you wrote is used as-is — but the line is only added to the queue if that time is still in the future. If the time has already passed, the entry is skipped and logged as an “Expired time tag.” This is the mechanism behind everything in §5.

Each tick, RTTYApp reads the top queue line and:

When a line is selected to send:

Because of the “add only if still in the future” rule at load (§3B) combined with the send loop (§4), a date/time stamp is an “effective-until” (expiry), not an “effective-from”:

the file stays in rotation until its timestamp passes; after that, each reload drops it. One-shot / expiring content.

bulletin.txt and standing.txt both transmit and loop — until 10:00 on Jan 18. After that, reloads skip bulletin.txt; only standing.txt continues.

the loop keeps refiring until the stamp passes; after that the reload no longer fires, the queue drains, and the system stops.

A and B send and resend until 19:30:15 on Jan 15, then stop.

In Timer mode, a future stamp also means “don’t send until then.” That’s the scheduling lever: a line with a future timestamp waits (showing the countdown) and fires when its time arrives.

There is no “effective-from” date and no delay-between-transmissions command. Scheduling is done entirely with expiry stamps plus the timer, and the clock trick in §7.

$reload is a command entry. When the send loop reaches it, RTTYApp re-reads schedule_temp.lst and then schedule.lst — re-appending their current contents to the queue. That refill is what makes the queue loop forever. Remove the $reload and the queue plays once and stops.

Feed-by-historical-date technique (worked out with Daniel Jones, K6YIC, for his WW2 Nimitz Gray Book stream): put each message in schedule_temp.lst with the timestamp of its original historical send time, run in Timer mode, and set the transmitting PC’s clock to the target date. Each message then waits in the queue until “its” time and rolls off at the original hour — replaying a day’s traffic in real time. Because the machine’s clock is deliberately wrong, this wants a dedicated computer (Daniel used a cheap mini-PC per feed). The Count Down box is how you see “N seconds to the next transmission.”

Any queue entry (or incoming directive) beginning with $ is a command. Matched case-insensitively on the first few letters:

(All of these are also listed as ITTYBadWord entries in the ini so they can’t be injected into the transmit stream by an incoming SMTP message.)