The Packet interface in TurboLog 4 is completely new designed. The core of the software implementation is the powerful and extremely stable NexusDB database which has already proved its versability as the logbook keeper. This means that all data from packet streams will be stored in just one database ( PacketTable ). The main advantage of this approach is the availability of numerous powerful data management routines, such as for data retrieval, filtering, storage, etc. Unlike TurboLog 3 the Packet data has to be stored only once for all operations. Thus, data integrity, memory consumption and maintenance can be implemented very effectively.
An outline of the software architecture is given in the sketch below:
Figure 221: Packet Software Architecture
This sketch should help to understand the basics of the Packet operations in TurboLog 4. As can be seen in the graph the database is embedded in a thread. This design assures completely independent access of the data base from internal and external clients. This means that high speed data streams may flow into the database via the Packet channels while you can still carry out loogbook operations with vitually no delay in log data access or writing. Additionally, this structure will allow us to implement various other processes requiring realtime access to computer ressources.
Another software layer, the Data Base Interface, decouples the core from the Packet data streams of various sources. Thus, the core only has to deal with a standard type of data record. Each one of the records, however, is stamped with time and its source key. Thus, inputs can later be sorted by source types. There are currently three Packet sources implemented in TurboLog 4:
TC = TNC based Packet Radio ( single channel or multi connects )
IP = Internet DX cluster
DE = Demo cluster
DX spots from a "show/dx" operation are detected and automatically sorted in timely order as well. This is a real highlight in Packet operations since you will not need to scroll back and forth in order to inspect a bulk of spots flowing in from the cluster. The newest spot will always be at the bottom of the display.
All sources can be operated fully simultaneously. Each Packet source transmits data to the Data Base Interface via its individual driver. These drivers decouple the interface from the specifics of the Packet sources. This mechanism easily allows to add more sources or Packet channels if required while it prevents spill over from one source to another.
With the Packet data streams being neatly stored in a timely order in the Packet Table all Packet displays are just customized views of this data volume. Filters and Decoders are implemented in order to retrieve the data required for a user commanded display. The data is placed on Data Grids for display. All of these Grids are derived from the same basic object which is used for various tasks throughout TurboLog 4, e.g. for the display of the logbook & log review window.
As indicated in the sketch a number of Grids with different contents of data can be displayed at the same time. Additionally the user has full control of the data to be displayed. Control procedures to perform these operations will be described below. As known from customizing the logbook window the user can also arrange the fields on the Grids and sort the data by various criteria.
As the arrows in the sketch indicate all Packet data flows are bidirectional. The same procedures are used for received and transmitted streams. Of course the user has to decide into which of the available Packet sources he wants to transmit potential data to be communicated to a cluster. Recalling the Packet history then simply means to retrieve records from the Packet Table with the filter set to "TX" and the particular data category of interest, e.g spots, announcements, WX, WWV, etc.
Finally, you will not be surprised that the Packet software implementation will allow you to search the Packet Table for any character string you wish. The full potential of SQL search commands is available here as well as in log search operations.
Please note:
All Packet operations are based on filtering out character strings from the incoming data stream. This is by no means a trivial task. One of the most important tasks is to identify the end of the individual data lines. In TurboLog 4 we are looking for an End-Of-Line ( EOL ) character which is defined in the TNC Script File. Most clusters send a <CR> ( carriage return ) as EOL. Consequently we will trigger on it. A problem may rise if clusters send no EOL, e.g. at the end of line prompts. These prompts will we on hold in an internal buffer until a line follows with the regular EOL. The prompt may thus be output with noticeable delay. The internal processing, however, will not be hampered by this event.
This topic was last edited on Monday, 03-Jul-2023, at 23:57