(WOTA)
Application
Developers |
| Adding WOTA to your Software Application WOTA Specification Version 2.0 Effective June 5, 2006 |
||
WOTA Introduction |
||
Adding WOTA to your logging software
is easy. If you already support DX spotting via TCP, it will be
a snap. The WOTA database maintains an hour's worth of data (or at
least 50 records). The basic concept is to enable users to upload their
current operating data, view and contact others who are on the air
(including a messaging feature) and query the database for specific
information. The basic communication is handled by TCP to server1.wotadb.org on
port 1001.
|
||
Fields |
||
The following fields are maintained in WOTA database: |
||
Call |
||
When to Upload Data |
||
Uploads should not occur more often
than necessary. As the popularity of WOTA grows, there will be lots
of data flowing through the system. Since data is only kept for an
hour, the user's data should be uploaded at least that frequently.
Data should also be uploaded as the operator's data changes. Here
is the recommended WOTA upload strategy:
Every 5 minutes, check the user's information and upload on the following conditions: - More than 50 minutes (3000) seconds have elapsed since the last upload - The user has changed frequency - The user's status has changed (more on status below) In addition, an upload should occur
when the user begins tuning after he has previously uploaded a status
of listening. For example,
call this section of code each time the user changes frequency:
If LastStatusUploaded = 2 And CurrentFrequency <> LastFrequencyUploaded
Then Upload
|
||
Status |
||
| The status is a single digit numeric
value that should be interpreted by your logging software. It is
determined as follows: 1 = Tuning - If current frequency <> last frequency uploaded Then Status = 1 2 = Listening - If current frequency = last frequency uploaded Then Status = 2 3 = Calling/Running - If current frequency = last frequency uploaded AND a contact has been added Then Status = 3 |
||
Upload Format TO WOTA |
||
The fields in the upload string are pipe delimited. Please make sure that your user can't inadvertently add a pipe character to the data he is uploading. Also note that date and time are not uploaded. The date and time are added by the server. The upload of data should be in the following format: Call|Frequency|Country|PAS|Grid|SAS|Latitude|Longitude|Status|Comment|Program
Name|Future 1|Future 2|<EOR>
Please ALWAYS conclude any data sent
to the server with a <EOR>. Otherwise, the server won't know
if it has a complete record and won't respond. For example:
N3FJP|28.400|291|MD|FM19|Harford|39.53|76.34|2|Calls
Welcome!|ACLog 3.0|f1|f2|<EOR> |
||
Data Returned FROM WOTA |
||
Data returned from WOTA is almost the same as data uploaded, except that two additional fields are added after Future 2. They are Date and Time. N3FJP|28.400|291|MD|FM19|Harford|39.53|76.34|2|Calls
Welcome!|ACLog 3.0|f1|f2|2006-03-13|14:30|<EOR> |
||
Special Functions |
||
Anything other than a regular upload should be preceded with a colon. This tells the server that there is a special command. |
||
Busy (Distributed Server Concept) |
||
To enable a large number of users
and lots of data, WOTA has been designed with a distributed server
concept in mind. Once
the new master server is on line, it will only maintain connections
with auxiliary servers. All other connection requests will be
assigned to the auxiliary server with the lowest number of users in
the same geographic area.
When you connect to the master server,
it will issue a command as follows :BMASTER|Auxiliary IP Address|<EOR>. For
example:
:BMASTER|192.168.1.1|<EOR>.
When your software receives this
command, please immediately disconnect from the master server and then
connect to the assigned auxiliary address.
This feature has not been coded into
the master server yet, but will be shortly.
|
||
Messaging |
||
To send a message to another station, begin with a colon, the letter M, and then the following format: Call|Message Text|From Call|<EOR>. For example, a message sent from KA3SEQ to N3FJP is formatted as follows: :MN3FJP|How are you?|KA3SEQ|<EOR> Received messages are formatted from the server in the same way. |
||
List
|
||
After the user connects to the database,
you may want to issue a command to retrieve a list of recent posts. Please
be sure to wait 5 seconds after connecting to the master server before
issuing this command in case a Busy command is issued. To send a list request, begin with a
colon, the letter L, and then the following format:
Call|<EOR>.
The list command is sent as follows:
:LN3FJP|<EOR> Currently, the List command will not respond until you have uploaded at least one record. |
||
Group
Messaging
This field allows the user to decide
on any groups for which he would like to receive messages and include
that information in his upload. For
example, a user who might be interested in weather messages and messages
for his local EmComm group might
include the following space delimited keywords:
|WX HarfordEmComm|
When the server receives a message
command, in addition to looking for the call sign, it will also do
an "in string" function on the data in this field and distribute the
message to any matches. In
other words, to send a WX message, format it as follows:
:MWX|Tornado touched down near the intersection
of 136 and 165|N3FJP|<EOR>
The server will forward that message
to anyone who has WX included in
the string. The receiving app could also be optionally configured to screen
and/or show alerts for the same state, county or grid as configured
by the user.
The user can enter any group name
that he would like, but the following keywords are reserved to be used
universally for message groups such as:
WX - Weather
SOS - Universal
distress (It is encouraged that this keyword be included as a default)
ALL - Show any message addressed
to all
EMCOMM - General emergency communication coordination
ADIF
Field
To provide maximum flexibility, the
ADIF field is provided to be used for any other field(s) that software
developers would like. This
data should be uploaded according to the ADIF spec so that multiple
fields can be captured in this single data field. The
ADIF data field with CQ zone, ITU zone and mode would look like this:
|<CQZ:2>08 <ITUZ:2>11 <MODE:3>USB|
Applications can simply inspect the
ADIF data, look for common ADIF field identifiers and display the data
to the user as you see fit.
|
||
Query (Search) |
||
You can submit queries for any listed items in the database for the following fields: Call
Lower Frequency Upper Frequency Country PAS SAS Grid To send a query, begin with a colon,
the letter Q, and then the following format:
Call|Lower Frequency|Upper Frequency|County|PAS|SAS|Grid|<EOR>.
For example, here is a query that
includes data for all fields:
:QN3FJP|10|20|291|MD|HARFORD|FM19|<EOR>
Blank fields are ignored. A search
that would return everyone in grid FM19 would look like this:
:Q||||||FM19|<EOR> |
||
Keep Alive |
||
| After every 5 minutes of inactivity, WOTA will send a :A when the new server comes on line. Currently it sends a single space. Be sure that your program ignores this command. | ||
Need More Help? |
||
For more information, please subscribe to WOTA development reflector: In fact, we encourage all software developers to subscribe to this listing so that everyone can keep up with the latest WOTA developments. Thanks for adding WOTA to your software! |
||
| ©2006 wotadb.org |