Joataman Webpages

A Collection of Interests, Activities and Projects


SQUID (Super QUick IDentification)

A Method for Station Identification

General Philosophy of SQUID:- The idea for SQUID came to me after thinking about different schemes for making the "first contact" over long distances in marginal conditions where the window of opportunity in propagation terms is very limited. Initially a minimal scheme which provided station ID and operational mode or signal report exchange was saught after. At the bottom of this page are several posts circa 19/12/01 to the RSGB and LowFer email groups which give some of the parameters. However, subsequently the protocol was split into two protocols which are specialised for specific purposes. The SQUID protocol became solely for station ID in the minimum time, and a second protocol was developed for exchange of information which I call GENIE (GENetic Information Exchange). That protocol is described in another page located here (GENIE).

Proposed Protocol for SQUID:- The SQUID scheme was developed to have the following characteristics to assist in rapid identification of stations -

  1. Be as short as possible.
  2. Contain the minimum number of tones for ease of implementation (DFCW users can manage two tones, target for SQUID is three and should not be too difficult). The use of three tones narrows the bandwidth and allows far simply tone generation. Also should be able to use serial port to control a non-soundcard based interface.
  3. Each sequence of tones should possess the property such that when they are repeated end to end (no times when there isn't a tone), they can be unambiguously decoded against all the other sequences in the set. One of the weaknesses of QRSS/DFCW is that if you don't see a tone, you cannot be sure if that QSB has taken out the tone, or it actually is a space.
  4. Given the reception of any sequence of tones (short band opening), it must be possible to decode the ID. That is, if the ID consists of, say, a sequence of 5 tones which are transmitted continuously, as long as any consecutive 5 tones is sufficient to decode the ID. This allows identification of a station even if the the band opens, say, half-way through a cycle of the sequence and continues to the end of that cycle and half-way through the next cycle. There is no need for synchronisation of any sort as part of the decoding.
  5. Each sequence will contain at least the highest frequency and the lowest frequency. This eliminates any need to somehow determine absolute frequency as part of the decoding. For example, if you chose 1 to N tones to encode information, how do you determine whether you are receiving tone 1 and tone 2, or, tone 2 and tone 3 ? The answer is either fiddle until the message makes sense or wait for some synchronising bit to tell you. In SQUID the ambiguity is eliminated directly in the encoding.

SQUID Format:-

ID Number
Tone Sequence
Allocated Station
1
AAABC
2
AAACB
3
AAACC
4
AABAC
5
AABBC
6
AABCB
7
AABCC
8
AACAB
9
AACAC
10
AACBB
11
AACBC
12
AACCB
13
AACCC
14
ABABC
AXSO (VK2ZTO)
15
ABACB
RIC (VK2ZTO)
16
ABACC
VK2ZTO
17
ABBAC
18
ABBBC
19
ABBCB
20
ABBCC
21
ABCAC
22
ABCBB
23
ABCBC
24
ABCCB
25
ABCCC
26
ACACB
27
ACACC
28
ACBBB
29
ACBBC
30
ACBCB
31
ACBCC
32
ACCBB
33
ACCBC
34
ACCCB

Suggested Tone Spacings for Argo Display:-

ARGO Mode
Argo Screen Span
Suggested Tone Spacing
Bandwidth Used
10 second
27Hz
1 or 2Hz
2 or 4Hz
30 second
6.7Hz
0.5Hz
1Hz
60 second
3.3Hz
0.2Hz
0.4Hz
120 second
1.7Hz
0.1Hz
0.2Hz

Spacing is not critical as there is only different three tones which makes it easier if the transmitter is generating the tones by pulling a crystal. For soundcard driven systems the spacing can be as small as can be easily distinguished on the Argo screen. Soundcard-based software will produce frequencies which will be monotonic (A will never be between B and C). For systems which generate the tones via such methods as pulling a crystal, a wider spacing might be prudent to ensure monotonicity.

Example ID Sequence (for RIC - ABACB):-

I have reserved ID sequence #15 for RIC beacons. The sequence is ABACB. The 'A' tone is the highest frequency, the 'B' tone the middle frequency and the 'C' tone the lowest frequency. The sequence is transmitted continuously with no pauses between sequence cycles.

Initial Ideas:-

" I have a further suggestion to make. I preface this suggestion with Rik's clarification. The suggestion is not a replacement for the tried and true methods, but a tool to search out the limits of the medium we are playing with. For those pioneering efforts (like Bob Vernall's (ZL2CA) crossing of the Pacific on 136kHz) a super specialised scheme is justified. Here goes.

The first stage of laying the tracks down for others to follow in any pioneering effort is not to lay down a highway, but simply to establish a link, however tenuous. Explorers, to establish that they had indeed made the journey often just left a marker (sometimes just a pile of stones) to verify the feat.

Most of these pioneering efforts (but not all) have used beacons to establish the parameters. The first stage of receiving a beacon is to simply unequivocably identify it. This technique has long been used in navigation. Lighthouses don't send morse code or a callsign, they send a unique flash pattern which unambiguously identifies that "beacon".

I suggest that we adopt the same idea. I propose a three "dot" 3-tone sequential protocol which does not attempt to transmit the alphabet, but simply to identify the transmitting station plus the TMO reporting system. Beacons would only transmit the the ID part, those calling for a QSO could transmit the ID plus a CQ code, those engaged in a QSO could transmit the ID part plus a TMO part. The sequences must be chosen such that when they are run end to end (no spaces anywhere) they can be unambiguously identified. This ambiguity should extend to both beaconing sequences and QSO sequences. This would mean having to throw away some sequences. This may mean that a three "dot" 3-tone protocol may not have enough unique sequences to cover the expected number of participating stations plus TMO and CQ codes and would have to be extended to either more "dots" or more tones. The barest minimum should be aimed for to allow wider spacing of tones on a given resolution Argo screen and to minimise elapsed time for the unique identification of the station (to take advantage of the short opening times on the long hauls). The codes should still be much easier to decode by eye than a 7-tone system.

I haven't had time to do the necessary evaluation to see how many unique and also sequentially unambiguous codes are available from a 3 "dot" 3-tone system, but it would need to cover 4-info codes (TMO + CQ) and a limited number of station IDs (5, 10, 15... ?). I will try and do this on the weekend or before. I suspect a 3 "dot" 3-tone scheme will not have enough unique sequences. However, even a 4 "dot" scheme would only take 8 minutes to send the an ID plus TMO or CQ code using 60 second dots. "

and

" Having done a quick scratchpad analysis of SQUID, it would seem that a 3-bit, 3-tone protocol won't produce enough unique codes. Will try 4-bit, 3-tone next.

The criteria I set for the sequences are pretty severe. If someone is, say, transmitting a sequence of ABC then running this continuously produces a sequence of ...ABCABCABCABCA... This means that if someone only gets a three-tone snippet of the transmission, then sequences CAB and BCA can't be used by other transmitters as they would be ambiguous with the ABC sequence. This rapidly eliminates candidate sequences.

I was discussing this idea with my son (trying to get him intrigued enough so that he would write some program to allow automatic generation and selection of sequences :-) and he remarked that it was like trying to assign an unique "genetic" sequence to each transmitter and "splicing" an operational/signal report mode sequence onto that transmitter "genetic" sequence. Good analogy. Maybe it should be called GENIE - for GENetic IdEnt :-) He also suggested that instead of "splicing" two sequences for station ID and operational/signal report mode together, it might shorten the sequences to combine them into one unique sequence. Mmmm.... Good idea, except I remarked to him that I am already in territory that few will want to go and that extra step in decoding would not be attractive.

As Bob Vernall has indicated a "temporary" call register for ID sequences should not cause too much angst. On the LWCA site there has been information about beacons for LowFer, MedFer and HiFer beacon for a long time giving information about location, frequency, mode, operator, one to five character ID, etc. A similar table maintained somewhere on the Web with an extra field giving the n-bit, n-tone sequence shouldn't be onerous. Bob also points out that this idea is not without precedent if you consider the single "Q" sent by himself instead of "ZL6QH" as a station ID. That transmission took 5-bits. I hope to get a total of 8-bits to transmit an unique station ID and operational/signal report mode.

If this idea is feasible one of the things that might need to be decided is the number of required station IDs. Taking the LWCA list as an indicator, the LowFer list has some 60 odd participants. So the absolute upper limit would be, say, 60. Accounting for willingness to move away from QRSSS and other modes would surely reduce that to less than half (30). Taking into account interest, motivation, inertia, NIH and difficulty factors - I would be surprised if there was a need for more than 15 (more likely 10) as a maximum. I will initially try for sequences assuming 20 station IDs (these could be re-used or re-assigned for different bands). "