[wsjt-devel] extended CALL, FT8 spare bit

[Iztok Saje]

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, 

Re: [wsjt-devel] Looking for UDP listener written in C#/.Net

[walt williams]

check out "GridTracker" by N0TTL
https://tagloomis.com/grid-tracker/

73s
N5CDE

On Sun, Feb 18, 2018 at 1:23 PM, Alan Rovner  wrote:

> Hi guys, has anyone written a UDP listener for WSJT-X in C#/.Net?  I'm
> especially interested in how you defined data structures and packet types.
> Please contact me off the list if you have any info.
>
> TU, 73,
> Al, K7AR
>
> 
> --
> 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
>
--
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

[wsjt-devel] Looking for UDP listener written in C#/.Net

[Alan Rovner]

Hi guys, has anyone written a UDP listener for WSJT-X in C#/.Net?  I'm 
especially interested in how you defined data structures and packet 
types.  Please contact me off the list if you have any info.


TU, 73,
Al, K7AR

--
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

[wsjt-devel] Incorrect tooltip in configuration

[Alessandro Gorobey via wsjt-devel]

Hi All,

in release > r8447 the tooltip of
file-->settings-->advanced-->4x tone spacing
is incorrect. The file is Configuration.ui

This happened with rename of checkbox
-   
+   

The actual is:

htmlhead/bodypDecode on-the-fly 
rather than at end of Rx 
sequence./p/body/html



I think can be:

htmlhead/bodypGenerate Tx audio 
with quadruple the normal tone spacing.  Intended for special LF/MF 
transmitters that use a divide-by-4 before generating 
RF./p/body/html




--
73
Sandro
IW3RAB

--
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

[wsjt-devel] Email test

[Black Michael via wsjt-devel]

Seeing if the devel list is back up after the sourceforge move
de Mike W9MDB



--
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