Date   

locked Re: "QSO Not Logged"

Ed Ireland
 

Thanks Michael.  I will try increasing the time to log.  I had not paid attention to that parameter.  Thanks!


On Tue, Jun 2, 2020 at 10:49 PM Michael Black via groups.io <mdblack98=yahoo.com@groups.io> wrote:
Change the time here

Inline image





On Tuesday, June 2, 2020, 10:31:19 PM CDT, Ed Ireland <ed@...> wrote:


I get the message "QSO not logged" from time to time but the QSO is always logged in DXKeeper. Any idea why this message comes up?


locked Re: "QSO Not Logged"

Michael Black
 

Change the time here

Inline image





On Tuesday, June 2, 2020, 10:31:19 PM CDT, Ed Ireland <ed@...> wrote:


I get the message "QSO not logged" from time to time but the QSO is always logged in DXKeeper. Any idea why this message comes up?


locked Re: "QSO Not Logged"

David Burden
 

You possibly may have some autologging function enabled to QRZ, Clublog, EQSL, LOTW or other that has failed for that contact. Worth checking.

73 David VK3BDX


locked "QSO Not Logged"

Ed Ireland
 

I get the message "QSO not logged" from time to time but the QSO is always logged in DXKeeper. Any idea why this message comes up?


locked Re: Non-coloring of WSJT-X 2.2.0 -rc decodes by JTAlert - cause identified.

jushamn@...
 

Hi All
I'm running WSJT-x v2.1.2 0068f9 and JTAlert v2.16.2 and I have the same problem. I'm not inclined to run the release candidates. Attached is my system specs file created with Speccy by Piriform. I looked in Setup> Applications>WSJT-X/JTDX and appears good there.

Hope this info helps. Laurie maybe you can pass this on to WSJT-X dev-list.
Let me know if there is something else I can do.


locked Another Possible Security Hurdle with New Windows 10 2004

Stephen Taylor - K6SJT
 

Just a heads up I ran into after the Windows 10 2004 Update - And note I already have Windows Defender set to allow all JTAlert folders and files.

In my situation, JTAlert would not open after the Windows update. I tracked it down Windows Defender:  'App & browser control'  >  'Exploit protection'  >  'Data Execution Prevention (DEP)'.

Only after I set that to 'Off by default' and restarted the computer would JTAlert (v2.16.6.1) again open and perform correctly.

Others may not have this issue, but in case you do, this may save you some time tracking it down.

Stephen Taylor - K6SJT


locked Re: Non-coloring of WSJT-X 2.2.0 -rc decodes by JTAlert - cause identified.

Tony Dixon G4CJC
 
Edited

On Tue, Jun 2, 2020 at 01:55 PM, Tony Dixon G4CJC wrote:
On Mon, Jun 1, 2020 at 11:41 PM, HamApps Support (VK3AMA) wrote:
I finally tracked down the JTAlert non-coloring of decodes in the release candidates.
WSJT-X2.1.2 works correctly, but the -rcs don't when the decode string contains a positive report. Reports that are negative are colored correctly.
Tested both rc2 & rc3

eg.

"AA1AA VK3AMA +12" & "AA1AA VK3AMA R+12" - FAIL

"AA1AA VK3AMA -12" & "AA1AA VK3AMA R-12" - OK

JTAlert sending the coloring command containing the "VK3AMA R-12" string correctly colors while "VK3AMA R+12" fails with the only difference is the number sign in the string sent to WSJT-X.

This report has already been sent to the WSJT-X dev-list.

de Laurie VK3AMA

 Wow, kudos to you Laurie. Even when I knew what to look for it took me ages to spot.
Where did you get the clues for that one?
All the best
Tony G4CJC
This fault persists in the latest version of WSJT-X v2.2

Tony G4CJC


locked Email Preferences

Rickey
 

If I missed any notices I apologize but do we no longer receive email updates?
I have not received any notifications since early May. Thanks.
--
Rickey Gilliland
k4rky@...


locked Re: Callsigns disappearing in 2.16.6 (beta)

Jim Reisert AD1C
 

Untick the "Clear callsigns display after logging" option under the Logging section of the JTAlert Settings window (scroll the section down, it is the last checkbox).
Done, thanks.

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us


locked Re: Non-coloring of WSJT-X 2.2.0 -rc decodes by JTAlert - cause identified.

Tony Dixon G4CJC
 

On Mon, Jun 1, 2020 at 11:41 PM, HamApps Support (VK3AMA) wrote:
I finally tracked down the JTAlert non-coloring of decodes in the release candidates.
WSJT-X2.1.2 works correctly, but the -rcs don't when the decode string contains a positive report. Reports that are negative are colored correctly.
Tested both rc2 & rc3

eg.

"AA1AA VK3AMA +12" & "AA1AA VK3AMA R+12" - FAIL

"AA1AA VK3AMA -12" & "AA1AA VK3AMA R-12" - OK

JTAlert sending the coloring command containing the "VK3AMA R-12" string correctly colors while "VK3AMA R+12" fails with the only difference is the number sign in the string sent to WSJT-X.

This report has already been sent to the WSJT-X dev-list.

de Laurie VK3AMA

 Wow, kudos to you Laurie. Even when I knew what to look for it took me ages to spot.
Where did you get the clues for that one?
All the best
Tony G4CJC


locked Re: JTAlert two instance, two two different resended ports

Robert, SP8SN
 

OK thank You
--
Robert, SP8SN


locked Re: Non-coloring of WSJT-X 2.2.0 -rc decodes by JTAlert - cause identified.

Norbert Graf - DD3KF
 

Hello Laurie,

 

yesterday I made another odd observation:

 

I decoded stations from a NEW GRID calling CQ:

 

JTALERT:

- Showing DXl with green background for CQ,

- only Audio Alert for NEW GRID,

- TX1 by DX showing light blue background for NEW GRID.

(sorry, no screen shot).

 

WSJT-X RC

pse see sample screen shot.

DX: DL3TW

 

My working environment:

- Windows 10, 64 bit

- WSJT-X 2.2.0 RC3 64 bit

- JTAlert 2.16.6

- HRD Log 6.7.0.277, logging via JTAlert

Alter priority:

- NEW GRID

- CQ

 

I dont know if this is related to your following post.

 

73!

 

______________

Norbert Graf

D D 3 K F

 

Von: Support@HamApps.groups.io <Support@HamApps.groups.io> Im Auftrag von HamApps Support (VK3AMA)
Gesendet: Dienstag, 2. Juni 2020 00:42
An: Support@HamApps.groups.io
Cc: main@HamAppsBeta.groups.io
Betreff: [HamApps] Non-coloring of WSJT-X 2.2.0 -rc decodes by JTAlert - cause identified.

 

I finally tracked down the JTAlert non-coloring of decodes in the release candidates.
WSJT-X2.1.2 works correctly, but the -rcs don't when the decode string contains a positive report. Reports that are negative are colored correctly. Tested both rc2 & rc3

eg.

"AA1AA VK3AMA +12" & "AA1AA VK3AMA R+12" - FAIL

"AA1AA VK3AMA -12" & "AA1AA VK3AMA R-12" - OK

JTAlert sending the coloring command containing the "VK3AMA R-12" string correctly colors while "VK3AMA R+12" fails with the only difference is the number sign in the string sent to WSJT-X.

This report has already been sent to the WSJT-X dev-list.

de Laurie VK3AMA


locked Re: Worked B4 sometimes not working

HamApps Support (VK3AMA)
 

On 1/06/2020 10:12 pm, Steve Weeks wrote:
Laurie - I have noted two different anomalies repeatedly since loading rc3.  

1.  The one previously discussed in other messages, where JTAlert shows B4 entries colored correctly (grey in my case) but the coloring sporadically shows up on some, but not all, of the corresponding entries in the WSJT-X Band Activity list.

2.  Not all of the time, but not rarely either, the first 1 to 3 entries in the Band Activity window for a cycle do not show up at all in the JTAlert boxes.  Typically this happens when such early entries are very strong (+15 dB or higher) and I am guessing it may be a timing issue.  rc3 now displays decodes as they are decoded rather than collecting all of them for a phase of decoding and putting them in frequency order to display, and it starts the first phase of decoding (of the 3 phases that it now uses) before the 12.6 second Tx window is even completed.  If there are strong signals, they are decoded first and come out much earlier in the cycle than in prior versions, possibly (just a guess) before JTAlert is expecting them.

Maybe these issues are related.

Thank you for your amazing efforts in developing and maintaining this essential product.

73, Steve AA8SW

1. is due to a WSJT-X anomaly. If you look closely you will see that the non-colored decodes in WSJT-X (when they should be) have a positive signal report. I discovered this earlier today. See https://hamapps.groups.io/g/Support/message/30069
The WSJT-X devs are looking into it.

2. is fixed in the 2.16.6 build 0001 beta. See https://hamapps.groups.io/g/Support/message/30015

de Laurie VK3AMA


locked Re: JTAlert two instance, two two different resended ports

HamApps Support (VK3AMA)
 

On 31/05/2020 7:12 pm, Robert, SP8SN wrote:
Hallo. I have some problem. Two instances work well here. Everything works as it should. On the desktop I have two shortcuts with the addition of "--rig-name = ......". However, I have a problem setting two different ports in the "Resend WSJT-X UDP package". I need 2334 on one transceiver and 2335 on the other. I use them for the WSJTDXAggregator application. Currently both instances use 2335. Unstable WSJTDXAggregator is not working properly and does not send spots to DXmap. He receives mixed packages simultaneously from both tracivers. The second instance has unavailable settings window. Is there any possibility to change the config of the second instance in JTAlert? I tried to use "= callsign ..." but giving a parameter other than my callsign here is not suitable for login and spots etc.
Greetings, Robert SP8SN

Sorry it is not possible to have each JTAlert instance use a unique UDP port for WSJT-X packets resending'

de Laurie VK3AMA


locked Re: Callsigns disappearing in 2.16.6 (beta)

HamApps Support (VK3AMA)
 

On 2/06/2020 11:46 am, Jim Reisert AD1C wrote:
5.  I click on OK to log the QSO (while I am transmitting)
6.  The list of previously-decoded callsigns disappears

Is that normal?  If I just call CQ, calls don't disappear.  And I saw
it happen twice and *not* happen once.
Untick the "Clear callsigns display after logging" option under the Logging section of the JTAlert Settings window (scroll the section down, it is the last checkbox).

de Laurie VK3AMA



locked Callsigns disappearing in 2.16.6 (beta)

Jim Reisert AD1C
 

This bug report is against the beta because I didn't know that 12.6.6
was released.

I'm seeing decoded callsigns disappear in the following scenario:

1. I'm near the end of a QSO
2. Decode completes, Several (or many) calls listed.
3. WSJT-X (v2.2.0-rc2) pops up the logging window
4. WSJT-X starts transmitting to finish the QSO
5. I click on OK to log the QSO (while I am transmitting)
6. The list of previously-decoded callsigns disappears

Is that normal? If I just call CQ, calls don't disappear. And I saw
it happen twice and *not* happen once.

NOTE: I have my Windows 10 mouse set to make a window active just by
hovering over it (i.e. clicking not required). I don't know if that
is part of the recipe for success.

73 - Jim AD1C

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us


locked Re: Non-coloring of WSJT-X 2.2.0 -rc decodes by JTAlert - cause identified.

Alfred Reeves
 

Calling you now ur -10 here

On 6/1/2020 6:41 PM, HamApps Support (VK3AMA) wrote:
I finally tracked down the JTAlert non-coloring of decodes in the release candidates.
WSJT-X2.1.2 works correctly, but the -rcs don't when the decode string contains a positive report. Reports that are negative are colored correctly.
Tested both rc2 & rc3

eg.

"AA1AA VK3AMA +12" & "AA1AA VK3AMA R+12" - FAIL

"AA1AA VK3AMA -12" & "AA1AA VK3AMA R-12" - OK

JTAlert sending the coloring command containing the "VK3AMA R-12" string correctly colors while "VK3AMA R+12" fails with the only difference is the number sign in the string sent to WSJT-X.

This report has already been sent to the WSJT-X dev-list.

de Laurie VK3AMA


locked Non-coloring of WSJT-X 2.2.0 -rc decodes by JTAlert - cause identified.

HamApps Support (VK3AMA)
 

I finally tracked down the JTAlert non-coloring of decodes in the release candidates.
WSJT-X2.1.2 works correctly, but the -rcs don't when the decode string contains a positive report. Reports that are negative are colored correctly.
Tested both rc2 & rc3

eg.

"AA1AA VK3AMA +12" & "AA1AA VK3AMA R+12" - FAIL

"AA1AA VK3AMA -12" & "AA1AA VK3AMA R-12" - OK

JTAlert sending the coloring command containing the "VK3AMA R-12" string correctly colors while "VK3AMA R+12" fails with the only difference is the number sign in the string sent to WSJT-X.

This report has already been sent to the WSJT-X dev-list.

de Laurie VK3AMA


locked Re: Missing Calls in grid

Tom Melvin
 

Great 

Got it now with the URL - yes that seems to relevant 

Off to try

Tom



--
73

Tom
GM8MJV (IO85)





On 1 Jun 2020, at 21:47, Ron W3RJW via groups.io <w3rjw@...> wrote:

[Edited Message Follows]

Take a look at the post from Laurie right next to yours ...  Above or below depending on your setup.

https://hamapps.groups.io/g/Support/topic/new_jtalert_beta_available/74527969?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,74527969
--
73
Ron, W3RJW


locked Re: Missing Calls in grid

Tom Melvin
 

Hi Ron

Can you let me know subject?  Or message URL.

I read the newsgroup via a mail reader so I have have no idea what above/below is.

Looked back a day or so - can see some B4 issues and wsjt colouring - don’t think it applies as only coloured calls on the 1st row are affected - and you can’t see the calls there are over-written. Any other row or later in the cycle are fine - It’s JTAlert only nothing to do with feeding colours back to wsjt-x. 

Tom


--
73

Tom
GM8MJV (IO85)





On 1 Jun 2020, at 21:47, Ron W3RJW via groups.io <w3rjw@...> wrote:

Take a look at the post from Laurie right next to yours ...  Above or below depending on your setup.
--
73
Ron, W3RJW

5541 - 5560 of 35446