Re: [wsjt-devel] callsigns in <>

2023-12-27 Thread Joe Taylor via wsjt-devel

Hi Bruce,

Please read Section 7.5, "Nonstandard Callsigns", in the WSJT-X User Guide.

https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.6.1.html#COMP-CALL

Take particular notice of this sentence:

"Except for the special cases involving /P or /R used in VHF contesting, 
WSJT-X 2.6 offers no support for two nonstandard callsigns to work each 
other."


In such a situation you should work WB0GAG/1 as WB0GAG.

-- 73, Joe, K1JT

On 12/27/2023 10:37 AM, Bruce Dagel via wsjt-devel wrote:

WSJT-X version 2.6.1

My mistake, I was going from memory.
The actual problem comes with a longer call.  WB0GAG/1  R+11 
transmits as WB0GAG 


73,
Bruce, WB0GAG


___
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


Re: [wsjt-devel] callsigns in <>

2023-12-27 Thread James Shaver via wsjt-devel
This is outlined in section 7.5 “non-standard callsigns” - specifically the 
last sentence in that section: “  offers no support for two nonstandard 
callsigns to work each other.”


> On Dec 27, 2023, at 10:43 AM, Bruce Dagel via wsjt-devel 
>  wrote:
> 
> WSJT-X version 2.6.1
> 
> My mistake, I was going from memory.
> The actual problem comes with a longer call.  WB0GAG/1  R+11 
> transmits as WB0GAG 
> 
> 73,
> Bruce, WB0GAG
> 
> 
> ___
> 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


Re: [wsjt-devel] callsigns in <>

2023-12-27 Thread Black Michael via wsjt-devel
That's correct -- you cannot do two compound calls like that.  It's a known 
limitation of the message format.
There is an option for "full call in..." options but they don't seem to 
honored.  I'm still seeing full call transmitted in all messages.

Would be more than nice if WSJT-X could call ft8code internally and show what 
is actually going to get transmitted.
 1.  W9MDB/4 +11                   W9MDB/4                      
*  4.  Nonstandard call


Mike W9MDB


 

On Wednesday, December 27, 2023 at 09:44:28 AM CST, Bruce Dagel via 
wsjt-devel  wrote:  
 
 WSJT-X version 2.6.1

My mistake, I was going from memory.
The actual problem comes with a longer call.  WB0GAG/1  R+11 
transmits as WB0GAG 

73,
Bruce, WB0GAG


___
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


Re: [wsjt-devel] callsigns in <>

2023-12-27 Thread Bruce Dagel via wsjt-devel

WSJT-X version 2.6.1

My mistake, I was going from memory.
The actual problem comes with a longer call.  WB0GAG/1  R+11 
transmits as WB0GAG 


73,
Bruce, WB0GAG


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] callsigns in <>

2023-12-27 Thread Christopher Wawak via wsjt-devel
Bruce, when callsigns are in angle brackets WSJTx is actually sending a
hash of the callsign and not the actual callsign. The software is not
sending plaintext as a string.

More info here:

https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.7.0-rc2.html#COMP-CALL


-- 73 Chris kc2ieb


On Wed, Dec 27, 2023 at 9:53 AM Bruce Dagel via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> While coordinating W1AW/O for Iowa, I observed that I couldn't make some
> contacts because the signal report was cut off, i.e., Tx2 would be
> WB0GAG   when WB0GAG  R+11 should be sent.  I believe it
> is a matter of too many characters.  The called station had nothing to
> confirm.
>
> A solution would appear to be to change so that the angle brackets
> replace the spaces instead of being added to them, i.e.
> WB0GAGR+11, where the angle brackets would do double duty.
>
> 73,
> Bruce, WB0GAG
>
>
> ___
> 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


Re: [wsjt-devel] callsigns in <>

2023-12-27 Thread Black Michael via wsjt-devel
What version of WSJT-X?
This message seems to encode OK as a standard message.    Is it possible your 
decode window isn't wide enough to see the R+11??
C:\WSJT\wsjtx\bin>ft8code "WB0GAG  R+11"    Message                     
          Decoded                             Err 
i3.n3
 1. WB0GAG  R+11                  WB0GAG  R+11                  
   1.  Standard msg
Mike W9MDB
 

On Wednesday, December 27, 2023 at 08:59:04 AM CST, Bruce Dagel via 
wsjt-devel  wrote:  
 
 While coordinating W1AW/O for Iowa, I observed that I couldn't make some 
contacts because the signal report was cut off, i.e., Tx2 would be 
WB0GAG   when WB0GAG  R+11 should be sent.  I believe it 
is a matter of too many characters.  The called station had nothing to 
confirm.

A solution would appear to be to change so that the angle brackets 
replace the spaces instead of being added to them, i.e. 
WB0GAGR+11, where the angle brackets would do double duty.

73,
Bruce, WB0GAG


___
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] callsigns in <>

2023-12-27 Thread Bruce Dagel via wsjt-devel
While coordinating W1AW/O for Iowa, I observed that I couldn't make some 
contacts because the signal report was cut off, i.e., Tx2 would be 
WB0GAG   when WB0GAG  R+11 should be sent.  I believe it 
is a matter of too many characters.  The called station had nothing to 
confirm.


A solution would appear to be to change so that the angle brackets 
replace the spaces instead of being added to them, i.e. 
WB0GAGR+11, where the angle brackets would do double duty.


73,
Bruce, WB0GAG


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Callsigns substituted by <...>

2018-12-15 Thread Ton PA0TBR
Hello Bill,

Thank you for the clear explanation, as always.
One question remains, how long will an entry in the hash table exist for?
In particular is it cleared after a band change?
I sometimes do bandhopping to monitor different bands.

Thanks again and 73,
Ton pa0tbr

On Sat, 15 Dec 2018 at 18:50, Bill Somerville  wrote:

> On 15/12/2018 17:11, Ton PA0TBR wrote:
> > I am trying to work out why some callsigns are shown as <...> in WSJT-X
> > Sometimes <...> is reflected in JTAlert as ...  other times it is not
> > shown in JTAlert.
> >
> > For example:
> > 103615 -12  1.8 1590 ~  <...> LZ1PPZ
> > 103645  -2  1.8 1590 ~  <...> LZ1PPZ R-18
> > 103715  -5  1.9 1589 ~  <...> LZ1PPZ R-20
> > 103745  -8  1.8 1588 ~  OG55W  73
> >
> > Looks like LZ1PPZ worked OG55W, but why was the call of OG55W not
> > shown in the initial messages?
> > And why is LZ1PPZ enclosed by <> in the last message?
> >
> > Other examples:
> > 112030 -12  0.3  915 ~  G3PLP <...> -16
> > 112100 -14  0.3  915 ~   ZS9YOTA RR73
> > Why was ZS9YOTA substituted by <...> ?
> >
> > 111800 -17  0.1  650 ~  CQ SD4C JP80   Sweden
> > 111830 -14  0.1  650 ~  <...>
> > What happened here?
> >
> > I use WSJT-X v2.0.0.0 in FT8 mode
> >
> > 73,
> > Ton pa0tbr
>
> Hi Ton,
>
> in the WSJT-X 77-bit FT8 (and MSK144) protocol non-standard callsigns
> like OG55W and ZS9YOTA require one of the callsigns in a two-callsign
> message to be compressed to a hash code  to make space for the rest of
> the message information. The hash code is a one-way algorithm so the
> callsign cannot be looked up until a message with the callsign in full
> has been received, until then the hash code is indicated as <...>. Once
> the hash table is populated, the callsigns received as hash codes are
> printed between '<' and '>' characters. The QSO flow and choice of which
> of the two callsigns is hashed is arranged so that a station hearing
> either end of the QSO will eventually get the hash table populated for
> both callsigns. Also the flow and choice of which callsign to hash means
> that during a QSO each station will send and receive each callsign
> un-hashed at least once, in fact this is a corollary of the previous
> sentence.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> 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


Re: [wsjt-devel] Callsigns substituted by <...>

2018-12-15 Thread Steven Franke via wsjt-devel
> On Dec 15, 2018, at 11:11 AM, Ton PA0TBR  wrote:
> 
> I am trying to work out why some callsigns are shown as <...> in WSJT-X
> Sometimes <...> is reflected in JTAlert as ...  other times it is not shown 
> in JTAlert.
> 
> For example:
> 103615 -12  1.8 1590 ~  <...> LZ1PPZ
> 103645  -2  1.8 1590 ~  <...> LZ1PPZ R-18
> 103715  -5  1.9 1589 ~  <...> LZ1PPZ R-20
> 103745  -8  1.8 1588 ~  OG55W  73
> 
> Looks like LZ1PPZ worked OG55W, but why was the call of OG55W not shown in 
> the initial messages?
> And why is LZ1PPZ enclosed by <> in the last message?

For the first three messages, the full callsign OG55W had not yet been received 
and entered into the hashtable. Therefore, the hash number that was received in 
place of OG55W could not be associated with the callsign OG55W. On the other 
hand, the full call of LZ1PPZ was received in each of the first three messages, 
and each time that it was received it was entered into the hashtable. So when 
the hash of LZ1PPZ was received in the 4’th message, the callsign could be 
looked up in the hashtable and printed between angle brackets .

> 
> Other examples:
> 112030 -12  0.3  915 ~  G3PLP <...> -16
> 112100 -14  0.3  915 ~   ZS9YOTA RR73
> Why was ZS9YOTA substituted by <...> ?

Same as above. 

> 
> 111800 -17  0.1  650 ~  CQ SD4C JP80   Sweden
> 111830 -14  0.1  650 ~  <…>

> What happened here?

Don’t know.

> 
> I use WSJT-X v2.0.0.0 in FT8 mode
> 
> 73,
> Ton pa0tbr

Steve k9an



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Callsigns substituted by <...>

2018-12-15 Thread Joe Taylor

Ton --

On 12/15/2018 12:11, Ton PA0TBR wrote:

I am trying to work out why some callsigns are shown as <...> in WSJT-X
Sometimes <...> is reflected in JTAlert as ...  other times it is not 
shown in JTAlert.


Why not consult the User Guide?  Why do you think we bother to write 
one, which takes a lot of time?


A simple search for "<" will bring you quickly to Section 7.5, "Compound 
Callsigns":


https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.0.0.html#COMP-CALL

Most of what you want to know is there.  If you have further questions 
about interaction with JTAlert, or whatever, feel free to then ask a 
better informed question.


-- Joe, K1JT



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Callsigns substituted by <...>

2018-12-15 Thread OG55W
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.0.0.html

Compound call signs

Keijo OG55W

From: Ton PA0TBR 
Sent: Saturday, December 15, 2018 7:11 PM
To: WSJT software development 
Subject: [wsjt-devel] Callsigns substituted by <...>

I am trying to work out why some callsigns are shown as <...> in WSJT-X
Sometimes <...> is reflected in JTAlert as ...  other times it is not shown in 
JTAlert.

For example:
103615 -12  1.8 1590 ~  <...> LZ1PPZ
103645  -2  1.8 1590 ~  <...> LZ1PPZ R-18
103715  -5  1.9 1589 ~  <...> LZ1PPZ R-20
103745  -8  1.8 1588 ~  OG55W  73

Looks like LZ1PPZ worked OG55W, but why was the call of OG55W not shown in the 
initial messages?
And why is LZ1PPZ enclosed by <> in the last message?

Other examples:
112030 -12  0.3  915 ~  G3PLP <...> -16
112100 -14  0.3  915 ~   ZS9YOTA RR73

Why was ZS9YOTA substituted by <...> ?


111800 -17  0.1  650 ~  CQ SD4C JP80   Sweden

111830 -14  0.1  650 ~  <...>

What happened here?


I use WSJT-X v2.0.0.0 in FT8 mode

73,
Ton pa0tbr








___
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


Re: [wsjt-devel] Callsigns substituted by <...>

2018-12-15 Thread Bill Somerville

On 15/12/2018 17:11, Ton PA0TBR wrote:

I am trying to work out why some callsigns are shown as <...> in WSJT-X
Sometimes <...> is reflected in JTAlert as ...  other times it is not 
shown in JTAlert.


For example:
103615 -12  1.8 1590 ~  <...> LZ1PPZ
103645  -2  1.8 1590 ~  <...> LZ1PPZ R-18
103715  -5  1.9 1589 ~  <...> LZ1PPZ R-20
103745  -8  1.8 1588 ~  OG55W  73

Looks like LZ1PPZ worked OG55W, but why was the call of OG55W not 
shown in the initial messages?

And why is LZ1PPZ enclosed by <> in the last message?

Other examples:
112030 -12  0.3  915 ~  G3PLP <...> -16
112100 -14  0.3  915 ~   ZS9YOTA RR73
Why was ZS9YOTA substituted by <...> ?

111800 -17  0.1  650 ~  CQ SD4C JP80       Sweden
111830 -14  0.1  650 ~  <...>
What happened here?

I use WSJT-X v2.0.0.0 in FT8 mode

73,
Ton pa0tbr


Hi Ton,

in the WSJT-X 77-bit FT8 (and MSK144) protocol non-standard callsigns 
like OG55W and ZS9YOTA require one of the callsigns in a two-callsign 
message to be compressed to a hash code  to make space for the rest of 
the message information. The hash code is a one-way algorithm so the 
callsign cannot be looked up until a message with the callsign in full 
has been received, until then the hash code is indicated as <...>. Once 
the hash table is populated, the callsigns received as hash codes are 
printed between '<' and '>' characters. The QSO flow and choice of which 
of the two callsigns is hashed is arranged so that a station hearing 
either end of the QSO will eventually get the hash table populated for 
both callsigns. Also the flow and choice of which callsign to hash means 
that during a QSO each station will send and receive each callsign 
un-hashed at least once, in fact this is a corollary of the previous 
sentence.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Callsigns substituted by <...>

2018-12-15 Thread Ton PA0TBR
I am trying to work out why some callsigns are shown as <...> in WSJT-X
Sometimes <...> is reflected in JTAlert as ...  other times it is not shown
in JTAlert.

For example:
103615 -12  1.8 1590 ~  <...> LZ1PPZ
103645  -2  1.8 1590 ~  <...> LZ1PPZ R-18
103715  -5  1.9 1589 ~  <...> LZ1PPZ R-20
103745  -8  1.8 1588 ~  OG55W  73

Looks like LZ1PPZ worked OG55W, but why was the call of OG55W not shown in
the initial messages?
And why is LZ1PPZ enclosed by <> in the last message?

Other examples:
112030 -12  0.3  915 ~  G3PLP <...> -16
112100 -14  0.3  915 ~   ZS9YOTA RR73
Why was ZS9YOTA substituted by <...> ?

111800 -17  0.1  650 ~  CQ SD4C JP80   Sweden
111830 -14  0.1  650 ~  <...>
What happened here?

I use WSJT-X v2.0.0.0 in FT8 mode

73,
Ton pa0tbr
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel