Hi Bill,
Z6 is not (yet) on the list of 330 valid prefixes (prefixes.txt), as it is
rather new.
For numeric: Indeed. As numeric length is reasonable long,
we might say "replace last numeric characters", then G4 becomes G250,
and S52D becomes S5000D if needed.
Using two bits for position is another approach, similar to alphabetic part.
Ugly hack, that solves most of the problems with CALLs, but not all.
For all, maybe additional beacons:
72 bits are split into regular 28 "JT65" call, one A/B bit and 43 data bits.
With A/B and 43+43 bits we can really encode any call.
WSJTX might keep list of heard beacons (transmitted once in 10 minutes) to
translate
any "JT65" call to any real call.
If they are valid for one hour, and a list is maintained by, say, PSK reporter,
it might work.
Unfortunately, it calls for misuse, and I would not be happy if S52D translates
to QRMQRM for a while.
Adding such message to every QSO (to block misuse) is too much overhead.
73 gl
Iztok, s52d
From: Bill Somerville g4wjs:
On 18/02/2018 21:16, Iztok Saje wrote:
Z6/S56A had some nice stories, I guess some people who managed QSO do
not even know they have Z6 worked.
Hi Iztok,
your proposal looks interesting and using one or more of the extra FT8
payload bits for better exotic callsign handling has been considered. I
am confused about what he issue with the above Z6/S56A callsign is as
that is a valid type 2 prefix compound callsign and should be handled
reasonably well by the existing source encoding.
I do have some doubt about your proposed extension mechanism as it seems
to sometimes rely on a regular base base callsign being present in the
exotic form which may not always be the case, in fact the contraction to
a regular base callsign may be some other operators callsign. For
example you suggest that if I were allowed to use, say G250WJS for some
250th special celebration. But contracting this callsign to G2WJS plus
50 encoded in the grid word would be incorrect as my call is G4WJS.
73
Bill
G4WJS.
On 02/18/2018 10:16 PM, Iztok Saje wrote:
Hello!
With FT8 avalanche on shortwave, we are facing more and more problems with
CALLs that can not be encoded in JT65/FT8 etc.
Z6/S56A had some nice stories, I guess some people who managed QSO do not even
know they have Z6 worked.
I am not sure have I worked RI1ANO or RI150ANO? I put both into LotW, just to
be safe.
One spare bit can be used to indicate FT8-EXTENDED call: when used, locator
square 15 bits are replaced by additional information.
Users can define classic "JT65" call and "FT8 extended call", like S56A and
Z6/S56A, RI1ANO and RI150ANO,
DA0WRT and DA0WRTC, OH2YOT and OH2YOTA etc.
Out of 15 bits, one indicates NUMBER_only. If set, then additional number
(encoded in remaining 14 bits) is appended
after last numeric character in the CALL.
Example: RI150ANO is coded as RI1ANO + extended 50, thus producing RI150ANO.
This is common problem for special calls targeting WPX award. For example,
several S5 stations added numbers.
I can imagine S5242D for Towel Day, or S52356D to celebrate 356 days long year,
or so.
If not numeric, then remaining 14 bits are split into:
- two bits for position (prefix, after first alpfabetic character, after first
numeric character, append to the end)
- one bit to add "/", either Z6/S56A or S%6A/Z6 depending on position bits
- 11 bits are used to encode two characters from NULL, A-Z, 0-9
(as there are some more possibilities, some two character combinations might be
added).
Stations using extended calls use extended CALL, other answering (and old WSJTX users)
call them with "JT65" CALL.
SO, extended call bit, when set, refers to sender only. When two stations with
extended calls have QSO, they
use own extended call and others JT65 call.
Extended call serves purpose to provide proper identification according to
license, while short JT65 call is used
for QSO, but has no legal impact. We use same approach with compound calls
today.
JT65/MSK144 community is smaller and it can handle exceptions better.
One possibility is to add comment line (TX4 freetext) to map JT65/classic calls
to FT8-extended call.
Maybe beacon every 10 minutes, and clients can keep map?
There are calls that can not be encoded with proposed scheme: for example
DR5LUTHER, VK100ANZAC.
But, they are really rare, and probably even some logging programs might object.
Best 73, gd DX
Iztok, S52D
p.s.
With more and more people coming to FT8, congestion is severe. KN spare bit as
well as random delayed repetitions on CQ answer
would help us make more QSOs.
On 10/17/2017 08:07 AM, Iztok Saje wrote:
Hello!
In order to lower QRM, increase QSO rate and speed up user education, there are
several proposals, all
efectivelly blocking QRM transmission in different conditions.
1. one spare FT8 bit is used as KN bit (Do not transmit unless invited)
2. When there are several responses to CQ, implement Aloha principle (repeated
retransmissions are randomly blocked)
3. Do not transmit if time left is too short for good decode.
For all three cases where TX is automatically disabled, normally red "Enable
TX" shall go yellow
for duration of blocked TX period. There should be manual override with
keyboard, in case operator knows he has to transmit.
KN bit (one of spare bits):
--------------------------------
For a century KN on the end of CW transmission means "only invited station
shall transmit, others stand by).
In FT8, quite often we see unwanted transmissions. People call in the middle of
the QSO etc, probably
overlooking when to press "stop TX".
With FT8 HF dominance, it makes sense to use one of three spare bits to
indicate KN.
WSJTX-X shall add KN bit on all frames but CQ/QRZ (when everyone is invited)
and final 73 (where KN omitting is effectively
meaning CQ/QRZ).
When KN is received, station shall check:
- if my call is in the frame, I can transmit.
- if I am in the QSO, and about to send final TX lines, I can transmit (messgae without
calls, like "TU 73 LOTW")
- if originator of KN bit is not in my qso, ignore KN, I can transmit (some
other QSO)
but:
do not send to originator if I am not in the QSO. This shall work even if TX/RX
tones are not same, there is no need to
call DX in the middle of QSO. Wait till she is listening for another QSO
partner.
Usage of KN bit is not needed so much in other modes, so it is justified to be "FT8
specific".
By checking both calls, we can avoid KN bit misuse to get faster response
(sending fake KN message to stop legitimate callers).
This is to be considered for wsjtx-1.90, probably. But in some time, most of
clients would resoect KN bit
(even on CW some stations do not)
Aloha
-------------
Sometimes even S52D calling CQ receives several answers, similar strength, so
no response is decoded.
All calling stations just repeat calling. Classic action is: stop calling CQ
and wait till somebody stops calling,
until one station is decoded. Or send "PSE SPLIT".
This can be done automatically: when answering CQ, transmit twice. On third
call, use 50% probability to transmit or not
(so, it makes it more likely for one answer to get decoded).
On fourth and next repetitions, use 33% probability to transmit.
Of course, regardless of frequency: there is often congestion on other tones as
well.
Combined with split, this can help even rare DX to make more QSOs.
This is not hard to implement, but can help a lot. Maybe too late for 1.80.
Short transmissions
-------------------
Very often, I am too late to select next QSO partner, so I start transmitting
late. Thus, I generate only QRM, as
my transmission can not be decoded. SO, no FT8 transmission starts more then 5
seconds after period starts.
This can go to 1.80, it is easy to implement and test.
It is mode specific, and again, mostly needed on FT8.
Best regards, mni DX, 73 es GL
Iztok, S52D
s52d FT8 status: 165 DXCC, over 5000 QSOs, K1JT on three bands
Pravni pogoji / Legal disclaimer
Telekom Slovenije, d.d., Ljubljana <http://www.telekom.si/disclaimer>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
