Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

donate to eham
   Home   Help Search  
Pages: Prev 1 2 [3] 4 5 6 7 Next   Go Down
  Print  
Author Topic: 9LY1JM Sierra Leone DXpedition  (Read 5856 times)
WA2VUY
Member

Posts: 458




Ignore
« Reply #30 on: January 14, 2019, 06:42:24 AM »

I'm not on FT8 but I know that HH70A,  a special call sign the Haitian ARC is using to celebrate their 70th anniversary, and RI50ANO on South Shetland could not use FT8 with those prefixes last year.

The FT8 problem is due to their weird callsign.
If you enter 9LY1JM, then WSJT-X cannot work properly in DXmode.
If you try 9L1YJM, then all is ok...  But ofcourse wrong callsign.
Logged
W9IQ
Member

Posts: 3044




Ignore
« Reply #31 on: January 14, 2019, 07:07:18 AM »

Most of this was address in Version 2.0 of WSJT-X. It uses a technique of creating a hash of non-standard call signs and using that for subsequent references to the non-standard call. The catch is that you need to have recently received the non-standard call at least once "in the clear" via message format 4. If you have not done this then the call cannot be displayed. So if you have not been on frequency for a while or the DX station has not CQed recently, you may not have loaded the call so it can be decoded.

Note that two non-standard calls cannot have an exchange.

- Glenn W9IQ
Logged

- Glenn W9IQ

I never make a mistake. I thought I did once but I was wrong.
KB2FCV
Member

Posts: 2956


WWW

Ignore
« Reply #32 on: January 14, 2019, 07:10:45 AM »

I see I need this one on a couple of bands... especially 80.. will definitely start listening for them.
Logged
W9IQ
Member

Posts: 3044




Ignore
« Reply #33 on: January 14, 2019, 09:53:29 AM »

Most of this was addressed in Version 2.0 of WSJT-X. It uses a technique of creating a hash of non-standard call signs and using that for subsequent references to the non-standard call. The catch is that you need to have recently received the non-standard call at least once "in the clear" via message format 4. If you have not done this then the call cannot be displayed. So if you have not been on frequency for a while or the DX station has not CQed recently, you may not have loaded the call so it can be decoded.

Note that two non-standard calls cannot have an exchange.

- Glenn W9IQ

I should add that the DX station should enclose their non-standard call sign in angled brackets < > in order for the above described feature to work.

Also, if you receive a < . . . > in the decode instead of the station's call, then you did not yet receive the call in the clear so that it can translate the hash to the full call.

- Glenn W9IQ
Logged

- Glenn W9IQ

I never make a mistake. I thought I did once but I was wrong.
KJ4Z
Member

Posts: 1449




Ignore
« Reply #34 on: January 14, 2019, 10:26:42 AM »

Most of this was address in Version 2.0 of WSJT-X. It uses a technique of creating a hash of non-standard call signs and using that for subsequent references to the non-standard call. The catch is that you need to have recently received the non-standard call at least once "in the clear" via message format 4. If you have not done this then the call cannot be displayed. So if you have not been on frequency for a while or the DX station has not CQed recently, you may not have loaded the call so it can be decoded.

Note that two non-standard calls cannot have an exchange.

- Glenn W9IQ

Thanks for the interesting info.  Does this mean that in normal operation (i.e. when not having received a transmission in "format 4"), WSJT-X relies at least partially on pre-established rules of what constitutes a "valid" callsign?  If so, is that via some sort of database, or a regular expression, or... ?  I'm a bit surprised that the protocol needs to care what the contents of the message are, particularly making assessments as to the callsigns, other than applying some sort of checksum.
Logged
WO7R
Member

Posts: 3893




Ignore
« Reply #35 on: January 14, 2019, 01:13:04 PM »

Well, remember, we are dealing with a 77 bit message.  That's a bigger restriction than it may sound at first glance.

Rendered in conventional 7 bit ASCII, that is only 11 characters.  Most of the messages in FT8/JT65/et al require two callsigns.

An ordinary 2x3 callsign, common throughout the world, would require 42 bits, uncompressed and unhashed.  Two of them are 84 bits.

So clearly, just to exchange callsigns, you are at risk to exceeding the allocation.  And, further lengthening the message will impact performance.  You really don't want any added bits (the previous FT8 was less than 77).

Of course, computers are good at encoding schemes, but 26 English Latin letters plus 10 numbers is 36, which essentially takes 6 bits to deal with unless you use tricks such as having rules for where things are in the message dictating the encoding.  I haven't read the manual on how they do it, but it is not a small thing to compress this stuff.  Since call signs (the bulk of the content) are essentially random, getting below 6 bits a character requires doing things like assuming call signs follow particular rules so you can have a bit or two to declare "which rule" and then follow with a tight string of bits to encode it.

Anyway, 6 bits per call sign "element" and two 2x3 calls gets you to 72 bits without encoding RRR R-17, -17, or, critically, the grid, which would be optimally encoded in around 14 bits itself.   A couple of prefix bits to give the six "standard" messages plus a seventh or eighth for "pure" text would easily eat up the rest.  The prefix bits would mean that RRR or RR73 would not be sent "as such" but be encoded in a few bits.  The report could be done in 9 bits or perhaps with a bit of cleverness, as few as 7 or 8.

None of this even accounts, fully, for the KP4/WO7R type of call sign either.  That takes some similar magic and you see it in the message restrictions (e.g. no grid square for compound call signs in TX1).

Again, look up in the manual to see how they actually do it.  But yeah, there are significant constraints to hold the message to 77 bits for fundamental performance.  You move the message up to 84 bits or so and no doubt some of these restrictions disappear.  But if you can encode 95, 97, 99 per cent of actual ham exchanges in 77 bits, then you betcha, that's what you design and ship.

Let us hope the plague of 3XY0AB and 9LY1MBC kind of calls do not proliferate.
Logged
KJ4Z
Member

Posts: 1449




Ignore
« Reply #36 on: January 14, 2019, 03:05:42 PM »

Let us hope the plague of 3XY0AB and 9LY1MBC kind of calls do not proliferate.

Well, I guess this new knowledge would also imply that if you *do* have a weird callsign, you should frequently "waste" a slot calling CQ, even into a howling pileup.  It sounds like a "format 4" message would clear up a lot of the confusion.
Logged
W9IQ
Member

Posts: 3044




Ignore
« Reply #37 on: January 14, 2019, 03:32:25 PM »

Thanks for the interesting info.  Does this mean that in normal operation (i.e. when not having received a transmission in "format 4"), WSJT-X relies at least partially on pre-established rules of what constitutes a "valid" callsign?  If so, is that via some sort of database, or a regular expression, or... ?  I'm a bit surprised that the protocol needs to care what the contents of the message are, particularly making assessments as to the callsigns, other than applying some sort of checksum.

There is nothing that establishes a valid call sign - that is one of the key restrictions that was removed in 2.0. There is quite a bit of logic to the call sign encoding in WSJT-X. It is not a simple matter of considering the 77 bits and how many call sign characters will fit in a message. The technique is rather clever in that the software will transmit the full, non-standard call sign periodically but most of the time it will use a shorter hash to point to (represent) the full call sign. This saves a great deal of message space to accommodate the other QSO elements that must be exchanged. Since these messages comprise most of the QSO, not continually sending the long call sign is very efficient. The disadvantage is you must at some point copy the long call in full so that the full call sign can be substituted for the hash when you see the exchange.

Also note that the old type 1 and type 2 compound call signs from pre version 2.0 are no longer an issue  - this distinction is removed in favor of simply nonstandard. You either have a standard (with or without /P or /R) or a nonstandard call sign.

Quoting from the manual:

Compound callsigns like xx/K1ABC or K1ABC/x and nonstandard callsigns like YW18FIFA are supported for normal QSOs but not for the special contest-style messages. If the message includes a grid locator or numerical signal report, the brackets must enclose the compound or nonstandard callsign; otherwise the brackets may be around either call.

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.0 offers no support for two nonstandard callsigns to work each other.



- Glenn W9IQ
« Last Edit: January 14, 2019, 03:48:09 PM by W9IQ » Logged

- Glenn W9IQ

I never make a mistake. I thought I did once but I was wrong.
WO7R
Member

Posts: 3893




Ignore
« Reply #38 on: January 14, 2019, 04:17:58 PM »

Well, I guess I really do need to read the manual, in detail.

But, a QSO I just had gives powerful clues to how it works.

CQ P4/S50M     no <> characters means it was transmitted in full.  But note, no Grid.  Presumably, not room.
<P4/S50M> WO7R -15    was what I transmitted.  So, my version of the code immediately hashed the P4/S50M call.
WO7R <P4/S50M> R-05   The P4 hashed his own call, sent mine in the clear.
P4/S50M <WO7R> RR73   I hashed my own call
<WO7R> P4/S50M 73     He hashed my call.

It seems exceedingly likely that the hash is unique to the call and the call alone and not time sensitive or has any other factors in it.  It relies on collisions in the hash being sufficiently rare and in having the hashed call sign having been sent reasonably recently, which further disambiguates the hashing.  There are still probably cases where it goes south (e.g. P4/S50M contacted someone else with the same hash just before they contact me) but these probably work out as too rare to cause many problems in practice.

This still doesn't account for the clipping in the F&H messages, unless hashing just doesn't happen there.  Note that before any hashing on "either side" took place, each party (me, P4/S50M) transmitted the entire call at least once before it was hashed regardless of which call we hashed at a given moment.
Logged
WB9LUR
Member

Posts: 494


WWW

Ignore
« Reply #39 on: January 15, 2019, 12:25:01 PM »

Question for you FT8 guys (nothing against digital modes - just not my thing) ... question:

I have read several of your posts in the forum - is there something that digital ops need to do differently (because of the non-standard call) to work them on FT8 successfully? Or am I reading too much into some of your posts?


Randy / WB9LUR
Logged

. .

73, Randy / WB9LUR - http://www.CallingDX.com

. .
WO7R
Member

Posts: 3893




Ignore
« Reply #40 on: January 15, 2019, 02:12:10 PM »

It's hard to say.  I did nothing out of the ordinary except interpret some clipped messages.

The QSO was otherwise normal and I see my QSO was uploaded to Clublog, so the ops on the other side figured out how to manage it.

I have friends reporting their QSO wasn't uploaded.  So, it seems to be specific to the individual.
Logged
VK3HJ
Member

Posts: 2071




Ignore
« Reply #41 on: January 15, 2019, 09:56:03 PM »

Check out the statistics of this operation so far, and how it reflects the current state of propagation.

EU and NA make up 95.5% of the log. The rest of the world accounts for only 4.5%!
Logged
N3QE
Member

Posts: 5567




Ignore
« Reply #42 on: January 16, 2019, 07:04:25 AM »

Let us hope the plague of 3XY0AB and 9LY1MBC kind of calls do not proliferate.

That's nothing like what you're gonna hear on every WPX weekend!

Fortunately no WPX contests allow FT8. (Although I believe the WPX award allows FT8).

Logged
WO7R
Member

Posts: 3893




Ignore
« Reply #43 on: January 16, 2019, 10:12:47 AM »

Oh, I love the WPX contests.  I just don't like the calls that don't fit the 2x2, 2x3 kind of traditional pattern.

Sooner or later, it plays games with all kinds of software.
Logged
KJ4Z
Member

Posts: 1449




Ignore
« Reply #44 on: January 16, 2019, 10:45:10 AM »

Sooner or later, it plays games with all kinds of software.

Including the wetware.  I'm still slightly confused by working 9L1YXJ and 9LY1JM in the same week.
Logged
Pages: Prev 1 2 [3] 4 5 6 7 Next   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!