Re: [wsjt-devel] EmulateTransceiver bug

[Black Michael via wsjt-devel]

I don't see anything in there about serialization...but here's a thread which 
shows some examples and says "don't do it" referring to pass by reference.
https://stackoverflow.com/questions/8455887/stack-object-qt-signal-and-parameter-as-reference

Mike 

On Thursday, January 24, 2019, 5:22:36 PM CST, Bill Somerville 
 wrote:  
 
 On 24/01/2019 23:07, Black Michael via wsjt-devel wrote:
> And where does this serialization take place?  Are you saying it's a 
> default condition of Qt to serialize across event boundaries?
>
> de Mike W9MDB
>
Mike,

you need to read up on the Qt signal/slot mechanism and how queued 
signals are processed:

http://doc.qt.io/qt-5/signalsandslots.html

The serialization is done by the Qt meta-type system. Since the Qt 
meta-type system uses run-time refection it can determine if the 
receiver of a signal is running in another thread, in which case the 
connection is made by creating an event on the target thread event queue 
which includes serialized copies of the signal arguments. Anyway, not 
relevant here as the compiler resolves same thread non-queued signal to 
slot connections as function calls by some C++ template magic and the 
moc pre-compiler tool that augments QObject classes.

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] 2.0.0 WSPR odd behaviors

[Jörg Hochheimer , DL6ZBN]

Hi Steve,

wouldn't it be a good idea to include those hints as "known issues" in 
the  the release notes for the current version, because several users 
have reported those false decodesrecently. I've had a couple of those, 
too. I remember that in several sections of the user guide it is 
recommended to set the decode depth to "deep"for other modes, but 
without the given background info people don't see a reason why not to 
use deep in FT8, too.


Just a thought.

Vy 73 de Joe, DL6ZBN

Am 24.01.2019 um 14:23 schrieb Steven Franke via wsjt-devel:

Hi Paul,

Recently, we’ve introduced a couple of techniques that have significantly 
improved the sensitivity of WSPR-2. Increased sensitivity comes with higher 
probability of false decodes. The next release of WSJT-X will fix a bug that 
should eliminate some of those false decodes - but it will not address either 
of the issues that you have observed. You might consider running with decode 
depth set to “Normal” rather than “Deep”. This will give you the same 
performance that was available under the “Deep” setting in earlier versions of 
WSJT-X. You will lose a couple of dB in decoding sensitivity, but you will also 
see fewer false decodes.

73 Steve, k9an


On Jan 24, 2019, at 4:03 AM, N1BUG  wrote:

I want to report two new behaviors with WSPR in 2.0.0 that were not
occurring with prior versions.

1. Occasionally a known / real call sign will decode with an
incorrect grid. Usually the grid is thousands of miles from where it
should be, sometimes in the arctic or the middle of an ocean. A look
around WSPRnet confirms this is not limited to me.

2. I have always had the occasional spurious decode while
transmitting, due to all the noise of receiver overload I presume. I
use separate receiver and transmitter (LF and MF). Usually it is
14MDA LR90. Prior to 2.0.0 it would happen a couple times a day or
so. What is new in 2.0.0 is that once this decode comes up once, it
keeps coming up every few minutes if not every transmission. If I
delete hashtable.txt or remove the 14MDA entry from that file, it
will then be several hours before I get another of those decodes.

Note: I am not yet certain whether not having hashtable.txt prevents
the first odd behavior. I am now running a script which deletes that
file after every decode period in an attempt to find out, but it
will take some time to be sure. Fortunately WSJT-X does not seem to
mind finding itself deprived of hashtable.txt and just silently
re-creates it.

73,
Paul N1BUG


___
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] EmulateTransceiver bug

[Bill Somerville]

On 24/01/2019 23:07, Black Michael via wsjt-devel wrote:
And where does this serialization take place?  Are you saying it's a 
default condition of Qt to serialize across event boundaries?


de Mike W9MDB


Mike,

you need to read up on the Qt signal/slot mechanism and how queued 
signals are processed:


http://doc.qt.io/qt-5/signalsandslots.html

The serialization is done by the Qt meta-type system. Since the Qt 
meta-type system uses run-time refection it can determine if the 
receiver of a signal is running in another thread, in which case the 
connection is made by creating an event on the target thread event queue 
which includes serialized copies of the signal arguments. Anyway, not 
relevant here as the compiler resolves same thread non-queued signal to 
slot connections as function calls by some C++ template magic and the 
moc pre-compiler tool that augments QObject classes.


73
Bill
G4WJS.



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

Re: [wsjt-devel] EmulateTransceiver bug

[Black Michael via wsjt-devel]

And where does this serialization take place?  Are you saying it's a default 
condition of Qt to serialize across event boundaries?
de Mike W9MDB

 

On Thursday, January 24, 2019, 4:05:37 PM CST, Bill Somerville 
 wrote:  
 
  On 24/01/2019 21:07, Black Michael via wsjt-devel wrote:
  
 If appears to me that the new_state variable is passed by reference to the 
update event and it may be losing scope before being handled. 
  
 
Hi Mike,
 
I doubt that. The signal is not crossing a thread boundary so it will simply be 
a function call. If it did cross a thread boundary then the object is 
serialized so is effectively passed by value. Either way the scope of the 
object should be fine.
 
If you want to be certain you can simply change the signal definition in 
Transceiver.hpp to take that argument by value for a test, no other code will 
need changing as it is equivalent.
   // rig state changed
  Q_SIGNAL void update (Transceiver::TransceiverState,
unsigned sequence_number) const;
 
Debug trace lines missing when there is a program crash is likely to be a 
buffer flushing issue, is it a crash you are trying to debug?
 
Are you sure your analysis is correct, the trace message you show above is 
coming from the Transceiver instance used for PTT wrapped one used for rig 
control, that setup is due to RTS or DTR on a second serial port being selected 
for PTT. That seems an unlikely setup for a Flex Radio SDR.
 
 
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] EmulateTransceiver bug

[Black Michael via wsjt-devel]

Could be a buffer flushing problem on the segfault.  
Here's more context
[20190124 06:32:14.097 Eastern Standard Time D] 
C:\JTSDK-Tools\tmp\wsjtx\HamlibTransceiver.cpp:1017 - 
"HamlibTransceiver::poll:" rig_get_ptt PTT = 0[20190124 06:32:15.061 Eastern 
Standard Time D] C:\JTSDK-Tools\tmp\wsjtx\Configuration.cpp:764 - 
Configuration::transceiver_online:  Transceiver::TransceiverState(online: yes 
Frequency {7074000Hz, 7073500Hz} Transceiver::MODE(DIG_U); SPLIT: on; PTT: 
off)[20190124 06:32:15.061 Eastern Standard Time D] 
C:\JTSDK-Tools\tmp\wsjtx\Configuration.cpp:787 - 
Configuration::transceiver_frequency: 7074000 
Transceiver::TransceiverState(online: yes Frequency {7074000Hz, 7073500Hz} 
Transceiver::MODE(DIG_U); SPLIT: on; PTT: off)[20190124 06:32:15.061 Eastern 
Standard Time D] C:\JTSDK-Tools\tmp\wsjtx\Configuration.cpp:795 - 
Configuration::transceiver_tx_frequency: 7073500 
Transceiver::TransceiverState(online: yes Frequency {7074000Hz, 7073500Hz} 
Transceiver::MODE(UNK); SPLIT: on; PTT: off)[20190124 06:32:15.061 Eastern 
Standard Time D] C:\JTSDK-Tools\tmp\wsjtx\EmulateSplitTransceiver.cpp:23 - 
EmulateSplitTransceiver::set: state: Transceiver::TransceiverState(online: yes 
Frequency {7074000Hz, 7073500Hz} Transceiver::MODE(UNK); SPLIT: on; PTT: off) 
#: 1698[20190124 06:32:15.061 Eastern Standard Time D] 
C:\JTSDK-Tools\tmp\wsjtx\Configuration.cpp:813 - 
Configuration::transceiver_ptt: true Transceiver::TransceiverState(online: yes 
Frequency {7074000Hz, 7073500Hz} Transceiver::MODE(UNK); SPLIT: on; PTT: 
off)[20190124 06:32:15.061 Eastern Standard Time D] 
C:\JTSDK-Tools\tmp\wsjtx\TransceiverBase.cpp:44 - "TransceiverBase::set:" #: 
1698 Transceiver::TransceiverState(online: yes Frequency {7074000Hz, 0Hz} 
Transceiver::MODE(UNK); SPLIT: off; PTT: off)[20190124 06:32:15.061 Eastern 
Standard Time D] C:\JTSDK-Tools\tmp\wsjtx\EmulateSplitTransceiver.cpp:41 - 
EmulateSplitTransceiver::handle_update: from wrapped: 
Transceiver::TransceiverState(online: yes Frequency {7074000Hz, 0Hz} 
Transceiver::MODE(DIG_U); SPLIT: off; PTT: off)



 

On Thursday, January 24, 2019, 4:05:37 PM CST, Bill Somerville 
 wrote:  
 
  On 24/01/2019 21:07, Black Michael via wsjt-devel wrote:
  
 If appears to me that the new_state variable is passed by reference to the 
update event and it may be losing scope before being handled. 
  
 
Hi Mike,
 
I doubt that. The signal is not crossing a thread boundary so it will simply be 
a function call. If it did cross a thread boundary then the object is 
serialized so is effectively passed by value. Either way the scope of the 
object should be fine.
 
If you want to be certain you can simply change the signal definition in 
Transceiver.hpp to take that argument by value for a test, no other code will 
need changing as it is equivalent.
   // rig state changed
  Q_SIGNAL void update (Transceiver::TransceiverState,
unsigned sequence_number) const;
 
Debug trace lines missing when there is a program crash is likely to be a 
buffer flushing issue, is it a crash you are trying to debug?
 
Are you sure your analysis is correct, the trace message you show above is 
coming from the Transceiver instance used for PTT wrapped one used for rig 
control, that setup is due to RTS or DTR on a second serial port being selected 
for PTT. That seems an unlikely setup for a Flex Radio SDR.
 
 
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] EmulateTransceiver bug

[Bill Somerville]

On 24/01/2019 21:07, Black Michael via wsjt-devel wrote:
If appears to me that the new_state variable is passed by reference to 
the update event and it may be losing scope before being handled.



Hi Mike,

I doubt that. The signal is not crossing a thread boundary so it will 
simply be a function call. If it did cross a thread boundary then the 
object is serialized so is effectively passed by value. Either way the 
scope of the object should be fine.


If you want to be certain you can simply change the signal definition in 
Transceiver.hpp to take that argument by value for a test, no other code 
will need changing as it is equivalent.


  // rig state changed
  Q_SIGNAL void update (Transceiver::TransceiverState,
unsigned sequence_number) const;

Debug trace lines missing when there is a program crash is likely to be 
a buffer flushing issue, is it a crash you are trying to debug?


Are you sure your analysis is correct, the trace message you show above 
is coming from the Transceiver instance used for PTT wrapped one used 
for rig control, that setup is due to RTS or DTR on a second serial port 
being selected for PTT. That seems an unlikely setup for a Flex Radio SDR.


73
Bill
G4WJS.

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

[wsjt-devel] EmulateTransceiver bug

[Black Michael via wsjt-devel]

I'm working with a user who was running a Flex and split=Fake It.
The last line of his debug log showed this:[20190124 06:32:15.061 Eastern 
Standard Time D] C:\JTSDK-Tools\tmp\wsjtx\EmulateSplitTransceiver.cpp:41 - 
EmulateSplitTransceiver::handle_update: from wrapped: 
Transceiver::TransceiverState(online: yes Frequency {7074000Hz, 0Hz} 
Transceiver::MODE(DIG_U); SPLIT: off; PTT: off)
The debug line at 59 was never saved to the file.

If appears to me that the new_state variable is passed by reference to the 
update event and it may be losing scope before being handled.
  if (state.split ())    {      Q_EMIT failure (tr ("Emulated split mode 
requires rig to be in simplex mode"));    }  else    {      TransceiverState 
new_state {state};      // Follow the rig if in RX mode.      if (state.ptt ()) 
new_state.frequency (rx_frequency_);
      // These are always what was requested in prior set state operation      
new_state.tx_frequency (tx_frequency_);      new_state.split (split_);
#if WSJT_TRACE_CAT      qDebug () << "EmulateSplitTransceiver::handle_update: 
signalling:" << state;#endif
      // signal emulated state      Q_EMIT update (new_state, sequence_number); 
   }
de Mike W9MDB___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Fortran errors with GCC/GFortran 9.0.0

[Richard Shaw]

Guys,

Fedora Rawhide has updated to gcc 9.0.0 and as usual the compiler gets more
pedantic about code and has raised some new errors with the fortran code of
wsjtx. Since it stops at the first error and I've already seen two with
different compile attempts it may take a few iterations to fix them all but
here's what I have so far:

[ 64%] Building Fortran object
CMakeFiles/wsjt_fort_omp.dir/lib/ft8/chkcrc13a.f90.o
/usr/bin/gfortran -DBIGSYM=1 -DCMAKE_BUILD -DQT5 -DQT_NO_DEBUG_OUTPUT
-DQT_NO_WARNING_OUTPUT -DUNIX
-I/builddir/build/BUILD/wsjtx-2.0.0/wsjtx/build
-I/builddir/build/BUILD/wsjtx-2.0.0/wsjtx
-I/builddir/build/BUILD/wsjtx-2.0.0/wsjtx/build/wsjt_fort_omp_autogen/include
-I/usr/include  -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-I/usr/lib64/gfortran/modules -DNDEBUG -fbounds-check -funroll-all-loops
-fno-f2c -Wall -Wno-conversion -fno-second-underscore
-Jfortran_modules_omp   -fopenmp -c
/builddir/build/BUILD/wsjtx-2.0.0/wsjtx/lib/ft8/chkcrc13a.f90 -o
CMakeFiles/wsjt_fort_omp.dir/lib/ft8/chkcrc13a.f90.o
BUILDSTDERR:
/builddir/build/BUILD/wsjtx-2.0.0/wsjtx/lib/ft8/chkcrc13a.f90:16:26:
BUILDSTDERR:16 |
 i1Dec8BitBytes(10)=iand(i1Dec8BitBytes(10),128+64+32+16+8)
BUILDSTDERR:   |  1
BUILDSTDERR: Error: Arguments of 'iand' have different kind type parameters
at (1)
BUILDSTDERR: make[2]: *** [CMakeFiles/wsjt_fort_omp.dir/build.make:573:
CMakeFiles/wsjt_fort_omp.dir/lib/ft8/chkcrc13a.f90.o] Error 1

There's also a number of warnings that would be nice to fix. I'll post a
link to the build log once the errors are corrected.

Thanks,
Richard
KF5OM
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] (no subject)

[Rich Zwirko - K1HTV]

VK2/G3NJV.
Paul,
  In addition to being active using WSJT-X v2.0.0 784f75 , I also run a
Redpitaya to decode FT8 stations and feed the FT8 RBN as well as PSK
reporter. My spot of you may also have been from the RP receiver/decoder.

73,
Rich - K1HTV
= = =
From: Paul Randall 
To: "wsjt-devel@lists.sourceforge.net" 
Cc:
Bcc:
Date: Thu, 24 Jan 2019 01:50:04 +
Subject: [wsjt-devel]  WSJT Reporting to PSK Reporter

 Hi, I got this address from the WSJT website. I am new to this
group and not sure of the protocols. I tried emailing yesterday but am
unsure if this was received.



I am operating as VK2/G3NJV. After upgrading to v2.0.0 I found reports of
my transmissions almost disappeared from PSK Reporter. I now get just a
handful of reports all from stations NOT using WSJT. Most of these come
from stations using “Red Pitaya FT8 TRX 1.0”. I spoke to Philip Gladstone
about this and he told me that WSJT does not send reception reports to PSK
Reporter unless it receives callsign and locator in a single message. It is
impossible for me to transmit a message like this. Because I have a type B
callsign, all that will fit in a single message is “CQ VK2/G3NJV”



This seems a particularly harsh outcome for type B callsign holders
upgrading to v2.0.0. who, like me, are often operating portable stations
with makeshift antennas where reception reports are extremely valuable. The
reports from stations using a Red Pitaya are perfectly acceptable and I’m
not sure of the reasoning behind the current WSJT “callsign + QRA” rule.
Would it be possible to modify this to allow reception reports for type B
callsigns received without a QRA?



Many thanks for your attention.

Paul Randall

G3NJV



PS After completing this email I checked the PSK Reporter website again.
Sure enough there were just 5 reception reports, four from monitors using
Red Pitaya but also a single report from K1HTV  using WSJT-X v2.0.0 784f75.
This is the only WSJT reception report seen since 10 December so now I’m
not sure what is going on!
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPR-15

[N1BUG]

On 1/24/19 6:44 AM, Bill Somerville wrote:
> I am fairly confident that given a mode that might have the sensitivity 
> of WSPR-15, on LF bands, with similar or less bandwidth and similar T/R 
> period to WSPR-2, users would consider upgrading their transmitters for 
> the necessary frequency stability.

Hi Bill,

The mode sounds exciting but as a very active LF operator I am not
sure I share your optimism regarding equipment upgrades. While the
more dedicated transmitting stations will no doubt be willing to
upgrade, for some it may be a path too far to seriously consider.
Much will depend on just what level of stability is required. It
could mean starting completely over with all new equipment for some.
One of the attractions of LF and MF is that (for current modes) one
can build a very capable station for little money.

Any mode intended for propagation study or identifying openings is
inherently dependent on the  much larger number of receiving
stations compared to the small number of transmitting stations. I
suspect many of them will be unwilling or unable to shoulder the
burden of upgrading for the ability to monitor one more mode. Again,
much will depend one just what is required.

Another factor which may or may not be relevant is that the vast
majority of LF transmitting stations do not have linear amplifiers.
Class D and E are the norm.

73,
Paul N1BUG




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

Re: [wsjt-devel] 2.0.0 WSPR odd behaviors

[Steven Franke via wsjt-devel]

Hi Paul,

Recently, we’ve introduced a couple of techniques that have significantly 
improved the sensitivity of WSPR-2. Increased sensitivity comes with higher 
probability of false decodes. The next release of WSJT-X will fix a bug that 
should eliminate some of those false decodes - but it will not address either 
of the issues that you have observed. You might consider running with decode 
depth set to “Normal” rather than “Deep”. This will give you the same 
performance that was available under the “Deep” setting in earlier versions of 
WSJT-X. You will lose a couple of dB in decoding sensitivity, but you will also 
see fewer false decodes.

73 Steve, k9an

> On Jan 24, 2019, at 4:03 AM, N1BUG  wrote:
> 
> I want to report two new behaviors with WSPR in 2.0.0 that were not
> occurring with prior versions.
> 
> 1. Occasionally a known / real call sign will decode with an
> incorrect grid. Usually the grid is thousands of miles from where it
> should be, sometimes in the arctic or the middle of an ocean. A look
> around WSPRnet confirms this is not limited to me.
> 
> 2. I have always had the occasional spurious decode while
> transmitting, due to all the noise of receiver overload I presume. I
> use separate receiver and transmitter (LF and MF). Usually it is
> 14MDA LR90. Prior to 2.0.0 it would happen a couple times a day or
> so. What is new in 2.0.0 is that once this decode comes up once, it
> keeps coming up every few minutes if not every transmission. If I
> delete hashtable.txt or remove the 14MDA entry from that file, it
> will then be several hours before I get another of those decodes.
> 
> Note: I am not yet certain whether not having hashtable.txt prevents
> the first odd behavior. I am now running a script which deletes that
> file after every decode period in an attempt to find out, but it
> will take some time to be sure. Fortunately WSJT-X does not seem to
> mind finding itself deprived of hashtable.txt and just silently
> re-creates it.
> 
> 73,
> Paul N1BUG
> 
> 
> ___
> 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] WSJT Reporting to PSK Reporter

[Paul Randall]

Hi Phil
It says in the WSJT v2 user guide section 7.5 “WSJT-X 2.0 offers no support for 
two nonstandard callsigns to work each other” so this is a well known 
limitation.

I do not understand the logic that WSJT does not give reception reports to PSK 
reporter unless a QRA and callsign exist in a single message whereas all QSOs 
made with my type B callsign are valid without any QRA locator information 
being exchanged at all?

I wonder if anyone else has experienced what I call “callsign hijacking” where 
mid way through a QSO you start transmitting the wrong “other station” 
callsign. The message boxes are all filled correctly yet the wrong callsign 
appears to be transmitted and brings the QSO to a halt. Restarting the program 
and abandoning the QSO seems to be the only way to stop it. Presumably this is 
an unwanted result of using hash codes.

As it stands v2.0.0 does a lot for “normal” callsign holders but is really 
quite tricky if you have a type B callsign.  I have used FT8 a lot whilst 
operating from Australia with simple wire antennas and it has allowed me to 
work around the globe. However, tuning across 17m this evening the band was 
absolutely empty - until I hit 18100 and the S meter almost hit the stops. For 
a weak signal mode there are a lot of powerful stations crowded into that 3kHz 
and I felt sad the popularity of FT8 seems to have emptied the band of SSB 
stations.

Paul G3NJV

Sent from Mail for Windows 10


From: t...@gmx.fr 
Sent: Thursday, January 24, 2019 7:26:59 PM
To: wsjt-devel@lists.sourceforge.net
Cc: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT Reporting to PSK Reporter

Hi,

Paul, I have the same issue when I use the call ZS1/F5FDV.

Since december last year I was wondering why I get only few reports from 
PSKReporter.
Your post provides a very relevant the explanation, in my opinion.

Reporting went well with revisions prior to 2.0.

It seems consistent with the statement that it is now impossible to make proper 
QSO between two type B stations (see previous posts from me to the group). I 
think that there is a weakness in the coding or decoding of type B call signs. 
Decoding maybe, because reporting of these stations by WSJT-X to PSKReporter do 
no happen.

73,

Phil F5FDV

Envoyé: jeudi 24 janvier 2019 à 03:50
De: "Paul Randall" 
À: "wsjt-devel@lists.sourceforge.net" 
Objet: [wsjt-devel] WSJT Reporting to PSK Reporter
 Hi, I got this address from the WSJT website. I am new to this group 
and not sure of the protocols. I tried emailing yesterday but am unsure if this 
was received.

I am operating as VK2/G3NJV. After upgrading to v2.0.0 I found reports of my 
transmissions almost disappeared from PSK Reporter. I now get just a handful of 
reports all from stations NOT using WSJT. Most of these come from stations 
using “Red Pitaya FT8 TRX 1.0”. I spoke to Philip Gladstone about this and he 
told me that WSJT does not send reception reports to PSK Reporter unless it 
receives callsign and locator in a single message. It is impossible for me to 
transmit a message like this. Because I have a type B callsign, all that will 
fit in a single message is “CQ VK2/G3NJV”

This seems a particularly harsh outcome for type B callsign holders upgrading 
to v2.0.0. who, like me, are often operating portable stations with makeshift 
antennas where reception reports are extremely valuable. The reports from 
stations using a Red Pitaya are perfectly acceptable and I’m not sure of the 
reasoning behind the current WSJT “callsign + QRA” rule. Would it be possible 
to modify this to allow reception reports for type B callsigns received without 
a QRA?

Many thanks for your attention.
Paul Randall
G3NJV

PS After completing this email I checked the PSK Reporter website again. Sure 
enough there were just 5 reception reports, four from monitors using Red Pitaya 
but also a single report from K1HTV  using WSJT-X v2.0.0 784f75. This is the 
only WSJT reception report seen since 10 December so now I’m not sure what is 
going on!
___ 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] Layout different when "Menus" enabled/disabled

[DG2YCB, Uwe]

Hi Bill,

 

Thanks for your reply. Well, reducing also the spaces when hiding the menu bar 
is a good idea. However, as unfortunately the height of the control panel is 
NOT reduced (only the minimum width), for 16/9 monitors in practice it doesn’t 
bring any advantage. Just as an idea for future releases: Maybe it is possible 
somehow optionally to reduce the total height of the control panel (e.g. 
reducing horizontal spaces, reducing size of clock, or making fields a little 
smaller). Would help those using laptop computers.

 

73 de DG2YCB,

Uwe



German Amateur Radio Station DG2YCB

Dr. Uwe Risse

eMail:   dg2...@gmx.de

Info:   www.qrz.com/db/DG2YCB

 

Von: Bill Somerville [mailto:g4...@classdesign.com] 
Gesendet: Donnerstag, 24. Januar 2019 11:20
An: wsjt-devel@lists.sourceforge.net
Betreff: Re: [wsjt-devel] Layout different when "Menus" enabled/disabled

 

On 24/01/2019 07:23, OG55W wrote:

One minor issue: The layout for the various fields in WSJT-X v2.0.0 is somewhat 
different when “Menus” is enabled or disabled. (My preferred layout is that 
when menus are enabled, but usually I like the menus disabled…). Not a big 
deal, but maybe it can be corrected for the next release.

Hi Keijo and Uwe,

there is nothing to fix here, the shrinking of layout spacing is deliberate and 
consistent with the original intent of hiding the menu bar, which is to reduce 
the screen space used by the WSJT-X user interface.

73
Bill
G4WJS.

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

Re: [wsjt-devel] WSPR-15

[Bill Somerville]

On 24/01/2019 11:00, N1BUG wrote:

On 1/24/19 5:41 AM, Bill Somerville wrote:

On the new lower LF bands a decoder can take advantage of the far more
stable propagation than is found on the higher short-wave bands.
Coherence across significant periods of time allows assumptions that
frequency and phase of a signal are essential stable, this opens up
significant techniques for improved sensitivity.

Hi Bill,

Forgive me if this is a silly question, but does that imply extreme
frequency stability would be required of the transmitter and
receiver? I hope this won't be a mode limited to those who have
everything GPSDO referenced. WSPR-15 seems reasonably drift tolerant.

73,
Paul N1BUG


Hi Paul,

not a silly question at all. I doubt frequency accuracy will be an 
issue. OTOH frequency stability certainly is relevant, you can only take 
advantage of the stability of the propagation path if the transmitted 
signal is at least as stable. Drift can be accounted for if it proves to 
be a serious problem, the first order drift component is likely to be 
the most significant by far, for crystal controlled sources, once 
frequency references have reached temperature equilibrium. WSPR like 
modes have an advantage that considerable CPU resources can be used to 
process the received signals since, unlike QSO modes, there are no 
deadlines to decide the next message content based on message context so 
elaborate and expensive algorithms to make such corrections are feasible.


I am fairly confident that given a mode that might have the sensitivity 
of WSPR-15, on LF bands, with similar or less bandwidth and similar T/R 
period to WSPR-2, users would consider upgrading their transmitters for 
the necessary frequency stability.


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

Re: [wsjt-devel] WSPR-15

[N1BUG]

On 1/24/19 5:41 AM, Bill Somerville wrote:
> On the new lower LF bands a decoder can take advantage of the far more 
> stable propagation than is found on the higher short-wave bands. 
> Coherence across significant periods of time allows assumptions that 
> frequency and phase of a signal are essential stable, this opens up 
> significant techniques for improved sensitivity.

Hi Bill,

Forgive me if this is a silly question, but does that imply extreme
frequency stability would be required of the transmitter and
receiver? I hope this won't be a mode limited to those who have
everything GPSDO referenced. WSPR-15 seems reasonably drift tolerant.

73,
Paul N1BUG


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

Re: [wsjt-devel] WSPR-15

[Bill Somerville]

On 24/01/2019 10:29, N1BUG wrote:

I want to inquire one more time about WSPR-15. Is this mode finally
declared forever abandoned or is there still some hope it will find
its way into WSJT-X?


Hi Paul,

there has been some work on a WSPR-LF mode that should perform at least 
as well as WSPR-15, on LF bands, using considerably shorter T/R periods. 
On the new lower LF bands a decoder can take advantage of the far more 
stable propagation than is found on the higher short-wave bands. 
Coherence across significant periods of time allows assumptions that 
frequency and phase of a signal are essential stable, this opens up 
significant techniques for improved sensitivity.


The work so far is a background project which may get more attention 
when some other current developments are completed.


73
Bill
G4WJS.



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

[wsjt-devel] WSPR-15

[N1BUG]

I want to inquire one more time about WSPR-15. Is this mode finally
declared forever abandoned or is there still some hope it will find
its way into WSJT-X?

I must emphasize WSPR-15 is the miracle beacon and propagation study
mode for LF, where it is still used every day. As one example:
recently WSPR-15 brought me numerous LF reports from KL7, I7 and SV8
where WSPR-2 could not. I was running alternating WSPR-15 / WSPR-2
as I often do, two transmissions of WSPR-15 per hour and six of
WSPR-2. WSPR-15 has a huge advantage over WSPR-2.

The "problem" is that not everyone is able to run WSPR-X
successfully. I myself have spent nearly two years trying to figure
out why it isn't stable on my system but have no answers. Sometimes
it will run for a week, other times it will silently terminate every
few minutes. This does not seem related to what other software is
running or when the PC was rebooted. It seems completely
unpredictable. Others report similar experience. Also, WSPR-X often
fails to upload to WSPRnet. Note: no other application has any
problems on my system, including multiple instances of WSJT-X which
are flawlessly stable.

The fact that there have been two recent third party attempts to
"patch" or work around these issues with WSPR-X should say something
about how the LF community views WSPR-15.

I have heard some rumors about a possible replacement for WSPR-15. I
won't comment much on that since I heard these rumors indirectly but
the ideas I heard left me wondering if it would really measure up to
what WSPR-15 can tell us about propagation.

73,
Paul N1BUG


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

Re: [wsjt-devel] Layout different when "Menus" enabled/disabled

[Bill Somerville]

On 24/01/2019 07:23, OG55W wrote:


One minor issue: The layout for the various fields in WSJT-X v2.0.0 is 
somewhat different when “Menus” is enabled or disabled. (My preferred 
layout is that when menus are enabled, but usually I like the menus 
disabled…). Not a big deal, but maybe it can be corrected for the next 
release.



Hi Keijo and Uwe,

there is nothing to fix here, the shrinking of layout spacing is 
deliberate and consistent with the original intent of hiding the menu 
bar, which is to reduce the screen space used by the WSJT-X user interface.


73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT Reporting to PSK Reporter

[Bill Somerville]

On 24/01/2019 08:26, t...@gmx.fr wrote:

Hi,
Paul, I have the same issue when I use the call ZS1/F5FDV.
Since december last year I was wondering why I get only few reports 
from PSKReporter.

Your post provides a very relevant the explanation, in my opinion.
Reporting went well with revisions prior to 2.0.
It seems consistent with the statement that it is now impossible to 
make proper QSO between two type B stations (see previous posts from 
me to the group). I think that there is a weakness in the coding or 
decoding of type B call signs. Decoding maybe, because reporting of 
these stations by WSJT-X to PSKReporter do no happen.

73,
Phil F5FDV


Phil,

your statement that it is impossible to make proper QSOs between two 
type B stations is ridiculous, whatever a type B station is. As for PSK 
Reporter spotting, see my replies to to Paul when he asked the same 
question a couple of days back:


https://sourceforge.net/p/wsjt/mailman/message/36524657/

and also to Lorin, WA1PGB, after a similar query:

https://sourceforge.net/p/wsjt/mailman/message/36525529/

Please remember that the sending a gridsquare is not essential for a 
valid QSO, the reason gridsquares are sent with standard callsigns when 
calling and replying to CQ messages are largely for use on VHF and above 
and on EME paths where location information is critical for aerial 
pointing and Doppler calculations. There use on HF is handy and does 
enable tools like PSK Reporter to give accurate mapping information but 
you can work around that as I have explained.


Most importantly, the changes in the 77-bit protocol related to compound 
and non-standard callsigns benefits many current and potential WSJT-X 
users. There are a few who will loss some no-essential capabilities but 
TBH making QSOs with compound callsigns has never been optimal and for 
those with other non-standard callsigns virtually impossible. When there 
are strict constraints on a protocol a major rework will mean some 
losers but we hope the many winners will make the changes worthwhile to 
the community.


73
Bill
G4WJS.



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

[wsjt-devel] 2.0.0 WSPR odd behaviors

[N1BUG]

I want to report two new behaviors with WSPR in 2.0.0 that were not
occurring with prior versions.

1. Occasionally a known / real call sign will decode with an
incorrect grid. Usually the grid is thousands of miles from where it
should be, sometimes in the arctic or the middle of an ocean. A look
around WSPRnet confirms this is not limited to me.

2. I have always had the occasional spurious decode while
transmitting, due to all the noise of receiver overload I presume. I
use separate receiver and transmitter (LF and MF). Usually it is
14MDA LR90. Prior to 2.0.0 it would happen a couple times a day or
so. What is new in 2.0.0 is that once this decode comes up once, it
keeps coming up every few minutes if not every transmission. If I
delete hashtable.txt or remove the 14MDA entry from that file, it
will then be several hours before I get another of those decodes.

Note: I am not yet certain whether not having hashtable.txt prevents
the first odd behavior. I am now running a script which deletes that
file after every decode period in an attempt to find out, but it
will take some time to be sure. Fortunately WSJT-X does not seem to
mind finding itself deprived of hashtable.txt and just silently
re-creates it.

73,
Paul N1BUG


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

Re: [wsjt-devel] WSJT Reporting to PSK Reporter

[tmp1]

Hi,

 

Paul, I have the same issue when I use the call ZS1/F5FDV.

 

Since december last year I was wondering why I get only few reports from PSKReporter.

Your post provides a very relevant the explanation, in my opinion.

 

Reporting went well with revisions prior to 2.0.

 

It seems consistent with the statement that it is now impossible to make proper QSO between two type B stations (see previous posts from me to the group). I think that there is a weakness in the coding or decoding of type B call signs. Decoding maybe, because reporting of these stations by WSJT-X to PSKReporter do no happen.


 

73,

 

Phil F5FDV

 


Envoyé: jeudi 24 janvier 2019 à 03:50
De: "Paul Randall" 
À: "wsjt-devel@lists.sourceforge.net" 
Objet: [wsjt-devel] WSJT Reporting to PSK Reporter




 Hi, I got this address from the WSJT website. I am new to this group and not sure of the protocols. I tried emailing yesterday but am unsure if this was received.

 

I am operating as VK2/G3NJV. After upgrading to v2.0.0 I found reports of my transmissions almost disappeared from PSK Reporter. I now get just a handful of reports all from stations NOT using WSJT. Most of these come from stations using “Red Pitaya FT8 TRX 1.0”. I spoke to Philip Gladstone about this and he told me that WSJT does not send reception reports to PSK Reporter unless it receives callsign and locator in a single message. It is impossible for me to transmit a message like this. Because I have a type B callsign, all that will fit in a single message is “CQ VK2/G3NJV”

 

This seems a particularly harsh outcome for type B callsign holders upgrading to v2.0.0. who, like me, are often operating portable stations with makeshift antennas where reception reports are extremely valuable. The reports from stations using a Red Pitaya are perfectly acceptable and I’m not sure of the reasoning behind the current WSJT “callsign + QRA” rule. Would it be possible to modify this to allow reception reports for type B callsigns received without a QRA?

 

Many thanks for your attention.

Paul Randall

G3NJV

 

PS After completing this email I checked the PSK Reporter website again. Sure enough there were just 5 reception reports, four from monitors using Red Pitaya but also a single report from K1HTV  using WSJT-X v2.0.0 784f75. This is the only WSJT reception report seen since 10 December so now I’m not sure what is going on!

___ 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