VHF path as per National recommendation
HF path as per National recommendation
VK7HSE-2 - 145.825MHz
VK7DIK-4 - 30m (10.147)
VK7HSE-4 - 40m (7.036)
VK7HSE-1 - Kingston | Status Page tasmania.aprs2.net
VK7DIK-4 - Rosebery | Status ?
VK7DC - Burnie | Status ?
Welcome to VK6 APRS
Further information will be online here soon.
Danny - VK6ZUK
For more information about APRS in Tasmania (VK7) please contact...
VK7HSE Scott Evans aprs <at> vk7hse <dot> hobby-site <dot> org
This is just a quick page to get some information specific to VK6 up on to the site. Further information will be added in the near future.
Content in this section is managed by Peter Schrader - vk4ea <at> wia <dot> org <dot> au, if you have any updates please send an email.
Preferable to contact your local iGate operator who will be familiar with local conditions if you are thinking about establishing an iGate and/or digipeater.
You are also encouraged to join the vk4aprs Yahoo group.
This page is a rough guide to using the MEX application for this year's WICEN HCC event.
MEX is an APRS Messaging application written by Andrew VK5EX for WICEN Car Rally events in SA.
The software is pre-configured for each event, allowing the checkpoint operator to simply start the application and go - without the risks associated with "once a year" packet operation introducing bad configurations that can seriously degrade a data network performance.
Benefits of APRS messaging over traditional Packet
In previous years traditional Packet BBS operation has been used during the HCC with limited success.
The Packet BBS network consisted of several digipeaters on different frequencies throughout the course, and the occasional ROSE node to get packet back to the BBS.
Messages needed to be compiled by one checkpoint and uploaded to the BBS as "Left Here", where they were then downloaded by the next checkpoint as "Due Soon" messages. Because of the size of the messages and the overheads of connected mode AX25, it was very common to have a checkpoint recieve the "Due Soon" message for a canoe after that canoe had already left! It was also very common for message upload/download to the BBS to fail completely due to excessive retries, rendering the entire message undelivered.
An example message transfer from Checkpoint A to Checkpoint B using the BBS would follow:
CP-A>BBS: Connect Request
BBS>CP-A: Connect ACK
BBS>CP-A: Login banner data
CP-A>BBS: Submit message request
CP-A>BBS: Message Data (2-3 packets)
CP-A>BBS: Message Data (2-3 packets)
CP-A>BBS: Disconnect Request
BBS>CP-A: Disconnect Command
CP-A>BBS: Disconnect ACK
BBS>Broadcast: New messages available for.....
<Some time passes before CP-B decides to get new messages>
CP-B>BBS: Connect Request
BBS>CP-B: Connect ACK
BBS>CP-B: Login banner data
CP-B>BBS: Message Retrieve Request
BBS>CP-B: Message Data (2-3 packets)
BBS>CP-B: Message Data (2-3 packets)
CP-B>BBS: Disconnect Request
BBS>CP-B: Disconnect Command
CP-B>BBS: Disconnect ACK
APRS uses unconnected (Unproto) mode AX25, meaning that there is significantly less overhead in getting a message through. Using a client application such as MEX also introduces fixed-format messages, passing as much information as possible in the shortest packet possible, and cutting out the possibility for irrellevent information to be included in a message. APRS Messaging still implements Acknowledgements, so we can be sure that the message was delivered.
An example message transfer from Checkpoint A to Base using APRS would follow:
CP-A>BASE: Canoe Message
In addition, a Single frequency can be used for the entire course, with checkpoints acting as Fill-In digipeaters where required to improve coverage into the fixed Wide area digipeaters. This greatly simplifies the setup and maintenance of the data network for the event.
Most TNC's that support KISS mode are supported. Even BAYCOM style modems are supported by the MEX application.
The following is the list presented during the MEX initialisation:
- MFJ 127x
- TAPR TNC2 or Clone
- AEA (PK232 etc.)
- KAM early versions
- KAM+ KPC3 late ver
- Kenwood TM-D700
- Kenwood TH-D7
- TF EPROM TNC
- KISS EPROM TNC
Note that although the Kenwood TH-D7 is listed in the startup menus, it may not work correctly as it is known to have bugs in it's KISS implementation.
Installing the MEX client application is as simple as unzipping the MEX archive to your C: drive.
If you are running under DOS, simply cd c:\mex and then use run.bat
If you are running under WindowsXP, you will need to run MEX from a command window, however it requires COMMAND.COM to be called instead of the more common CMD. To do this, from the START menu, select RUN, then enter COMMAND.COM as the application name. A DOS Command window will be shown - from here cd c:\mex and enter run.bat
The startup script will prompt you for some information regarding your TNC connection.
At this point your TNC will be placed into KISS mode, and then you will be prompted for your callsign.
After entering your callsign, you'll be prompted for your CHECKPOINT identifier. Enter the single letter designation of your checkpoint.
Once this has been entered, MEX enters its operating mode, which appears as shown below.
Also at this point, a LOGON message is transmitted to the server, which associates your callsign with your checkpoint within the server software.
The screen is divided into three sections.
- The top section provides a monitor window where packet activity on the channel can be seen.
- The middle section is the main message window, where all transmitted and recieved messages are displayed.
- The bottom section is the data entry section, which can either be plain text or pre-formatted message strings.
(You will note that the TO callsign is pre-configured to be the MEX Server)
Note that you can scroll backwards and forwards through the message window using the up and down arrow keys, as well as PgUp and PgDn.
Submitting a canoe time
Use the F1 key to place MEX into "COMPETITOR ENTRY" mode. The bottom section of the screen will change, and prompt for a canoe number.
- Simply enter the canoe number and press enter.
- You will then be prompted for the canoe time, which will be pre-populated with the CURRENT time. Please adjust the time if required so that the time reflects when the canoe actually passed your checkpoint (Arrived Here time). Press enter to accept the time displayed.
- You are then prompted for another canoe number. If there is a second canoe to enter, follow the steps above. If there is no further data to send, simply press enter.
The COMPETITOR ENTRY form will automatically send a pre-formatted APRS Message after the THIRD entry, or on pressing Enter for the canoe number for entry 2 or 3.
Submitting a Withdrawal
In the current MEX client there is no entry screen for Withdrawals, however Withdrawal messages ARE supported by the server and can be entered MANUALLY.
To do this, use the ESC key to return to freeform text entry mode
Enter the withdrawal message in the format below - NOTE THAT THE SYNTAX IS IMPORTANT FOR THE SERVER TO READ THE MESSAGE
x = Checkpoint letter
bbb = Canoe number
hhmm = Time of withdrawal
Up to three withdrawals can be entered in a single message. If there is only one withdrawal to enter, only use one bbb,hhmm block.
WF,123,2021 will log a Withdrawal for canoe 123 at checkpoint F at 20:21
Message Acknowledgement by the server
When any message is submitted from the MEX client, it will wait for an acknowledge message from the server. A transmitted but un-acknowledged message will be displayed in CYAN text in the middle window.
If an ACK is recieved, the message in the middle window will change colour to BLUE, and the next message in the queue (if any) will be sent.
If no ACK is recieved within a pre-configured time period, the message is sent again.
If no ACK is recieved after 6 attempts, MEX will raise an audible alarm to advise the checkpoint operator that thier messages are not getting through. If this alarm is raised, the operator should check thier equipment to ensure that they are still transmitting correctly.
If no ACK is recieved after 10 attempts, MEX will suspend operations. Any new messages entered will still be added to the transmit queue, however MEX will not transmit them until it returns to normal operations mode.
In order to return to normal ops mode, MEX simply needs to hear the TO callsign on air, which will occur within 10 minutes, as the server sends a frequent status message and withdrawal information messages.
Aborting a message
If it is absolutely necessary to abort a message before transmitting, it can be aborted by using the F3 key. This will cause the FIRST message in the queue to be marked as aborted, and the next message will be transmitted.
Aborted messages are indicated in the message window in RED.
At regular intervals, the server will send an APRS bulletin containing the current canoe numbers that have withdrawn from the event.
Bulletin messages appear in YELLOW in the message window (refer to example above) and trigger an audible alert to draw the checkpoint operator's attention to them.
It is also possible for the server and other users to send messages between checkpoints using MEX. If a message is recieved that is specifically addressed TO your checkpoint's callsign, an audible alert is sounded, and the message appears on the MEX message window in GREEN.
It is possible to use the Search functionality built into MEX to find messages relating to a canoe number if required.
To search, press F6 (Note that this will SUSPEND APRS operations, so don't leave the client in Search mode too long)
In search mode, you will be prompted for the competitor number.
The first match of that competitor number will be displayed, and you will be prompted if you want to find further messages. Selecting Y will display the next match and so on until you end the search, or no further matches are found.