Re: [wsjt-devel] FT8 on 160m with Beverage antenna

2023-11-13 Thread Gary McDuffie via wsjt-devel



> On Nov 13, 2023, at 14:38, Dennis W1UE via wsjt-devel 
>  wrote:
> 
>  beverage antenna will often produce weaker signals than, say, an inverted L.
> However, it will decrease the noise on the signal, and make it easier to 
> copy, which 
> should make it easier to decode.

Going a step further, it should also increase the signal to noise ratio due to 
the gain of that antenna in the desired direction and the loss of noise signal 
in the other directions.  Remember, signal strength is not what WSJT-X is 
reporting.  It is the strength of the decoded signal over the overall noise.  

Gary  -  AG0N

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


Re: [wsjt-devel] FT8 on 160m with Beverage antenna

2023-11-13 Thread Joseph B. Fitzgerald via wsjt-devel
Most "receiving" antennas for 160m including Beverages actually result in less 
signal at the receiver compared to "transmitting" antennas, however recieving 
antennas have _much_ lower noise.As you alluded to the name of the game for 
receiving is to improve the signal to noise ratio, so a Beverage will improve 
decoding in many situations.

de KM1P Joe



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


Re: [wsjt-devel] FT8 on 160m with Beverage antenna

2023-11-13 Thread Bill Barrett via wsjt-devel
May want to browse the W8JI website for a lot of interesting information on
all phases of ham radio.
Here's a link to the Beverage antenna section:
https://www.w8ji.com/beverages.htm
Have a look at his antenna comparison spreadsheet to get an idea of
performance of various receive antennas. https://www.w8ji.com/receiving.htm

Best DX

Bill W2PKY

On Mon, Nov 13, 2023 at 6:12 PM Neil via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi Glenn, I've only been using Beverages on 160m for 40 years, so this is
> a somewhat partial and subjective view, but they certainly increase the S/N
> ratio considerably for human ear reception of extremely weak signals *when
> terminated correctly*.  Usual gain is around -20 dBi, but irrelevant
> because I use carefully-designed preamps to increase the signal level back
> to the receivers to overwhelm locally-generates noises from my neighbours
> properties.
>
> I found that I could get almost as good results with phased rotatable
> terminated loops, using Vactrols and phasing networks to tune the
> characteristics, mainly null steering to reduce high-angle local signals,
> and reducing human-generated noise and noise from the auroral curtain up
> here at 54 degrees north. Those loops have a gain around -32 dBi when
> phased, but the gain in S/N is definitely worthwhile.  Beverages work
> *because* of the lossy dielectric soil beneath them, not despite it.
>
> E-field probe antennas and small loops also work very well to improve the
> S/N on some paths.  You need a selection of different antennas to get best
> results for all directions. I also use multiple receivers concurrently.
>
> You also have to detune and terminated any transmit antennas within a few
> wavelengths while you are on receive, avoid putting a station near any
> large wire arrays such as power grid feeds or electric fences or strained
> wire fences.
>
> I agree that Beverages and other specialist receive antennas are difficult
> to model, but luckily folks have been getting excellent results since
> FOREVER without worrying about whether they can be modelled.  Having a way
> to adjust the terminating resistor is helpful, and having the wire elevated
> the right distance above ground and having it multiple wavelengths long is
> also helpful. but I've used Beverage-on-ground antennas over poor soil with
> some success.
>
> Using my receive antennas often bring signals up that are entirely
> invisible and undecodable on the waterfall on transmit antennas.
>
> --
> Neil G4DBN
> https://youtube.com/MachiningandMicrowaves
>
> On 13/11/2023 21:41, robert evans LAST_NAME via wsjt-devel wrote:
>
> When they built and installed the beverages they noticed they
> had just as much noise as the other antennas if not more.
>
> I modeled the Beverage and discovered it was a very high
> loss antenna. The soil was the lossy element and if you
> tried to reduce the loss by tuning the termination and
> matching networks you compromised the front to back
> ratios and lost directionality.
>
> The performance of the Beverage was dependent on soil
> characteristics and difficult to model and variable to
> to due to rain etc.
>
> We put an oscillator in the undesired direction.
> Before a contest the termination and matching was
> tweaked to null the oscillator in the park while favoring
> European stations.
>
> The Beverage is a lossy antenna with the least loss
> in the desired direction when correctly terminated and
> matched for the soil conditions.
>
> BCNU DE N2LO~>
>
>
> On 11/13/2023 11:45 AM EST Glenn Williams via wsjt-devel 
>   wrote:
>
>
> This is a theory question. There is a bit of FT8 on 160m.  Does use of a
> Beverage Antenna to get more signal raise the S/N value? Would that
> antenna help with receiving weaker signals (a variation of that S/N
> question)?
> --73, Glenn, AF8C
>
>
>
> ___
> 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] FT8 on 160m with Beverage antenna

2023-11-13 Thread Neil via wsjt-devel
Hi Glenn, I've only been using Beverages on 160m for 40 years, so this 
is a somewhat partial and subjective view, but they certainly increase 
the S/N ratio considerably for human ear reception of extremely weak 
signals *when terminated correctly*.  Usual gain is around -20 dBi, but 
irrelevant because I use carefully-designed preamps to increase the 
signal level back to the receivers to overwhelm locally-generates noises 
from my neighbours properties.


I found that I could get almost as good results with phased rotatable 
terminated loops, using Vactrols and phasing networks to tune the 
characteristics, mainly null steering to reduce high-angle local 
signals, and reducing human-generated noise and noise from the auroral 
curtain up here at 54 degrees north. Those loops have a gain around -32 
dBi when phased, but the gain in S/N is definitely worthwhile.  
Beverages work *because* of the lossy dielectric soil beneath them, not 
despite it.


E-field probe antennas and small loops also work very well to improve 
the S/N on some paths.  You need a selection of different antennas to 
get best results for all directions. I also use multiple receivers 
concurrently.


You also have to detune and terminated any transmit antennas within a 
few wavelengths while you are on receive, avoid putting a station near 
any large wire arrays such as power grid feeds or electric fences or 
strained wire fences.


I agree that Beverages and other specialist receive antennas are 
difficult to model, but luckily folks have been getting excellent 
results since FOREVER without worrying about whether they can be 
modelled.  Having a way to adjust the terminating resistor is helpful, 
and having the wire elevated the right distance above ground and having 
it multiple wavelengths long is also helpful. but I've used 
Beverage-on-ground antennas over poor soil with some success.


Using my receive antennas often bring signals up that are entirely 
invisible and undecodable on the waterfall on transmit antennas.


--
Neil G4DBN
https://youtube.com/MachiningandMicrowaves

On 13/11/2023 21:41, robert evans LAST_NAME via wsjt-devel wrote:

When they built and installed the beverages they noticed they
had just as much noise as the other antennas if not more.

I modeled the Beverage and discovered it was a very high
loss antenna. The soil was the lossy element and if you
tried to reduce the loss by tuning the termination and
matching networks you compromised the front to back
ratios and lost directionality.

The performance of the Beverage was dependent on soil
characteristics and difficult to model and variable to
to due to rain etc.

We put an oscillator in the undesired direction.
Before a contest the termination and matching was
tweaked to null the oscillator in the park while favoring
European stations.

The Beverage is a lossy antenna with the least loss
in the desired direction when correctly terminated and
matched for the soil conditions.

BCNU DE N2LO~>


On 11/13/2023 11:45 AM EST Glenn Williams via 
wsjt-devel  wrote:

  
This is a theory question. There is a bit of FT8 on 160m.  Does use of a

Beverage Antenna to get more signal raise the S/N value? Would that
antenna help with receiving weaker signals (a variation of that S/N
question)?
--73, Glenn, AF8C


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


Re: [wsjt-devel] FT8 on 160m with Beverage antenna

2023-11-13 Thread robert evans LAST_NAME via wsjt-devel
When they built and installed the beverages they noticed they
had just as much noise as the other antennas if not more.

I modeled the Beverage and discovered it was a very high
loss antenna. The soil was the lossy element and if you
tried to reduce the loss by tuning the termination and
matching networks you compromised the front to back
ratios and lost directionality.

The performance of the Beverage was dependent on soil
characteristics and difficult to model and variable to
to due to rain etc.

We put an oscillator in the undesired direction.
Before a contest the termination and matching was
tweaked to null the oscillator in the park while favoring
European stations.

The Beverage is a lossy antenna with the least loss
in the desired direction when correctly terminated and
matched for the soil conditions.

BCNU DE N2LO~>

> On 11/13/2023 11:45 AM EST Glenn Williams via wsjt-devel 
>  wrote:
> 
>  
> This is a theory question. There is a bit of FT8 on 160m.  Does use of a 
> Beverage Antenna to get more signal raise the S/N value? Would that 
> antenna help with receiving weaker signals (a variation of that S/N 
> question)?
> --73, Glenn, AF8C
> 
> -- 
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> 
> 
> ___
> 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] FT8 on 160m with Beverage antenna

2023-11-13 Thread Dennis W1UE via wsjt-devel
Glenn

A beverage antenna will often produce weaker signals than, say, an inverted
L.
However, it will decrease the noise on the signal, and make it easier to
copy, which
should make it easier to decode.

Dennis W1UE


On Mon, Nov 13, 2023 at 4:29 PM Glenn Williams via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> This is a theory question. There is a bit of FT8 on 160m.  Does use of a
> Beverage Antenna to get more signal raise the S/N value? Would that
> antenna help with receiving weaker signals (a variation of that S/N
> question)?
> --73, Glenn, AF8C
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
>
> ___
> 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] FT8 on 160m with Beverage antenna

2023-11-13 Thread Glenn Williams via wsjt-devel
This is a theory question. There is a bit of FT8 on 160m.  Does use of a 
Beverage Antenna to get more signal raise the S/N value? Would that 
antenna help with receiving weaker signals (a variation of that S/N 
question)?

--73, Glenn, AF8C

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com


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


Re: [wsjt-devel] FT8 TX6 mod entry and security hole

2023-05-09 Thread Reino Talarmo via wsjt-devel
> However attempting to use "CQ 3C AF8C EN81" created a couple of  problems.

Hi Glenn,
You are simply trying something that is not supported in WSJT-X. The only
supported additions to the CQ message are:
CQ 000 - CQ 999 3 to 1002
CQ A - CQ Z 1004 to 1029
CQ AA - CQ ZZ 1031 to 1731
CQ AAA - CQ ZZZ 1760 to 20685
CQ  - CQ  21443 to 532443

The number ranges after possible number or letter combinations are the
actual values used in the message encoding process. 
In short either exactly 3 number characters or from 1 to 4 letters are only
supported in the encoding.
For further information you may study in document
https://wsjt.sourceforge.io/FT4_FT8_QEX.pdf 
It is a bit heavy, I promise.

73, Reino OH3mA



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


Re: [wsjt-devel] FT8 TX6 mod entry and security hole

2023-05-08 Thread Alan McDonald via wsjt-devel
Why do you generate msgs if you are wanting to call CQ?
Generate Msgs takes the DXCall value but there is probably no value there if
you wish to call CQ.

Alan McDonald
VK1AO

-Original Message-
From: Glenn Williams via wsjt-devel  
Sent: Tuesday, May 9, 2023 2:38 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Glenn Williams 
Subject: [wsjt-devel] FT8 TX6 mod entry and security hole

Hello,

Setup:  FT8 V2.6.1, Windows 10, Kenwood TS590SG operated via USB cable.
Time/Date:  Last night, thinking about changing TX6 to specifically call
3C3CA with a CQ.

So we know that "CQ DL AF8C EN81"
WILL be transmitted if I modify TX6 and call CQ for Germany,

However attempting to use "CQ 3C AF8C EN81" created a couple of  problems.

Problem #1: If I insert DL into TX6 and select "Generate Std Msgs" using DL
and not 3C, even if the DL is in lower case, the DL gets converted to upper
case. Fine.  Also transmitting the CQ works fine.  But if I instead insert
3C and click "Generate Std Msgs" the 3C is erased and TX6 looks normal. So
that means I can't aim a CQ at entities with number first prefixes?  BOO!

So tonight I did it all over again and in addition put in a "#" 
character instead of 3C, and got similar results.

Problem #2: Follow mostly the sequence in Problem 1 but instead of clicking
"Generate Std Msgs" just click "Enable Tx".  With DL that works also. But
with 3C I transmit "  AF8C EN81 " .
Notice also the extra underscore and less-than sign and greater-than sign.

Transcript of Rx Frequency window follows:

030545  Tx  1281 ~  CQ DL AF8C EN81
030615  Tx  1281 ~  CQ SV AF8C EN81
030645  Tx  1281 ~   AF8C EN81
030715   8  0.1 1795 ~   K7ACZ 73
030815 -18  0.1 1216 ~  CQ TI2GBB EJ89 Costa Rica
030900  Tx  1281 ~  TI2GBB AF8C EN81
030915 -13  0.1 1218 ~  WB4JTT TI2GBB RR73
030930  Tx  1281 ~  TI2GBB AF8C EN81
031000  Tx  1457 ~  TI2GBB AF8C EN81
031101  Tx  1648 ~  TI2GBB AF8C EN81
031130  Tx  1648 ~  TI2GBB AF8C EN81
031200  Tx  1648 ~  TI2GBB AF8C EN81
031230  Tx  1648 ~  TI2GBB AF8C EN81
031330  Tx  1613 ~  TI2GBB AF8C EN81
031400  Tx  1613 ~  TI2GBB AF8C EN81
031430  Tx  1613 ~  TI2GBB AF8C EN81
032000  Tx  1613 ~   AF8C EN81
032100  Tx  1613 ~   AF8C EN81
032130  Tx  1613 ~  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] FT8 TX6 mod entry and security hole

2023-05-08 Thread Glenn Williams via wsjt-devel

Hello,

Setup:  FT8 V2.6.1, Windows 10, Kenwood TS590SG operated via USB cable.
Time/Date:  Last night, thinking about changing TX6 to specifically call
3C3CA with a CQ.

So we know that "CQ DL AF8C EN81"
WILL be transmitted if I modify TX6 and call CQ for Germany,

However attempting to use "CQ 3C AF8C EN81" created a couple of  problems.

Problem #1: If I insert DL into TX6 and select "Generate Std Msgs" using 
DL and not 3C, even if the DL is in lower case, the DL gets converted
to upper case. Fine.  Also transmitting the CQ works fine.  But if I 
instead insert 3C and click "Generate Std Msgs" the 3C is erased and TX6 
looks normal. So that means I can't aim a CQ at entities with number

first prefixes?  BOO!

So tonight I did it all over again and in addition put in a "#" 
character instead of 3C, and got similar results.


Problem #2: Follow mostly the sequence in Problem 1 but instead of
clicking "Generate Std Msgs" just click "Enable Tx".  With DL
that works also. But with 3C I transmit "  AF8C EN81 " .
Notice also the extra underscore and less-than sign and greater-than sign.

Transcript of Rx Frequency window follows:

030545  Tx  1281 ~  CQ DL AF8C EN81
030615  Tx  1281 ~  CQ SV AF8C EN81
030645  Tx  1281 ~   AF8C EN81
030715   8  0.1 1795 ~   K7ACZ 73
030815 -18  0.1 1216 ~  CQ TI2GBB EJ89 Costa Rica
030900  Tx  1281 ~  TI2GBB AF8C EN81
030915 -13  0.1 1218 ~  WB4JTT TI2GBB RR73
030930  Tx  1281 ~  TI2GBB AF8C EN81
031000  Tx  1457 ~  TI2GBB AF8C EN81
031101  Tx  1648 ~  TI2GBB AF8C EN81
031130  Tx  1648 ~  TI2GBB AF8C EN81
031200  Tx  1648 ~  TI2GBB AF8C EN81
031230  Tx  1648 ~  TI2GBB AF8C EN81
031330  Tx  1613 ~  TI2GBB AF8C EN81
031400  Tx  1613 ~  TI2GBB AF8C EN81
031430  Tx  1613 ~  TI2GBB AF8C EN81
032000  Tx  1613 ~   AF8C EN81
032100  Tx  1613 ~   AF8C EN81
032130  Tx  1613 ~  The missing greater-than symbol at 032130 is also a feature because I 
entered "CQ_#AADFDF12345676890 AF8C EN81" and clicked Enable Tx.


The last one there happened because I modified TX6 to say something
really ugly like

CQ #AADFDF1234567890afdkjhkdfhasdsadsff AF8C EN81

and then clicked Enable Tx.

Evidently inserting a long string overflows a buffer which is then 
truncated when Enable Tx is clicked?


OK Time to quit operating and send this email!

Security hole question:
Now what would happen if I was running WSJT-X remotely with some
Remote Desktop App which had malware in it and the malware part
decided to overflow the TX6 buffer with some kind of malware insertion
trick?  Full disclosure here, I do not code up malware. I don't know
how. I have just read about it, where somewhere in the past I read
that forcing buffer overflows is one trick used to compromise a 
computer.  Perhaps somewhere in your code you have a catch to limit

buffer overflows?

Perhaps you need more work to enable CQing ALL legal call signs
and at the same time the team should audit the code for disallowing 
dirty tricks? Also add a special character rejection part.

-
--73, Glenn, AF8C


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com


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


[wsjt-devel] FT8 7 signal generator

2022-11-09 Thread Bob Larkin via wsjt-devel
I have been doing duty as curator of a DSP library for the Teensy 
processors.  This has quite a few ham radio classes that now include FT8 
T/R based on the work of Karlis Goba and others.  This is all intended 
for the Teensy 4.x boards that use ARM Cortex-M7 processors.


This note is about a generator that was used to test the receive class 
but that might be of interest to folks on this list, as it is a simple, 
stand-alone inexpensive gadget that generates audio signals of known 
SNR.  A description of this is at 
http://www.janbob.com/electron/FT8Generator/FT8Generator.html including 
links for the hardware and software, including the library.  I believe 
the signals meet specs and they include GMFK filtering and raised cosine 
tones.


The hope is that this might be a useful to others, but in addition, if 
anyone sees any problems or bugs, let me know!


Thanks and 73, Bob  W7PUA



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


Re: [wsjt-devel] FT8 issues

2021-10-27 Thread Greg Sieckman via wsjt-devel
Thanks

From: Bill Somerville via wsjt-devel 
Sent: Wednesday, October 27, 2021 1:49 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] FT8 issues

On 27/10/2021 18:50, Greg Sieckman via wsjt-devel wrote:
Hi,
I upped the software not too long ago to 2.4 & have now gone to 2.5.1. Running 
win 10.

I suddenly have the sequence of transmissions going from my RRR to CQ. I have 
to manually back track to send the 73. It was functioning ok before updates: 
but also, at that time I had the RR73 represented there vs the RRR.  
Thoughts?

I'd like to have the RR73 instead of the RRR.  I have tried to type it early in 
the qso, but it won't take it at that point, defaults back to RRR


Thanks,& 73 Greg wa9tba

Hi Greg,

there is no example in the WSJT-X User Guide where a station sending an RRR 
message follows with a 73 message.

To switch the Tx4 message to an RR73 style message double-click either the 
"Next" or "Now" button next to it.

https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.5.1.html#_standard_exchange<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphysics.princeton.edu%2Fpulsar%2Fk1jt%2Fwsjtx-doc%2Fwsjtx-main-2.5.1.html%23_standard_exchange=04%7C01%7C%7C92c13553236a412c066208d9997bd9dd%7C84df9e7fe9f640afb435%7C1%7C0%7C637709579515583965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=q%2FPqizv5mI7S2oRXjCwdWCJRpyHi9AxzX8YRlJFNkUg%3D=0>

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


Re: [wsjt-devel] FT8 issues

2021-10-27 Thread James Shaver (N2ADV) via wsjt-devel
Double click the TX4 button as noted in the manual. 

> On Oct 27, 2021, at 2:32 PM, Greg Sieckman via wsjt-devel 
>  wrote:
> 
> 
> Hi,
> I upped the software not too long ago to 2.4 & have now gone to 2.5.1. 
> Running win 10.
>  
> I suddenly have the sequence of transmissions going from my RRR to CQ. I have 
> to manually back track to send the 73. It was functioning ok before updates: 
> but also, at that time I had the RR73 represented there vs the RRR.  
> Thoughts?
>  
> I’d like to have the RR73 instead of the RRR.  I have tried to type it early 
> in the qso, but it won’t take it at that point, defaults back to RRR
>  
>  
> Thanks,& 73 Greg wa9tba
>  
> ___
> 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] FT8 issues

2021-10-27 Thread Bill Somerville via wsjt-devel

On 27/10/2021 18:50, Greg Sieckman via wsjt-devel wrote:


Hi,

I upped the software not too long ago to 2.4 & have now gone to 2.5.1. 
Running win 10.


I suddenly have the sequence of transmissions going from my RRR to CQ. 
I have to manually back track to send the 73. It was functioning ok 
before updates: but also, at that time I had the RR73 represented 
there vs the RRR.  Thoughts?


I’d like to have the RR73 instead of the RRR.  I have tried to type it 
early in the qso, but it won’t take it at that point, defaults back to RRR


Thanks,    & 73 Greg wa9tba


Hi Greg,

there is no example in the WSJT-X User Guide where a station sending an 
RRR message follows with a 73 message.


To switch the Tx4 message to an RR73 style message double-click either 
the "Next" or "Now" button next to it.


https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.5.1.html#_standard_exchange

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


[wsjt-devel] FT8 issues

2021-10-27 Thread Greg Sieckman via wsjt-devel
Hi,
I upped the software not too long ago to 2.4 & have now gone to 2.5.1. Running 
win 10.

I suddenly have the sequence of transmissions going from my RRR to CQ. I have 
to manually back track to send the 73. It was functioning ok before updates: 
but also, at that time I had the RR73 represented there vs the RRR.  
Thoughts?

I'd like to have the RR73 instead of the RRR.  I have tried to type it early in 
the qso, but it won't take it at that point, defaults back to RRR


Thanks,& 73 Greg wa9tba

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


[wsjt-devel] FT8 stops decoding after a mode change and back

2021-06-03 Thread Joe Dzekevich
WSJT-X 2.5.0  rc1

Windows 10

 

I was working some MA to FL Es on 50.313 on FT8 and all worked great.  No
problems at all.

Then I switched to Q65-30A on 50.275 and called four CQs.  No one around.

Then I switched back to FT8 on 50.313 and the FT8 signals were not decoding.

I stopped WSJT-X and restarted it and all was fine.  FT8 was decoding as
normal.

TIME.IS shows the time as exact.

This is repeatable 100%.

 

So, after a FT8-Q65-FT8 mode change sequence, FT8 stops decoding.  A restart
fixes it.  It is repeatable 100%.

 

73,

Joe, K1YOW

 

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


Re: [wsjt-devel] [FT8-Digital-Mode] WSJT-X V2.31 Issues

2021-04-12 Thread Alan VK2ZIW via wsjt-devel
Hi all,

Several ( many) years back I had the same symptoms with WSPR in that it failed 
after a few days

and lasted longer running on machines with more memory.

The problem was, not freeing up Virtual Memory after a decode cycle.

On Windows systems, the problem did not surface, only on Linux. This was 
Windows XP at the time as I recall.

Perhaps with later versions of Windows (10 etc.), the Virtual Memory system has 
changed.

So, can you check the program's memory usage, both real and virtual?

At the time I had to convince the developer, Virtual Memory is not limitless. 

Alan VK2ZIW

On Sun, 11 Apr 2021 20:45:51 -0400, William Smith wrote
> I'm seeing it too, just listening on 40M WSPR and reporting to wspr.net, and 
> it stops working probably once a day.  The waterfall stops moving and decodes 
> stop happening.  I have to stop and restart WSJT-X 
> 
> I'm running v2.3.1 0e7224 if it matters.  I've seen similar behavior on 
> previous releases, but it usually takes several days to fall over.
> 
> Copying the dev list above...
> 
> 73, Willie N1JBJ
> 
> 
> 
> On Apr 11, 2021, at 7:58 PM, KB3Z via groups.io 
>  wrote:
> I just installed WSJT-X V2.31 this morning. And I thought that everything was 
> working ok. But it seems for some reason after a period of time that the Band 
> Activity data all of a sudden stops and then moves over to the RX Frequency 
> side. And it doesn't seem to update after a period of time.It seems that this 
> program has more bugs then go a mile. Whatever happened to the program that 
> always worked? Any advice would be greatly appreciated.Mark Griffin, KB3Z
> _._,_._,_ 
---
 Groups.io Links:
> You receive all messages sent to this group. 
> View/Reply Online (#5407) | Reply To Group | Reply To Sender | Mute This 
> Topic | New Topic Your Subscription | Contact Group Owner | Unsubscribe 
> [w_sm...@compusmiths.com] 
> _._,_._,_

--- 
Alan VK2ZIW 
Before the Big Bang, God, Sela. 
OpenWebMail 2.53, nothing in the cloud.

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


Re: [wsjt-devel] [FT8-Digital-Mode] WSJT-X V2.31 Issues

2021-04-11 Thread William Smith
I'm seeing it too, just listening on 40M WSPR and reporting to wspr.net, and it 
stops working probably once a day.  The waterfall stops moving and decodes stop 
happening.  I have to stop and restart WSJT-X 

I'm running v2.3.1 0e7224 if it matters.  I've seen similar behavior on 
previous releases, but it usually takes several days to fall over.

Copying the dev list above...

73, Willie N1JBJ

> On Apr 11, 2021, at 7:58 PM, KB3Z via groups.io 
>  wrote:
> 
> I just installed WSJT-X V2.31 this morning. And I thought that everything was 
> working ok. But it seems for some reason after a period of time that the Band 
> Activity data all of a sudden stops and then moves over to the RX Frequency 
> side. And it doesn't seem to update after a period of time.
> 
> It seems that this program has more bugs then go a mile. Whatever happened to 
> the program that always worked? Any advice would be greatly appreciated.
> Mark Griffin, KB3Z
> _._,_._,_
> Groups.io Links:
> You receive all messages sent to this group.
> 
> View/Reply Online (#5407)  
> | Reply To Group 
> 
>  | Reply To Sender 
> 
>  | Mute This Topic  | New Topic 
> 
> Your Subscription  | 
> Contact Group Owner  | Unsubscribe 
>  
> [w_sm...@compusmiths.com]
> 
> _._,_._,_

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


Re: [wsjt-devel] FT8 poor decoding problem solved

2021-03-17 Thread Don Hawbaker
My comments were based on the instructions included in the user manual, and the 
information that is displayed when you hover the mouse over the dB reading, and 
my experience operating from 1 to 10 GHz.

30 dB with no signals present is recommended.  I have never seen a 50 dB over 
S9, or even an S9, or even a signal that moves my S meter.  We operate in two 
different worlds.  I just assumed the same guidelines applied.

WA3RGQ

Sent from Mail for Windows 10

From: Jim Brown
Sent: Wednesday, March 17, 2021 5:13 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FT8 poor decoding problem solved

On 3/17/2021 12:29 PM, Donhawbaker wrote:
> The receive level, i.e. mic gain, should be set to 30, not 50 or 60.

I strongly disagree with this advice when there are very strong signals 
present. On 6M and 160M which I most often use WSJT-X modes, I often see 
my neighbors decoding in the range of 30 dB, and they're probably a lot 
stronger than that. Let's say, for example, a station is 50 dB over S9. 
If I set the top of my A/D to 30 on that voltmeter (the green bar), that 
strong station will prevent the decoder from seeing signals weaker than 
20 dB over S9. But the practical dynamic range of a 16-bit A/D is 
typically in the range of 85 dB or so.

The solution is to set the gain on the analog side of the A/D so that, 
with those strong signals present, that green bar never turns red, 
indicating that we've hit the top of the A/D. This can be done by 
reducing audio or RF gain at the radio, or at the input to the audio 
interface (if there is one). I use a Tascam US100, which has both front 
panel gain controls for analog input and analog output, and an LED that 
is green with signal and turns red as the signal hits digital clip. With 
that interface, I can run the green bar in the range of 70-80 dB WITH 
strongest signals present, and I use slow AGC.

73,



___
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] FT8 poor decoding problem solved

2021-03-17 Thread Jim Brown

On 3/17/2021 12:29 PM, Donhawbaker wrote:

The receive level, i.e. mic gain, should be set to 30, not 50 or 60.


I strongly disagree with this advice when there are very strong signals 
present. On 6M and 160M which I most often use WSJT-X modes, I often see 
my neighbors decoding in the range of 30 dB, and they're probably a lot 
stronger than that. Let's say, for example, a station is 50 dB over S9. 
If I set the top of my A/D to 30 on that voltmeter (the green bar), that 
strong station will prevent the decoder from seeing signals weaker than 
20 dB over S9. But the practical dynamic range of a 16-bit A/D is 
typically in the range of 85 dB or so.


The solution is to set the gain on the analog side of the A/D so that, 
with those strong signals present, that green bar never turns red, 
indicating that we've hit the top of the A/D. This can be done by 
reducing audio or RF gain at the radio, or at the input to the audio 
interface (if there is one). I use a Tascam US100, which has both front 
panel gain controls for analog input and analog output, and an LED that 
is green with signal and turns red as the signal hits digital clip. With 
that interface, I can run the green bar in the range of 70-80 dB WITH 
strongest signals present, and I use slow AGC.


73,



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


Re: [wsjt-devel] FT8 poor decoding problem solved

2021-03-17 Thread Donhawbaker
  
  

 The receive level, i.e. mic gain, should be set to 30, not 50 or 60.
  
  
  

  

  
  
>   
> On Mar 17, 2021 at 3:10 PM,   (mailto:reino.tala...@kolumbus.fi)>  wrote:
>   
>   
> 
>   
>   
>
>   I'm passing along this info for others who might be experiencing low 
> numbers of FT8 decodes.
>
>   
>
>   In the past month on 3 occasions the number of FT8 decodes on very busy 
> bands didn’t match the activity noted on the Wide Graph. Although many dozens 
> of stations were seen, fewer than 10 were being decoded on the odd cycles and 
> only 1 or 2 stations were decoded during the even cycles. This same pattern 
> was noted on all 3 times that this problem was observed. The problem occurred 
> while using WSJT-X V2.3.0 GA as well as 2.4.0-rc1  &  3 versions.
>
>   
>
>   I verified that D4.EXE had recently updated the time and the “Time.IS” 
> website said the computer clock was “Exact”, so it wasn’t a time issue. Using 
> the Windows Task Manager, the maximum CPU usage with the dual core I5-2500 
> CPU running at 3.3 GHz never exceeded 40% on peaks. There was plenty of the 
> 16GB of memory available, so it didn’t appear to be a memory issue either. 
> The audio receive level was between 50 and 60 dB on the WSJT-X bar meter.
>
>   
>
>   I shut down all other apps but the poor decode performance continued with 
> only WSJT-X running. Shutting down and restarting WSJT-X didn’t correct the 
> problem.
>
>   
>
>   The fix?I rebooted the computer and during subsequent decode cycles, 
> between 40 and 60+ stations were decoded each cycle. The reboot fixed the 
> poor decoding each time the problem was observed.
>
>   
>
>   Any thoughts as to why this was happening?
>
>   
>
>   Thanks Rich of your positive report. Could you remind us which rig are 
> using and how it is connected to your PC, please?
>  73, Reino OH3mA
>
>   
>   
>   
>   
  
  
 ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] FT8 poor decoding problem solved

2021-03-17 Thread Reino Talarmo
I'm passing along this info for others who might be experiencing low numbers of 
FT8 decodes.

In the past month on 3 occasions the number of FT8 decodes on very busy bands 
didn’t match the activity noted on the Wide Graph. Although many dozens of 
stations were seen, fewer than 10 were being decoded on the odd cycles and only 
1 or 2 stations were decoded during the even cycles. This same pattern was 
noted on all 3 times that this problem was observed. The problem occurred while 
using WSJT-X V2.3.0 GA as well as 2.4.0-rc1 & 3 versions.

I verified that D4.EXE had recently updated the time and the “Time.IS” website 
said the computer clock was “Exact”, so it wasn’t a time issue. Using the 
Windows Task Manager, the maximum CPU usage with the dual core I5-2500 CPU 
running at 3.3 GHz never exceeded 40% on peaks. There was plenty of the 16GB of 
memory available, so it didn’t appear to be a memory issue either. The audio 
receive level was between 50 and 60 dB on the WSJT-X bar meter.

I shut down all other apps but the poor decode performance continued with only 
WSJT-X running. Shutting down and restarting WSJT-X didn’t correct the problem. 

The fix?  I rebooted the computer and during subsequent decode cycles, between 
40 and 60+ stations were decoded each cycle. The reboot fixed the poor decoding 
each time the problem was observed.

Any thoughts as to why this was happening? 

Thanks Rich of your positive report. Could you remind us which rig are using 
and how it is connected to your PC, please?
73, Reino OH3mA

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


[wsjt-devel] FT8 poor decoding problem solved

2021-03-17 Thread Rich - K1HTV
I'm passing along this info for others who might be experiencing low
numbers of FT8 decodes.

In the past month on 3 occasions the number of FT8 decodes on very busy
bands didn’t match the activity noted on the Wide Graph. Although many
dozens of stations were seen, fewer than 10 were being decoded on the odd
cycles and only 1 or 2 stations were decoded during the even cycles. This
same pattern was noted on all 3 times that this problem was observed. The
problem occurred while using WSJT-X V2.3.0 GA as well as 2.4.0-rc1 & 3
versions.

I verified that D4.EXE had recently updated the time and the “Time.IS”
website said the computer clock was “Exact”, so it wasn’t a time issue.
Using the Windows Task Manager, the maximum CPU usage with the dual core
I5-2500 CPU running at 3.3 GHz never exceeded 40% on peaks. There was
plenty of the 16GB of memory available, so it didn’t appear to be a memory
issue either. The audio receive level was between 50 and 60 dB on the
WSJT-X bar meter.

I shut down all other apps but the poor decode performance continued with
only WSJT-X running. Shutting down and restarting WSJT-X didn’t correct the
problem.

The fix?  I rebooted the computer and during subsequent decode cycles,
between 40 and 60+ stations were decoded each cycle. The reboot fixed the
poor decoding each time the problem was observed.

Any thoughts as to why this was happening?

73,

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


Re: [wsjt-devel] ft8 not decode I can decode ft4

2021-02-20 Thread Richard Larson via wsjt-devel

I would ask if you were on the right frequency or traditional FT8 frequency

Rick KD0XD

On 2/20/2021 2:09 PM, Donald Rossman wrote:


I have ft8 2.2.0

I have windows 10

Ft8 not decode ft4 do decode

In still t8 2.2.0



___
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] ft8 not decode I can decode ft4

2021-02-20 Thread George J Molnar
Moon, we will need a little more than “it doesn’t work” to help you out. I 
presume you have checked your audio paths and clock? Can you provide more 
details of your installation and the specific problem?

George, KF2T

> On Feb 20, 2021, at 3:09 PM, Donald Rossman  wrote:
> 
> I have ft8 2.2.0
> I have windows 10
> Ft8 not decode ft4 do decode 
> In still t8 2.2.0 
>  
> ___
> 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] ft8 not decode I can decode ft4

2021-02-20 Thread Scott Brown
upgrade to 2.3.

From: Donald Rossman 
Sent: Saturday, February 20, 2021 3:09 PM
To: wsjt-devel@lists.sourceforge.net 
Subject: [wsjt-devel] ft8 not decode I can decode ft4


I have ft8 2.2.0

I have windows 10

Ft8 not decode ft4 do decode

In still t8 2.2.0


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


[wsjt-devel] ft8 not decode I can decode ft4

2021-02-20 Thread Donald Rossman
I have ft8 2.2.0
I have windows 10
Ft8 not decode ft4 do decode
In still t8 2.2.0

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


[wsjt-devel] ft8 not decode

2021-02-20 Thread Donald Rossman

Ft8 not decode I have not see ppl  in ft8 I do see ppl in ft4
Sent from Mail for Windows 10

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


Re: [wsjt-devel] FT8 Packet example

2021-01-22 Thread Reino Talarmo
>I have been digesting the "The FT4 and FT8 Communication Protocols"
paper, and something is just not clicking for me, and I think I need to see
it graphically.

>Does anyone have or a link to a raw packet diagram for the 77 bit payload
broken down by bits? My Google-fu is not paying off today.

Hi Warren,

I don't have link nor a graphic diagram, but perhaps this character based
presentation helps a little.
You need use a constant width font e.g. Consolas to get it correctly.

Standard message 
 10203040506070
1234567890123456789012345678901234567890123456789012345678901234567890123456
7
iiirrRgg
g
3  28  128  1115

Field day
 10203040506070
1234567890123456789012345678901234567890123456789012345678901234567890123456
7
iiinnnRkkkSS
S
3  3  28  28  14   3  7

EU VHF
 10203040506070
1234567890123456789012345678901234567890123456789012345678901234567890123456
7
iiihhRrrrsss
g
3  12  2212  11 25


correctly I picked three different message types as examples. The first
ruler gives tens of bits and second you may guess. The message bits are
marked with the bit-field tags used in Table 1 and last line in each gives
how many bits are in each bit-field for each tag character.

Bit-field purposes are defined in Table 2 and details in Appendix A. Even
Appendix A refers further to algorithms that finally define bits. Some of
those are complex and impossible to present as a linear mapping to bits.

Hope this gives some inside look into an efficient source coding.

73, Reino OH3mA

___
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] FT8 Packet example

2021-01-21 Thread halst...@gmail.com
I have been digesting the "The FT4 and FT8 Communication Protocols"
paper, and something is just not clicking for me, and I think I need
to see it graphically.

Does anyone have or a link to a raw packet diagram for the 77 bit
payload broken down by bits? My Google-fu is not paying off today.

Respectfully,

~Warren


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


Re: [wsjt-devel] [FT8-Digital-Mode] WSJT-X 2.3. RC2 on MacOS #wsjt-x

2020-11-16 Thread Philippe Nicolas
Hello Joe

My problem was on macOS not on Windows but with your response, you show me the 
way, and for that I thank you a lot !
Indeed I could TX but get nothing from the air despite I show signals on the 
rig.

I search in the system audio parameters and eventually discover in
“Security & Privacy” -> “Microphone” that WSJT-X was disable.
So WSJT-X do not have the right to use microphone, neither “USB Audio CODEC”.
I did not touch this parameter after install, so I don’t know why it is 
disable...

It take me some time to discover this issue because I didn’t have any problem 
at all with macOS and WSJT-X…

Thanks

Best regards

73
Philippe
F4IQP



> On 16 Nov 2020, at 19:42, Joe Hobart  wrote:
> 
> Hello Philippe,
> 
> It appears your FT8 program is not receiving audio.
> 
> Check your sound card settings.  Windows will reset the sound card or sound
> modem to default and/or change your level settings during updates.
> 
> If that does not work, completely uninstall ALL versions of WSJT-X and 
> reinstall
> the new version.  Do this from Windows Control Panel, Programs: Uninstall a
> program.  You should only have one version of WSJT-X installed on your 
> computer.
> 
> 73,
> Joe, W7LUX
> Flagstaff, Arizona
> 
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
> 



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


Re: [wsjt-devel] FT8 auto-QSY ?

2020-07-01 Thread n2xk
I'm sorry I miss understood that you wanted FT8 with the boxes used on MSK144.FT8 does QSY the other station just like MSK144 if you call let's say on 7.074:CQ 080 N2XK FN20In this way you'd have to use split on the radio just as you did for JA's on 160.FredN2XKOn Jul 1, 2020 8:16 AM, Saku  wrote:
Now I have tried more.
Fred you said it has been there always. Can you please tell me
  how I can make this box appear with FT8 mode?


  This clip is taken when MSK144 mode is on. When switch to FT8 it
  disappears.
  
  So I wonder how you make it?

Saku kirjoitti 1.7.2020 klo 13.47:


  
  Really!
  I tried to be nice and  read the v2.2.2/Help/Online manual
*before* posting. Used browsers "find" and found  2 hits with
word QSY.
  First one tells how to enter frequency (the freq selector) and
second describes just this MSK144/J9 fast modes case. No other
hits.
  I have to try more. First test (before mailing) it did not do
so when FT8 mode was used.
  
  n...@hotmail.com
kirjoitti 1.7.2020 klo 12.05:
  
  

FT8 already does this just as MSK144. It always
  has.
  
  
  Fred
  N2XK



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


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


Re: [wsjt-devel] FT8 auto-QSY ?

2020-07-01 Thread Saku

Now I have tried more.

Fred you said it has been there always. Can you please tell me how I can 
make this box appear with FT8 mode?



This clip is taken when MSK144 mode is on. When switch to FT8 it disappears.

So I wonder how you make it?

Saku kirjoitti 1.7.2020 klo 13.47:


Really!

I tried to be nice and  read the v2.2.2/Help/Online manual *before* 
posting. Used browsers "find" and found  2 hits with word QSY.


First one tells how to enter frequency (the freq selector) and second 
describes just this MSK144/J9 fast modes case. No other hits.


I have to try more. First test (before mailing) it did not do so when 
FT8 mode was used.


n...@hotmail.com kirjoitti 1.7.2020 klo 12.05:

FT8 already does this just as MSK144. It always has.

Fred
N2XK


--
Saku
OH1KH


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


--
Saku
OH1KH

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


Re: [wsjt-devel] FT8 auto-QSY ?

2020-07-01 Thread Saku

Really!

I tried to be nice and  read the v2.2.2/Help/Online manual *before* 
posting. Used browsers "find" and found  2 hits with word QSY.


First one tells how to enter frequency (the freq selector) and second 
describes just this MSK144/J9 fast modes case. No other hits.


I have to try more. First test (before mailing) it did not do so when 
FT8 mode was used.


n...@hotmail.com kirjoitti 1.7.2020 klo 12.05:

FT8 already does this just as MSK144. It always has.

Fred
N2XK


--
Saku
OH1KH

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


Re: [wsjt-devel] FT8 auto-QSY ?

2020-07-01 Thread n2xk
FT8 already does this just as MSK144. It always has.FredN2XKOn Jul 1, 2020 4:51 AM, Saku  wrote:Hi!

As seen FT8 segments start to get crowded when band conditions get better.

By manual MSK144 and fast JT9 modes have "QSY" feature where CQ calling 
station can make autoqsy for responding station to some free frequency. 
MSK144 I have tested before and it works fine.

Is there any idea to expand it also to FT8 ?

This came in to my mind today when 50.313MHz was filled by JA stations. 
Unfortunately the rest of EU also heard them that made my 2el and 100W 
too small.
Those few stations that I managed to meet at 50.323MHz were easy to work.

Just how to tell the others that they should peek also 10kHz up?

Auto QSY could be better than self spotting at DXCluster.

-- 
Saku
OH1KH



___
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] FT8 auto-QSY ?

2020-07-01 Thread Saku

Hi!

As seen FT8 segments start to get crowded when band conditions get better.

By manual MSK144 and fast JT9 modes have "QSY" feature where CQ calling 
station can make autoqsy for responding station to some free frequency. 
MSK144 I have tested before and it works fine.


Is there any idea to expand it also to FT8 ?

This came in to my mind today when 50.313MHz was filled by JA stations. 
Unfortunately the rest of EU also heard them that made my 2el and 100W 
too small.

Those few stations that I managed to meet at 50.323MHz were easy to work.

Just how to tell the others that they should peek also 10kHz up?

Auto QSY could be better than self spotting at DXCluster.

--
Saku
OH1KH



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


Re: [wsjt-devel] FT8: Double Click, sometimes wrong CallSign

2020-06-29 Thread roland.hartmann
Hi Reino,

 

I am trying it. Until now it seems to work – thanks !

 

73 Roland, DK4RH

 

Von: Reino Talarmo  
Gesendet: Montag, 29. Juni 2020 19:26
An: 'WSJT software development' 
Betreff: Re: [wsjt-devel] FT8: Double Click, sometimes wrong CallSign

 

Hi Roland,

You could try use General > Display Start new period decodes at top. At
least I got help.

73, Reino OH3mA

 

From: roland.hartm...@web.de <mailto:roland.hartm...@web.de>
[mailto:roland.hartm...@web.de] 
Sent: 29. kesäkuuta 2020 19:24
To: 'WSJT software development' mailto:wsjt-devel@lists.sourceforge.net> >
Subject: [wsjt-devel] FT8: Double Click, sometimes wrong CallSign

 

Think a smaller issue, but also happened on other stations:

 

Sometimes I try to answer a CQ with a double click in the Band Activity Part
- but not the station is used, which I had selected.

 

Example:



 

I did a double click on IU8MOA – but N9FN was used.

 

It is almost happened, if something was decoded a little bit later

Before this single one was happened, I thought it is only happened if the
Band activity is scrolling – but in this case it was not the case (timestamp
= 160815).

Think the best way is to store the position / CallSign of the first click.
And the second click should only be used to change the RX Frequency and
enable Tx (if activated). But for the stored CallSign of the first click.

 

I have the impression this is happened also in installations of other OM/YL.
Sometimes I get an answer even I didn’t send a CQ, only was a call with
another station.

 

Think this is not a big issue, but should be easy to change in the software.

My System: Windows 10 64-bit, WSJT-X 2.2.1  (not 2.2.2 of course I have
always an additional active session with WSPR).

 

73 de Roland, DK4RH

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


Re: [wsjt-devel] FT8: Double Click, sometimes wrong CallSign

2020-06-29 Thread Gary McDuffie



> On Jun 29, 2020, at 11:25, Reino Talarmo  wrote:
> 
> Sometimes I try to answer a CQ with a double click in the Band Activity Part 
> - but not the station is used, which I had selected.

More than likely, you are a victim of the multiple decoding cycles per 15 
second sequence.  The screen updates as you double click, and it grabs the 
callsign adjacent to the one you wanted.  This is an unfortunate side effect of 
the multiple decode per sequence added in the later updates.  Quck way to get 
around it is to turn MONITOR off before you double click the line you want.  It 
will stop and stay where it is and you can proceed from there.  

Gary - AG0N

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


Re: [wsjt-devel] FT8: Double Click, sometimes wrong CallSign

2020-06-29 Thread Reino Talarmo
Hi Roland,

You could try use General > Display Start new period decodes at top. At
least I got help.

73, Reino OH3mA

 

From: roland.hartm...@web.de [mailto:roland.hartm...@web.de] 
Sent: 29. kesäkuuta 2020 19:24
To: 'WSJT software development' 
Subject: [wsjt-devel] FT8: Double Click, sometimes wrong CallSign

 

Think a smaller issue, but also happened on other stations:

 

Sometimes I try to answer a CQ with a double click in the Band Activity Part
- but not the station is used, which I had selected.

 

Example:



 

I did a double click on IU8MOA – but N9FN was used.

 

It is almost happened, if something was decoded a little bit later

Before this single one was happened, I thought it is only happened if the
Band activity is scrolling – but in this case it was not the case (timestamp
= 160815).

Think the best way is to store the position / CallSign of the first click.
And the second click should only be used to change the RX Frequency and
enable Tx (if activated). But for the stored CallSign of the first click.

 

I have the impression this is happened also in installations of other OM/YL.
Sometimes I get an answer even I didn’t send a CQ, only was a call with
another station.

 

Think this is not a big issue, but should be easy to change in the software.

My System: Windows 10 64-bit, WSJT-X 2.2.1  (not 2.2.2 of course I have
always an additional active session with WSPR).

 

73 de Roland, DK4RH

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


[wsjt-devel] FT8: Double Click, sometimes wrong CallSign

2020-06-29 Thread roland.hartmann
Think a smaller issue, but also happened on other stations:



Sometimes I try to answer a CQ with a double click in the Band Activity Part
- but not the station is used, which I had selected.



Example:





I did a double click on IU8MOA - but N9FN was used.



It is almost happened, if something was decoded a little bit later

Before this single one was happened, I thought it is only happened if the
Band activity is scrolling - but in this case it was not the case (timestamp
= 160815).

Think the best way is to store the position / CallSign of the first click.
And the second click should only be used to change the RX Frequency and
enable Tx (if activated). But for the stored CallSign of the first click.



I have the impression this is happened also in installations of other OM/YL.
Sometimes I get an answer even I didn't send a CQ, only was a call with
another station.



Think this is not a big issue, but should be easy to change in the software.

My System: Windows 10 64-bit, WSJT-X 2.2.1  (not 2.2.2 of course I have
always an additional active session with WSPR).



73 de Roland, DK4RH

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


Re: [wsjt-devel] FT8 Decode lockup observations

2020-06-22 Thread Al

Bill,
  As stated in my post, replaying .wav files that where saved during 
when the original failure occurred does NOT cause the failure to recur.
  Also note that while WSJT-X is in the fault mode, ALT-Z only clears 
the indicator until the next time the decoder is supposed to run (~ 12 
sec ). And then the decode indicator stays on again.


AL, K0VM

On 6/21/2020 10:28 AM, Bill Somerville wrote:

On 21/06/2020 16:10, Al wrote:

( WSJT-X 2.2.1, Win 10 )

From time to  time, usually while monitoring 6m over night, I get a a 
Decode lockup.  The Decode button is ON continuously, wide graph is 
still running, wav files still being saved and no decodes are 
displayed in the band activity window. Seems more frequent with 2.2.1 
than 2.1.2.


Stopping and restarting WSJT will clear the issue. Replaying .wav 
files for the time when the lock up occurred does not induce a lockup.


When the lock up occurs, an 'Erase Band activity' will result in a 
brief pause in the highlight button being ON ( i.e. at about 12 
seconds into the cycle, the button toggles off for about 1 second, 
and then back on until the next 12 second epoch. )
If I issue a ALT-Z at the beginning of a cycle, the decode indicator 
goes off until the next 12 sec epoch and then stays on.  If I pause 
decodes by turning off the monitor, issue a ALT-Z and playback a 
.wav  file, the decode indicator comes on immediately and stays on.  
( Even with .wav files that playback correctly after WSJT has been 
restarted. )


Once locked up, changing the decode depth has no effect on recovery 
attempts.


If you have addition debugging trials.

AL, K0VM


Hi Al,

if you can provide a .WAV file or minimal sequence of .WAV files that 
can reproduce this issue when playing them back in WSJT-X, then please 
provide them.


The FT8 decoder can be "unfrozen" by hitting the Alt+Z key when this 
as yet undiagnosed issue occurs. See "Menu->Help->Shortcut keys" for a 
reminder.


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] FT8 Decode lockup observation

2020-06-22 Thread Tony
Hi Bill –

Already tried using Option+letter instead of Alt+letter …. No luck.  The 
Ctrl+letter and Shift+letter keyboard shortcuts work on the Mac keyboard with a 
Mac Mini … none of the Option+letter (aka Alt+letter) work in 2.2.1 as far as I 
can see.

-Tony


On 22/06/2020 11:16, Tony wrote:
>
> Hi Bill ?
>
> I was interested in keeping the Alt-Z shortcut in mind that you 
> mentioned to Al. ?I have found on WSJT-X 2.2.1 that most shortcuts 
> work on my MacMini (with a Mac keyboard), but no matter what I try I 
> can not get any of the ?Alt? shortcuts to work.? Mac keyboards have 
> the ?Alt/Option? key.? Are ?Alt? shortcuts supported for the Mac?? Is 
> there some other keyboard trick on the Mac to get the ?Alt? 
> shortcuts?? I?m guessing these shortcuts were originally designed for 
> a PC environment.? (Set-up here is Mac-Mini to a FT-991.)
>
> Thanks,
>
> Tony ? AE0AU
>
Hi Tony,

Alt+letter should be invoked by Option+letter, and Ctrl+letter should be 
invoked by Command+letter on Mac keyboards.

73
Bill
G4WJS.


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


Re: [wsjt-devel] FT8 Decode lockup observation

2020-06-22 Thread Bill Somerville

On 22/06/2020 11:16, Tony wrote:


Hi Bill –

I was interested in keeping the Alt-Z shortcut in mind that you 
mentioned to Al.  I have found on WSJT-X 2.2.1 that most shortcuts 
work on my MacMini (with a Mac keyboard), but no matter what I try I 
can not get any of the “Alt” shortcuts to work.  Mac keyboards have 
the “Alt/Option” key.  Are “Alt” shortcuts supported for the Mac?  Is 
there some other keyboard trick on the Mac to get the “Alt” 
shortcuts?  I’m guessing these shortcuts were originally designed for 
a PC environment.  (Set-up here is Mac-Mini to a FT-991.)


Thanks,

Tony – AE0AU


Hi Tony,

Alt+letter should be invoked by Option+letter, and Ctrl+letter should be 
invoked by Command+letter on Mac keyboards.


73
Bill
G4WJS.

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


Re: [wsjt-devel] FT8 Decode lockup observation

2020-06-22 Thread Tony
Hi Bill –
I was interested in keeping the Alt-Z shortcut in mind that you mentioned to 
Al.  I have found on WSJT-X 2.2.1 that most shortcuts work on my MacMini (with 
a Mac keyboard), but no matter what I try I can not get any of the “Alt” 
shortcuts to work.  Mac keyboards have the “Alt/Option” key.  Are “Alt” 
shortcuts supported for the Mac?  Is there some other keyboard trick on the Mac 
to get the “Alt” shortcuts?  I’m guessing these shortcuts were originally 
designed for a PC environment.  (Set-up here is Mac-Mini to a FT-991.)

Thanks,

Tony – AE0AU

Message: 1
Date: Sun, 21 Jun 2020 10:10:30 -0500
From: Al 
To: WSJT software development 
Subject: [wsjt-devel] FT8 Decode lockup observations
Message-ID: 
Content-Type: text/plain; charset="utf-8"; Format="flowed"

( WSJT-X 2.2.1, Win 10 )

 From time to? time, usually while monitoring 6m over night, I get a a 
Decode lockup.? The Decode button is ON continuously, wide graph is 
still running, wav files still being saved and no decodes are displayed 
in the band activity window. Seems more frequent with 2.2.1 than 2.1.2.

Stopping and restarting WSJT will clear the issue. Replaying .wav files 
for the time when the lock up occurred does not induce a lockup.

When the lock up occurs, an 'Erase Band activity' will result in a brief 
pause in the highlight button being ON ( i.e. at about 12 seconds into 
the cycle, the button toggles off for about 1 second, and then back on 
until the next 12 second epoch. )
If I issue a ALT-Z at the beginning of a cycle, the decode indicator 
goes off until the next 12 sec epoch and then stays on. If I pause 
decodes by turning off the monitor, issue a ALT-Z and playback a .wav? 
file, the decode indicator comes on immediately and stays on.? ( Even 
with .wav files that playback correctly after WSJT has been restarted. )

Once locked up, changing the decode depth has no effect on recovery 
attempts.

If you have addition debugging trials.

AL, K0VM
-- next part --
An HTML attachment was scrubbed...

--

Message: 2
Date: Sun, 21 Jun 2020 16:28:18 +0100
From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FT8 Decode lockup observations
Message-ID: <2019f1d6-034a-9ea7-e69a-3f3deb1ef...@classdesign.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 21/06/2020 16:10, Al wrote:
> ( WSJT-X 2.2.1, Win 10 )
>
> From time to? time, usually while monitoring 6m over night, I get a a 
> Decode lockup.? The Decode button is ON continuously, wide graph is 
> still running, wav files still being saved and no decodes are 
> displayed in the band activity window. Seems more frequent with 2.2.1 
> than 2.1.2.
>
> Stopping and restarting WSJT will clear the issue. Replaying .wav 
> files for the time when the lock up occurred does not induce a lockup.
>
> When the lock up occurs, an 'Erase Band activity' will result in a 
> brief pause in the highlight button being ON ( i.e. at about 12 
> seconds into the cycle, the button toggles off for about 1 second, and 
> then back on until the next 12 second epoch. )
> If I issue a ALT-Z at the beginning of a cycle, the decode indicator 
> goes off until the next 12 sec epoch and then stays on.? If I pause 
> decodes by turning off the monitor, issue a ALT-Z and playback a .wav? 
> file, the decode indicator comes on immediately and stays on.? ( Even 
> with .wav files that playback correctly after WSJT has been restarted. )
>
> Once locked up, changing the decode depth has no effect on recovery 
> attempts.
>
> If you have addition debugging trials.
>
> AL, K0VM

Hi Al,

if you can provide a .WAV file or minimal sequence of .WAV files that 
can reproduce this issue when playing them back in WSJT-X, then please 
provide them.

The FT8 decoder can be "unfrozen" by hitting the Alt+Z key when this as 
yet undiagnosed issue occurs. See "Menu->Help->Shortcut keys" for a 
reminder.

73
Bill
G4WJS.

-- next part --

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


Re: [wsjt-devel] FT8 Decode lockup observations

2020-06-21 Thread Bill Somerville

On 21/06/2020 16:10, Al wrote:

( WSJT-X 2.2.1, Win 10 )

From time to  time, usually while monitoring 6m over night, I get a a 
Decode lockup.  The Decode button is ON continuously, wide graph is 
still running, wav files still being saved and no decodes are 
displayed in the band activity window. Seems more frequent with 2.2.1 
than 2.1.2.


Stopping and restarting WSJT will clear the issue. Replaying .wav 
files for the time when the lock up occurred does not induce a lockup.


When the lock up occurs, an 'Erase Band activity' will result in a 
brief pause in the highlight button being ON ( i.e. at about 12 
seconds into the cycle, the button toggles off for about 1 second, and 
then back on until the next 12 second epoch. )
If I issue a ALT-Z at the beginning of a cycle, the decode indicator 
goes off until the next 12 sec epoch and then stays on.  If I pause 
decodes by turning off the monitor, issue a ALT-Z and playback a .wav  
file, the decode indicator comes on immediately and stays on.  ( Even 
with .wav files that playback correctly after WSJT has been restarted. )


Once locked up, changing the decode depth has no effect on recovery 
attempts.


If you have addition debugging trials.

AL, K0VM


Hi Al,

if you can provide a .WAV file or minimal sequence of .WAV files that 
can reproduce this issue when playing them back in WSJT-X, then please 
provide them.


The FT8 decoder can be "unfrozen" by hitting the Alt+Z key when this as 
yet undiagnosed issue occurs. See "Menu->Help->Shortcut keys" for a 
reminder.


73
Bill
G4WJS.

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


[wsjt-devel] FT8 Decode lockup observations

2020-06-21 Thread Al

( WSJT-X 2.2.1, Win 10 )

From time to  time, usually while monitoring 6m over night, I get a a 
Decode lockup.  The Decode button is ON continuously, wide graph is 
still running, wav files still being saved and no decodes are displayed 
in the band activity window. Seems more frequent with 2.2.1 than 2.1.2.


Stopping and restarting WSJT will clear the issue. Replaying .wav files 
for the time when the lock up occurred does not induce a lockup.


When the lock up occurs, an 'Erase Band activity' will result in a brief 
pause in the highlight button being ON ( i.e. at about 12 seconds into 
the cycle, the button toggles off for about 1 second, and then back on 
until the next 12 second epoch. )
If I issue a ALT-Z at the beginning of a cycle, the decode indicator 
goes off until the next 12 sec epoch and then stays on. If I pause 
decodes by turning off the monitor, issue a ALT-Z and playback a .wav  
file, the decode indicator comes on immediately and stays on.  ( Even 
with .wav files that playback correctly after WSJT has been restarted. )


Once locked up, changing the decode depth has no effect on recovery 
attempts.


If you have addition debugging trials.

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


Re: [wsjt-devel] FT8: Double Click on entry in Rx Frequency only set the own Rx frequency

2020-06-08 Thread roland.hartmann
Attached one example what maybe also for other is happened.

 

During FT8-Calls I got a direct call from EA3HKY   (not called from me before, 
also had not send a CQ before).

Friendly how I am I answer via double click.

SEND-Frequency is not changed.  I have to change it separately – than the 
sequence is going on.

 

Not a big issue – in the meantime I set the sending-frequency also.

But think such is not happened only for my ?!

 

(PS: Has nothing to do with “Hold TX Freq”. In addition those isn’t activated 
from my part.)

 

 



 

-Ursprüngliche Nachricht-
Von: Gary McDuffie  
Gesendet: Montag, 1. Juni 2020 07:51
An: WSJT software development 
Betreff: Re: [wsjt-devel] FT8: Double Click on entry in Rx Frequency only set 
the own Rx frequency

 

 

 

> On May 30, 2020, at 07:53,  <mailto:roland.hartm...@web.de> 
> roland.hartm...@web.de wrote:

> 

> In all other cases where I was not named as receiver Rx and Tx frequency are 
> changed.

 

You should check the HOLD TX box so the transmitter does NOT shift.  You should 
not call on the other station’s frequency.  Pick a clear frequency on your time 
cycle and call.

 

Gary - AG0N

 

___

wsjt-devel mailing list

 <mailto:wsjt-devel@lists.sourceforge.net> wsjt-devel@lists.sourceforge.net

 <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> 
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] FT8: Double Click on entry in Rx Frequency only set the own Rx frequency

2020-05-31 Thread Gary McDuffie


> On May 30, 2020, at 07:53, roland.hartm...@web.de wrote:
> 
> In all other cases where I was not named as receiver Rx and Tx frequency are 
> changed.

You should check the HOLD TX box so the transmitter does NOT shift.  You should 
not call on the other station’s frequency.  Pick a clear frequency on your time 
cycle and call.

Gary - AG0N

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


Re: [wsjt-devel] FT8: Double Click on entry in Rx Frequency only set the own Rx frequency

2020-05-30 Thread roland.hartmann
Hi,

>> This makes sense. The calling station heard you where you are. He may not 
>> hear you if you move.

Do not know, what the other really was doing - but think follow situation is 
happen:
I think the other station are making CQ calling, without activation of "Call 
1st". After End of watchdog their TX do not send anymore. I am moving to 
another one, those station recognize a little later on that there was an answer 
- and manually activate the sequence.
If I activate the sequence by double click on the answer to me they definitely 
not recognize my on the "wrong" frequency. I have to go to their frequency, 
where they are calling.
And special those is, what I forget quite often in those situation. To change 
the Tx frequency also ☹

73, Roland - DK4RH


-Ursprüngliche Nachricht-
Von: Jim Shorney  
Gesendet: Samstag, 30. Mai 2020 17:05
An: wsjt-devel@lists.sourceforge.net
Betreff: Re: [wsjt-devel] FT8: Double Click on entry in Rx Frequency only set 
the own Rx frequency


This makes sense. The calling station heard you where you are. He may not hear 
you if you move. 

73

-Jim
NU0C

On Sat, 30 May 2020 15:53:18 +0200
 wrote:

> After testing a little bit I recognize: If I do an double click in Rx 
> Frequency on an entry where I was named as receiver - than only the Rx 
> Frequency is changed. In all other cases where I was not named as receiver Rx 
> and Tx frequency are changed.
> 
> 73, Roland - DK4RH


___
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] FT8: Double Click on entry in Rx Frequency only set the own Rx frequency

2020-05-30 Thread Jim Shorney


This makes sense. The calling station heard you where you are. He may not hear 
you if you move. 

73

-Jim
NU0C

On Sat, 30 May 2020 15:53:18 +0200
 wrote:

> After testing a little bit I recognize: If I do an double click in Rx 
> Frequency on an entry where I was named as receiver - than only the Rx 
> Frequency is changed. In all other cases where I was not named as receiver Rx 
> and Tx frequency are changed.
> 
> 73, Roland - DK4RH


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


Re: [wsjt-devel] FT8: Double Click on entry in Rx Frequency only set the own Rx frequency

2020-05-30 Thread roland.hartmann
Hallo Frank,

habe auch schon einige 100 QSOs mit den RC-Versionen hinter mir. Kann sein, 
dass der Issue schon vorher war - habe lange nicht mehr so intensiv FT8 oder 
gar FT4 gemacht.
Gerade noch etwas ausprobiert, Häkchen "Hold Tx Freq" war NICHT gesetzt. 
Sicherheitshalber gesetzt und zurück gesetzt.
Interessanter Lerneffekt: Mache ich im Rx Frequency Eintrag einen Doppelklick 
auf einen Eintrag, der NICHT für mich bestimmt war - so werden Tx und Rx 
Frequenz gesetzt.
Mache ich einen Doppelklick auf einen Eintrag der für mich bestimmt ist - so 
wird ausschließlich die Rx Frequenz geändert.

Shortly in English:
After testing a little bit I recognize: If I do an double click in Rx Frequency 
on an entry where I was named as receiver - than only the Rx Frequency is 
changed. In all other cases where I was not named as receiver Rx and Tx 
frequency are changed.

73, Roland - DK4RH

-Ursprüngliche Nachricht-
Von: Frank Hunger  
Gesendet: Samstag, 30. Mai 2020 13:32
An: WSJT software development 
Betreff: Re: [wsjt-devel] FT8: Double Click on entry in Rx Frequency only set 
the own Rx frequency



> Am 30.05.2020 um 12:56 schrieb  
> :
> 
> Hi ,
> 
> sometimes I am trying already to answer another station - and get an 
> answer of a station some minutes ago.
> Than I do a double click on the entry in the Rx Frequency Window. Only 
> my own Tx frequency is changed - the Tx frequency stay.
> (takes always a little bit to recognize and change also the Tx 
> frequency...)
> 
> 73, Roland - DK3RH
> 
> Hallo, ich denke, dass Dich die andere Station weitergerufen hat, weil sie 
> ev. kein rr73 bekommen hat. 
Mit dem Häkchen bei tx änderst Du den Sendebeginn. Muss man immer mal wechseln, 
wenn es klemmt. 
Die rc3 läuft eigentlich ganz gut, habe heute ca. 20 QSO’s von 80 -6 m 
gefahren, es gab nur einen einzigen Klemmer.
Das kann auch manchmal an der Gegenstation liegen.
73 und schöne Pfingsten de Frank DM5KK
> 
> ___
> 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


Re: [wsjt-devel] FT8: Double Click on entry in Rx Frequency only set the own Rx frequency

2020-05-30 Thread Frank Hunger


> Am 30.05.2020 um 12:56 schrieb  
> :
> 
> Hi ,
> 
> sometimes I am trying already to answer another station - and get an answer
> of a station some minutes ago.
> Than I do a double click on the entry in the Rx Frequency Window. Only my
> own Tx frequency is changed - the Tx frequency stay.
> (takes always a little bit to recognize and change also the Tx frequency...)
> 
> 73, Roland - DK3RH
> 
> Hallo, ich denke, dass Dich die andere Station weitergerufen hat, weil sie 
> ev. kein rr73 bekommen hat. 
Mit dem Häkchen bei tx änderst Du den Sendebeginn. Muss man immer mal wechseln, 
wenn es klemmt. 
Die rc3 läuft eigentlich ganz gut, habe heute ca. 20 QSO’s von 80 -6 m 
gefahren, es gab nur einen einzigen Klemmer.
Das kann auch manchmal an der Gegenstation liegen.
73 und schöne Pfingsten de Frank DM5KK
> 
> ___
> 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] FT8: Double Click on entry in Rx Frequency only set the own Rx frequency

2020-05-30 Thread roland.hartmann
Hi ,

sometimes I am trying already to answer another station - and get an answer
of a station some minutes ago.
Than I do a double click on the entry in the Rx Frequency Window. Only my
own Tx frequency is changed - the Tx frequency stay.
(takes always a little bit to recognize and change also the Tx frequency...)

73, Roland - DK3RH



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


Re: [wsjt-devel] FT8 with click anomaly

2020-05-28 Thread Artie Langston
I actually experienced that myself on my end once. It was solved by
plugging the IC-7300 directly into the computer rather than a USB hub. I
could actually see the spike on the 7300's audio scope.

I caught it very quickly, but maybe that was me! :-)

Artie KD0GY

On Thu, May 28, 2020 at 5:01 PM Gary McDuffie  wrote:

>
>
> > On May 28, 2020, at 12:33, Andy Durbin  wrote:
> >
> > The linked WAV file was captured by, and edited in, Audacity.  It does
> not replay in WSJT-X.
> >
> > https://tinyurl.com/y8ehtrkd
>
> I don’t have a definitive answer, Andy, but have heard that myself now and
> then.  I sometimes chalk that sort of thing up to having the blanker turned
> on.  Verify, of course, by turning it off.  That’s not always the case here
> though.
>
> Gary - AG0N
>
> ___
> 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] FT8 with click anomaly

2020-05-28 Thread George J Molnar

Sometimes hear that kind of effect showing up from an overtaxed computer. 
Over/under-runs and such.


George J Molnar, KF2T 
Arlington, Virginia, USA


> On May 28, 2020, at 6:00 PM, Gary McDuffie  wrote:
> 
> 
> 
>> On May 28, 2020, at 12:33, Andy Durbin  wrote:
>> 
>> The linked WAV file was captured by, and edited in, Audacity.  It does not 
>> replay in WSJT-X.
>> 
>> https://tinyurl.com/y8ehtrkd
> 
> I don’t have a definitive answer, Andy, but have heard that myself now and 
> then.  I sometimes chalk that sort of thing up to having the blanker turned 
> on.  Verify, of course, by turning it off.  That’s not always the case here 
> though.
> 
> Gary - AG0N
> 
> ___
> 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] FT8 with click anomaly

2020-05-28 Thread Gary McDuffie


> On May 28, 2020, at 12:33, Andy Durbin  wrote:
> 
> The linked WAV file was captured by, and edited in, Audacity.  It does not 
> replay in WSJT-X.
> 
> https://tinyurl.com/y8ehtrkd

I don’t have a definitive answer, Andy, but have heard that myself now and 
then.  I sometimes chalk that sort of thing up to having the blanker turned on. 
 Verify, of course, by turning it off.  That’s not always the case here though.

Gary - AG0N

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


[wsjt-devel] FT8 with click anomaly

2020-05-28 Thread Andy Durbin
I observed an FT8 signal that was "wide" in a similar way to a CW signal with 
key clicks.  I listened to the signal and could hear what appears to be a 
regularly repeating series of clicks.  The signal, which was from a local 
station, decoded normally.

The linked WAV file was captured by, and edited in, Audacity.  It does not 
replay in WSJT-X.

https://tinyurl.com/y8ehtrkd

I have never seen or heard an FT8 signal like this one.  Does anyone know what 
could cause this anomaly?

73,
Andy, k3wyc

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


Re: [wsjt-devel] FT8 False Decodes 2.2.0 rc1

2020-05-16 Thread Saku

Hi!

Downloaded wsjtx source from GIt yesterday and now rig model #2 Net 
rigctld works again as before.

Fine!. Thanks !
I have used 2.2.0rc1 just few hours but noticed also one false decode on 
17m band.


It was claimed to be Iraq by prefix, but Grid was something CIxx
At the end of the line there was no "aX" marking, so assumed to be a 
"real decode"


My companion program gave me a warning about new country so I was 
calling back until noticed that the grid was nonsense.
I'll be looking forward to catch these with the wav file to see if re 
decoding gives same false result again.
Perhaps it needs to re decode several previous files in chain to get the 
error (If it comes from some kind of memory leak).


--
Saku
OH1KH

Black Michael via wsjt-devel kirjoitti 16.5.2020 klo 6.28:

Save your WAV files and submit some examples.

de Mike W9MDB




On Friday, May 15, 2020, 10:10:38 PM CDT, Allan VK4QG 
 wrote:



Hi All,

While monitoring 6m, which for 99% of the time is very quiet here, (from
a QRM and amateur activity perspective) I am getting a vast increase in
the number of false decodes with the new version 2.2.0. rc1, compared
with 2.1.2.  With the previous version, I would get maybe one false
decode per week.

This occurs regardless of the Decode setting 'Fast, Normal or Deep' and
'Enable AP' is not checked. In fact all settings are the same as per 2.1.2

This issue has also been observed by another amateur friend VK4ZB, while
monitoring both 10m and 6m.

An example of the false decodes are below: -

200512_002930    50.313 Rx FT8    -24  2.0 1808 CQ J HQIZ4GD 0
200512_032845    50.313 Rx FT8    -24  1.2 2381 U71SSP/P M42TGQ/P OI41
200512_040245    50.313 Rx FT8    -24  0.7 1364 QP4BHA/R 1A4MVL R KK78
200512_040930    50.313 Rx FT8    -24 -2.4 2338 D72IQQ/R 2B7VII BD64
200512_05    50.313 Rx FT8    -24  1.1 1813 507D7D79D66E12EB7A
200512_234345    50.313 Rx FT8    -24 -2.1 3691 MR9/L3QWI 80

200513_000900    50.313 Rx FT8    -24  1.2 3981 WK5PMR <...> R 599 0804
200513_003430    50.313 Rx FT8    -24 -0.5 3851 K1QYN6U/KQA <...> RRR
200513_010045    50.313 Rx FT8    -24  0.8 1256 WX3GJ/P SS9BHE/P R PI36
200513_042015    50.313 Rx FT8    -24  1.6 2556 <...> <...> 561942 [I97KI
200513_053915    50.313 Rx FT8    -24  2.0 3771 TU; OE0OZT EC4QCC 569 7525

200514_021400    50.313 Rx FT8    -24  0.5 267 <...> <...> R 521355 ^H91WH
200514_023645    50.313 Rx FT8    -24  2.1 2976 9U2BYC ML6BHS R JF39
200514_061500    50.313 Rx FT8    -24  1.8 3091 CQ DXY594TSN5O
200514_063715    50.313 Rx FT8    -24  1.9 1178 <...> <...> R 541099 
QA66CK

200514_070600    50.313 Rx FT8    -23 -1.6 1116 2U3MFE UT8XXJ R 549 3369
200514_222645    50.313 Rx FT8    -24  0.7 4049 <...> <...> 590273 LI86TB
200514_223100    50.313 Rx FT8    -24  1.9 2621

200515_00    50.313 Rx FT8    -24  0.8 2494 <...> <...> 550288 MF80PU
200515_011100    50.313 Rx FT8    -19  2.3 1702 QG9JQJ ZN5GT R 539 1171
200515_021200    50.313 Rx FT8    -24 -0.1 931 4X4AYF/P HR3SFK R LQ91
200515_024815    50.313 Rx FT8    -24  0.8 1130 3PG/45ZQ4EEIK
200515_035230    50.313 Rx FT8    -24  1.7 1072 75NMC/P UY2MGH/P R ID64
200515_063415    50.313 Rx FT8    -24  2.4 2618 <...> 816BNE IA00
200515_223815    50.313 Rx FT8    -22  0.1 143 <...> <...> R 532031 JA38SR

My system is a Dell1650, i7 @3.40 GHz, 16GB RAM, W10 pro 64bit

73,

Allan - VK4QG




___
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


Re: [wsjt-devel] FT8 False Decodes 2.2.0 rc1

2020-05-15 Thread Stephen Ireland
Allan,

I have been reporting exactly the same occurrence in exactly the same sequence 
in this place ! Bill has responded around 24 hours earlier !

You play recordings back and the "false decode" is not reported so its 
pointless posting these !

73

Steve I
VK3VM / Vk3SIR

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


Re: [wsjt-devel] FT8 False Decodes 2.2.0 rc1

2020-05-15 Thread Black Michael via wsjt-devel
Save your WAV files and submit some examples.
de Mike W9MDB

 

On Friday, May 15, 2020, 10:10:38 PM CDT, Allan VK4QG 
 wrote:  
 
 Hi All,

While monitoring 6m, which for 99% of the time is very quiet here, (from 
a QRM and amateur activity perspective) I am getting a vast increase in 
the number of false decodes with the new version 2.2.0. rc1, compared 
with 2.1.2.  With the previous version, I would get maybe one false 
decode per week.

This occurs regardless of the Decode setting 'Fast, Normal or Deep' and 
'Enable AP' is not checked. In fact all settings are the same as per 2.1.2

This issue has also been observed by another amateur friend VK4ZB, while 
monitoring both 10m and 6m.

An example of the false decodes are below: -

200512_002930    50.313 Rx FT8    -24  2.0 1808 CQ J HQIZ4GD 0
200512_032845    50.313 Rx FT8    -24  1.2 2381 U71SSP/P M42TGQ/P OI41
200512_040245    50.313 Rx FT8    -24  0.7 1364 QP4BHA/R 1A4MVL R KK78
200512_040930    50.313 Rx FT8    -24 -2.4 2338 D72IQQ/R 2B7VII BD64
200512_05    50.313 Rx FT8    -24  1.1 1813 507D7D79D66E12EB7A
200512_234345    50.313 Rx FT8    -24 -2.1 3691 MR9/L3QWI 80

200513_000900    50.313 Rx FT8    -24  1.2 3981 WK5PMR <...> R 599 0804
200513_003430    50.313 Rx FT8    -24 -0.5 3851 K1QYN6U/KQA <...> RRR
200513_010045    50.313 Rx FT8    -24  0.8 1256 WX3GJ/P SS9BHE/P R PI36
200513_042015    50.313 Rx FT8    -24  1.6 2556 <...> <...> 561942 [I97KI
200513_053915    50.313 Rx FT8    -24  2.0 3771 TU; OE0OZT EC4QCC 569 7525

200514_021400    50.313 Rx FT8    -24  0.5  267 <...> <...> R 521355 ^H91WH
200514_023645    50.313 Rx FT8    -24  2.1 2976 9U2BYC ML6BHS R JF39
200514_061500    50.313 Rx FT8    -24  1.8 3091 CQ DXY594TSN5O
200514_063715    50.313 Rx FT8    -24  1.9 1178 <...> <...> R 541099 QA66CK
200514_070600    50.313 Rx FT8    -23 -1.6 1116 2U3MFE UT8XXJ R 549 3369
200514_222645    50.313 Rx FT8    -24  0.7 4049 <...> <...> 590273 LI86TB
200514_223100    50.313 Rx FT8    -24  1.9 2621

200515_00    50.313 Rx FT8    -24  0.8 2494 <...> <...> 550288 MF80PU
200515_011100    50.313 Rx FT8    -19  2.3 1702 QG9JQJ ZN5GT R 539 1171
200515_021200    50.313 Rx FT8    -24 -0.1  931 4X4AYF/P HR3SFK R LQ91
200515_024815    50.313 Rx FT8    -24  0.8 1130 3PG/45ZQ4EEIK
200515_035230    50.313 Rx FT8    -24  1.7 1072 75NMC/P UY2MGH/P R ID64
200515_063415    50.313 Rx FT8    -24  2.4 2618 <...> 816BNE IA00
200515_223815    50.313 Rx FT8    -22  0.1  143 <...> <...> R 532031 JA38SR

My system is a Dell1650, i7 @3.40 GHz, 16GB RAM, W10 pro 64bit

73,

Allan - VK4QG




___
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] FT8 False Decodes 2.2.0 rc1

2020-05-15 Thread Allan VK4QG

Hi All,

While monitoring 6m, which for 99% of the time is very quiet here, (from 
a QRM and amateur activity perspective) I am getting a vast increase in 
the number of false decodes with the new version 2.2.0. rc1, compared 
with 2.1.2.  With the previous version, I would get maybe one false 
decode per week.


This occurs regardless of the Decode setting 'Fast, Normal or Deep' and 
'Enable AP' is not checked. In fact all settings are the same as per 2.1.2


This issue has also been observed by another amateur friend VK4ZB, while 
monitoring both 10m and 6m.


An example of the false decodes are below: -

200512_002930    50.313 Rx FT8    -24  2.0 1808 CQ J HQIZ4GD 0
200512_032845    50.313 Rx FT8    -24  1.2 2381 U71SSP/P M42TGQ/P OI41
200512_040245    50.313 Rx FT8    -24  0.7 1364 QP4BHA/R 1A4MVL R KK78
200512_040930    50.313 Rx FT8    -24 -2.4 2338 D72IQQ/R 2B7VII BD64
200512_05    50.313 Rx FT8    -24  1.1 1813 507D7D79D66E12EB7A
200512_234345    50.313 Rx FT8    -24 -2.1 3691 MR9/L3QWI 80

200513_000900    50.313 Rx FT8    -24  1.2 3981 WK5PMR <...> R 599 0804
200513_003430    50.313 Rx FT8    -24 -0.5 3851 K1QYN6U/KQA <...> RRR
200513_010045    50.313 Rx FT8    -24  0.8 1256 WX3GJ/P SS9BHE/P R PI36
200513_042015    50.313 Rx FT8    -24  1.6 2556 <...> <...> 561942 [I97KI
200513_053915    50.313 Rx FT8    -24  2.0 3771 TU; OE0OZT EC4QCC 569 7525

200514_021400    50.313 Rx FT8    -24  0.5  267 <...> <...> R 521355 ^H91WH
200514_023645    50.313 Rx FT8    -24  2.1 2976 9U2BYC ML6BHS R JF39
200514_061500    50.313 Rx FT8    -24  1.8 3091 CQ DXY594TSN5O
200514_063715    50.313 Rx FT8    -24  1.9 1178 <...> <...> R 541099 QA66CK
200514_070600    50.313 Rx FT8    -23 -1.6 1116 2U3MFE UT8XXJ R 549 3369
200514_222645    50.313 Rx FT8    -24  0.7 4049 <...> <...> 590273 LI86TB
200514_223100    50.313 Rx FT8    -24  1.9 2621

200515_00    50.313 Rx FT8    -24  0.8 2494 <...> <...> 550288 MF80PU
200515_011100    50.313 Rx FT8    -19  2.3 1702 QG9JQJ ZN5GT R 539 1171
200515_021200    50.313 Rx FT8    -24 -0.1  931 4X4AYF/P HR3SFK R LQ91
200515_024815    50.313 Rx FT8    -24  0.8 1130 3PG/45ZQ4EEIK
200515_035230    50.313 Rx FT8    -24  1.7 1072 75NMC/P UY2MGH/P R ID64
200515_063415    50.313 Rx FT8    -24  2.4 2618 <...> 816BNE IA00
200515_223815    50.313 Rx FT8    -22  0.1  143 <...> <...> R 532031 JA38SR

My system is a Dell1650, i7 @3.40 GHz, 16GB RAM, W10 pro 64bit

73,

Allan - VK4QG




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


Re: [wsjt-devel] FT8 F/H mode - am I out of step ?

2020-02-26 Thread Frode Igland
It seems just right. According to the "RX Frequency" window you did not
transmit 091645 and 091715 (no yellow line). That is the times when you see
in the "Band Activity" window what was going on from all the other chasers
you were able to decode. They did the same on all other 15 and 45, but you
didn't see that because you were transmitting and therefore not decoding
them.

It looks like there was a good pile-up going, so congratulations on making
the contact, Erik.

73 Frode LA6VQ

ons. 26. feb. 2020 kl. 10:51 skrev :

> Hi,
>
> This morning I was trying to contact the PY0FF expedition and observed a
> strange behaviour when attempting the QSO and sending my locator.
> My "PY0FF ON4PB JO20" message is sent every 30 secs whereas all other
> stations are sending their locator in group at a specific time (see
> screenshot at 091715).
>
> I did not receive other stations sending their locator "out of step", so I
> thought something went amiss here ?
> From the screenshot, one can see that I am in hound mode and calling above
> 1000 Hz :
>
> https://1drv.ms/u/s!AtBGol2-BnqRhflgvVRljaWMXxDnjg?e=T9rava
>
> And for the record, I was eventually able to complete the QSO.
> Is this a correct behaviour or am I missing something here ?
>
> 73's Erik
> ON4PB
>
>
>
>
>
> ___
> 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] FT8 F/H mode - am I out of step ?

2020-02-26 Thread George J Molnar
Looks absolutely fine

George J Molnar, KF2T 
Arlington, Virginia, USA


> On Feb 26, 2020, at 4:48 AM, runninge...@gmail.com wrote:
> 
> Hi,
> 
> This morning I was trying to contact the PY0FF expedition and observed a
> strange behaviour when attempting the QSO and sending my locator.
> My "PY0FF ON4PB JO20" message is sent every 30 secs whereas all other
> stations are sending their locator in group at a specific time (see
> screenshot at 091715).
> 
> I did not receive other stations sending their locator "out of step", so I
> thought something went amiss here ?
> From the screenshot, one can see that I am in hound mode and calling above
> 1000 Hz :
> 
> https://1drv.ms/u/s!AtBGol2-BnqRhflgvVRljaWMXxDnjg?e=T9rava
> 
> And for the record, I was eventually able to complete the QSO.
> Is this a correct behaviour or am I missing something here ?
> 
> 73's Erik
> ON4PB
> 
> 
> 
> 
> 
> ___
> 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] FT8 F/H mode - am I out of step ?

2020-02-26 Thread runningerik
Hi,

This morning I was trying to contact the PY0FF expedition and observed a
strange behaviour when attempting the QSO and sending my locator.
My "PY0FF ON4PB JO20" message is sent every 30 secs whereas all other
stations are sending their locator in group at a specific time (see
screenshot at 091715).

I did not receive other stations sending their locator "out of step", so I
thought something went amiss here ?
>From the screenshot, one can see that I am in hound mode and calling above
1000 Hz :

https://1drv.ms/u/s!AtBGol2-BnqRhflgvVRljaWMXxDnjg?e=T9rava

And for the record, I was eventually able to complete the QSO.
Is this a correct behaviour or am I missing something here ?

73's Erik
ON4PB





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


Re: [wsjt-devel] FT8 diversity patch

2020-01-21 Thread Iztok Saje

Hello!

Patch now works for FT4 and FT8 with WSJTX 2.1.2, I am finalizing documentation 
and doing some more testing.
There are three Fortran files changed, so only jt9 needs to be recompiled.
As I am on Linux, I can not compile Windows version.

I would kindly ask if somebody can compile jt9.exe, so I can include it?
K3 with two RX/IC-7610 owners preferred, so they can test it as well.
Personal E-mail, please.

Best 73, gl
Iztok, S52D








On 02/01/2019 06:45 AM, Iztok Saje wrote:

Hello!

Following some discussion on this forum, where I was too noisy, make me think.

When joining two uncorrelated  FT8 frames (taken on exactly same frequency, but 
not at the same time)
main problem is how to synchronize all tones?
My solution is to shift frames 7 times and do decoding after each shift, thus 
every tone get
summed up in phase (or close enough).
CPU load is few times higher as with standard decoder, but my I7 CPU can do it 
on time.

Testing in 1.9.1 gave me excellent results: I made several QSOs where plain FT8 
decoder would fail.

Source code for WSJTX 2.0.0 with more detailed description is now tested a bit 
and available at
http://lea.hamradio.si/~s52d/ft8div page.
You have to compile it yourself.

Time diversity (also called incremental redundancy) works by combining two 
consecutive
even/odd frames, good to take repeated messages out of the QRM/QRN.

Space diversity (called stereo diversity by W8JI) works when twp copies of 
WSJTX are run
with phase synchronuos RX like K3, IC-7610 etc. Bursts from two  RX/antennas 
are combined.
Data is exchanged using temporary files, so both WSJTX copies need separate 
configuration file.

IMHO this approach is worth to be considered to be included in one of the 
future releases.

Best 73, mni DX, CU

Iztok, S52D





[http://psn.sdn.si/ts/TS_Banner_NEO_oktober_2019_250x170.jpg]

Pravni pogoji / Legal disclaimer
Telekom Slovenije, d.d., Ljubljana 


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


Re: [wsjt-devel] FT8 encoding logic

2020-01-04 Thread Graham c
Indeed, pskreporter of course can not do anything with something it doesn't
get. The dependency is of course on the client software and what it does.

I did some more testing prompted by Reino's postings.

FN25 VE3GHM does not get sent to pskreporter by WSJT-X, likewise nor does
VE3GHM FN25.

CQ VE3GHM FN25, QRZ VE3GHM FN25 and DE VE3GHM FN25 all do get sent to
pskreporter

free text CQ VE3GH FN25 (i.e. 13 characters) also gets sent to pskreporter

cheers, Graham ve3gtc


On Sat, Jan 4, 2020 at 4:02 PM Philip Gladstone <
pjsg-w...@nospam.gladstonefamily.net> wrote:

> Whether PSK reporter gets to see some particular signal depends on the
> decoding software. It is easy enough to experiment with various
> transmissions and see which get reported. Use different callsigns
> (suffixes) so that you can tell which signals get through.
>
> On Sat, Jan 4, 2020 at 10:26 AM Reino Talarmo 
> wrote:
>
>> It seems that many, if not all messages, where the call sign is in the
>> 'sender' position are reported to pskreporter.info. So 'DE VE3GHM FN25'
>> would be fine, if non-standard call sign were supported with a locator. No
>> need to use CQ, if broadcasting and not needing a response at that time.
>>
>> 73, Reino oh3mA
>>
>>
>>
>> ___
>> 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


Re: [wsjt-devel] FT8 encoding logic

2020-01-04 Thread Philip Gladstone
Whether PSK reporter gets to see some particular signal depends on the
decoding software. It is easy enough to experiment with various
transmissions and see which get reported. Use different callsigns
(suffixes) so that you can tell which signals get through.

On Sat, Jan 4, 2020 at 10:26 AM Reino Talarmo 
wrote:

> It seems that many, if not all messages, where the call sign is in the
> 'sender' position are reported to pskreporter.info. So 'DE VE3GHM FN25'
> would be fine, if non-standard call sign were supported with a locator. No
> need to use CQ, if broadcasting and not needing a response at that time.
>
> 73, Reino oh3mA
>
>
>
> ___
> 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] FT8 encoding logic

2020-01-04 Thread Reino Talarmo
It seems that many, if not all messages, where the call sign is in the
'sender' position are reported to pskreporter.info. So 'DE VE3GHM FN25'
would be fine, if non-standard call sign were supported with a locator. No
need to use CQ, if broadcasting and not needing a response at that time.

73, Reino oh3mA



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


Re: [wsjt-devel] FT8 encoding logic

2020-01-03 Thread Jim Brown

On 1/3/2020 9:05 AM, Christoph Berg wrote:

Re: Graham c 2020-01-03 


WSPR of course uploads reception reports to wsprnet.org. WSJT-X uploads FT8
reports to pskreporter.info but only for those CQ   messages -
as far as I know something like VE3GHM FN25 (without the CQ) would not get
uploaded by WSJT-X to pskreporter.info.


Calling CQ without listening seems like a no-go to me.


Agreed it's pretty poor practice. I mostly use FT8 on 6M and 160M, and 
often leave the radio on and monitoring while I'm out of the shack. If 
I'm feeding PSKReporter, which I do by default, and ask to display 
anything sent or received by me, I'll see all the stations I've decoded 
of the time period selected, so it's easy to determine band conditions 
and activity.


My shack is in an outbuilding; from the house, I look at PSKReporter 
before heading out the door; if I don't see decodes from the areas I 
want to work, I stay inside. Once in the shack, after monitoring for a 
whike, I'll call CQ several times to see who's hearing me, again 
assessing activity asnd conditions. Mostly though, I monitor and call 
stations I want to work, causing minimum QRM to others.


73, Jim K9YC


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


Re: [wsjt-devel] FT8 encoding logic

2020-01-03 Thread Christoph Berg
Re: Graham c 2020-01-03 

> WSPR of course uploads reception reports to wsprnet.org. WSJT-X uploads FT8
> reports to pskreporter.info but only for those CQ   messages -
> as far as I know something like VE3GHM FN25 (without the CQ) would not get
> uploaded by WSJT-X to pskreporter.info.

Calling CQ without listening seems like a no-go to me.

Christoph DF7CB


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


Re: [wsjt-devel] FT8 encoding logic

2020-01-03 Thread Graham c
Hi Reino,

Belt and suspenders - WSPR is the belt and would be the primary
tracking source providing, location and encoded in the power field altitude
in some transmsissions, and temperature in others; FT8 would be the
suspenders as a secondary mode and just provide a position using a four
character grid square to supplement the WSPR transmissions of provide fills
whenever they may not be any WSPR reports.

The basic premise is the use of crowd sourced reception reports by the
world wide users of FT8 and WSPR.

WSPR of course uploads reception reports to wsprnet.org. WSJT-X uploads FT8
reports to pskreporter.info but only for those CQ   messages -
as far as I know something like VE3GHM FN25 (without the CQ) would not get
uploaded by WSJT-X to pskreporter.info.

these pico balloon tracker are transmitting approximately 5mW at best. At
the moment I have a very simple beacon transmitting FT8 that hops around on
80/40/30 and 20m sending a CQ once a minute on each band at 5mW. The actual
transmit frequency within the FT8 sub band is randomized as well. All based
on an Arduiono UNO and a QRP Labs si5351a synthesizer. That 5mW does
surprisingly well for a pip squeak signal on very busy and active FT8
frequencies.  This will show what other stations have copied my
transmissions over the past 24 hours:

https://pskreporter.info/pskmap.html?preset=ve3ghm=tx=FT8=86400=1=1=1=1=1=1


 Now, if WSJT-X uploaded reception spots for VE3GHM FN25 to pskreporter
then that would also make for a very simple solution.  I think I tried that
but I may try it again just in case it does work.

cheers, Graham ve3gtc

On Fri, Jan 3, 2020 at 8:23 AM Reino Talarmo 
wrote:

> >Since my call is six characters the grid gets truncated hence the reason
> for my journey of discovery down the path of digging into the WSJT-X source
> to understand how the standard message with non-standard call logic works.
>
>
>
> Hi Graham,
>
> You have an interesting Pico Balloon project. May I ask how the FT8 mode
> will should provide a belt and suspenders? I assume that the balloon
> transmitter just broadcasts WSPR and/or FT8 without any reception
> possibility and so nobody should answer to that CQ. If so I think that you
> don’t need a ‘CQ’ in your message at all and could use Free text to
> broadcast VE3GHM FN25 or whatever the locator may be. Even VE3GHM FN25JR
> would just fit in!
>
> 73, Reino oh3mA
> ___
> 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] FT8 encoding logic

2020-01-03 Thread Reino Talarmo
>Since my call is six characters the grid gets truncated hence the reason for 
>my journey of discovery down the path of digging into the WSJT-X source to 
>understand how the standard message with non-standard call logic works.

 

Hi Graham,

You have an interesting Pico Balloon project. May I ask how the FT8 mode will 
should provide a belt and suspenders? I assume that the balloon transmitter 
just broadcasts WSPR and/or FT8 without any reception possibility and so nobody 
should answer to that CQ. If so I think that you don’t need a ‘CQ’ in your 
message at all and could use Free text to broadcast VE3GHM FN25 or whatever the 
locator may be. Even VE3GHM FN25JR would just fit in!

73, Reino oh3mA

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


Re: [wsjt-devel] FT8 encoding logic

2020-01-03 Thread Graham c
I will do some more testing, it could have been that my testing
methodology was flawed. I will play around some more with your example.

yes indeed, it is getting truncated.  The FT8 encoding found in Jason's
NT7S JTEncode Arduino library will encode free text but nothing else. and
since my call is six characters the grid gets truncated hence the reason
for my journey of discovery down the path of digging into the WSJT-X source
to understand how the standard message with non-standard call logic works.

If I had a five character call I could have just stayed blissfully
ignorant,  However, nothing ventured, nothing gained. If nothing else I
have developed a feel for the internal workings of WSJT-X and it's various
modes.

cheers, Graham ve3gtc


On Thu, Jan 2, 2020 at 9:39 PM Pete  wrote:

> Hi Graham,
>
> > I tried long long and uint64_t, and ULL. They all compile but in the
> > end are still only 4 bytes. There are some online posts to the
> > contrary but I couldn't get more than 4 bytes.
>
> I don't have any Arduinos any more but I tested some simple code on a
> Teensy2 which is still a 328 processor and the Arduino IDE.
>
> It prints the sizeof a uint32_t variable as 8. The problem you can run
> into with uint64_t is when you try to print it because the serial class
> only handles 32-bit integers. You have to print the variable in two
> pieces as shown in this simple sketch:
>
> volatile uint64_t testing_i;
> void setup(void)
> {
>Serial.begin(9600);
>while(!Serial);
>delay(1000);
>
>Serial.print("Sizeof uint64_t = ");
>Serial.println(sizeof(testing_i));
>
>testing_i ^= 0x12345678ULL;
>Serial.print((uint32_t)(testing_i >> 32)&0x,HEX);
>Serial.println((uint32_t)testing_i&0x,HEX);
> }
>
> void loop(void)
> {
> }
>
>
> > BUT CQ VE3GHM FN25 gets truncated and drops the 5
>
> That string is 14 characters long, which suggests that it is being
> truncated to 13 characters as if it was free text.
>
> 73 de Pete VE5VA
>
>
> ___
> 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] FT8 encoding logic

2020-01-02 Thread Pete

Hi Graham,

I tried long long and uint64_t, and ULL. They all compile but in the 
end are still only 4 bytes. There are some online posts to the 
contrary but I couldn't get more than 4 bytes.


I don't have any Arduinos any more but I tested some simple code on a 
Teensy2 which is still a 328 processor and the Arduino IDE.


It prints the sizeof a uint32_t variable as 8. The problem you can run 
into with uint64_t is when you try to print it because the serial class 
only handles 32-bit integers. You have to print the variable in two 
pieces as shown in this simple sketch:


volatile uint64_t testing_i;
void setup(void)
{
  Serial.begin(9600);
  while(!Serial);
  delay(1000);

  Serial.print("Sizeof uint64_t = ");
  Serial.println(sizeof(testing_i));

  testing_i ^= 0x12345678ULL;
  Serial.print((uint32_t)(testing_i >> 32)&0x,HEX);
  Serial.println((uint32_t)testing_i&0x,HEX);
}

void loop(void)
{
}



BUT CQ VE3GHM FN25 gets truncated and drops the 5


That string is 14 characters long, which suggests that it is being 
truncated to 13 characters as if it was free text.


73 de Pete VE5VA


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


Re: [wsjt-devel] FT8 encoding logic

2020-01-02 Thread Graham c
Hi Pete,

Short term yes, atmega328 long term doesn't matter so much i.e. samd21,
stm32, teensy or whatever.

The idea is to be able to provide a secondary mode to WSPR for a Pico
Balloon tracker. WSPR works well as primary mode but the desire is to have
a secondary mode as well - kind of a belt and suspenders idea.  The current
tracker hardware is nothing more than a GPS module, atmega328 and si5351a
synthesizer. Very simple and very light weight but the atmega328 is the
limiting factor. I am not even sure I can squeeze everything required for
WSPR and FT8 into the 32k program space plus there is only 2k of ram.

I tried long long and uint64_t, and ULL. They all compile but in the end
are still only 4 bytes. There are some online posts to the contrary but I
couldn't get more than 4 bytes.

I have free text working using the FTEcode arduino library by NT7S and
sending something like CQ VE5VA FN02 does get copied correctly by WSJT-X
and uploaded to pskreporter BUT CQ VE3GHM FN25 gets truncated and drops the
5. So, unless we have access to a call sign with 5 characters we would need
to be able to properly encode a standard message.

This has been an interesting exercise and may in the short term not go
anywhere but at least I will have some background when we decide to move on
with a more capable processor.

cheers, Graham ve3gtc


On Thu, Jan 2, 2020 at 8:21 PM Pete  wrote:

> Graham,
> > The atmega328 is an 8 bit controller and Arduino is limited to 32 bits
> > (i.e. 4 byte) and I have so far been unable to come up with some
> > workaround that lets me do this 64 bit stuff on Arduino
>
> There is a uint64_t (and int64_t) datatype which allows you to work with
> a 64-bit word on the atmega328, even though manipulating them will
> require the compiler to add support routines (e.g. using the ^ operator
> adds about 220 bytes of code). 64-bit constants just require the LL or
> ULL suffix - e.g. 0x12345678ULL. But do you have to use the 328?
>
> I have ported the FT4 encoder to a Teensy4 with free text and telemetry
> messages but I haven't bothered (yet) to add the encoding of callsigns
> and hashes.
>
> 73 de Pete VE5VA
>
>
>
>
>
> ___
> 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] FT8 encoding logic

2020-01-02 Thread Pete

Graham,
The atmega328 is an 8 bit controller and Arduino is limited to 32 bits 
(i.e. 4 byte) and I have so far been unable to come up with some 
workaround that lets me do this 64 bit stuff on Arduino


There is a uint64_t (and int64_t) datatype which allows you to work with 
a 64-bit word on the atmega328, even though manipulating them will 
require the compiler to add support routines (e.g. using the ^ operator 
adds about 220 bytes of code). 64-bit constants just require the LL or 
ULL suffix - e.g. 0x12345678ULL. But do you have to use the 328?


I have ported the FT4 encoder to a Teensy4 with free text and telemetry 
messages but I haven't bothered (yet) to add the encoding of callsigns 
and hashes.


73 de Pete VE5VA





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


Re: [wsjt-devel] FT8 encoding logic

2020-01-02 Thread Bill Somerville

On 02/01/2020 02:15, Graham c wrote:
I have been working through the code that does the encoding of 
standard messages in FT8 with a goal of creating a simplified version 
that can compiled and used on an atmega328 processor (i.e. Arduino).


There is an Arduino library called JTEncode which includes FT8 but 
this only encodes free text messages limited to 13 characters. So, I 
can encode something like CQ N2NCZ FN03  but CQ VE3GHM FN25 get 
truncated to 13 characters and drops the 5 from the grid square.


The problem I am having is not being able to work my way through the 
code but rather the use of 64bit (8 byte) may in the pack28 call sign 
hash routines. The atmega328 is an 8 bit controller and Arduino is 
limited to 32 bits (i.e. 4 byte) and I have so far been unable to come 
up with some workaround that lets me do this 64 bit stuff on Arduino 
without getting very messy and consuming far too much of the very 
limited ram available.


Which brings me to my question - is anyone aware of any code for 
encoding FT8 standard messages that can use 32bit math on something 
like the atmeag328 / Arduino?


cheers, Graham ve3gtc


Hi Graham,

free text messages involve the biggest numbers as they require a 71-bit 
field. The maths required should not be that challenging for an 8-bit 
CPU core like the AVR since the main operations are bitwise or addition, 
addition only requires a basic carry operation to extend the length past 
8-bits.


Although encoding FT8 on a small 8-bit MCU is an interesting academic 
exercise you should keep in mind that FT8 is a QSO mode so any 
implementation that does not include decoding will not be providing 
anything particularly useful. Decoding FT8 to any sort of workable time 
schedule in not possible on a CPU with only a few MHz clock speed. You 
may be thinking of beacon type operations, I would strongly suggest 
looking at WSPR, or perhaps JT9 since both have greatly better 
sensitivity while using less bandwidth.


73
Bill
G4WJS.



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


[wsjt-devel] FT8 encoding logic

2020-01-01 Thread Graham c
I have been working through the code that does the encoding of standard
messages in FT8 with a goal of creating a simplified version that can
compiled and used on an atmega328 processor (i.e. Arduino).

There is an Arduino library called JTEncode which includes FT8 but this
only encodes free text messages limited to 13 characters. So, I can encode
something like CQ N2NCZ FN03  but CQ VE3GHM FN25 get truncated to 13
characters and drops the 5 from the grid square.

The problem I am having is not being able to work my way through the code
but rather the use of 64bit (8 byte) may in the pack28 call sign hash
routines. The atmega328 is an 8 bit controller and Arduino is limited to 32
bits (i.e. 4 byte) and I have so far been unable to come up with some
workaround that lets me do this 64 bit stuff on Arduino without getting
very messy and consuming far too much of the very limited ram available.

Which brings me to my question - is anyone aware of any code for encoding
FT8 standard messages that can use 32bit math on something like the
atmeag328 / Arduino?

cheers, Graham ve3gtc
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-23 Thread Claude Frantz

On 11/23/19 5:21 AM, Jim Brown wrote:

I see FT8 and DXpedition mode to be the greatest thing to happen to the 
little pistol station since I learned CW 60 years ago.


That is exactly my opinion, too.

Claude (DJ0OT)


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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-22 Thread jarmo
Fri, 22 Nov 2019 20:21:47 -0800
Jim Brown  kirjoitti:

> On 11/22/2019 2:33 PM, Grant VK5GR wrote:
> > and FOX mode is playing a big part in the success of that.  
> 
> I see FT8 and DXpedition mode to be the greatest thing to happen to
> the little pistol station since I learned CW 60 years ago.
> 
> 73, Jim K9YC

Well said Jim, agreed 100+

Jarmo


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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-22 Thread Jim Brown

On 11/22/2019 2:33 PM, Grant VK5GR wrote:

and FOX mode is playing a big part in the success of that.


I see FT8 and DXpedition mode to be the greatest thing to happen to the 
little pistol station since I learned CW 60 years ago.


73, Jim K9YC


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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-22 Thread Bill Frantz

On 11/19/19 at 8:01 AM, iztok.s...@telekom.si (Iztok Saje) wrote:


Hi!

On band activity: how about ALL.TXT?

On linux:
tail -f ALL.TXT |grep -v A35JT

would give nice idea what is going on the band segment.
I assume ALL.TXT works in Fox mode, and there are similar 
commands in Windows as well.


Best 73, gd DX
Iztok, S52D


You could probably pipe the output into egrep with some patterns 
that give you just the information you want. For example, just 
the stations calling a fox other than you.


73 Bill AE6JV

-
Bill Frantz| Re: Hardware Management Modes: | Periwinkle
(408)356-8506  | If there's a mode, there's a   | 16345 
Englewood Ave
www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos, 
CA 95032




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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-22 Thread Grant VK5GR
Joe,

Sorry, the on list response was in responses to Steve's question which was made 
on this forum.

Other questions I have replied to you directly. However one I will reply to 
here. A35JT's peak QSO rate was 340/hr to Japan on 12m from memory. We 
regularly ran at 150-200+ an hour for expected periods with 230 being a fairly 
common average in good propagation. We usually ran about 3-4 slots. We were 
balancing slot count against throughput and would manipulate the slot count to 
maximise QSO completion rates. As the EU path in particular (one of our key 
targets) is a difficult one from A3 and signals were not strong, at times we 
dropped to one slot just to ensure QSO completion. This was all based on a 500W 
station with beams or phased arrays on the low bands.

In comparison our CW operation also ran at around 150-200/hr and voice was 
between 100-140 peaking at 240/hr when conditions were really good and we had 
enough callers. In that sense, we were justified in running FOXHOUND mode. 
Anytime we could get over 50 QSOs an hour or tried the main channels and caused 
congestion with more than 5-6 callers chasing us we would move to FOX mode. 
Often it only took 4-5 minutes on the main channel for the congestion to start, 
which prompted us to announce using freetext a switch to FOX mode and the 
frequency we were going to QSY to on the band. 

Is fox mode being over used? In point of fact I don’t think so. You almost 
never see home stations running it. Only portable operations to top 120DXCCs 
typically go to the effort. What is noticeable however is the number of 
expeditions, big and small in terms of operator count, around in general at the 
moment. It is a smorgasboard for DX Chasers and FOX mode is playing a big part 
in the success of that. I don’t see it needs to be curtailed, but if it can be 
improved to manage channel contention a little better then thats a good thing.

Regards,
Grant

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Saturday, 23 November 2019 1:40 AM
To: WSJT software development
Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

Grant --

You asked me to take our exchanges off-list, but then you seem to have 
reverted to the list.  So for the record, I'll respond here.

As I explained to you off-list, the ALL.TXT file in WSJT-X 2.1.0 
provides the information you asked for, in real time.

Perhaps we can furnish this information in a way you would find more 
convenient, in some future release.  We have not heard from other Fox 
operators that this should be a high priority.

Yes, especially with heavy Rx traffic and a slow computer, times listed 
for late decodes are sometimes incorrectly listed in ALL.TXT with the 
timestamp of the next T/R sequence.

We consider ALL.TXT to be an undocumented feature.  It's there mainly 
for diagnostic purposes, and (as they say) "its contents may change 
without notice."

I have not paid close attention to the extent of Fox-and-Hound usage in 
recent months, but my general impression is that it may be somewhat 
over-used.  What were the peak and average hourly QSO rates at A35JT ? 
How many Tx slots did you generally use?  Did you consider using FT4 
rather than FT8 with NSlots > 1 ?

-- 73, Joe, K1JT

On 11/21/2019 9:17 PM, Grant Willis wrote:
> Steve,
> 
> Sorry that is my mistake. It was an incorrect memory based on when I was 
> reviewing the ALL.TXT file trying to find broken log records when we got 
> home after A35JT. (I had discovered that ALL.TXT didnt store the TX 
> strings from the FOX transmissions - instead it only stored one string 
> and  not the contents of the up to 5 FOX TX channels). I incorrectly 
> turned my conclusion of 5 weeks ago that ALL.TXT was incomplete when it 
> came to tracing broken log entries into the incorrect memory/assumption 
> that ALL.TXT didnt have the fox band activity data in it at all.
> 
> My apologies for making an invalid later assumption that ALL.TXT didnt 
> have FOX channel traffic at all. Goes to show one should never assume 
> anything as it makes one look like an ASS - sorry about that. An 
> unnecessary distraction to the real debate about band activity 
> visualisation in FOX mode.
> 
> So to clarify - ALL.TXT does appear to log the FOX Channel receive 
> activity and running a tail job in a separate window would provide band 
> activity monitoring needed to detect channel collisions.
> 
> The debate however then becomes is that something that the majority of 
> FOX operators would know how to do? My suggestion is that it isn't. 
> Finding a better solution to warning FOX operators that there are people 
> on their channel calling other expeditions is still very important in my 
> mind. Taking rows from the Band activity where the FOX station callsign 
> is not even present and putting them into the RX activity window would

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-22 Thread Joe Taylor

Grant --

You asked me to take our exchanges off-list, but then you seem to have 
reverted to the list.  So for the record, I'll respond here.


As I explained to you off-list, the ALL.TXT file in WSJT-X 2.1.0 
provides the information you asked for, in real time.


Perhaps we can furnish this information in a way you would find more 
convenient, in some future release.  We have not heard from other Fox 
operators that this should be a high priority.


Yes, especially with heavy Rx traffic and a slow computer, times listed 
for late decodes are sometimes incorrectly listed in ALL.TXT with the 
timestamp of the next T/R sequence.


We consider ALL.TXT to be an undocumented feature.  It's there mainly 
for diagnostic purposes, and (as they say) "its contents may change 
without notice."


I have not paid close attention to the extent of Fox-and-Hound usage in 
recent months, but my general impression is that it may be somewhat 
over-used.  What were the peak and average hourly QSO rates at A35JT ? 
How many Tx slots did you generally use?  Did you consider using FT4 
rather than FT8 with NSlots > 1 ?


-- 73, Joe, K1JT

On 11/21/2019 9:17 PM, Grant Willis wrote:

Steve,

Sorry that is my mistake. It was an incorrect memory based on when I was 
reviewing the ALL.TXT file trying to find broken log records when we got 
home after A35JT. (I had discovered that ALL.TXT didnt store the TX 
strings from the FOX transmissions - instead it only stored one string 
and  not the contents of the up to 5 FOX TX channels). I incorrectly 
turned my conclusion of 5 weeks ago that ALL.TXT was incomplete when it 
came to tracing broken log entries into the incorrect memory/assumption 
that ALL.TXT didnt have the fox band activity data in it at all.


My apologies for making an invalid later assumption that ALL.TXT didnt 
have FOX channel traffic at all. Goes to show one should never assume 
anything as it makes one look like an ASS - sorry about that. An 
unnecessary distraction to the real debate about band activity 
visualisation in FOX mode.


So to clarify - ALL.TXT does appear to log the FOX Channel receive 
activity and running a tail job in a separate window would provide band 
activity monitoring needed to detect channel collisions.


The debate however then becomes is that something that the majority of 
FOX operators would know how to do? My suggestion is that it isn't. 
Finding a better solution to warning FOX operators that there are people 
on their channel calling other expeditions is still very important in my 
mind. Taking rows from the Band activity where the FOX station callsign 
is not even present and putting them into the RX activity window would 
be a good start to enabling a channel self monitoring function inside 
the software IMHO.


As an aside - looking back at ALL.TXT - it does raise a point. The 
contents of the TX channels that are sent over the air in FOX mode are 
not being recorded in ALL.TXT currently. Is that by design or is that a BUG?


In fact it is very strange that RX records are still being written when 
I an transmitting in the next cycle. I enclose a sample of my ALL.TXT 
file here. It might reveal more of whats going on? I can send the whole 
file along with the FOXQSO.TXT file if it would help try to get a handle 
on whats actually going on with ALL.TXT?


190929_003930    14.067 Rx FT8     -2  0.0 1895 A35JT VK5BC PF95
190929_003930    14.067 Tx FT8      0  0.0  538 VK3BDX A35JT RR73
  <-- I answered more than VK3BDX in this over
190929_003930    14.067 Rx FT8     -2  0.4 2112 A35JT 6K5YIA PM45
<--  am still receiving even though my TX is up for the next over?

190929_003930    14.067 Rx FT8     11 -0.0 2294 A35JT XE1TD DL80
190929_003930    14.067 Rx FT8      9  0.0 2460 A35JT VE7SV CN99
190929_003930    14.067 Rx FT8    -14  0.0 2972 A35JT N5WXY R-09
190929_003930    14.067 Rx FT8      3  0.0 3071 A35JT JH0INP PM96
190929_003930    14.067 Rx FT8    -14  0.2 1037 A35JT VK3GWS QF22
190929_003930    14.067 Rx FT8     -8  0.1 1088 A35JT JG3KLF PM74
190929_003930    14.067 Rx FT8    -19  0.0 1544 A35JT N2AJ FN30
190929_003945    14.067 Rx FT8     -4  0.0 1019 A35JT K9NU EN55
190929_003945    14.067 Rx FT8     -9  0.1 1088 A35JT JG3KLF PM74
190929_003945    14.067 Rx FT8     -4  0.1 1274 A35JT W7DN CN85
190929_003945    14.067 Rx FT8    -10  0.4 1337 A35JT KI5BLU CN87
190929_003945    14.067 Rx FT8      5  0.1 1388 A35JT VE3VEE EN94
190929_003945    14.067 Rx FT8     -4  0.2 1495 A35JT PP2FRS GH63
190929_003945    14.067 Rx FT8     -7 -0.2 1599 A35JT K5GS DM42
190929_003945    14.067 Rx FT8      1  0.0 1689 A35JT JR1JYR PM95
190929_004000    14.067 Tx FT8      0  0.0  538 VK3BDX A35JT RR73 <-- 
same string grabbed again by the SW but I answered others
190929_004000    14.067 Rx FT8     -2  0.0 1821 A35JT KQ5M DM65   <--- 
still receiving things after I started TX

190929_004000    14.067 Rx FT8     -6 -0.0 1895 A35JT VK5BC PF95
190929_004000    14.067 Rx FT8   

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-22 Thread Reino Talarmo
Hi Grant,

I assume that the timestamps in the ALL.TXT are taken from the slot time 
counter at the moment, when software has performed its reception decoding. If 
the decoding happens to take place after the start of the next transmission, 
then the time indicated is wrong. That may or may not been fixed in the next 
release.

73, Reino oh3mA

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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-21 Thread Grant Willis
Steve,

Sorry that is my mistake. It was an incorrect memory based on when I was
reviewing the ALL.TXT file trying to find broken log records when we got
home after A35JT. (I had discovered that ALL.TXT didnt store the TX strings
from the FOX transmissions - instead it only stored one string and  not the
contents of the up to 5 FOX TX channels). I incorrectly turned my
conclusion of 5 weeks ago that ALL.TXT was incomplete when it came to
tracing broken log entries into the incorrect memory/assumption that
ALL.TXT didnt have the fox band activity data in it at all.

My apologies for making an invalid later assumption that ALL.TXT didnt have
FOX channel traffic at all. Goes to show one should never assume anything
as it makes one look like an ASS - sorry about that. An unnecessary
distraction to the real debate about band activity visualisation in FOX
mode.

So to clarify - ALL.TXT does appear to log the FOX Channel receive activity
and running a tail job in a separate window would provide band activity
monitoring needed to detect channel collisions.

The debate however then becomes is that something that the majority of FOX
operators would know how to do? My suggestion is that it isn't. Finding a
better solution to warning FOX operators that there are people on their
channel calling other expeditions is still very important in my mind.
Taking rows from the Band activity where the FOX station callsign is not
even present and putting them into the RX activity window would be a good
start to enabling a channel self monitoring function inside the software
IMHO.

As an aside - looking back at ALL.TXT - it does raise a point. The contents
of the TX channels that are sent over the air in FOX mode are not being
recorded in ALL.TXT currently. Is that by design or is that a BUG?

In fact it is very strange that RX records are still being written when I
an transmitting in the next cycle. I enclose a sample of my ALL.TXT file
here. It might reveal more of whats going on? I can send the whole file
along with the FOXQSO.TXT file if it would help try to get a handle on
whats actually going on with ALL.TXT?

190929_00393014.067 Rx FT8 -2  0.0 1895 A35JT VK5BC PF95
190929_00393014.067 Tx FT8  0  0.0  538 VK3BDX A35JT RR73
 <-- I answered more than VK3BDX in this over
190929_00393014.067 Rx FT8 -2  0.4 2112 A35JT 6K5YIA PM45
<--  am still receiving even though my TX is up for the next over?
190929_00393014.067 Rx FT8 11 -0.0 2294 A35JT XE1TD DL80
190929_00393014.067 Rx FT8  9  0.0 2460 A35JT VE7SV CN99
190929_00393014.067 Rx FT8-14  0.0 2972 A35JT N5WXY R-09
190929_00393014.067 Rx FT8  3  0.0 3071 A35JT JH0INP PM96
190929_00393014.067 Rx FT8-14  0.2 1037 A35JT VK3GWS QF22
190929_00393014.067 Rx FT8 -8  0.1 1088 A35JT JG3KLF PM74
190929_00393014.067 Rx FT8-19  0.0 1544 A35JT N2AJ FN30
190929_00394514.067 Rx FT8 -4  0.0 1019 A35JT K9NU EN55
190929_00394514.067 Rx FT8 -9  0.1 1088 A35JT JG3KLF PM74
190929_00394514.067 Rx FT8 -4  0.1 1274 A35JT W7DN CN85
190929_00394514.067 Rx FT8-10  0.4 1337 A35JT KI5BLU CN87
190929_00394514.067 Rx FT8  5  0.1 1388 A35JT VE3VEE EN94
190929_00394514.067 Rx FT8 -4  0.2 1495 A35JT PP2FRS GH63
190929_00394514.067 Rx FT8 -7 -0.2 1599 A35JT K5GS DM42
190929_00394514.067 Rx FT8  1  0.0 1689 A35JT JR1JYR PM95
190929_00400014.067 Tx FT8  0  0.0  538 VK3BDX A35JT RR73  <-- same
string grabbed again by the SW but I answered others
190929_00400014.067 Rx FT8 -2  0.0 1821 A35JT KQ5M DM65   <---
still receiving things after I started TX
190929_00400014.067 Rx FT8 -6 -0.0 1895 A35JT VK5BC PF95
190929_00400014.067 Rx FT8  3  0.0 2057 VK6MIT AA4M DM42
190929_00400014.067 Rx FT8 -8  0.4 2112 A35JT 6K5YIA PM45
190929_00400014.067 Rx FT8  6  0.0 2295 A35JT XE1TD DL80
190929_00400014.067 Rx FT8  1  0.0 2459 A35JT VE7SV CN99
190929_00400014.067 Rx FT8-13  0.0 2510 A35JT N5WXY R-13
190929_00400014.067 Rx FT8-15  0.2 2993 A35JT JA6KLP PM53
190929_00400014.067 Rx FT8  4  0.0 3072 A35JT JH0INP PM96
190929_00400014.067 Rx FT8-11  0.3 1036 A35JT VK3GWS QF22
190929_00401514.067 Rx FT8  4  0.0  596 A35JT NU1O R-15
190929_00401514.067 Rx FT8  2  0.0 1018 A35JT K9NU EN55
190929_00401514.067 Rx FT8-11  0.3 1337 A35JT KI5BLU CN87
190929_00401514.067 Rx FT8-12  0.2 1358 A35JT YV5AJ FK60
190929_00401514.067 Rx FT8  2  0.7 1514 A35JT VK3OD QF22
190929_00401514.067 Rx FT8 -3  0.1 1598 A35JT K5GS DM42
190929_00401514.067 Rx FT8-15  0.4 1684 A35JT W9ZCL EN62
190929_00401514.067 Rx FT8  3  0.0 1774 A35JT W5XU EM40
190929_00401514.067 Rx FT8  1  0.0 1821 A35JT KQ5M DM65
190929_00403014.067 Tx FT8  0  0.0  538 VK3BDX A35JT RR73

190929_00403014.067 Rx FT8 -4 -0.0 1895 A35JT VK5BC PF95
190929_00403014.067 Rx FT8  

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-21 Thread Gary McDuffie



> On Nov 21, 2019, at 16:55, Carl Buehler  wrote:
> 
> How long does it take, after making the request, to be taken off this list?
> K9ZA

Should be immediate right after you REMOVE YOURSELF.

Gary


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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-21 Thread Carl Buehler
How long does it take, after making the request, to be taken off this list?
K9ZA

On Tue, Nov 19, 2019, 07:22 Iztok Saje  wrote:

> Hi!
>
> On band activity: how about ALL.TXT?
>
> On linux:
> tail -f ALL.TXT |grep -v A35JT
>
> would give nice idea what is going on the band segment.
> I assume ALL.TXT works in Fox mode, and there are similar commands in
> Windows as well.
>
> Best 73, gd DX
> Iztok, S52D
>
>
>
> >
> >> 18. nov. 2019 kl. 19:18 skrev Joe Taylor :
> >>
> >> Hi Grant and all,
> >>
> >> Thanks for reporting the bug in WSJT-X v2.1.0 that causes *Tx Enable*
> to be turned off when Fox sends RR73.  We knew about this issue and
> corrected it several months ago, back in August, but -- having received no
> complaints from users -- we have been waiting to issue a bug-fix release
> until several other issues are resolved.
> >>
> >> We will schedule a release of WSJT-X v2.1.1 soon.
> >>
> >> Your other request, to have standard "Band Activity" displayed when in
> Fox mode, will not be addressed in v2.1.1.  Code for Fox mode is based on
> an understanding that you (the Fox) will have a well-advertised band
> segment to yourself.
> >>
> >> Have you tried simply running a second instance of WSJT-X, in normal
> mode, so that you can monitor what's going on in a difficult situation?
> >>
> >> -- 73, Joe, K1JT
> >>
> >>
> >> ___
> >> wsjt-devel mailing list
> >> wsjt-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
>
> [http://psn.sdn.si/ts/TS_Banner_NEO_oktober_2019_250x170.jpg]
> <
> https://neo.io/info?utm_source=mail_podpis_medium=mail_podpis_campaign=mail_podpis
> >
> Pravni pogoji / Legal disclaimer
> Telekom Slovenije, d.d., Ljubljana 
>
>
> ___
> 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] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-21 Thread Steven Franke via wsjt-devel
Grant,

> On Nov 21, 2019, at 2:31 PM, Grant VK5GR  wrote:
> 
> Folks,
> 
> ALL.TXT is not populated when in FOX mode in 2.1.0 - I checked the logs from
> A35JT. Only when we were in standard mode was it being updated.

I am not able to reproduce this.

I have just tested v2.1.0 here on Linux and separately on MacOS. In both cases 
I find that all decodes are written to ALL.TXT while running in Fox mode. I 
tested this in two ways: (i) running as Fox in monitor mode while tuned to 
14.074 MHz and (ii) using two instances of WSJT-X, one Fox and one Hound, and 
connecting the two instances using a loopback connection. This second loopback 
setup was used so that I could run as Fox while transmitting CQs every other 
sequence. In both cases, all of the Fox’s decodes were written to ALL.TXT, 
whether the decode was addressed to Fox or not.

73
Steve, k9an

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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-21 Thread Grant VK5GR
Folks,

ALL.TXT is not populated when in FOX mode in 2.1.0 - I checked the logs from
A35JT. Only when we were in standard mode was it being updated.

The fix needs to be more elegant.

Grant VK5GR

-Original Message-
From: Iztok Saje [mailto:iztok.s...@telekom.si] 
Sent: Friday, 22 November 2019 3:55 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

Hi!

Let wsjtx dev team focus on hard stuff, and use support programs
for the rest.

While proposed tail -f can do the job,
I think it is relatively easy to hack small program that reads last lines in
ALL.TXT every 15 seconds
and make small screen supporting Fox operation.

Is frequency clean? (how many frames are NOT for me?)
Are there LIDs calling on uplink frequency? I guess moving up 120 Hz is good
anti-measure.
Is there another Fox? (Sveral callers, R-SNR frames below 1000 kHz) here or
+/1 1/2 kHz?

Analyzing RX reports: can we afford additional stream?
QSO rate, repetition rate.

Based on UL sqares: how callers are spread in directon? Is it time to turn
antenna?

Now... It is highly unlikely I will operate Fox soon, but those planning so
might consider it.

Best 73, GL
Iztok, S52D






On 11/19/2019 02:01 PM, Iztok Saje wrote:
> Hi!
>
> On band activity: how about ALL.TXT?
>
> On linux:
> tail -f ALL.TXT |grep -v A35JT
>
> would give nice idea what is going on the band segment.
> I assume ALL.TXT works in Fox mode, and there are similar commands in
Windows as well.
>
> Best 73, gd DX
> Iztok, S52D
>
>
>
>>

[http://psn.sdn.si/ts/TS_Banner_NEO_oktober_2019_250x170.jpg]
<https://neo.io/info?utm_source=mail_podpis_medium=mail_podpis_campa
ign=mail_podpis>
Pravni pogoji / Legal disclaimer
Telekom Slovenije, d.d., Ljubljana <http://www.telekom.si/disclaimer>


___
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] FT8 Fox and Hound Mode - FOX Mode Operator

2019-11-21 Thread Iztok Saje

Hi!

Let wsjtx dev team focus on hard stuff, and use support programs
for the rest.

While proposed tail -f can do the job,
I think it is relatively easy to hack small program that reads last lines in 
ALL.TXT every 15 seconds
and make small screen supporting Fox operation.

Is frequency clean? (how many frames are NOT for me?)
Are there LIDs calling on uplink frequency? I guess moving up 120 Hz is good 
anti-measure.
Is there another Fox? (Sveral callers, R-SNR frames below 1000 kHz) here or +/1 
1/2 kHz?

Analyzing RX reports: can we afford additional stream?
QSO rate, repetition rate.

Based on UL sqares: how callers are spread in directon? Is it time to turn 
antenna?

Now... It is highly unlikely I will operate Fox soon, but those planning so 
might consider it.

Best 73, GL
Iztok, S52D






On 11/19/2019 02:01 PM, Iztok Saje wrote:

Hi!

On band activity: how about ALL.TXT?

On linux:
tail -f ALL.TXT |grep -v A35JT

would give nice idea what is going on the band segment.
I assume ALL.TXT works in Fox mode, and there are similar commands in Windows 
as well.

Best 73, gd DX
Iztok, S52D







[http://psn.sdn.si/ts/TS_Banner_NEO_oktober_2019_250x170.jpg]

Pravni pogoji / Legal disclaimer
Telekom Slovenije, d.d., Ljubljana 


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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

2019-11-20 Thread Grant VK5GR
George,

 

Allow me to answer your questions in line:

 

| Aren’t major efforts (those we expect to use F/H) frequencies pre-coordinated 
and published in advance of the trip? 

 

You would like to think so. In practice despite trying to do just that the 
larger expeditions just took the information I tried sending about 

A35JT and filed it into the circular filing cabinet – then published my 
proposed A35JT frequencies as their own despite being told we 

were going out there months before they published theirs. So you cannot rely on 
pre-coordination.

 

| Do holiday-style trips really need F/H?

 

Depends on where they go now doesn’t it? If it was a one man holiday trip to a 
top 40-50 most wanted destination (or even a top 100 it seems) 

you can very quickly overwhelm and destroy the main standard FT8 channels. 
Whether it is one person or 30 at the DXpedition site doesn’t matter. 

If the location they are operating from is rarely activated and they have more 
than 5-6 callers at a time trying to work them, then there is a case 

to move to Fox/Hound mode, one – to speed up your QSO rate and two – to prevent 
overwhelming the main channels.

 

| Major dxpeditions should never operate in the standard watering holes, right? 
Isn’t there advice about this in the manual?

 

The software in fact means that you cant activate FOX mode on one of the 
primary frequencies. We are not talking about running FOX mode on the 

Existing standard mode frequencies anyway.

 

| So, why would operators looking to maximize QSO count need additional band 
monitoring displays? Shouldn’t they 
| concentrate on answering the calls headed their way? Clearing contacts would 
seem to be the goal, not searching a 
| pileup for a multiplier or rare one, right?

 

Sorry but this looks like a question from someone who has never been on the 
receiving end of an expedition FOX operation.

 

a.   We are trying to maximise QSO count

b.  There is no band activity display currently – so if another FOX 
operation starts up on top of you, you really don’t know about it initially – 
only secondary indications start to give you a hint that there is a problem.

c.   The multiplier comment is also irrelevant because in FOX mode I can do 
that today with the controls I have for stations calling me 
anyway – if I want to preference someone I can without the band activity window

 

| I grant you, DQRM or operator error can wreak havoc. Wouldn’t this show up in 
the fox’s completion rate and thus 
| raise suspicion by an experienced operator?

 

And it does – but it takes time and an experienced operator to see their 
completion rate fall. Unfortunately there are multiple reasons the

completion rate can fall – often caused by people using standard mode to call a 
FOX station repeatedly on the FOX uplink sub-channel. Direct
evidence on screen that there are callers for another FOX on the same frequency 
as yourself would allow you to more quickly take evasive 
action – or better still give you pause and not start up your FOX CQ on top of 
someone else in the first place. 

 

| For hounds not willing to set up a profile, why? It is extremely easy and 
affords you the ability to enter the Dxpeditions 
| published frequencies, switch between them nearly instantly, and keep some 
semblance of order by not editing your normal 
| frequency list. Is there an advantage I am missing?

 

Couldn’t agree more – do it all the time – but this is not at issue here

 

Your other questions I will leave others to reply to as they are not about FOX 
mode operation from the FOX operator position.

 

Regards,

Grant VK5GR – Dxpedition Leader for A35JT Tonga

 

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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

2019-11-20 Thread George J Molnar
A couple recent comments on Fox/Hound mode have me perplexed. 

Aren’t major efforts (those we expect to use F/H) frequencies pre-coordinated 
and published in advance of the trip? 

Do holiday-style trips really need F/H?

Major dxpeditions should never operate in the standard watering holes, right? 
Isn’t there advice about this in the manual?

So, why would operators looking to maximize QSO count need additional band 
monitoring displays? Shouldn’t they concentrate on answering the calls headed 
their way? Clearing contacts would seem to be the goal, not searching a pileup 
for a multiplier or rare one, right?

I grant you, DQRM or operator error can wreak havoc. Wouldn’t this show up in 
the fox’s completion rate and thus raise suspicion by an experienced operator?

For hounds not willing to set up a profile, why? It is extremely easy and 
affords you the ability to enter the Dxpeditions published frequencies, switch 
between them nearly instantly, and keep some semblance of order by not editing 
your normal frequency list. Is there an advantage I am missing?

Hound mode allows full passband monitoring capability, check-box on the main 
screen. Is this insufficient to check band activity before jumping in? I 
thought the receive side of hound mode looks and acts like “normal” FT8. 

In the event of multi-signal operation from non-WSJT-x operations (perhaps in 
the watering holes), why would there be interest in switching to hound mode? 
Standard FT8 works perfectly in this situation. Identifying the mode of 
operation takes little time - if you see someone above 1000 Hz complete a 
contact, it’s not F/H. Or am I confused?

I appreciate the group’s indulgence and patience.

George J Molnar, KF2T 
Arlington, Virginia, USA___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

2019-11-20 Thread George J Molnar
Please forgive what may be ridiculous questions. Some are for foxes, others 
for hounds.

Fox/Hound operation should only be carried out away from the main “watering 
holes,” right? For expeditions, isn’t it standard practice to coordinate with 
other expeditions before leaving home to ensure efficient spectrum use?

Why is looking for another station on the same DF and cycle helpful? Wouldn’t 
the sudden influx of calls for someone-not-you be a tipoff?

Is building a configuration for F/H so onerous, since it could even include the 
announced DXpedition frequencies in the drop down without messing with 
day-to-day use?

Isn’t there a “receive all frequencies” checkbox on the main screen during F/H 
operation? Is this not sufficient to monitor the pileup before jumping in?

Is there value to monitoring another frequency while operating F/H that can’t 
best be solved with a second instance?





George J Molnar, KF2T 
Arlington, Virginia, USA
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

2019-11-20 Thread David Gilbert


I don't use Fox/Hound, of course, but it seems to me that VK5GR's 
request when using it is legitimate.  I wouldn't have said anything at 
all if it weren't for the dev reply that cited a lack of screen real 
estate as the reason for not addressing it.


It's not bitching to point out the obvious.

Dave   AB7E


On 11/20/2019 4:29 AM, Fred Price wrote:
Ya know if you so much want this why not open your computer and 
reprogram the interface yourself?
What's it take 30 seconds to open settings or change a config? Is the 
DX going to disappear in that time?
I guess everyone forgot about when the NA contest mode had a check box 
on the GUI. So many wondered why they were in contest mode because 
they mistakingly checked the box.
Most like the dev group has a lot more to do then move a check box. 
I'd bet they have life's outside of ham radio as well. I think the dev 
group does a helluva job. Just one last thing, how can anybody bitch 
about free software


On Nov 19, 2019 7:25 PM, David Gilbert  wrote:


If anyone was seriously concerned about real estate usage in the
WSJT-X
user window there wouldn't be all that wasted space in the lower left
corner for any of the modes.  The Frequency display doesn't need
to be
anywhere near that large, DX Call and DX Grid is mostly
superfluous, the
size of the Date/Time box is ridiculous ...   and all of that
could be
resized and repositioned under the Auto Seq and Call 1st buttons.

All of which has been brought up before.

Dave   AB7E

On 11/19/2019 2:36 PM, Grant VK5GR wrote:
> Joe,
>
> As for the band activity window - yes screen realestate is
cluttered as it
> stands - but not being able to see the band activity is an
extremely serious
> problem on the air. The "workarounds" proposed are just that -
workarounds.
> Not all Fox operators will be that savvy (although I wish I had
thought of
> the tail ALL.TXT idea out on the island).
>
> Regards,
> Grant
>



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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

2019-11-20 Thread Joe Taylor

Grant --

On 11/19/2019 4:36 PM, Grant VK5GR wrote:


We tested a lot of the station before we left - as much functionality and
hardware as we could in fact. However in the case of FOX mode, that is
something that is extremely difficult to test ... 


Actually, the disabling of *Tx Enable* after Fox sends RR73 in WSJT-X 
2.1.0 is very easy to confirm.  Fox needs only make a single QSO with 
someone acting as Hound.  Do it over the air, if you wish, but it's 
trivial to simulate by using two instances of WSJT-X running on a single 
computer, with loop-back audio.



... until you arrive somewhere
where people will a) accept you should be running FOX mode and b) are able
to attract enough callers to even conduct the test. I'm afraid your
suggestion of "test before you leave" in this case perhaps isn't a practical
one :) 


Quite the contrary.


Most expeditions running FOX mode these days start with small 2-3 man
shows which head out to exotic places that justify FOX mode. Things like the
RR73 problem only really become apparent after perhaps 15-30 minutes of use
when it dawns on you what is going on too. In reality most FOX stations
don't have the resources to try a full FOX mode QSO test as you suggested
prior to leaving.


Again, this makes no sense.


As for the band activity window - yes screen realestate is cluttered as it
stands - but not being able to see the band activity is an extremely serious
problem on the air. The "workarounds" proposed are just that - workarounds.
Not all Fox operators will be that savvy (although I wish I had thought of
the tail ALL.TXT idea out on the island).


Managing a pileup, perhaps in the presence of unrelated QRM, is surely 
the responsibility of the operator of a much desired DX station. 
Yesterday I described two different ways to keep track of such 
"unrelated QRM".


-- Joe, K1JT


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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

2019-11-20 Thread Tom Ramberg via wsjt-devel
Fred, I see no bitching here, just friendy questions and mostly very polite 
answers.

73 de Tom OH6VDA (occasionally semi-rare JW6VDA)

Sendt fra min iPad Air 2

> 20. nov. 2019 kl. 13:34 skrev Fred Price :
> 
> 
> Ya know if you so much want this why not open your computer and reprogram the 
> interface yourself?
> What's it take 30 seconds to open settings or change a config? Is the DX 
> going to disappear in that time?
> I guess everyone forgot about when the NA contest mode had a check box on the 
> GUI. So many wondered why they were in contest mode because they mistakingly 
> checked the box.
> Most like the dev group has a lot more to do then move a check box. I'd bet 
> they have life's outside of ham radio as well. I think the dev group does a 
> helluva job. Just one last thing, how can anybody bitch about free software
> 
> On Nov 19, 2019 7:25 PM, David Gilbert  wrote:
> 
> If anyone was seriously concerned about real estate usage in the WSJT-X 
> user window there wouldn't be all that wasted space in the lower left 
> corner for any of the modes.  The Frequency display doesn't need to be 
> anywhere near that large, DX Call and DX Grid is mostly superfluous, the 
> size of the Date/Time box is ridiculous ...   and all of that could be 
> resized and repositioned under the Auto Seq and Call 1st buttons.
> 
> All of which has been brought up before.
> 
> Dave   AB7E
> 
> On 11/19/2019 2:36 PM, Grant VK5GR wrote:
> > Joe,
> >
> > As for the band activity window - yes screen realestate is cluttered as it
> > stands - but not being able to see the band activity is an extremely serious
> > problem on the air. The "workarounds" proposed are just that - workarounds.
> > Not all Fox operators will be that savvy (although I wish I had thought of
> > the tail ALL.TXT idea out on the island).
> >
> > Regards,
> > Grant
> >
> 
> 
> ___
> 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


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

2019-11-20 Thread Fred Price
Ya know if you so much want this why not open your computer and reprogram the 
interface yourself?
What's it take 30 seconds to open settings or change a config? Is the DX going 
to disappear in that time?
I guess everyone forgot about when the NA contest mode had a check box on the 
GUI. So many wondered why they were in contest mode because they mistakingly 
checked the box.
Most like the dev group has a lot more to do then move a check box. I'd bet 
they have life's outside of ham radio as well. I think the dev group does a 
helluva job. Just one last thing, how can anybody bitch about free software

On Nov 19, 2019 7:25 PM, David Gilbert  wrote:

If anyone was seriously concerned about real estate usage in the WSJT-X
user window there wouldn't be all that wasted space in the lower left
corner for any of the modes.  The Frequency display doesn't need to be
anywhere near that large, DX Call and DX Grid is mostly superfluous, the
size of the Date/Time box is ridiculous ...   and all of that could be
resized and repositioned under the Auto Seq and Call 1st buttons.

All of which has been brought up before.

Dave   AB7E

On 11/19/2019 2:36 PM, Grant VK5GR wrote:
> Joe,
>
> As for the band activity window - yes screen realestate is cluttered as it
> stands - but not being able to see the band activity is an extremely serious
> problem on the air. The "workarounds" proposed are just that - workarounds.
> Not all Fox operators will be that savvy (although I wish I had thought of
> the tail ALL.TXT idea out on the island).
>
> Regards,
> Grant
>


___
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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

2019-11-19 Thread Tom Melvin
Dave

There is not a lot of space under the 'Auto Seq' box - I will agree date and 
time could be smaller - but disagree as to the DX Call/Grid  - they need to be 
easily seen/entered for distance/Bearing - my eyes are not quite what the were 
a few years back and with all the different frequencies in use I really do need 
to see that easily at a glance.

See attached if it made it through



--
73’s

Tom
GM8MJV (IO85)





On 20 Nov 2019, at 00:25, David Gilbert  wrote:

> 
> If anyone was seriously concerned about real estate usage in the WSJT-X user 
> window there wouldn't be all that wasted space in the lower left corner for 
> any of the modes.  The Frequency display doesn't need to be anywhere near 
> that large, DX Call and DX Grid is mostly superfluous, the size of the 
> Date/Time box is ridiculous ...   and all of that could be resized and 
> repositioned under the Auto Seq and Call 1st buttons.
> 
> All of which has been brought up before.
> 
> Dave   AB7E
> 
> 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

2019-11-19 Thread David Gilbert


If anyone was seriously concerned about real estate usage in the WSJT-X 
user window there wouldn't be all that wasted space in the lower left 
corner for any of the modes.  The Frequency display doesn't need to be 
anywhere near that large, DX Call and DX Grid is mostly superfluous, the 
size of the Date/Time box is ridiculous ...   and all of that could be 
resized and repositioned under the Auto Seq and Call 1st buttons.


All of which has been brought up before.

Dave   AB7E


On 11/19/2019 2:36 PM, Grant VK5GR wrote:

Joe,

As for the band activity window - yes screen realestate is cluttered as it
stands - but not being able to see the band activity is an extremely serious
problem on the air. The "workarounds" proposed are just that - workarounds.
Not all Fox operators will be that savvy (although I wish I had thought of
the tail ALL.TXT idea out on the island).

Regards,
Grant





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


  1   2   3   4   5   6   7   >