UI-View on HF Bands

Setting up and using UI-View on the HF bands By Jim G0JXN

  • Introduction

    Operating UI-View on the HF bands is different in a number of respects to operating on VHF. These notes are intended to explore these differences on the basis that the reader already has some experience with UI-View on the VHF bands.

    (Thanks go to Jim for writing this article for the website de Andy, M0CYP)

  • Fequency Setting

    UI-View being a mode that uses the same protocol as Packet it has naturally followed the same practices. On the VHF bands it employs FM modulation while on HF, with the exception of some activity on 10m where FM is used, SSB is used. Not SSB as we normally think of it with phone but with just two tones. These are generated by a TNC or a computer program and results in two corresponding sideband frequencies when SSB is selected on the tranceiver. The tones are always 200Hz apart but their actual frequency is dependant on the standard used, of which there are two: -

    1. KAM 1600Hz & 1800Hz i.e. centred on 1700Hz
    2. PK-232 2110Hz & 2310Hz i.e. centred on 2210Hz

    Where a carrier (dial) frequency is quoted it is normally for KAM tones and therefore when PK232 tones are used it is necessary to make an adjustment to the carrier frequency of 510Hz. With UI-View it is normal to use LSB on all the HF bands so if PK-232 is used the carrier should be increased by 510Hz. The exception is the 30m band where the carrier is normally quoted as 10.151MHz. While the sidebands on LSB will be within the UK allocation there is always the possibility that there may be out of band carrier leakage. It is therefore usual practice in the UK to use USB with the carrier moved to 10,147.600Hz so that the sideband tones still fall at the same frequencies. The fact that they are now reversed does not affect the operation, as it is the difference between the tones that conveys the data. If PK-232 is used with USB then the carrier frequency must be reduced by 510Hz. If you use the AGW Packet Engine with the computer sound card instead of a TNC please note that it uses PK-232 tones. I would also suggest that you download Ralph Milnes', KC2RLM, excellent pages on the subject of AGW at: - http://patmedia.net/ralphmilnes/soundcardpacket/

  • Baud Rate

    On VHF/FM UI-View uses a baud rate of 1200 whereas on HF, again with the exception of some SSB activity on the 10m band, 300 baud is used to keep within accepted digimode practice. This means of course that the transmission of data will be four times slower and the possibility of collisions will be correspondingly greater. In the case of VHF/FM there is the capture effect where normally the stronger signal will prevail and the weaker one is lost. This is not the case with HF/SSB, any serious QRM will result in both signals being corrupted and not being decoded.

  • Distances

    Unlike VHF, where paths between stations tend to be consistent on a dedicated channel, HF communication is very much dependant on conditions and can vary from non-existent to a 1000 miles+ compare this with VHF at around 15 miles+. These conditions can change in a matter of minutes and there is the usual QRM, QRN problems that one experiences with other modes. While the ear and brain may allow phone or CW communication under quite adverse conditions any corruption to the UI-View data stream will result in it not being decoded.

  • Frequencies to use

    UI-View/APRS Frequencies

    Band Frequency Mode Baud Rate Remarks
    10 29.250 FM 1200 Not USA
    15 21.117 SSB 300 Africa
    17 18.102 SSB 300  
    20 14.103 SSB 300 DX
    20 14.105 SSB 300 Europe
    30 10.147,600 SSB* 300 UK
    30 10.151 SSB 300 Not UK
    40 7.035 SSB 300 Not UK


    • SSB is all LSB except * which is USB
    • No Crossband on 14.103 please this channel is for DX
  • Increasing Success

    So how might we maximise our chances with UI-View on the HF bands? As noted above the chances of collisions are higher with 300 baud. If the length of the frame is kept to a minimum this will reduce the opportunity for a collision. Compare the two frames below. They both convey the essential information on location, type of station and operator and yet one is almost twice as long as the other. Do you really need to give your address? After all your location will be shown on the receiving stationís map. And other information can be shown in the Status Text.

    • G0JXN-14>APU254,RELAY,TRACE3-3,WIDE3-3
    • =5143.11N\00001.71W-Cheshunt Herts. Jim. jim.g0jxn@ntlworld.com {UIV32}
    • G0JXN-14>APU254,WIDE6-6
    • =5143.11N\00001.71W-Jim {UIV32}

    And what about the paths? Both will go six hops but while you might have the luxury of seeing the exact path your signal is taking with TRACEn-n, each time your signal is digipeated the frame will get longer by that stationís callsign/alias.

  • SSID

    You will notice that in the frames above I have used a SSID of -14. Some of the HF operators use this to signify that it is a 14MHz station in order that it might be identified as such when it has been digipeated. On 30m -10 is used. This does unfortunately cause a problem for APRS stations that use SSIDs to indicate the station classification i.e. HOME, CAR, LORRY etc.

  • Beacon Interval

    Adjust the interval of your beacon according to condition. If they are poor you may wish to reduce it to a minimum but if they are good be a responsible operator and donít clutter up the channel unnecessarily.

  • Messages

    Avoid overloading the channel. Keep the message lines as short as possible and of course use abbreviations. There is a slight twist when it comes to the path you prescribe. If you use TRACEn-n the receiving station will send the ACKnowledgement with the path defined in the same way as the signal was received, i.e. with specific callsigns. In a multi hop situation part of the forward path may no longer exist by the time the ACK has worked its way back through several digipeaters, for any of the reasons given above. If you use WIDEn-n the receiving station will simply define the path in the same way and the ACK signal will seek any path that is available. There is however an exception to this where the forward path is direct. The receiving station will ignore either TRACEn-n or WIDEn-n and attempt to send the ACK direct. Of course if that station is a QRP station the ACK may never be received. The solution to this situation is to use WIDEn-n increasing the first n by one e.g. WIDE3-2. The receiving station will now identify that the signal has been received via a digipeater and send the ACK with a path WIDE3-3. This does not work with TRACEn-n.

    As you might gather by the attention I have paid to the matter of ACK this can be a problem on HF. Once you have established communication with another station donít worry too much about getting ACKs. If you keep sending repeats of a line, which the other station may already have on their screen anyhow, you will just clutter up the channel unnecessarily. If you get any gaps in the received lines simply prefix your next message line with the missing line number(s) thus: - 09,11?Normal message.

  • Digipeater

    Unless there is another digipeater locally, doing a better job than you can, have your digipeater enabled. When it comes to Crossband Gateways the subject is contentious. I am personally against this. I find that in the 2 years I have been playing with UI-View on HF I can rarely communicate with the 2m stations I see scattered all over Europe. Many are mobiles, sending out their position information about every minute, which couldnít communicate with me unless they parked up anyhow. It just serves to clutter up the channel.

  • BeaconNet

    BEACONet is a propagation project that uses a PSK31 add'on version of UI-View. The beacons transmitted use a Grid Square Locator rather than Long/Lat and include coded information about the transmitter and aerial parameters.

    Frequencies and information about the project is available from the BEACONet web site at: - www.rochesterny.org/beaconet