Revision 1

Solar Technology System Overview

About this Documentation

This document is meant to provide a starting point to the entire collection of documentation, as well as provide an overview of how a Solar Technology controller works and how to interoperate with it. The documentation as written is meant to be read it its entirety before being used. It is, in the main, descriptive rather than narrative.

Every effort has been made to ensure that this documentation is correct. In particular, the existing user interfaces were written against this documentation. (To be specific, most of the Trafix interface and all of the Control Center 3000 interface, the Web interface, and NTCIP were developed using this documentation.)

All files in this documentation are available through the documentation index.

Introduction

The Solar Technology Sign Controller runs a collection of components, called daemons (according to standard unix terminology) which handles its various functions. Each daemon provides a network protocol with which it is controlled or otherwise interacted.

These protocols, taken together are the Solartech Network Protocols. They are all TCP/IP protocols which begin with a version negotiation, followed optionally by a challenge/response authentication phase. This handshake phase is described in the Solartech Protocol Handshake & Authentication specification. Each protocol is described in the section of this documentation about the daemon which provides it. (Including which TCP port it uses.)

Direct, unfirewalled TCP/IP access to the controller is the preferred method for accessing the controller and using the Solartech Network Protocols. If direct TCP/IP access is not available, or at least if configuring the firewall to allow the several ports required is too onerous, then the Connection Multiplexer protocol is available to tunnel the various Solartech Network Protocols through a single TCP/IP port. The Connection Multiplexer protocol is also available to communicate with the sign via a serial modem (typically a circuit-switched cellular modem connected to the sign, and a regular land-line telephone modem on the computer's side). Direct access via RS232 null modem cable is not currently supported.

Because the Solartech Network Protocols are meant to be delivered over a sequenced, reliable connection (primarily TCP/IP), there is no error correction, packet length identification, or other features meant to compensate for an imperfect transmission. (If those features are needed, the Connection Multiplexer provides them.) Further, because all of the Solartech Network Protocols are versioned, it is expected that any software using the solartech protocols will understand every type of packet, and be able to allocate memory and storage space on the basis of packet identification. (The one exception is providing event/data sources, in which a subset of the event protocol is perfectly acceptible for a provider to understand.)

Daemons

Every Solartech sign controller runs one instance of each of the following daemons:

Information Daemon
The information daemon provides information about the system, and is the catch-all for functionality which doesn't fit comfortably into any other daemon.
Event Daemon
The Event Daemon coordinates event and data suppliers with event and data consumers, allowing for real-time control of what the sign is displaying.
Librarian
The librarian stores sequences for use by the schedulers and display drivers. It provides multiple libraries for easier organization of the sequences on a unit, though one library is designated the active library, and it is the only library which the scheduler can use.

A Solartech sign controller will run one instance of each of the following daemons per sign panel to which it is connected, unless it is configured to duplicate the main display onto the second panel, in which case it will run only one:

Scheduler
The scheduler provides scheduling for a Display Driver, and controls what it is displaying at all times. In the simplest circumstance, only the default sequence is used. Time-based scheduling and event-based scheduling is also permitted, with a priority-based conflict resolution scheme.
Display Driver
The display driver is responsible for actually sending each page of the message up to the display panel at the appropriate time. It is not normally accessed directly, except to query it about size and to ask it what sequence it is currently displaying (thus getting as authoritative an answer as possible). Normally it is accessed indirectly through the scheduler.

Formats

The Solar Technology software uses a number of formats for storing messages which were developed for the platform. These formats are described in the Formats section of the documentation list. These formats are used and referenced extensively throughout the protocols. With the exception of providing event and data sources, being able to read and write all of the sequence and message formats is required to be able to use the Solartech Network Protocols.

Unfortunately, these formats were developed when Solartech was still using the terminology that a sequence was made up of messages, rather than the current terminology that a message is made of pages. When reading the format documentation, this unfortunately confusing terminology should be born in mind, though the documentation is consistent in using the old nomenclature.

Keeping this terminology in mind, a sequence is not made exclusively of messages. Sequences can be nested inside of sequences (this is particularly useful for libraries of animated graphics). This means that there is no maximum size to a Solartech Sequence, though of course all equipment has limited storage capacity.

Access Roles

There are several ways that software can interact with a Solar Technology sign controller.

User Interfaces

There are several roles which the Solartech Network Protocols can be used. The user interfaces, if any, on the controller itself use these network protocols to control the daemons and retrieve the information which they need to present their user interface. Control Center 3000 uses these protocols to present its interface. Integration of control of Solar Technology signs into other control software, which wish to present the full functionality of Solartech signs to its users and not simply the subset exposed by NTCIP, are expected to likewise use all of these protocols, and to implement them completely, to control the sign.

As a special note, it is possible to use the librarian and scheduler protocols to frequently upload a sequence and cause it to be displayed, but this is not the usage that these protocols were meant for, and if this is attempted rough edges to this approach will quickly become obvious. These protocols were designed for implementing user interfaces, not real-time control of the sign. In particular, loading messages is a comparatively slow, resource-intensive task, because it causes information to be written down to the permanent storage medium in a way which ensures that no data can be lost. Also, changing a message is generally immedate, and does not wait for the current sequence to complete an iteration.

Real-time control

It is also possible to use the Solartech network protocols for real-time control of what the sign is displaying. The preferred method to achieve this is by providing Events & Data Sources to the sign from a remote computer. Event Sources are used by the scheduler to decide which message to display, and Data Sources are used by the Display Drivers to provide the contents of dynamic messages being displayed. A program connecting to the Source Daemon may provide event source, data sources, or both. In most cases, the simplest and best method for creating the dynamic messages and schedules to be used is via Control Center 3000.

Between event sources and data sources, very extensive control of the sign is possible via just the Source Daemon. Graphical data sources are also available, so if extreme control is desired, a message which consists of a single dynamic page with a short refresh time (and a fast network connection) can be used to control the sign as if it were simply a low-resolution monitor.

Common Tasks

Supplying an Event Source or Data Source

Event sources allow you to trigger the schedule to change a message based on a supplied event value. This allows you to pre-define all of the message formats that you wish to use, and to select them instantly. How to provide event sources is described in detail in the Events & Data Sources documentation.

Data sources allow you to supply some or all of the text to be rendered in a message, allowing you to change the text on the message board as rapidly as the refresh rate of the message. How to provide data sources is described in detail in the Events & Data Sources documentation.

Please note that in both cases, you must connect to the Solartech sign controller and offer your event sources when you create the schedule for them, and/or offer your data sources when you create the messages which use them. Control Center 3000 does not let you schedule on event sources or incorporate data sources which it doesn't know about.

Getting a list of available messages

The Librarian has an Item List Request Packet which causes the librarian to send an Item List Packet containing a list of the titles of all of the available messages.

Changing which sequence is displaying

If time- and event-based scheduling is not in use, changing the currently displaying sequence is simply a matter of sending a Sequence Packet to the appropriate scheduler. If more complicated scheduling is in use and you absolutely must display a message, the scheduler on newer Solartech controllers does provide an Override Sequence Packet, which sets a sequence that overrides all schedules. (This capability should be used carefully, because it will make the scheduler appear broken if a user tries to schedule a message which would, otherwise, take precedence.)

Fetching Status Information

There are two main avenues for fetching status information: The Information Daemon and data sources. Much of the information is available from the Information Daemon via its Get/Set Configuration packet.

Some information, such as temperature, battery voltage, and radar are available as event sources, and can be accessed by subscribing to these sources via the Event Daemon. To find out what these event sources are and what their value means, use control center to schedule an event-based message and read the descriptions of the appropriate sources.

Uploading a message for display

As mentioned earlier, uploading a message for display should be done by a user interface, and is not the preferred way to achieve real-time control of a sign because it is so resource intensive. If that is your goal, please read the section on Real-Time control, above.

The first step for uploading a message is to put together the sequence that you wish to display. Next, upload it to the Librarian with an item insertion packet (the item insertion packet automatically inserts the message into the active library, unlike the Library Item Insertion Packet, which lets you specify the library to insert the message into). Once you receive an Insertion Acknowledgement Packet, then send a Sequence Packet to the appropriate scheduler to set the new sequence to be the default sequence.

Blanking the Sign

To blank the sign, assuming that you are not using complex scheduling, send a Sequence Packet with the sequence title "_blank". This is a special sequence which does not appear on the Library list, but is always available in any library.

When a display driver is displaying the message "_blank", it will activate the sign's shutoff relay, saving power.