Ok, so explain to me why K2GC/P formats properly? I could certainly understand the issue more if my callsign were longer... but with such a short callsign I am not sure why all this 'making it fit' comes into play.
furthermore, so how is one supposed to operate? do I just call cq with no grid, and the software will out it in the exchange later? On Tue, Dec 11, 2018, 9:49 AM Bill Somerville <[email protected] wrote: > On 11/12/2018 01:41, Mike Maynard wrote: > > So I installed v2.0 GA on my 'mobile' setup today. I no longer have a > grid square in my standard messages with /M on my callsign. > > If I just put in my base callsign the grid square shows up fine. once I > change to K2GC/M the grid square drops out. > > Tried it on my shack setup too (also 2.0GA) and it does the same thing. > > this was a non-issue in 1.9.1 Did I miss something? or is this a bug? > > > -- > Mike > K2GC > www.k2gc.net > > Hi Mike, > > in the new 77-bit payload FT8 and MSK144 messages the handling of > callsigns has been unified, there are three ways of inserting a callsign > into a standard form message, either a standard callsign, a complex > callsign, or a hash code representing the callsign. Complex callsigns > include compound callsigns, longer callsigns that don't fit the WSJT-X > standard callsign pattern and those including standard suffixes like /M. > Note that all of these complex callsigns are now treated uniformly, there > are no type-1 or type-2 compound callsigns with the 77-bit messages. The > CQ, QRZ and similar words count as a standard callsign. The message can > contain two callsigns and some extra information except when one of the > callsigns is a complex callsign. The extra information can be a > grid-square, a report, a R-report, RRR, RR73, or 73. So that reports can be > exchanged with both callsigns printed when a complex callsign is involved, > one callsign can be represented by a hash code which uses less payload bits > than the callsign in full, this leaves space for one of a RRR, RR73, 73, > report, R-report, or a grid, but note that for the last three (reports or > grid) the complex callsign must be the one sent as a hash. > > So, given the above, a CQ message with a complex callsign cannot include a > grid-square because the only way to do so would be to replace the callsign > with a hash code and that will not work as hash codes can only be converted > to callsigns at the receiving end if the callsign has previously been > decoded and even then there may be two or more callsigns that map to the > same hash code, the hash codes have a one to many (actually one to few) > relationship with the callsigns they represent and where two or more > callsigns of interest map to the same hash code is what is known as a hash > collision. > > The bottom line is that special handling of basic suffixes like /M /P /A > /1 /2 ... /0 and other specified prefixes that had special encoding in the > 75-bit message format (type 1 compound callsigns) have been sacrificed to > allow message space for a uniform approach that works for vastly more > variations of complex callsigns including those originally covered by > type-1 special cases. > > You can send a message to you QSO partner including your grid square but > it must be of the following form: > > G4WJS <K2GC/M> FN03 > > this is fine once a QSO has started, you could sign off with it for > example, because your full call would have been sent earlier in the QSO and > your QSO partner and anyone listening will have the correct hash code > mapping to decode the message as shown above. Anyone not having the hash > code would receive the message above as: > > G4WJS <...> FN03 > > which is not much good to them. In the same way that sending: > > CQ <K2GC/M> FN03 > > would not be any use and in this case we even flag it as a bad message and > don't allow it to be sent. > > Just to complete the picture with complex callsigns, there are a couple of > special cases for the NA and EU VHF contest modes that allow /R and /P > respectively since these are necessary for many stations in such contests. > > 73 > Bill > G4WJS. > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
