Tower Lights and Tower Functions

TOWER FUNCTIONS (AUTONOMOUS MCU)

TOWER LIGHTS
I have deleted descriptions, and actual pictures, of tower lights.I have climbed towers to replaced many shot-out beacons - Been there, done that.

RULERYEL.GIF, 4 kB

The microprocessor usually used in the Tower-Module is the Microchip PIC16C73B.The sites are many miles away on a mountain top, and sence this is a windowed uv chip, upgrades can only be doneby carring a new chip in your pocket.

The Tuscan tower-light-module might seem meager, because it does not control anything. The tower light module only monitors.
Butthe monitoring is important, and required by the FAA.

( The Cohasset tower-function-module DOES have a control function:Deicers. It turns the antenna deicers on and off according to outside temperatures and temperature trends.Towers are each different, and have different requirements. The antenna at Tuscan has no antenna heaters.) RULERYEL.GIF, 4 kB

FUNCTIONS:

Both Tower lighting times and AM broadcast times are important to the broadcaster;Tower lighting for the FAA, and broadcasting to the FCC agencies. Local sunrise and local sunset times at the transmitter locationsare known by this module and there by form independent control well beyond "photocells". Tower-module has internal table of sunset and sunrise times.Tables are accurate to one minute.I was the first broadcaster with tables for tower control.The stations were KHSL and KNVN located in Chico, Ca. This feature allowed detection of defective lights which are operated principly by photocell.
This feature squarely puts this control system above others, in that my control system can monitor other controlsystems that use EXCLUSIVELY photocells.

Measurement of the number of BEACON bulbs lit.
With internal current limits, remotely settable.

Measurement of the BEACON blink rate.
With internal current limits, remotely settable.

Measurement of the BEACON on and off times: the Duty Cycle.

Measurement of the number of SIDE LIGHT bulbs lit.
With internal current limits, remotely settable.

Sence this module belongs to the net, there are Remote Alarms, involving speech and screen displays.
An important feature, not found on other systems.

RULERMAR.GIF, 1 kB

The alarming function is important in regards to the FCC and FAA.(And I just had a thought...
And this would apply to all modules, not just the Tower Lights.)

For years, in the case of an alarm, the operator would notify me (and possibly the FAA in the case of Tower Lights).The operatorwould type an acknowledgement on the keyboard, and the alarm would go away. End of story. However, all subsequent operators coming on duty possibly would not know about the alarm.

The rules are not to clear here... Perhaps each operator should be at least aware of anomalies evenif engineers are actively working on them. Over the years, operators have not complained withthis arrangement. - Of course not: ignorance is bliss! As each operator comes on duty, they type their initials (or any other short keystrokes they device).My system then signs them onto the log, as well as well as assigning their identity to internal operations. At the time that each new operator signs on would be a time to "redefine" the present alarms.Not to have any alarms (if present) reactivated; But to be read, reviewed, and acknowledged.This would be a new categoryof alarms: "reviewed". Yes! As the writer, I can do that...
RULERMAR.GIF, 1 kB

sensor
BEACONS
The software, inside the module, supplies a "artificial capacitor" integrator, which measures howmany bulbs are lit; despite the on and off flashing action. Software recognizesthe on cycle, and holds the max value. This value is slowly decremented (by1/255th value) each second. So, after the beacons are off, 255 seconds mayhave to pass before the reading will decay to zero.There is a slight rise at the initial ON pulse compared to the right hand side of the ON pulse.Digitization takes place at several random times along the surface of this "on" pulse.Despite the slight variance, the TowerFunction-module uses this method.

(The other software method isa software straight mathematical averager, but is not accurate because of the introduced timingvariable (on to off times is a variable).

Another method is the hardware electrolytic capacitor,as is employed at the Cohasset site. I like this method the least, because another circuit is needed tocalculate the timing rate. Timing is also required by the FAA, and is given directly - and conveniently - by thefirst method.

sensor
SIDE LIGHTS:
At present, the side lights are represented by 2.6 volts. With so many side lights, there existsan accuracy problem in determining the number of bulbs lit.The resolution is just barly there.One more loop around through the current sensor donut will bring the sensorvoltage near 4 volts: the ideal voltage. Four volts gives a good signal to noise ratio, and a good resolution, with so many bulbs.(At the time of this writing: a future task, yet to be done...)

It should be emphasized, that the alarm functions are internal to the module. Alarm pointsare not determined in a computer; my system does not need computers. The module - itself - generates the alarm. And, of course,this is true of not only the tower-functions-module, but all modules.

sensor
TOWER VOLTAGE PHASE1

sensor
TOWER VOLTAGE PHASE2

sensor
TOWER VOLTAGE PHASE3

sensor

DEHYDRATOR RUNNING
"Dehydrator-running" is an internal function of this module, and is displayed on any number of computer screens.Also, as with all modules, speech will iterate this function if the operator wishes.
However, enunciations of dehydrator events is a trivial event. Operators don't care, and an alarm will be generated anyway ifrun times are excessive.
Run times are tallied; and recorded on the log at the end of the broadcast day.(Unfortunately the tallying of the run times is not done internal of this module. Total run-timesare tallied, by a computer, during a process of printing a log.)

sensor
DEHYDRATOR ALARMS

The alarms are: humidity alarm, runtime alarm, and low pressure alarm.
The alarms are generated within this particular dehydrator (external equipment), and are only relayed to the Tower-Module. RULERMAR.GIF, 1 kB

Tuscan TowerFunction-module (in Plastic box).

Almost all MCU Control modules are placed in children's pensil boxes.The plastic boxes provide some insulation and ease of placement.Each box is placed as close to the equipment as possible. Then, only one CAT5 cable is ran to the box.The CAT5 cable contains all power, and all communications, for the module.Each module-in-a-box has a static ID, and joins a net of many such boxes.Not all wires of the CAT5 are used. I have too systems: one uses 6 wires, and one uses 4 wires. Bothhave full collision and arbitration control.

The tower screen as screen on a computer.

The tower screen as screen on a computer.
The background of tower framing is cosmetic.
The screen contains all of the tower voltages, and beaconcurrents, and side light currents.An operator can "slide the screens" any where on the computer face. The operatormay also place a screen in another application.

However...
If a significant change occurs - ON ANY SCREEN - then that screen takes front visibility (obtains focus);Unless, an operator has picked a screen for observation withen the last 30 seconds. This is a case where thenew screen only "flashes up" for about a half second; and the screen returns to the screen that the operatorhad chosen. With years of use, this feature is one of many, that are requested from operators. A control system can not be great, without design input from operators of that system.

MCU Time and Date.

The MCU (in a plastic box at a remote location)has an internal Date and Time which it uses to determinethe times of Sunup and Sundown. It uses this information to knowif the tower lights should be on or off. I know of no other system with this capability.

Also, this feature keeps a personal philosophy, of not depending on computers: they are vulnerable and not reliable.

Simulator board at night.

Simulator board at night.
The first LED indicates that the beacons are on.
The second LED indicates that the side lights are on.
The third LED indicates that it is NightTime.

Simulator board at night.

Simulator board at night.
A simulation of "Side Lights Out" (second LED).
An Internal Alarm is indicated by the last LED, which is on.

Setting internal limits...

Although the modules are autonomous, and do not need computers, the internal limits can be set remotely froma computer.
On the screen one simply moves sliders up and down; two limits above, and two limits below the actual parameter. There are too many parameters to be displayed on only one screen. The processtakes two screens.
Once the limits are established inside the module, a request is sent, from the computer to module, forverification of all limit settings; The module replies with internal limit settings.The computers can then be turned off; my system does not needcomputers.

Every morning this picture would occupy computer monitors in master Control. At the moment of official SunRise monitors wouldfill with this Sedona scene that I took during a trip to Arizona. It was an excellent representation of sunrise. The picture wouldremain untill an event happened. Other events would force a screen to the front and "take focus", however when this scene was done, it would totally vanish.

This table is held by computers. Computers know more than the PICs. For example, computers display holidays and special events.They know when an EAS test is scheduled - and this is on the year schedule.The computer simply looks in column 6 for the day of the year and reads many things, for example sunrise at 7:25. A "direct read" for a computer is easy with its huge harddrive.

But the PIC has limited resources...
One can use an algorithm, (using little memory, but inaccurate results); or an indexed Reference, and memory used as "offset memory".

Consider EEPROM Memory.
EEDATH:EEDATL register pair forms a 2-byte word that only holds 14-bit data; NOT 16 bit. So using this methodwill only support latitudes producing low difference values. 2 bits short (on the high byte) yields only 64 minutes.If one aphelion is set as a reference, say Day001 the opposite aphelion, say day 168, yields a difference of 160 minutes!And that is even above 128 (7bits). We need the full 8 bits. I could have chosen to waist the high byte, and devide availablememory in half. But not enough divided by half is still not enough.

Consider FLASH PROGRAM Memory...
We use the same EEDATH:EEDATL register pair, but we can be wasteful.I placed the data into program memory using directives, which waist no program memory for the task of importing.This memory only needs to be read. It never changes.

Sense we are stuck with a word (two bytes) representing one sunset time or one sunrise time, we should not be too wasteful: Use the lower byte for literal minutes instead of an offset.Hours need a max of 60 which is 6 bits (64).And use the upper (6bits) to house the literal hours; It can go to a max of 24, which is 5 bits.And - We do not have to worry about negative numbers.

The amount of bytes needed is 365 days x (two byte sunrises + two byte sunsets) = 1.46 kb
The PIC16F1933 theoretically works because it contains 4kb: I use a little over 2kb for the program itself, and the remainder works for the1.46kb program "data" memory. However, for the PIC16F1933, the 1.46kb must be contained on one page of a possible two pages. Both pages containover 1kb. There is no room.However, all was not lost. The PIC word in program memory is 14 bits long: that can be construed as TWO bytes.That is only 700 bytes. That will work for low end PICS!

Sunrise as two Hex bytes, and Sunset as two Hex bytes.

Placing a 14bit number into program memory is difficult if you want to maintain separation of hours and minutes.Of course you can combine hours and minutes to pure minutes and convert to Hex: that is ONE number, and nota representation of two.

Here is what I did...
Convert the decimal hours to Hex, and Convert the decimal minutes to Hex.Input to the PIC must be one word. However, output is two completely separable bytes; a characteristic for all PIC data.

I wrote in a high level language, VB, to create an output file.Simply take the above text file Schedule.YAR. This will be the input file. I already had many files created, one for each year. A composit was recreated daily.Any one of which could serve as an input file. If you do not have an input file already created, you will have to manually typein Sunset and Sunrise times...

The program goes down each line of the input file, identifying each line as valid with the descriptor: "DAY".The program picks out Sunrise and Sunset times from each line.

Here is the "machinery" at work...For example, when it finds a " SR" it knows what is to follow will be a SunRise time.It takes the value and begins to analyse it.

Down at the bottom you can see the new outputted data in a format that MPLab can use.And you did not have to type anything! All the work was done for you...

If the data was NOT laid out in rows, this would be the idea:
The "07" represents one byte and the "19" represents one byte.The two bytes artificially appear as ONE to the PIC.And the format is SunRise then SunSet, SunRise then SunSet, SunRise then SunSet, and so on...

Never ever laboriously copy by hand long lists of data. Mistakes magically appear in such work.Never input - by hand - tables. You WILL make a mistake...

Here is the file created...
File ready to come out of one program, and for a "Copy-and-Paste" into another: MPLab.

Open "HEXFILE.YAR" in NotePad, select all and Copy.After a Copy-and-Paste into MPLab...
Just drop it in; No work is needed on your part.

Now the directive does the hard part:
The directive puts the data in for free, before run time. There is no penalty.

After pasting the File in MPLab as a directive, and specifying where to put it...
Here is the actual PIC memory, after dumping in at Program address 0D00.
This is how the program memory looks inside the PIC.
You can see it is all there...

Can you imagine how long this would have taken manually - by hand?

The code is placed at the very top of program memory for this chip: PIC16F1933 (4k). Hopefully, future developmentswill not over run it.

This has been working great! Full minutes and full hours: no hyphenation.
I have also followed the lead of the FAA and FCC: STAY AWAY from Daylight Savings Time!!!

I have taken time out to show you in detail how to save some time, prevent errors, and program a PIC for memory storageusing program memory space.
Actually there is one more thing: The PIC code necessary to read this data ...
I have already set up the code to read every other value as a SunRise.
And I have not shown the one (and only) variable needed as an input variable to this module of code: The-Day-of-the-Year.
The DayOfYear is maintained internally in the PIC regardless of MasterClock input. But, ofcourse, the MasterClockfeeds this information several times an hour, such that the Tower module always knows the DayOfYear.

Now,
You will need to back up one address from the "0D00".
You can just copy the PIC manual on how to retrieve the data.
Finally, the data is inserted into the Variable TSunRisH (Hours), and TSunSetM (Minutes) for this particular day.The Tower Module uses these well established times to know if the beacon light sensor is working.

RULERMAR.GIF, 1 kB

For a couple of years the Tower Modules figured their own SunRise and SunSet times.But I began to question wether the function should lie innately with the Tower Modulesor with the MasterClock. The advantage with the function being internal to the Tower Module is that a broadcast tower never changes Latitude or Longitude, and the times are the same every year.

But I had personal reasons for the function to be in the MasterClock.
1) SunRise and SunSet times are true Time Functions. Logically, they should be there.
2) I put a MasterClock in my personal RV.
I had a MasterClock in my RV, and it traveled North and South, and East and West. The advantage of the MasterClock is that, in my RV, I would know when the sun was coming up. This is a cool function if you can awake with a beautiful view, have a camera, and have a lake. Naturally, I transferred the SunRise and SunSet functions to the MasterClock.

In fact, I even threw away the old complicated code, and started over: I divided the year into 4 quarters. A tiny table consisted of only four key DOY (Day Of the Year) dates.The Winter Solstice, Spring Equinox, Summer Solstice, and Summer Equinox. The DOY (Day of Year) was identified in code with its quarter. Each quarter was easy to determine and easy to work with, as SunRise and SunSet times always either increased or decreased in a smooth predictable manner, how be it unlinear. The tiny table established the reference or baseline time, and a small amount of minutes were either added or subtracted from it. This was the easiest method yet, with one minute accuracy, with the RV sitting still in one place.

One day my sister, not knowing about the Tower Modules, asked me why the MasterClocks had SunRise and SunSet times.Throughout the years, no one has asked me this question!

To explain it, I would have to go back to the Tower Module. This is what I said...

I don't talk about my accomplishments much, including my MasterClocks. And their importance is understated. But the clocks had a necessary and serious reason, including those sunrise and sunset times that you mentioned. But to answer your question, I will have to go back to the 1950's when I was just a kid having no idea that I would invent devices for broadcast stations. In the 50's, 60's, 70's and 80's the FAA required broadcast towers at night to be manually viewed by a human operator. And the FCC required such viewings be placed in an official log. If lights were out, especially beacons, aircraft could crash into a broadcast tower with tragic results. I came along before stations were controlled by remote control. As you know when I got out of the service, I was hired at the first door that I went through, and on the spot, and practically before I could sit down. And my carefree motorcycle riding days with brother Bob were done. I watched as companies experimented with remote control, and I observed a few companies slowly beginning to obtain Type-Acceptance licenses from the FCC. But they all were failures, in my opinion. I was trained in such matters, and I knew that I could invent a better and successful control system. I have described it on my Web site. Getting back to the matter of sunrise and sunset... I was successful at controlling a broadcast site, and I thought that I would also tackle the tower light problem. As you know, I was the first person to develop a "community of devices", and it was no problem to assign yet another microprocessor controlling device to each tower. It's job was to constantly monitor every light bulb and every beacon on the tower. That was its only job, and that is all it did. That was easy with accurate current metering. I implemented that right away, and the operators far away immediately knew of an alarmed condition on a tower. But that did not solve the problem of WHEN the tower lights should be on. The FCC rules stated that a human was to begin monitoring so many minutes past sunset. I had already established that a human no longer had to go outside and count the lights on the tower. Instead, the FCC had ruled that a human could use remote telemetry. That was good. I had already done that. I was in a grey area with my automatic alarms, as this did not require the operator to watch tower lighting parameters. Indeed, operators stopped looking, and instead, relied on my alarms. I was in charge, and was out on a limb, but said that was OK. But they still had to look initially at sundown to see if the lights had come on. At this time, every broadcast station had photosensitive eyes that turned on tower lights. And most of time they worked. I too could have used such a physical device, as an informative sensor, to determine the sunset and sunrise times. But such sensors fail, and just like those, my sensor could fail too. My system had to be perfect. You know: that compulsive Aspergers thing. So why not do it in code?

I lived in Cohasset then, and so I drove down to Chico and bought a Farmers Almanac. I looked at the tables of sunrise and sunset times, and saw how they predictably changed. Maybe a few seconds to a minute, each day. I could do that! I knew a couple of ways to implement this in code. My clocks have one second of accuracy, but I would aim for, and got, one minute accuracy on sunrise and sunset times.

Now, this technically brought me outside the law. Because now, the operator did not need to look at the tower lights at all; Ever. As Chief Operator, I was scared. I was frightened to be outside the regulations. So, I had the computer announce, in a computer voice, which I also invented, that it was sundown, and the computer placed a squiggly line on the log for a signature. The announcement was to draw attention to the fact that they should sign the log, in the place provided, and that they had verified the tower lights. My operators gladly tolerated this slight burden, because I informed them that KHSL would be fined $10,000 for each tower light violation, and I wanted nothing to jeopardize my system.
Anyway Carolyn...You asked

RULERMAR.GIF, 1 kB

Speech

My Concatenator Speech is in addition to synthesized Computer Speech. At remote sites the computeris turned off. Concatenator speech does not require any computers, it is embedded into theNetwork, and is always present. Tower events can be very important, and as such are iteratedto engineers.

RULERMAR.GIF, 1 kB

Here is an example of an old log back in 1993. Fan Fold, Green Bar.
It is cold outside: 36.4 degrees.
And two beacon bulbs are lit: "1.9"
The operator (Mike) requested the transmitter be brought up, and my modules brought it up OK.
The log contains a squiggly line for the operator to sign such things as Tower Lights On.

LogKNVN2005.jpg, 78kB

Throughout the years my logs have became more colorful.
I probably had the most colorful logs in the broadcast industry.

RULERBLU.gif, 10kB

Example of Syllable Concatenator speech by Clock (used to be Tower-MCU)

Attention: Submarine Sonar sound

Device: Clock

Clear Throat

Message...

End of Message Period: Spit

RULERMAR.GIF, 1 kB

In the middle of a dark night, with glove in mouth, high in the sky, I climb a stupid tower to replace a stupid beacon; not because the FAA demands it,but because my control system has some how put me to work. I made the alarms; Why can't I just turn off the alarm? Sometimes, I worry that things are not going in the right direction, in that my work is increasing.I do not like it up here! It is cold, dark and windy; I would rather be writing code down below.So much for automation...