hash22calc.exe cannot replicate a hash calculated by ft8code.exe, so I've made a patch to fix it: updating hash22calc to allow nonstandard callsigns as input. It also changes the output format.
The below text has also been posted to https://sourceforge.net/p/wsjt/wsjtx/merge-requests/19/ where it is formatted to make it easier to read. This patch cleans up hash22calc.exe so that it's more inline with ft8code[.exe]. The 22-bit hash for YW18FIFA is 0771524 or in binary 0010111100010111000100 The first 12 bits are 0010111100 This string of bits are the start of one of ft8code's sample messages: ## WSJT-X 2.7.0-rc6 $ ./ft8code "CQ YW18FIFA" Message Decoded Err i3.n3 ---------------------------------------------------------------------------------------------------- 1. CQ YW18FIFA CQ YW18FIFA 4. Nonstandard call Source-encoded message, 77 bits: 00101111000100000000000000001110111011100011100111111010101100001001110001100 ... To find the hashes of most callsigns, a user can employ hash22calc to calculate the hash, but not for this one: ## WSJT-X 2.7.0-rc6 $ ./hash22calc "YW18FIFA" Invalid callsign Usage: hash22calc <callsign> I've updated hash22calc[.exe] to allow longer callsigns, as are found in hashes generated elsewhere in wsjtx software. That's the crux of this patch. But just in case someone might have previously found the error message from hash22calc useful for checking if a callsign was a valid shorter standard callsign, I've added back this user feedback more explicitly. I've also made the hash value print first to make it easier to extract programmatically in future, and added code to stop invalid characters from being accepted. Here's the new output in its entirety: ## With this patch $ ./hash22calc "YW18FIFA" 0771524 YW18FIFA Valid standard callsign: no Valid nonstandard callsign: yes If you don't like the additional lines of text, or perhaps you think it should be moved to another program, then you can delete the block of code under the comment "!also print if it's valid to remove it." The patched version also accepts callsigns which are longer than an allowed "type 4" callsign because that is also allowed by ft8code. For example: ## WSJT-X 2.7.0-rc6 $ ./ft8code "CQ vk0muchTooLongCallsign" Message Decoded Err i3.n3 ---------------------------------------------------------------------------------------------------- 1. CQ VK0MUCHTOOLONGCALLSIGN CQ VK0MUCHTOOL * 4. Nonstandard call Source-encoded message, 77 bits: 01000101011010110101100001100111111001001010010011011101011110011000000001100 14-bit CRC: 10111011010101 83 Parity bits: 10110010011101111100011011010111110000101010111110001100100000111100110011111011011 Channel symbols (79 tones): Sync Data Sync Data Sync 3140652 31346620217433554737540021266 3140652 34432675223740637415507542722 3140652 ## With this patch $ /hash22calc "vk0muchTooLongCallsign" 1137640 VK0MUCHTOOLONGCALLSIGN Valid standard callsign: no Valid nonstandard callsign: no 1137640 is 0100010101101111101000 (22 bits) the first 12 bits are the start of the output from ft8code: 010001010110 So it can now match ft8code's existing and past output, which does indeed allow hashing of longer callsigns than even allowed by the nonstandard call format. Hope this patch made use of. I have been enjoying learning about the intricacies of the FT8 format and now the curiosities of Fortran. Peter (Pengo Wray) VK3PGO As background to explain the ft8 message for anyone trying to follow along, it's "type 4" FT8 message, which is the type that includes a longer, "nonstandard" call. CQ has been set by turning on bit #74 ("c1"), which also tells the receiver that the long callsign field is the sender's call, that it's a CQ message, and to ignore the first field (a 12-bit hash). Rather than leave the hash field empty, the hash of the sender's callsign is placed in this field by wsjtx, presumably for additional redundancy, or perhaps in case their call still doesn't fit in the extra wide nonstandard call field. The following patch is also viewable at: https://sourceforge.net/u/vk3pgo/wsjt/ci/32e8d814d3b5bb2061a5555aac35d9998061baea/ --- a/lib/77bit/hash22calc.f90 +++ b/lib/77bit/hash22calc.f90 @@ -3,14 +3,17 @@ use packjt77 - character*13 callsign + character*80 callsign character*1 c character*6 basecall logical cok + logical charok + character*38 valid_chars + valid_chars = ' 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ/' nargs=iargc() if(nargs.ne.1) then - print*,'Given a valid callsign, print its 22-bit hash.' + print*,'Given a callsign, print its 22-bit hash.' print*,'Usage: hash22calc <callsign>' print*,' e.g. hash22calc W9ABC' go to 999 @@ -25,17 +28,38 @@ callsign(i:i)=c enddo -! check for a valid callsign - call chkcall(callsign,basecall,cok) - if(.not.cok) then - print*,'Invalid callsign' - print*,'Usage: hash22calc <callsign>' - goto 999 + charok = .true. + do i=1, ilen + if (index(valid_chars, callsign(i:i)) == 0) then + charok = .false. + exit + endif + enddo + + if(.not.charok) then + print*,'Invalid callsign: contains invalid characters' + print*,'Usage: hash22calc <callsign>' + goto 999 endif -! calculate the hash +! calculate and print the hash n22 = ihashcall(callsign,22) - write(*,'(a,i7.7)') callsign,n22 + write(*,'(i7.7,1x,a)') n22,trim(callsign) + + ! also print if it's valid + write(*,*) + call chkcall(callsign,basecall,cok) + if(cok) then + write(*,'(a)') 'Valid standard callsign: yes' + else + write(*,'(a)') 'Valid standard callsign: no' + if (ilen <= 11) then + write(*,'(a)') 'Valid nonstandard callsign: yes' + else + ! exceeds 11 characters + write(*,'(a)') 'Valid nonstandard callsign: no' + endif + endif _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
