Common features

Top  Previous  Next

The block diagram explaining the packet software implementation indicates that there is only one packet database table for all packet spots. Furthermore, any packet spot is stored only once in TurboLog 4. This means: All the various representations of the packet spots are just different aspects or views of the same data volume. These views are computed at session time and on user's command. They are displayed in data grids of the same kind as used for the logbook and log review window.  The packet grids have inherited all features from their parent application. Of course the magnitude of features was adapted in a meaningful manner to the purposes of packet operations.

 

As outlined in the paragraph of the packet software implementation all spots are time stamped and stored in a strict timely order. This may confuse the user on the first glance since TurboLog 3 stored the spots as they arrived from the cluster. This resulted in a reversed timely order when a bloc of spots was recalled from the cluster, e.g. by means of a SH/DX/100 command. Sticking to this example TurboLog 4 would evaluate the time stamp added by the packet cluster to the spot and place the whole spot into the database in correct timely order, all on the flight. Please also note: If you would command say a SH/DX/100 ON 160m this could well produce spots of considerable age which merge into the existing data volume. This again happens in timely order yielding to the user's impression that nothing may have happened because the data is invisible ... again on the first glance only. Of course there are powerful means to retrieve all data and display it in a nice manner and just a few mouse clicks apart. The huge advantage, however, is a database in consistent order which can easily be maintained by the user.

 

Since TurboLog 4 allows you to be connected to various cluster sites via different transmission channels there will be duplicate spots arriving from the sites. We have taken measures to suppress duplicates in order to protect the user from loosing precious memory on irrelevant information. Every spot arriving is tested against a user defined number of predecessors. In case of a perfect match of the complete character sequence of the spot the duplicate will be aborted. The user can activate this facility and define its check range in the configuration menu at sub item packet.

 

Bearing in mind that there is only one packet database also implies that most representations of the spot data which can be commanded from the menu bar will internally "just" define suitable filters. They are applied to the database and the result of the filtering will be displayed in a packet data grid. The raw packet data ( BASIC ) is always presented on a white background. Any data extracted as a result of an applied filter will be displayed on a background specifically colored in order to visually identify this operation.

 

While we developed the new packet interface and tested it on different internet and radio clusters we were confronted with a large variety of "keywords". keywords are character strings which serve as identifiers for distinct cluster responses in order to generate internal triggers for future message sorting, e.g. DX_DE, TO_ALL_DE, WX_DE, etc.. Fortunately most cluster programs stick to common notations for the most important key strings. In order to keep track with potential cluster software modification and for ease of future service we have created an internal "service centre". It collects all unique keyword variations experienced from available clusters and carries out their transformation into generic expressions. These are the ones we internally work with. The user, however, has no access to this facility ... for the time being. Unfortunately there are a few cases remaining unresolvable. The CLX cluster software for example responds in a TALK session with a string  " <MYCALL>_DE_<HISCALL> ". This condition applies to most every clusterprompt and cannot be identified uniquely. Sorry, .... We just wonder whether the developer of CLX might have spent any thought on this matter...  

 

This topic was last edited on  Thursday, 17-Jun-2021,  at  10:49