I quote: "The developers will not allocate the needed spaces in the
program to correct the issue. "
The issue has NOTHING to do with the 'needed space' in the program, and
ALL to do with the 77 bits of the data package being sent. If it was
a simple change in the program it would have been done, but in order to
be able to send the entire data package twice within the ~13 second
windows, the data is limited to 77 bits. There is no additional space
available. There was one change made to the FT8 protocol about 2 or 3
years ago moving from a 75 bit package to a 77 bit one. That involved
having to revise the encoder/decoder and caused users of the older
versions of WSJT-X to upgrade to a new version. Any further changes
to the data package would create a brand new protocol as it would no
longer be FT8.
This has been a limitation from the beginning, and has been noted in the
User Guide. There is one more choice people have: make sure that
their 'lookup' pages on QRZ and the like are updated with their proper
location and grid, and create pages for /1, /2, /3, etc extensions with
other locations and grids for use if those normal extensions are
authorized for use by their governing bodies.
Neil, KN3ILZ
On 12/11/2021 8:19 AM, DX Jami wrote:
Philippe,
That is a known and common problem built into WSJT-X. Compound calls
can not communicate with compound calls. It is a real estate problem
within WSJT-X. The developers will not allocate the needed spaces in
the program to correct the issue. I understand that. They want to
keep the WSJT-X program size small and simple. I have the same problem.
You have at least two choices.
1. ignore the other compound-call station
2. if you really need that DXCC or station ... go into your set up
and change your call to a standard call. You may have a problem since
you sometimes use ZS1 as a prefix.
Good luck.
Danny
AH6FX/W4 - Virginia
On Saturday, December 11, 2021, 07:22:22 AM EST, James Shaver (N2ADV)
via wsjt-devel wrote:
Please take note of section 7.5 of the User Manual:
“ Angle brackets imply that the enclosed callsign is not transmitted
in full, but rather as a hash code using a smaller number of bits.
Receiving stations will display the full nonstandard callsign if it
has been received in full in the recent past. Otherwise it will be
displayed as < . . . >. These restrictions are honored automatically
by the algorithm that generates default messages for minimal QSOs.
Except for the special cases involving /P or /R used in VHF
contesting, WSJT-X 2.4 offers no support for two nonstandard callsigns
to work each other.”
Note the very last sentence in that paragraph.
73,
Jim S.
N2ADV
On Dec 11, 2021, at 3:29 AM, tmp1--- via wsjt-devel
wrote:
Good day everyone,
I operate with the compound call sign ZS1/F5FDV when I am in South
Africa.
I tried to contact YO4RYU/MM with the call sign in FT8 mode with
WSJT-X v2.5.2 for Mac Big Sur.
The option Tx message to Rx frequency window is ticked. Auto Seq is
ticked.
YO4RYU/MM responded to me but the only frame that the software could
send on my side was ZS1/F5FDV
I tried to select the reply messages manually but it was not succesfull.
Event if the proper selection seemed to be made on the display after
I selected it manually, the same message ZS1/F5FDV was
displayed in the Rx Frequency box and send out.
Y04RYU/MM steadily sent his message YO4RYU +02, which
tends to prove that my message did not change from
ZS1/F5FDV despite his answer. I do not think this lack of progress in
our exchanges was due to poor signal or QSB because the reports were
quite good on both sides.
Your will find a screen copy attached.
73,
Philippe F5FDV
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
