Re: [wsjt-devel] extended CALL, FT8 spare bit
OK Joe. It's a consequence of history, then, that neither /M nor /MM are on the "type 1" compound call list. I get it. /MM EME would need flat calm seas, and /M an extremely competent and steady ... or slow ... driver! 73 Gary ZL2iFB -Original Message- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Sunday, 25 February 2018 12:09 p.m. To: WSJT software development Subject: Re: [wsjt-devel] extended CALL, FT8 spare bit On 2/20/2018 4:23 PM, g...@isect.com ZL2IFB wrote: > I noticed that /M and /MM are missing from the "Short-list of Add-on > Suffixes" under the Help menu: is that just a little error on the help > text or a genuine (if surprising) omission from the list? > > I'm puzzled because I worked a /MM station yesterday, painlessly as I > recall. He gave his full call in his CQ message, and again in his 73. > I gave it in my 73 message. The nature of the list of Type 1 prefixes and suffixes has been described here many times, and also in the WSJT-X documentation. You worked a /MM station without any problems because his call with /MM is fully supported as a Type 2 compound callsign. Also. as described in the docs. The list of Type 1 prefixes and suffixes goes way back to the days when WSJT and JT65 were primarily used for EME. Not very many /MM stations are found working EME. -- Joe, K1JT -- 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
Re: [wsjt-devel] extended CALL, FT8 spare bit
On 2/20/2018 4:23 PM, g...@isect.com ZL2IFB wrote: I noticed that /M and /MM are missing from the "Short-list of Add-on Suffixes" under the Help menu: is that just a little error on the help text or a genuine (if surprising) omission from the list? I'm puzzled because I worked a /MM station yesterday, painlessly as I recall. He gave his full call in his CQ message, and again in his 73. I gave it in my 73 message. The nature of the list of Type 1 prefixes and suffixes has been described here many times, and also in the WSJT-X documentation. You worked a /MM station without any problems because his call with /MM is fully supported as a Type 2 compound callsign. Also. as described in the docs. The list of Type 1 prefixes and suffixes goes way back to the days when WSJT and JT65 were primarily used for EME. Not very many /MM stations are found working EME. -- Joe, K1JT -- 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
Re: [wsjt-devel] extended CALL, FT8 spare bit
I noticed that /M and /MM are missing from the "Short-list of Add-on Suffixes" under the Help menu: is that just a little error on the help text or a genuine (if surprising) omission from the list? I'm puzzled because I worked a /MM station yesterday, painlessly as I recall. He gave his full call in his CQ message, and again in his 73. I gave it in my 73 message. 73 Gary ZL2iFB -Original Message- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Wednesday, 21 February 2018 2:45 a.m. To: WSJT software development Subject: Re: [wsjt-devel] extended CALL, FT8 spare bit Itzok -- On 2/19/2018 11:56 PM, Iztok Saje S52D wrote: > Z6 is not (yet) on the list of 330 valid prefixes (prefixes.txt), as > it is rather new. Your comment seems to indicate a serious misunderstanding about the way standard callsigns and compound callsigns are handled in the structured protocols developed for WSJT and WSJT-X. Standard callsigns like Z6ABC, Z6XYZ, ... are fully supported in the structured protocols, and always have been. This is well documented, for example here in the WSJT-X User Guide https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-1.8.0.html#PR OTOCOLS "An amateur callsign consists of a one- or two-character prefix, at least one of which must be a letter, followed by a digit and a suffix of one to three letters." Two different mechanisms are provided for support of compound callsigns. The suffix /P and the prefix ZA/ appear in the fixed list of "Type 1 Prefixes and Suffixes", so the callsigns K1ABC/P and ZA/K1ABC are handled with the Type 1 mechanism. The prefix Z6/ does not appear in the Type 1 list, so calls like Z6/K1ABC are handles as Type 2 compound callsigns. More details can be found in the WSJT-X User Guiude here: http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html #COMP-CALL The list of Type 1 prefixes and suffixes was determined more than 10 years ago, and has remained fixed since then. It will not be changed. All other add-on prefixes and suffixes are supported through the "Type 2" addition to the source-encoding protocol. -- 73, Joe, K1JT -- 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
Re: [wsjt-devel] extended CALL, FT8 spare bit
Itzok -- On 2/19/2018 11:56 PM, Iztok Saje S52D wrote: Z6 is not (yet) on the list of 330 valid prefixes (prefixes.txt), as it is rather new. Your comment seems to indicate a serious misunderstanding about the way standard callsigns and compound callsigns are handled in the structured protocols developed for WSJT and WSJT-X. Standard callsigns like Z6ABC, Z6XYZ, ... are fully supported in the structured protocols, and always have been. This is well documented, for example here in the WSJT-X User Guide https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-1.8.0.html#PROTOCOLS "An amateur callsign consists of a one- or two-character prefix, at least one of which must be a letter, followed by a digit and a suffix of one to three letters." Two different mechanisms are provided for support of compound callsigns. The suffix /P and the prefix ZA/ appear in the fixed list of "Type 1 Prefixes and Suffixes", so the callsigns K1ABC/P and ZA/K1ABC are handled with the Type 1 mechanism. The prefix Z6/ does not appear in the Type 1 list, so calls like Z6/K1ABC are handles as Type 2 compound callsigns. More details can be found in the WSJT-X User Guiude here: http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html#COMP-CALL The list of Type 1 prefixes and suffixes was determined more than 10 years ago, and has remained fixed since then. It will not be changed. All other add-on prefixes and suffixes are supported through the "Type 2" addition to the source-encoding protocol. -- 73, Joe, K1JT -- 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
Re: [wsjt-devel] extended CALL, FT8 spare bit
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
Re: [wsjt-devel] extended CALL, FT8 spare bit
On 20/02/2018 00:38, Laurie, VK3AMA wrote: On 19/02/2018 8:35 AM, Bill Somerville wrote: 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. Bill, I wonder if the OP was referring JTDX rather than WSJT-X. There were recent reports of Z6 Calls being incorrectly logged as ZA coming from JTDX From the latest JTDX release notes... Discarded all changes done to Z6 prefix support: it has been supported in all versions 18.1 and new changes violated WSJT-X protocol. de Laurie VK3AMA Hi Laurie, maybe. We are well aware of the JTDX issues with unwise changes adding new type 1 prefixes. After discussion with Igor he has reverted his changes so that JTDX's type 1 prefix and suffix list matches those of WSJT-X, WSJT, JT65-HF and MSHV again. Type 1 prefixes are fixed and only really present to maintain backwards compatibility with the original JT65 v1 protocol. Type 2 prefixes were introduced several years ago and use a more generic source encoding that caters for all prefixes so long as they fit a particular pattern, this includes ES, KC4 and Z6 which were unnecessarily added to the type 1 prefix lists in JTDX. 73 Bill G4WJS. -- 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
Re: [wsjt-devel] extended CALL, FT8 spare bit
On 19/02/2018 8:35 AM, Bill Somerville wrote: 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. Bill, I wonder if the OP was referring JTDX rather than WSJT-X. There were recent reports of Z6 Calls being incorrectly logged as ZA coming from JTDX From the latest JTDX release notes... Discarded all changes done to Z6 prefix support: it has been supported in all versions 18.1 and new changes violated WSJT-X protocol. de Laurie VK3AMA -- 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
Re: [wsjt-devel] extended CALL, FT8 spare bit
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. -- 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
