Date   

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@...>, 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@...>, 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


locked Re: Missing Calls in grid

Ron W3RJW
 
Edited

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 Missing Calls in grid

Tom Melvin
 

Hi

Just noticed a little issue -  JTAlert 2.16.5 - Wsjt-x RC3

6m has been going mad just now - I have the wanted grid alert enabled.  Few times I have heard the alert, looked at the screen and no coloured call.  First few times put it down to imagination - then while looking at screen I see the call highlited briefly  and then gone - it appears the wanted grid was on the 1st row of calls but then the JTAlert screen was quickly re-drawn and that 1st line disappeared. 

It may have been fixed already but thought I would mention it. I will enable debug just incase I catch it again and have something to go on.

Tom

--
73

Tom
GM8MJV (IO85)






locked Re: Worked B4 sometimes not working

Steve Weeks
 

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





locked Re: Worked B4 sometimes not working

Tony Dixon G4CJC
 

On Mon, Jun 1, 2020 at 02:22 AM, HamApps Support (VK3AMA) wrote:
On 31/05/2020 12:53 am, Tony Dixon G4CJC wrote:
I seem to have the same problem, sometimes.
Using WSJT-X2.2.0 -rc3, JTAlert 2.16.6, W10 64bit with all updates current. The attached snip is of receiving FT4, EA1A having worked on FT8 with mode ignored. I have not researched this extensively but will make more note of seeming anomalies. Clearing the B4 cache does not seem to make any difference. Can I help in any way?
Cheers
Tony G4CJC
Tony,

Your screen-grab shows WSJT-X not showing the JTAlert coloring, but you didn't include an image of what JTAlert was displaying. Was JTAlert correctly showing the coloring and it is only WSJT-X that is not?

de Laurie VK3AMA

Sorry Laurie,
I don't remember and obviously that's important. I'll keep looking. 
Suddenly, I have a feeling I'm not seeing what I think I'm seeing.
In Settings, worked B4 if I tick Ignore Band, Ignore Mode, Ignore Gridsquare then if I've worked a station anywhere, any mode any band it will show as B4 in JTAlert. But not necessarily in WSJT-X? 
What effect does Clear B4 Cache have.
Cheers
Tony G4CJC

Cheers Tony G4CJC


locked Re: Field Day Operation

Dave Garber
 

you just have to change Jtalert to reflect logging to the FD contest log file.   at least that is what I have done in the past


then of course, change it back to the regular Aclog file when the contesting is done



Dave Garber
VE3WEJ / VE3IE


On Sun, May 31, 2020 at 9:26 PM Laurie, VK3AMA <hamapps.support@...> wrote:


On 1/06/2020 11:14 am, Larry wrote:
> N3FJP has updated his field day program. I will use that. WB2UFO

Unless Scott has changes the API used with his Contest Loggers, JTAlert
should still work with his new release.

de Laurie VK3AMA





locked Re: Incorrectly Identifying DXCC Entities Worked

Jeff - G4IUA
 
Edited

Meanwhile I'm just manually going to 'Wanted DXCC/Individual Bands', highlighting the band,  finding the incorrectly identified prefix for that particular band and sending it from the 'Wanted' column to 'Not Wanted'.  Not so much a problem now that I have a reasonably large number already worked but for someone starting out it would be a real pain.

BTW updated to WSJT-X 2.2.0 rc3 and JTAlert 2.16.6 r2

Jeff - G4IUA


locked Re: Worked B4 sometimes not working

neil_zampella
 

DOH .... I just remembered.   I turned that off because it was more of a distraction than assistance.    I had forgotten about it as I believe it was removed as an option for the clone.

Neil, KN3ILZ


locked Re: Worked B4 sometimes not working

Stephen Taylor - K6SJT
 

Laurie,

(1) I cleared the B4 cache.

(2) I have not observed the condition repeat over the weekend.

(3) FT4 has been very slow during this period, so if the issue is exacerbated by a high volume of calls (as mentioned in this blog) then that may be why I haven't observed it?

I'll keep watching and report any details of importance - Thank you,
Stephen Taylor - K6SJT