Re: [wsjt-devel] Transmit audio dropouts

[runningerik]

Hi,

This is an observation, not necessary a bug report, and as Bill pointed out
in one of the groups.io threads :

The root problem is that USB devices are "hot-pluggable" and adding or
removing a device, while the system is running, will cause all other devices
to be re-enumerated, this can change device identities but Windows does not
inform applications using them that they have been shuffled.

73's Erik.
ON4PB

-Original Message-
From: runninge...@gmail.com  
Sent: Tuesday, 22 June 2021 10:37
To: wsjt-devel@lists.sourceforge.net
Subject: Re : Transmit audio dropouts

Hi,

I think I have a simple recipe to reproduce this problem :

I have 4 WSTX instances connected to 4 slices on my Flex 6600M. All is
working fine.
My USB headset is connected to a USB port.
=> Disconnect the headset and after that, PTT will work but no transmit
audio. Reconnecting the headset does not cure the problem, restarting WSJTX
however does.

Now, there are a couple of variants to reproduce the audio dropout :
- reconnecting the headset with working WSJTX instances
- doing the same on 4 WSJTX instances connected to SparkSDR. So, the Flex is
not at fault.

And lastly, sometimes it occurs that all 4 decode buttons remain active
blue.

73's Erik
ON4PB


--

Message: 3
Date: Sun, 20 Jun 2021 19:39:29 + (UTC)
From: Louis Fiore 
To: "mailto:wsjt-devel@lists.sourceforge.net;

Subject: [wsjt-devel] Transmit audio dropouts
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Good Afternoon,

Running version 2.4.0. Out of the blue I?ve noticed a few instances with my
Flex 6500 transmitter keying on but no audio is transmitted. It happens
randomly on both FT4 & FT8 about 10 to 20% of the time. Does anyone have an
idea what may be causing this? 

73, Lou W2LTF 





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

Re: [wsjt-devel] Transmit audio dropouts

[runningerik]

Hi,

I think I have a simple recipe to reproduce this problem :

I have 4 WSTX instances connected to 4 slices on my Flex 6600M. All is
working fine.
My USB headset is connected to a USB port.
=> Disconnect the headset and after that, PTT will work but no transmit
audio. Reconnecting the headset does not cure the problem, restarting WSJTX
however does.

Now, there are a couple of variants to reproduce the audio dropout :
- reconnecting the headset with working WSJTX instances
- doing the same on 4 WSJTX instances connected to SparkSDR. So, the Flex is
not at fault.

And lastly, sometimes it occurs that all 4 decode buttons remain active
blue.

73's Erik
ON4PB


--

Message: 3
Date: Sun, 20 Jun 2021 19:39:29 + (UTC)
From: Louis Fiore 
To: "mailto:wsjt-devel@lists.sourceforge.net;

Subject: [wsjt-devel] Transmit audio dropouts
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Good Afternoon,

Running version 2.4.0. Out of the blue I?ve noticed a few instances with my
Flex 6500 transmitter keying on but no audio is transmitted. It happens
randomly on both FT4 & FT8 about 10 to 20% of the time. Does anyone have an
idea what may be causing this? 

73, Lou W2LTF 




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

[wsjt-devel] MAP65 V3.0.0-rc1 - Fortran runtime error

[runningerik]

Hi,

I believe this is another runtime error, which has not been reported (using
a FunCube Pro dongle - not caused by tuning the Offset spinner) :

Running: C:\WSJT\wsjtx\bin\m65 -s
At line 18 of file C:\Users\bill\src\k1jt\wsjtx\map65\libm65\display.f90
Fortran runtime error: Bad value during floating point read

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0x
#1  0x
#2  0x
#3  0x
#4  0x
#5  0x
#6  0x
#7  0x
#8  0x
#9  0x
#10  0x
#11  0x
#12  0x
#13  0x
#14  0x
#15  0x
#16  0x
#17  0x
#18  0x

73's Erik
ON4PB



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

[wsjt-devel] MAP65 3.0.0-rc1 fortran runtime error : Index ...

[runningerik]

Hi,

I was now able to reproduce this minor problem. It occurred whilst spinning
the "Offset kHz" to a value of 8 kHz, although not always.

73's Erik
ON4PB
--

Message: 5
Date: Mon, 14 Jun 2021 21:46:38 +0200
From: 
To: 
Subject: [wsjt-devel] MAP65 3.0.0-rc1 fortran runtime error : Index
'33110' ...
Message-ID: 
Content-Type: text/plain; charset="us-ascii"

Hi,

A big thumbs up for bringing back MAP65 ..  and a real pleasure to see the
baseband EME decoding unfolding using my Funcube Pro dongle.

Today, I had this Fortran runtime error, which I however cannot reproduce.
It could have been caused by changing the Offset spinner in the Wide Graph,
as I remember this was probably the last action I did on the GUI.

And as a sidenote, can something already be revealed how a future baseband
feed into WSJTX will look like ? Will it be possible to do away with audio
in/out channels ?

A sincere thanks for bringing all of this to the ham community,
73's Erik
ON4PB

So here it is :

 

---
Running: C:\WSJT\wsjtx\bin\m65 -s

At line 152 of file
C:\Users\bill\src\k1jt\wsjtx\map65\libm65\wideband_sync.f90

Fortran runtime error: Index '33110' of dimension 2 of array 'savg' outside
of expected range (32768:1)

 

Error termination. Backtrace:

 

Could not print backtrace: libbacktrace could not find executable to open

#0  0x

#1  0x

#2  0x

#3  0x

#4  0x

#5  0x

#6  0x

#7  0x

#8  0x

#9  0x

#10  0x

#11  0x

#12  0x

#13  0x

#14  0x

#15  0x



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

[wsjt-devel] MAP65 3.0.0-rc1 fortran runtime error : Index '33110' ...

[runningerik]

Hi,

 

A big thumbs up for bringing back MAP65 ..  and a real pleasure to see the
baseband EME decoding unfolding using my Funcube Pro dongle.

 

Today, I had this Fortran runtime error, which I however cannot reproduce.
It could have been caused by changing the Offset spinner in the Wide Graph,
as I remember this was probably the last action I did on the GUI.

 

And as a sidenote, can something already be revealed how a future baseband
feed into WSJTX will look like ? Will it be possible to do away with audio
in/out channels ?

 

A sincere thanks for bringing all of this to the ham community,

73's Erik

ON4PB

 

So here it is :

 

---

 

Running: C:\WSJT\wsjtx\bin\m65 -s

At line 152 of file
C:\Users\bill\src\k1jt\wsjtx\map65\libm65\wideband_sync.f90

Fortran runtime error: Index '33110' of dimension 2 of array 'savg' outside
of expected range (32768:1)

 

Error termination. Backtrace:

 

Could not print backtrace: libbacktrace could not find executable to open

#0  0x

#1  0x

#2  0x

#3  0x

#4  0x

#5  0x

#6  0x

#7  0x

#8  0x

#9  0x

#10  0x

#11  0x

#12  0x

#13  0x

#14  0x

#15  0x

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

[wsjt-devel] Highlight Callsign in NetworkMessage - Feature request

[runningerik]

Hi,

I find it very difficult to sync the list of highlighted callsigns between
server and WSJTX clients.
More specifically, when my udp server restarts, all previously highlighted
callsigns become zombies without being able to clear them.

Unless I have something seriously misunderstood, would it be possible to
provide a means to clear all highlighted callsigns in Network Message 13
(Highlight Callsign) ?
Maybe an empty callsign could clear the highlighted list ?

73's Erik
ON4PB




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

[wsjt-devel] 2.3.0 - Unexpected program exit in WSPR mode

[runningerik]

Hi,

I observed a number of unexpected program exits with release 2.3.0 in WSPR
mode / band hopping mode.
The exit is reproducible, the timing of when it happens however, is not.

The radio setting is : Hamlib NET rigctl, connected to a network server
(SparkSDR), PTT : CAT, Transmit Audio source : rear, Mode : None, Split :
Fake it.

The last syslog entry with filter set to debug is :

[2021-02-03 09:33:59.108031][00:00:14.896695][RIGCTRL][debug] () :
netrigctl_get_ptt called


The last syslog entry with filter set to trace is :

[2021-02-04 06:55:54.040793][00:06:01.833448][RIGCTRL][trace]
C:\Users\bill\src\k1jt\wsjtx\Transceiver\HamlibTransceiver.cpp(1008)
do_poll: rig_get_mode mode=USB bw=4000
[2021-02-04 06:55:54.040793][00:06:01.833460][RIGCTRL][debug] () :
rig.c(2586):rig_get_ptt entered
[2021-02-04 06:55:54.040793][00:06:01.833469][RIGCTRL][trace] () :
elapsed_ms: start = 1612421753,35880800
[2021-02-04 06:55:54.040793][00:06:01.833481][RIGCTRL][trace] () :
elapsed_ms: elapsed_msecs=1005
[2021-02-04 06:55:54.040793][00:06:01.833490][RIGCTRL][trace] () :
rig_get_ptt: cache check age=1004ms
[2021-02-04 06:55:54.040793][00:06:01.833497][RIGCTRL][trace] () :
rig_get_ptt: cache miss age=1004ms
[2021-02-04 06:55:54.040793][00:06:01.833505][RIGCTRL][debug] () :
netrigctl_get_ptt called
[2021-02-04 06:55:54.040793][00:06:01.833514][RIGCTRL][trace] () :
netrigctl_vfostr: called vfo=VFOA
[2021-02-04 06:55:54.040793][00:06:01.833523][RIGCTRL][trace] () :
netrigctl_vfostr: vfo_opt=0
[2021-02-04 06:55:54.040793][00:06:01.833532][RIGCTRL][debug] () :
netrigctl_transaction: called len=2
[2021-02-04 06:55:54.040793][00:06:01.833541][RIGCTRL][trace] () :
rig_flush: called for network device
[2021-02-04 06:55:54.040793][00:06:01.833549][RIGCTRL][debug] () :
network_flush called
[2021-02-04 06:55:54.040793][00:06:01.833558][RIGCTRL][debug] () :
write_block called
[2021-02-04 06:55:54.040793][00:06:01.833586][RIGCTRL][trace] () :
write_block(): TX 2 bytes
[2021-02-04 06:55:54.040793][00:06:01.833597][RIGCTRL][trace] () : 
74 0a   t.
[2021-02-04 06:55:54.040793][00:06:01.833606][RIGCTRL][trace] () :
read_string called, rxmax=96
[2021-02-04 06:55:54.040793][00:06:01.833625][RIGCTRL][trace] () :
read_string(): RX 2 characters
[2021-02-04 06:55:54.040793][00:06:01.833633][RIGCTRL][trace] () : 
30 0a   0.
[2021-02-04 06:55:54.040793][00:06:01.833643][RIGCTRL][trace] () :
elapsed_ms: start = 0,0
[2021-02-04 06:55:54.040793][00:06:01.833676][RIGCTRL][trace] () :
elapsed_ms: after gettime, start = 1612421754,40793800
[2021-02-04 06:55:54.040793][00:06:01.833686][RIGCTRL][debug] () :
rig.c(2631):rig_get_ptt return


The full log with the 2 program exits can be found at :

https://1drv.ms/u/s!AtBGol2-BnqRhqpYeMCyimEZJVr1rQ?e=Z7Xqm4

Let me know if you need more information, or if you prefer to forward this
problem to SparkSDR dev't.

And a big thumbs up for the syslog feature !

73's
Erik
ON4PB



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

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 - Audio input streaming (Bill Somerville)

[runningerik]

Thanks (once again) Bill for clarifying this, and appreciating the fact that
AudioIn Underrun errors are detected by the software.

As a sidenote, the absence of a Windows notification in case of audio
re-assignments is also very visible when running WSJT-X through a remote
desktop, with the Audio running at the remote PC.
When the Windows remote desktop session disconnects, all remote audio at the
remote PC will be cut off without any reason. Which makes it very difficult
to run WSJT-X at a remote unattended PC.
There are alternatives (running WSJTX inside a VM, other remote desktop
software, .. ), but still ..

73's Erik
ON4PB


--
Hi Erik,

those errors do go to the user, but they don't happen when Windows reassigns
the audio device, we get no notification.

73
Bill
G4WJS.



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

[wsjt-devel] WSJT-X 2.2.0-rc2 - Audio input streaming

[runningerik]

Dear developers,

 

Looking at some of the recent "audio in problem" posts, would it make sense
to raise audio input streaming errors to the GUI ? Maybe some visual hint
(f.e. a red decode button) or an error dialog ?

I can easily reproduce a situation on Win10-64 bit, where 8 running WSJT-X
instances (of which one is WSPR) will halt the WSPR decoding and this
without saving .wav files (although "Save decoded" is selected). 

 

More particularly, maybe catching these errors in Soundin.cpp and bring them
to the foreground ?

 

 case QAudio::OpenError:

  Q_EMIT error (tr ("An error opening the audio input device has
occurred."));

  break;

 

case QAudio::IOError:

  Q_EMIT error (tr ("An error occurred during read from the audio
input device."));

  break;

 

case QAudio::UnderrunError:

  Q_EMIT error (tr ("Audio data not being fed to the audio input
device fast enough."));

  break;

 

case QAudio::FatalError:

  Q_EMIT error (tr ("Non-recoverable error, audio input device not
usable at this time."));

  break;

 

Thanks for considering and 73's,

Erik

ON4PB

 

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

[wsjt-devel] WSJT-X 2.2.0-rc1 - WSPR decoding stops when multiple WSJT-X instances are running

[runningerik]

Dear developers,

Please allow me to report a situation where WSPR decoding halts when
multiple WSJT-X instances are running.

My setup is as follows : 

Two Hermes Lite II SDR's connected to a single instance of SparkSDR (yes !
my Hamlib Net rigctl is now working).
Two WSJTX instances (WSJT-X and WSJT-X - HL1 decoding FT8) are connected to
the first Hermes Lite II.
One WSJTX instance (WSJT-X - HL7 decoding WSPR) is connected to the second
Hermes Lite II.

When I turn on "Monitor" on WSJTX instances WSJT-X and WSJT-X - HL1
(decoding FT8), WSPR decoding stops on WSJTX instance WSJT-X - HL7 (decoding
WSPR).
And reversely, when I turn off "Monitor" on WSJTX instances WSJT-X and
WSJT-X - HL1 (decoding FT8), WSPR decoding resumes (on the fly) on WSJTX
instance WSJT-X - HL7 (decoding WSPR).
All this without restarting any WSJT-X instance.

Something to mention is that when switching on "Monitor" on WSJTX instances
WSJT-X and WSJT-X - HL1, the current WSPR time frame will be correctly
decoded, but not the next ones.

A screenshot of the 3 instances running, with WSPR decoding failing
(although the Wide Graph shows incoming signals) can be found here :
https://1drv.ms/u/s!AtBGol2-BnqRhfsJ7UXRuhRsil7olQ?e=3jRr4c

I have verified that no packets are lost between my transceivers and
SparkSDR. As well as no audio buffer underruns / overflows on the VAC's.
As well as deleted all AppData files and recreated the instances.

I also observed that the "Save -> Save All" option, sometimes does not save
wave files for my WSJT-X - HL7 instance decoding WSPR, when the decoding
failed (only one out of two wave files are written).

All running W10 - 64 bit.

Could someone maybe try to reproduce this problem (maybe a Red Pitaya SDR
user ?).

73's and hoping I don't have it all wrong ..
Erik
ON4PB.







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

[wsjt-devel] WSJT-X 2.2.0-rc1 - Blank line between decoding periods

[runningerik]

Dear WSJTX developers,

 

When ticking "Blank line between decoding periods" (and "Start new period
decodes at top" is unticked), there is no separation line anymore in the
Band Activity window (when decoding FT8 for example).

 

My apologies if this is a dupe report .. 

 

Stay safe and 73's,

Erik

ON4PB

 

 

 

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

Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Hamlib NET rigctl no longer works

[runningerik]

Hi Bill,

Thanks for looking into this and I can already provide you with the
following answers :

- WSJT-X reports in its error dialog "Rig Failure" "Hamlib error :
Communication timed out while getting current VFO frequency"
- There is no error in the SparkSDR latest "corelog-2020-05-12-19-35-54.txt"
and I have a suspicion, the WSJTX 2.2.0 command does not reach the network
server at SparkSDR
- The reason for my using the "rigctl-wsjtx" command was to check the
network transport (which seems to work). Now that I presume / understand you
are using rigctld for connecting to a network server, I will check with
M0NNB if we can debug this offline (and put you in email copy).
- Lets maybe keep in mind that this was working in release 2.1.2.

73's and thanks again,
Erik
ON4PB

---
Message: 2
Date: Tue, 12 May 2020 22:34:02 +0100
From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Hamlib NET rigctl no
longer works
Message-ID: <6bc371e6-9e40-e938-c597-98af91d1d...@classdesign.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 12/05/2020 22:16, runninge...@gmail.com wrote:
> Hi,
>
> thanks one more time for all the dedicated work with yet another big 
> step forward in decoding weal signals . !
>
> Let me report that I am no longer able to CAT control my SparkSDR with 
> the "Hamlib NET rigctl" network server.
>
> My settings are : "localhost:5" for Network server, which should 
> connect to my first (out of four) virtual transceiver in SparkSDR 
> (which is connected to a Hermes Lite II).
> Substituting "localhost" with its IP address or hostname does not 
> solve the problem neither.
> The same settings work fine with WSJT-X 2.1.2.
>
> Some more observations :
> - The "C:\WSJT\wsjtx\bin>rigctl-wsjtx -m 2 -r localhost:5 F 
> 7253500 M LSB 0" command correctly sets the VFO and mode.
> - Overwriting the 3 rigctl executables with the release 2.1.2 binaries 
> yields the same result (sorry but I could not withstand doing this .).
>
> This is on a windows 10 - 64 bit config.
>
> 73's and best regards,
> Erik
> ON4PB

Hi Erik,

I see no mention of you running any form of rigctld, this makes me think
that SparkSDR has hijacked the Hamlib internal network protocol and is
acting as a fake rigctld. If that is so then the authors of SparkSDR
probably need to update their software to conform with the latest Hamlib
network protocol. It may well be that WSJT-X is sending commands that he
fake rigctld server does not understand. Do you get an error from WSJT-X, if
so what is it including the details? Does SparkSDR have an way of tracing
the commands sent to it?

73
Bill
G4WJS.




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

[wsjt-devel] WSJT-X 2.2.0-rc1 - Hamlib NET rigctl no longer works

[runningerik]

Hi, 

thanks one more time for all the dedicated work with yet another big step
forward in decoding weal signals . !

Let me report that I am no longer able to CAT control my SparkSDR with the
"Hamlib NET rigctl" network server.

My settings are : "localhost:5" for Network server, which should connect
to my first (out of four) virtual transceiver in SparkSDR (which is
connected to a Hermes Lite II). 
Substituting "localhost" with its IP address or hostname does not solve the
problem neither.
The same settings work fine with WSJT-X 2.1.2.

Some more observations :
- The "C:\WSJT\wsjtx\bin>rigctl-wsjtx -m 2 -r localhost:5 F 7253500 M
LSB 0" command correctly sets the VFO and mode.
- Overwriting the 3 rigctl executables with the release 2.1.2 binaries
yields the same result (sorry but I could not withstand doing this .).

This is on a windows 10 - 64 bit config.

73's and best regards,
Erik
ON4PB







___
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 ?

[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] Adding "MY_RIG" info to the ADIF file when logging a QSO

[runningerik]

Hi Dave, 

A very good observation. 

If possible, I would default to the rig selection from the Settings Window
-> Radio Tab -> Rig and then allow for an override.

The reason is that there are a lot of rig emulations around : SDRConsole
emulates a TS-2000, uBitx emulates a Yaesu FT-817, and so on ...

73's Erik
ON4PB
--

Message: 1
Date: Mon, 18 Nov 2019 10:01:27 -0500
From: "Dave Slotter, W3DJS" 
To: WSJT software development 
Subject: Re: [wsjt-devel] Adding "MY_RIG" info to the ADIF file when
logging a QSO
Message-ID:

Content-Type: text/plain; charset="utf-8"

Would you want the ADIF log "MY_RIG" field to be populated from the Settings
Window -> Radio Tab -> Rig popup?

Or would you want a free-form text entry?




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

Re: [wsjt-devel] Adding "MY_RIG" info to the ADIF file when logging a QSO

[runningerik]

Hi Tom,

Let me clarify my request : the purpose is not to log the OPERATOR but
MY_RIG.

Today, I maintain my rig info through a manual log update and I thought it
could also be useful in case of multi station ops (sharing the same log).

73's 
Erik
ON4PB

--

Message: 3
Date: Mon, 18 Nov 2019 15:00:02 +0200
From: Tom Ramberg 
To: WSJT software development 
Subject: Re: [wsjt-devel] Adding "MY_RIG" info to the ADIF file when
logging a QSO
Message-ID: <721de260-91df-448e-b8fc-dcab6270b...@yahoo.com>
Content-Type: text/plain; charset=utf-8

Isn't the need for tracking which operator is on in a multiop stuation
covered by "OPERATOR"?

73 de Tom OH6VDA




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

[wsjt-devel] Adding "MY_RIG" info to the ADIF file when logging a QSO

[runningerik]

Is there any interest for adding a new "My rig" (+ retain tickbox) in the
Log QSO panel ?

This information could then be written to the wsjtx_log.adi file and
propagated to JTAlert ...

I find it very useful to keep track of the transceiver which was used to
make the QSO. 
This could also be helpful for multi-station operations like expeditions,
contests, .. where operators would like to keep track of their individual
station's traffic ..

If there is sufficient appetite for this feature, maybe considering this for
a future release ?

Thanks and 73's,
Erik
ON4PB



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

Re: [wsjt-devel] wsjt-devel Digest, Vol 68, Issue 6

[runningerik]

Hi Bill,

The "Decode" button stays permanently cyan colored on some of the instances,
and does not blink at all. As for the DT values, I have no evidence, and am
currently trying to reproduce the problem.
I will let you know as soon as the problem re-appears.

73's and have a nice day.
Erik
ON4PB


--

Message: 4
Date: Sun, 6 Oct 2019 13:03:03 +0100
From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJTX process priorities on Windows
Message-ID: 
Content-Type: text/plain; charset=windows-1252; format=flowed

On 06/10/2019 12:57, runninge...@gmail.com wrote:
> decoding halts after an unpredictable number of hours with the Decode 
> button turning blue and the waterfall still showing an incoming audio 
> stream.

Hi Erik,

can you clarify this statement please. Does the "Decode" button turn cyan
permanently or does it change each decode period but with no decodes
appearing? Another piece of information would be useful, do the DT values
drift towards the limit just before decoding stops?

73
Bill
G4WJS.



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

[wsjt-devel] WSJTX process priorities on Windows

[runningerik]

I would like to share an interesting observation on WSJTX process
priorities, although I am not sure if this is known or not, nor if it is
helpful.

When running 4 WSJTX instances on an Intel i5 - 2400 CPU, the FT8 (as well
as WSPR) decoding halts after an unpredictable number of hours with the
Decode button turning blue and the waterfall still showing an incoming audio
stream.

This with a Hermes Lite 2 transceiver and the SparkSDR software. There is
also a UDP server application running which logs all received messages to a
database. 

 

Now when adding the 4 WSJTX startups in a batch file with the /REALTIME
option, the decoding happily runs along and no halts were observed for over
a week.

The instructions are as follows :

 

cd C:\WSJT\wsjtx\bin

start /REALTIME wsjtx.exe

. 3 more starts follow here

 

With kind regards and 73's

Erik

ON4PB

 

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

[wsjt-devel] WW-Digi Post-Contest and UDP network message request

[runningerik]

I truly enjoyed participating in the latest WW-Digi contest and learned a
lot from it !

With my Hermes Lite II, I had 4 receivers open simultaneously and could
monitor the band activity as time progressed.

An cooperating program logged all traffic, but I had some difficulty to
distinguish the band for each network messages as they were sent by the
different WSJT-X instances.

A software workaround was to rely on the Status message to know the band of
each instance (and sometimes a heartbeat needed to be sent to know the
status ..).

 

Therefore my request to evaluate if it would not be possible to include the
"Dial Frequency (Hz)quint64" field in each Decode message just as it is
done for the WSPRDecode message ?

 

73's and thanks again for bringing WSJTX and the contest to the ham
community.

Erik

ON4PB.

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

[wsjt-devel] Highlight fox with a new color ?

[runningerik]

This morning, I was observing 5V7EI replying twice in the same timeslot
without really knowing if they are operating in FT8 expedition fox mode :

 

https://www.dropbox.com/s/8ospngdtgepdjwx/twocalls.JPG?dl=0

 

I do not think so, because these replies are not compounded into a single
message.

 

However, to avoid confusion, would it be possible to add a new colour to the
Decode Highlighting scheme for received foxes ?

 

>From the FT8 DXExpedition User guide, I can read that one of three extra
bits is set for lines 5 and 7 of the documented QSO, but I am not sure it
the extra bit is used in all fox messages ?

 

Thanks for considering this, and 73's,

 

Erik

ON4PB.

 

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

Re: [wsjt-devel] Busy CPU -- audio is lost

[runningerik]

Hi Mike,

Let me share my observations with Windows Remote Desktop (RDP). 
When you use Windows RDP in and out to a remote station, the remote station
will reconfigure all its audio devices each time the connection is opened or
closed. 
And this independently whether you bring the remote audio to the local PC or
not. That is a known Windows 10 problem (google : windows 10 rdp loses
remote audio). 
So any hiccup in the internet connection will result in a remote
reconfiguration of the remote audio devices. 

My solution was to abandon Windows RDP and use Teamviewer. With Teamviewer
you can happily RDP in and out without affecting the decoding. Remote
decoding was not affected and it works for a Raspberry Pi remote client as
well as a Windows Teamviewer remote client.

Hope this helps your particular case.
73's Erik
ON4PB.

Message: 1
Date: Mon, 4 Mar 2019 20:32:52 +
From: Mike Lewis 
To: WSJT software development 
Subject: Re: [wsjt-devel] Busy CPU
Message-ID:



Content-Type: text/plain; charset="utf-8"

Decodes do fail if the reads for the audio buffers are delayed too long and
unfortunately there is no easy way to spot this.  A debug version with audio
buffer timings displayed was used to diagnose my oddball case ultimately
tracked down to the Windows advanced power option for the Display Timeout,
had to set it to Never.  

Another case is if audio is briefly interrupted, the decoding and waterfall
stop, Monitor button remains green and the clock remains operational.  A
change to the audio in settings or restart of WSJT-X is required to get
things rolling again.  This is highly repeatable if you RDP in, start
decoding, drop the session (even quickly as an internet interruption for 1
second) and come back to see the results.  Decoding will have stopped.  

In the cases above decoding either stopped or cycles missed.  It would be
very helpful to put up a warning flag for these events.  A display or log
file message and/or Monitor button turned red or orange.  A further step
would be to attempt some self-healing such as buffer reinit after failure is
detected.  A use case: I run WSJT-X remote much of the time, mostly
monitoring in WSPR or FT8 with spotting at a remote site. I have to keep the
RDP session active all the time, and cannot tolerate any internet hiccups,
so cannot monitor through the nights reliably.

73,

Mike
K7MDL



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