Re: [wsjt-devel] WSJT-X patches

[Dan Bates]

Bill,

I added the json file to the .config directory. I set retry to 30 and now only 
see the error occasionally.  And only when I have quisk and cqrlog running 
along with WSJTX.  

I cannot get fldigi to work with rigctld at all. It closes the socket after one 
exchange.  Maybe I need to build a newer version of fldigi.

Dan

ARRL, QCAW, CW Ops
First licensed 1962

> On Sep 13, 2016, at 3:19 PM, Dan Bates  wrote:
> 
> Bill,
> 
> Let me know if you want help testing?
> 
> Dan
> 
> -Original Message-
> From: Rik van Riel [mailto:r...@surriel.com] 
> Sent: Tuesday, September 13, 2016 2:49 PM
> To: WSJT software development 
> Subject: Re: [wsjt-devel] WSJT-X patches
> 
>> On Sat, 2016-09-10 at 19:53 -0500, Dan Bates wrote:
>> Hi Bill,
>> 
>> I see the failures when a second  client is polling the rigctld 
>> socket.
>> 
>> The current code, in the failure routine just toggles a bool variable 
>> for a single retry before throwing the error.  Other apps (example
>> fldigi) have a user configurable variable for retry count.
> 
> Funny, I see fldigi fail more often than wsjtx.
> 
> I should take a look at rigctld to see what is going on, and send a fix to 
> upstream hamlib (assuming I figure it out).
> 
> -- 
> 
> All Rights Reversed.
> 
> 
> --
> ___
> 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] WSJTX request/suggestion

[Joe Taylor]

Hi Gary and all,

My earlier message was wrong about one thing:

> At present, any decode in MSK144 mode (whether or not you double-click
> on the decode) will set the "Rx Freq" spinner control to the frequency
> of the received signal. Tx Freq always stays fixed at 1500 Hz. In code
> revision 7076 these two controls are invisible. Probably we should
> change this; making them visible, with the Tx control disabled so you
> can't change its value from 1500 Hz, would be more informative.

However, Steve reminded me that at present the Rx Freq spinner control 
has no effect in MSK144 mode: we always transmit at 1500 Hz and receive 
at 1500 +/- Ftol Hz.  Therefore it made better sense to have the spinner 
controls invisible in MSK144 mode.

-- Joe, K1JT

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

Re: [wsjt-devel] WSJT-X patches

[Dan Bates]

Bill,

Let me know if you want help testing?

Dan

-Original Message-
From: Rik van Riel [mailto:r...@surriel.com] 
Sent: Tuesday, September 13, 2016 2:49 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] WSJT-X patches

On Sat, 2016-09-10 at 19:53 -0500, Dan Bates wrote:
> Hi Bill,
> 
> I see the failures when a second  client is polling the rigctld 
> socket.
> 
> The current code, in the failure routine just toggles a bool variable 
> for a single retry before throwing the error.  Other apps (example
> fldigi) have a user configurable variable for retry count.

Funny, I see fldigi fail more often than wsjtx.

I should take a look at rigctld to see what is going on, and send a fix to 
upstream hamlib (assuming I figure it out).

-- 

All Rights Reversed.


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

Re: [wsjt-devel] WSJT-X patches

[Rik van Riel]

On Sat, 2016-09-10 at 19:53 -0500, Dan Bates wrote:
> Hi Bill,
> 
> I see the failures when a second  client is polling the rigctld
> socket. 
> 
> The current code, in the failure routine just toggles a bool variable
> for a single retry before throwing the error.  Other apps (example
> fldigi) have a user configurable variable for retry count.  

Funny, I see fldigi fail more often than wsjtx.

I should take a look at rigctld to see what is going on,
and send a fix to upstream hamlib (assuming I figure it
out).

-- 

All Rights Reversed.

signature.asc
Description: This is a digitally signed message part
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] build instructions enhancement

[Claude Frantz]

On 09/13/2016 05:58 PM, Rik van Riel wrote:

Hi Rik and all,

>>> Specifically, the CMAKE_PREFIX_PATH is not enough to
>>> make it actually find hamlib.

There should be a file /usr/local/lib/pkgconfig/hamlib.pc or in another
suitable directory allowing the use of pkg-config. cmake can use
pkgconfig. This is probably a reliable way to get the hamlib configured.

best 88 de Claude (DJ0OT)

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

Re: [wsjt-devel] build instructions enhancement

[Rik van Riel]

On Tue, 2016-09-13 at 09:17 +0100, Bill Somerville wrote:
> On 13/09/2016 03:31, Rik van Riel wrote:
> > Specifically, the CMAKE_PREFIX_PATH is not enough to
> > make it actually find hamlib.
> 
> Hi Rik,
> 
> that instruction is correct. I looks like you have not run the
> install 
> target on the Hamlib build. You can install it into a local
> directory 
> e.g. ~/local/hamlib then that is the path that should be added to 
> CMAKE_PREFIX_PATH. CMake knows how to search a normal install
> structure 
> for the files of a package, you do not need to give it any extra 
> information other than the root of the installation or the upstream 
> package(s).
> 
> Please review the Hamlib build instructions in that same document,
> you 
> may have missed a step.

I did run the install target on the Hamlib build.

I have bin/ include/ lib/ and share/ subdirectories
in the hamlib directory.

However, I did invoke CMake the wrong way first time
I tried, and I suspect it may simply not have cleaned
up its cached data when I re-ran it with the correct
command line arguments later.

-- 

All Rights Reversed.

signature.asc
Description: This is a digitally signed message part
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX request/suggestion

[Joe Taylor]

Hi Gary,

Because this reponse to your email may be useful to others, I am copying 
it to the wsjt-devel ("WSJT Developers") email list.

AG0N wrote:
> If I am interpreting what I've done in testing correctly, the MSK144 tones
> center around 1500.  Again, from what I've seen, if you double click an 
> incoming
> signal, the tone shifts to the incoming (desirable).  But if you call CQ after
> doing that double click, the tone stays at that shifted frequency, rather than
> resetting to 1500.  I found that it WOULD reset by closing the program and
> reopening it again.  I did not try switching modes and coming back to do it, 
> so
> perhaps that would have done the same thing.  I'm wondering if it would be 
> good
> to reset to 1500 anytime the CQ line were triggered or an initiating call was
> made???  You've probably got a built-in limit to how far from 1500 it will go,
> but I like to know that I start at the same frequency every time.

By convention, the frequency of any of the FSK modes in WSJT-X is taken 
to be that of its lowest tone.  For MSK144, which actually uses an OQPSK 
(Offset Quadrature Phase-Shift Keying) waveform, frequency is defined as 
the center or "carrier" frequency.  The transmitted frequency is always 
1500 Hz.

At present, any decode in MSK144 mode (whether or not you double-click 
on the decode) will set the "Rx Freq" spinner control to the frequency 
of the received signal.  Tx Freq always stays fixed at 1500 Hz.  In code 
revision 7076 these two controls are invisible.  Probably we should 
change this; making them visible, with the Tx control disabled so you 
can't change its value from 1500 Hz, would be more informative.

> In contest mode, myself and a few others have found a small glitch.  I realize
> this contest mode was probably a last minute addition when Steve talked to you
> about it and the immediate need for it for the contest over the weekend.  With
> that in mind, I assume it will be expanded to accommodate different report
> requirements for the normal batch of contests during the year.  But, regarding
> the way it worked this last weekend, there is a problem that can be overcome 
> by
> the user if he is aware of it.
>
> Scenario:  Two guys make arrangements via PJ or whatever to meet on MSK144.
> W1ABC calls K1XYZ.  K1XYZ calls W1ABC but isn't heard by W1ABC.  K1XYZ hears
> W1ABC, auto-sequence flips to TX4 and sends RRR.  Per rules, W1ABC has not
> received the grid of K1XYZ, but upon hearing RRR, he flips to 73.  QSO done,
> even though one grid was not exchanged.  I hope I haven't confused myself in
> typing that up.  Regardless, there is a method of having an auto QSO completed
> without full info transferred.  Perhaps sending automated RRR can be inhibited
> without knowing the other stations call and grid?  Currently, the workaround 
> is
> for at least one of the two stations to call CQ, instead of calling the other
> station.

The User Guide will need to explain that "Contest mode" QSOs put some 
extra onus on operators to be sure that they have received all required 
information for the contest exchange.  Of course you can always send a 
message like "GRID?", or "PSE UR GRID?", or some such.  But better 
still, one should make sure that contest-mode QSOs start with someone 
calling CQ or "running a frequency", as in HF-style contests.

> A few of us have been playing with QRA64a on 160/80m.  I was amazed last night
> to see how it did through the wall of static crashes on those two bands.  Both
> stations were 100% first time decode, even with one of them running 1W in New
> York on 80m.

Yes, QRA64 can be impressive with very weak signals!  More work on QRA64 
(and especially its wider submodes) is currently underway, and is 
especially relevant for use of QRA64 for microwave EME.

Users should keep in mind that we consider the precise definition of the 
protocol not yet frozen.  We might change the sync pattern, for example, 
in a way that is not backward-compatible.  If this should happen, we'll 
be sure to make suitable announcements about the need to upgrade.  Old 
versions would not be able to communicate with new versions. in that case.

-- Joe, K1JT

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

[wsjt-devel] wsjtx-1.7.0-rc1-Darwin.dmg

[C. Gary Rogers]

Do we know when and where the OSX version of 1.7.0 release candidate will be 
posted for us non-compilers?  Thanks. 

Sent from my iPhone

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

Re: [wsjt-devel] Possible issues w/ WSJT-X 1.7 r7072

[Joe Taylor]

Hi David,

> I noticed the following on r7072 (Running under OSX 10.9.5):
>
> 1) Given a constant audio level input with the JT65 level adjusted
> to 30 dB, I see the correct 30dB audio reading using JT9, JT65,
> JT9+JT65, JT4, QRA64, and WSPR2. Switching to ISCAT, JTMSK or
> MSK144 results in a 5dB drop in the reported signal level.

For a no-longer-important reason, the arbitrary "0 dB" level for fast 
modes was defined differently (by 5 dB) than for slow modes.  This has 
no important consequence; the "sweet spot" for setting a good level is 
very broad -- far more than 5 dB wide.  However, the offset that 
surprised you will be removed.

> 2) I don't use the hamlib rig control (I set it to 'None'). In modes
> ISCAT, JTMSK, MSK144, and QRA64 I am unable to change the band
> dropdown by hand. All the other modes allow it.

Default frequencies for each band are "mode specific".  Apparently you 
see the behavior you describe because you haven't entered any choices of 
default frequencies for ISCAT, JTMSK, MSK144, or QRA64.

-- 73, Joe, K1JT

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

Re: [wsjt-devel] build instructions enhancement

[Bill Somerville]

On 13/09/2016 03:31, Rik van Riel wrote:
> Specifically, the CMAKE_PREFIX_PATH is not enough to
> make it actually find hamlib.

Hi Rik,

that instruction is correct. I looks like you have not run the install 
target on the Hamlib build. You can install it into a local directory 
e.g. ~/local/hamlib then that is the path that should be added to 
CMAKE_PREFIX_PATH. CMake knows how to search a normal install structure 
for the files of a package, you do not need to give it any extra 
information other than the root of the installation or the upstream 
package(s).

Please review the Hamlib build instructions in that same document, you 
may have missed a step.

73
Bill
G4WJS.


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