On 26/07/2017 01:18, Pino Zollo wrote:
Received report belonging to other station: 1.7.0
QSO:
0005 Tx 1003 # CQ DX ZP4KFX GG14
0006 -25 0.0 1002 # ZP4KFX W8VK EN70
0007 Tx 1002 # W8VK ZP4KFX -25
0008 -13 0.2 1003 # ZP4KFX JS6SVV -08
0009 Tx 1002 # W8VK ZP4KFX -25
0010
Received report belonging to other station: 1.7.0
QSO:
0005 Tx 1003 # CQ DX ZP4KFX GG14
0006 -25 0.0 1002 # ZP4KFX W8VK EN70
0007 Tx 1002 # W8VK ZP4KFX -25
0008 -13 0.2 1003 # ZP4KFX JS6SVV -08
0009 Tx 1002 # W8VK ZP4KFX -25
0010 -23 -0.0 1003 # ZP4KFX W8VK RRR
0011 Tx
Hi Richard,
On 7/25/2017 4:58 PM, Richard Lamont G4DYA wrote:
On 25/07/17 00:17, Joe Taylor wrote:
Ubuntu MATE 16.04 amd64
1.7.1-devel r7939
Auto seq and call 1st enabled
Tried it and it looks as though FT8 now has a two-pass decoder, which is
nice.
Since you're providing feedback on
Bill,
Can the team pre-assign some mode-identification characters (displayed
in the WSJT-X decodes and used in the UDP decode packet) that they will
use in future modes?
I'm trying to avoid the "~" clash we had with FT8 and T10 and old
JTAlert versions defaulting to JT9 where "~" was not
Hello All,
All I can say is, the fast mode "is fast".
Joe, Steve, Bill, etc are working on decoder refinement, but for me,
decoding 18+ stations each iteration is more than enough to contemplate. On
the fast mode, I just decoded a station at -21db. I think that's a record
for me on FT8. -20db
Hi Richard,
> 1.8.0-rc1 fast/normal/deep 0.2s/0.5s/0.7s
> 1.8.0-rc2-r7924fast/normal/deep 0.2s/0.5s/0.7s
> 1.7.1-devel-r7944 fast/normal/deep 0.4s/0.8s/2.5s
FWIW, you may find that r7946 is somewhat faster than r7944, on all settings. I
have made a change that will reduce
On 25/07/2017 21:58, Richard Lamont wrote:
As Bill mentioned in his OP, the FT8 decoder is still a work in progress
but I have noticed that the r7939/r7944 decoder is currently too slow to
be usable on my machine, which uses a Core 2 Duo E6700 CPU (2 x 2.66 GHz
cores), even with nothing much
Hi Richard,
> As Bill mentioned in his OP, the FT8 decoder is still a work in progress
> but I have noticed that the r7939/r7944 decoder is currently too slow to
> be usable on my machine, which uses a Core 2 Duo E6700 CPU (2 x 2.66 GHz
> cores), even with nothing much else running. (Admittedly
>On 25/07/2017 15:41, Bill Somerville wrote:
>> On 25/07/2017 15:29, K5GZR - Rick wrote:
>>> R7939 on Windows 10.
>>> Mode is FT8
>>> My call is K5GZR
>>> When I double click on the following msg in Band Activity:
>>> 140330 -10 0.6 1672 ~ AJ4F W5TN EM00
>>> I get the expected result ? W5TN
Thanks Bill,
I will ask Simon (SDR-Console's developer) about adding this feature. I
*think* I have asked for it before, but there wasn't enough interest. It
does seem like it would be simple to add a "Assign VFO to x" dropdown in
the settings page where serial ports are selected in
On 25/07/2017 18:49, Kyle McKenzie wrote:
I frequently am running many instances of WSJT-X, which get their
audio via VAC from multiple VFOs in SDR-Console (v2 and v3). With my
RSP1 I can usually fit at least 3 different ham bands within it's
10Mhz waterfall.
This works great, BUT as far as
I frequently am running many instances of WSJT-X, which get their audio via
VAC from multiple VFOs in SDR-Console (v2 and v3). With my RSP1 I can
usually fit at least 3 different ham bands within it's 10Mhz waterfall.
This works great, BUT as far as I know, I can only control VFO A using
Hamlib
On 25/07/2017 15:41, Bill Somerville wrote:
On 25/07/2017 15:29, K5GZR - Rick wrote:
R7939 on Windows 10.
Mode is FT8
My call is K5GZR
When I double click on the following msg in Band Activity:
140330 -10 0.6 1672 ~ AJ4F W5TN EM00
I get the expected result – W5TN goes into DX Call
On 25/07/2017 15:29, K5GZR - Rick wrote:
R7939 on Windows 10.
Mode is FT8
My call is K5GZR
When I double click on the following msg in Band Activity:
140330 -10 0.6 1672 ~ AJ4F W5TN EM00
I get the expected result – W5TN goes into DX Call box,
and standard messages are generated
R7939 on Windows 10.
Mode is FT8
My call is K5GZR
When I double click on the following msg in Band Activity:
140330 -10 0.6 1672 ~ AJ4F W5TN EM00
I get the expected result - W5TN goes into DX Call box,
and standard messages are generated for W5TN and K5GZR
However, when I
On 23/07/2017 21:26, Chip Hood via wsjt-devel wrote:
Rig controlled split operation does not work for a TS-590SG using Ham
Radio Deluxe. It will momentarily work (rig in split and WSJT-X rig
control indicator green with an S) but will drop out of split both on
the rig and the indicator in
On 25/07/2017 14:15, G8DQX (WSJT developers on SF) wrote:
If the current configuration requires adjustment, that option is
selected by clicking *OK*, which brings up the Settings→General tab.
The *Settings→Radio* tab would be a more obvious/sensible selection,
which I think is the point that
Sandro, Bill,
the WSJT-X program, when the dialog box Sandro referenced is displayed,
can not communicate with the radio, but has no means of knowing *why*
communication is not possible. There are various possibilities, and the
dialog box accounts for pretty much all of them:
* correct
On 25/07/2017 13:16, Joe Taylor wrote:
On 7/25/2017 1:36 AM, Mark Turner wrote:
Hi Joe,
I've been back through my saved files and picked out a few that
demonstrate what I'm randomly seeing, attached to this email. I'd be
interested to know if they reveal anything at all, including a
Hi Mark,
Your example *.wav files suggest something seriously going wrong in your
data acquisition chain. It's unlikely that long-distance attempts at
diagnosis can be successful; you'll need to do some sleuthing on your own.
--Joe, K1JT
On 7/25/2017 1:36 AM, Mark Turner wrote:
Hi
Hi all,
Following the recommendation to switch to the rc2 branch, I have found
fewer occurrences of this erratic behaviour.
Another erratic behaviour I have observed is the following one: When
switching to the sending state, the XCVR is switched on as expected, but
no audio signal is generated.
21 matches
Mail list logo
