Date   

locked Re: Field Day - FT8/FT4

 

On Sun, Jun 28, 2020 at 01:00 PM, D. Scott MacKenzie wrote:
kb0fhp

10 meters was wide open during FD with FT4  and CW signals coming in  from all over the USA.  

JTAlert worked very well although some ADIF fields such as “Class“  did not propagate to HRD
 
--
73, Bernie, VE3FWF Ottawa, Canada


locked Re: ACL, JTAlert, and Port 1100

W5BT
 

Thank you Laurie and everyone.
I tried all the suggestions to get the local pc to work but wasn't successful.
Probably just something with this computer.  No worries, the remote works fine. I also found out by accident today, that regardless of the file location selected for the remote configuration (ACL or Field Day database)  JTAlert sent information and logged the contact to the database that was open (or is my computer just that jacked up?). 
Great feature or happy accident, but i forgot to change the file location after FD and worked a half dozen locations. The fact that ACL was working fine, I didn't realize I hadn't changed the folder location till later. I went back and opened the database and all contacts were ACL and not in the FD log.
Anyway thank you Laurie for a wonderful program. Don't know how I ever used WSJT-X without it.
Thanks
Bruce W5BT


locked Re: Not logging some QSOs to DXKeeper. #DXLAB

Carl - WC4H
 

Hi Laurie.

In re-reading your post (part quoted below), I think that there is some confusion.

I I reported to Dave was as a result of his request that I run DXK debug.  I was not running JTAlerts debug then, so I would not expect you to see his data in the debug I sent you.

What I reported to you, has nothing to do with those callsigns.  I started your debug and waited until I got an error.

The station and QSO I reported as not being logged was:
Callsign: KE2D 6/26/2020 02:23 UTC 40M FT4
The QSO before (for reference) was with W8MDE at 02:18 UTC.

JTAlerts debug was definitely running then.  When the next QSO started, I turned the dbug off off.  Incidentally, the next one did not log either but I figured that you had one in the debug data.

So the status of KE2D is what should show up as not having been sent to DXK.

I am currently running both debugs but as I have said before:  Who knows when I'll get another error.

Thanks.
Carl - WC4H

"From Dave AA6YQ I got the following information

The errorlog shows the receipt of log directives for QSOs with
KE0CH at 2020-06-25 13:41:03
WB9DLC at 2020-06-25 13:43:11
WW0E at 2020-06-25 13:44:44

The errorlog does not show DXKeeper receiving a directive to log a QSO with WZ9B."


locked Re: Decodes window not always populating

W4WT
 

Sorry for the late reply.  Been working on a project for several days.

I'm not sure why my "friendly name" clears when I reboot the computer but it does every time.  I've tried just adding a word in front of whats there and even changing the complete name to a shorter one and it reverts every time I reboot.  Just to check and make sure I'm doing this like you are, I'm opening the Sound Control Panel, highlighting the default playback sound device, right clicking, selecting properties, and changing the name that appears above the "change icon" button, and clicking OK.

Joe


locked Field Day - FT8/FT4

D. Scott MacKenzie
 

All:

 

Modest effort this year – actually the first FD that I have actually been in country for the past 5 years or so.  It was a completely FT4/FT8 effort.  I used WSJT-X, JT-Alert and DXLabs for signal capture and logging.    Using a brick for a processor (I7-4770), Win10, 32Gb Ram and other miscellaneous hardware, I was able to make an all-digital FD without any issues, other than those self-inflicted.   Software worked as advertised without any error or hic-ups.  I was able to make contacts on each band 6M – 80M on either FT4 or FT8.  Everything worked just fine.

 

My results were less than stellar in terms of a body count, but that is the result of crap antennas.  All in all, for the couple of hours that I devoted to FD, it was a digital success.

 

Scott, aka kb0fhp

 


locked Re: Not logging some QSOs to DXKeeper. #DXLAB

Carl - WC4H
 

Hi Laurie.

As per your last instructions, I'm now running both DXKeeper and JTAlerts in debug mode.  Now I have to wait until I get the error again.

73.
Carl - WC4H


locked Re: ACL, JTAlert, and Port 1100

Dave Garber
 

Are you trying to configure a log or the field day log

sent by my LG phone

On Sat, Jun 27, 2020, 12:43 AM W5BT via groups.io, <bwtmlt=icloud.com@groups.io> wrote:
I'm sorry to bother everyone with this question, but after searching the archives I was unable to find a solution. I have been unable to connect to ACL through port 1100 via the local PC setting. I was able to do a work around by utilizing the remote PC function. However I would like to keep that set up for the Field Day and utilize the PC setting for the ACL. I am not trying to run ACL and the Contest Field Day log at the same time. I actually was not able to use the local PC option even before I loaded the Field Day log. For some reason JTAlert is just not able to find the ACL location without utilizing the remote PC function and me entering the location. 
Any suggestions would be appreciated.
Bruce W5BT


locked Re: Grid Alerts ?

HamApps Support (VK3AMA)
 

On 28/06/2020 1:49 am, Al Bailey (K8SIX) wrote:
Laurie I figured out the problem. I should have ANY MODE set instead of FT8. DUH. Thanks for the help though as I created the screenshot and saw my qso with the grid was on CW and it clicked. :)  :)  

Al,

Thanks for reporting back, sadly many don't bother.

I suspected a mode mismatch. Good that it was easy to find.

de Laurie VK3AMA


locked Re: ACL, JTAlert, and Port 1100

HamApps Support (VK3AMA)
 

On 27/06/2020 11:00 pm, W5BT via groups.io wrote:
Here is the screen shot. The port number will not populate or allow manual entry. I've checked the port number on ACL and it is checked and shows 1100.

4E8833D160E74D5C9958D0C5A3EF0C55.png
Bruce W5BT

Bruce,

The local configuration is automatic and doesn't allow for manual entry of values. The log file and port numbers are automatically populated (to avoid users selecting incorrect values) by JTAlert after reading the ACLog configuration file. With no data shown indicates that either JTAlert was unable to locate the ACLog config file in its fixed  (ie not user changeable) location or JTAlert was prevented from reading it.

I suggest a quick reinstall of ACLog to ensure that its config file is in the correct directory.
If your running ACLog elevated (set to run as administrator) that will cause Windows to prevent JTAlert from reading the ACLog config.

You need to restart JTAlert after any ACLog configuration changes.

If the Local configuration option stills fails to populate, than switch JTAlert to using the Remote configuration which will allow you to populate the 1100 port and select teh ACLog file (make sure you get that correct).

de Laurie VK3AMA


locked Re: Logging to N3FPJ times out no matter the length set

HamApps Support (VK3AMA)
 

On 28/06/2020 11:37 am, WB5JJJ - George wrote:
Restarted EVERYTHING and it still happens right on schedule.  No huge problem, but since everything is logging as expected, I'm moving right on along with FD.  

Did that include a PC restart? That's the only suggestion I have, if all was working normally and now doesn't.

de Laurie VK3AMA


locked Re: JT Alerts Logging to HRD for Field day #HRD

HamApps Support (VK3AMA)
 

On 28/06/2020 2:09 pm, Mike Cooper wrote:
Any Idea why JT Alerts doesnt log the Class and ARRL Section to those field in HRD??

JTAlert has not control over how HRDLogbook interprets the standard adif exchange data sent (SRX_STRING & STX_STRING) in the logging instruction.

The only requirement for JTAlert is that you enable the "Log WSJT-X Contest Exchanges..." option, under the Logging section of the Settings.

In order for JTAlert to log exchanges, that data must be sent by WSJT-X and that requires WSJT-X to be running in Contest mode AND the use of Tab1, NOT Tab2.

de Laurie VK3AMA


locked JT Alerts Logging to HRD for Field day #HRD

Mike Cooper
 

Any Idea why JT Alerts doesnt log the Class and ARRL Section to those field in HRD??


locked Re: Not logging some QSOs to DXKeeper. #DXLAB

HamApps Support (VK3AMA)
 

On 27/06/2020 11:35 pm, Carl - WC4H via groups.io wrote:
Whenever you can do it.  

Many thanks.
Carl - WC4H

Carl,
  • Your JTAlert debug data shows you turned debug recording off @ 13:36:50, with new data being capture starting back @ 14:11:26, ~ 35 minutes of debug data was not captured.


  • From Dave AA6YQ I got the following information
    The errorlog shows the receipt of log directives for QSOs with
    KE0CH at 2020-06-25 13:41:03
    WB9DLC at 2020-06-25 13:43:11
    WW0E at 2020-06-25 13:44:44

    The errorlog does not show DXKeeper receiving a directive to log a QSO with WZ9B.

  • The logging events in question occurred during the period JTAlert debug recording was off, as a result there is nothing for me to examine.

  • However, JTAlert maintains logging activity files for each of the supported loggers, independent of the main debug recording setting. Your DXKeeper activity file shows that the DXK TCP logging instruction being sent for all 4 QSOs, including the WZ9B qso which didn't get logged. The times exactly matching the times seen in the DXK errorlog.
  • The TCP logging instruction for WZ9B was executed by JTAlert and was recorded in the activity file, but it was never received by DXKeeper, Without  the JTAlert debug data, it is impossible to know why it was not received. There may have been a TCP connection issue which would get recorded if debug recording was on.

I will need to get further debug data for another failed logging event. Please repeat the previous exercise and submit a new Support request. I don't think we need to include the DXK errorlog capture for this new test. I'll take the ongoing analysis of your problem off-list when I get your next set of files.

de Laurie VK3AMA


locked Logging to N3FPJ times out no matter the length set

WB5JJJ - George
 

About 7 hours into the FD contest, N3FPJ via JTA generates an error stating it could not confirm the contact was logged.  When in fact, IT WAS LOGGED.  Rechecked all the LOGGING settings and nothing has changed, but re-selected the log file and log type on AC Log sub topic just to be sure.  

The error pops up exactly at the 11 second mark.  This all started with about 120 contacts logged.  

Restarted EVERYTHING and it still happens right on schedule.  No huge problem, but since everything is logging as expected, I'm moving right on along with FD.  

-
73's
George - WB5JJJ


locked Re: Sound file with the Kiwi accent?

HamApps Support (VK3AMA)
 

On 27/06/2020 9:44 pm, Timothy Brannon wrote:
In preparation for Field Day I updated WSJT-X and JTAlert to the latest versions, including the sound files.
But now I miss the girl with the distinctly Kiwi accent saying "Calling you"!  
I tried switching to the Australian sound file, but she sounds pretty American to me.
LOL, any way to bring the Kiwi girl back?
73 de Tim, WA5MD in Dallas

Attached.

Extract the .wav file and save it any where ever like, then use the sound Select button of the "Own Call" alert and navigate to and select this new file.

de Laurie VK3AMA


locked Re: Worked B4 list rebuild

HamApps Support (VK3AMA)
 

On 28/06/2020 7:00 am, Dan Osborne wrote:
Hi Laurie -
To be clear, does JTAlert rebuild the worked B4 list from the specified log file
every time the application is started ????

Would not use WSJT-X without JTAlert - thanks for all your efforts !

W5AFY

Dan,

To be clear, there is no worked B4 list to rebuild, sort-of.

JTAlert does maintain an in-memory cache of the Worked B4 statuses, but that is empty when JTAlert is started. This cache is dynamically updated with the B4 status of Callsigns when they are first decoded, with their B4 status determined by a one-time log lookup.

de Laurie VK3AMA




locked Worked B4 list rebuild

W5AFY Dan EM04id
 

Hi Laurie -
To be clear, does JTAlert rebuild the worked B4 list from the specified log file
every time the application is started ????

Would not use WSJT-X without JTAlert - thanks for all your efforts !

W5AFY


locked Re: JTAlert 2.16.8

Joe Roper
 

I wholeheartedly agree with Larry W0OGH, digital wouldn't be near as much fun without your tireless efforts Laurie!

Joe
N7IHB


locked Re: ACL, JTAlert, and Port 1100

Art N2AJO
 

Bruce

Uncheck the port number in acl. Manually type in a different port number. Doesn’t matter the number as I selected 2247. Recheck the box. Restart ACL. Verify the port number is what you set. Then start JTAlert it will read the ACL file and apply the port number you set in ACL

Art N2AJO 


On Jun 27, 2020, at 9:00 AM, W5BT via groups.io <bwtmlt@...> wrote:

Here is the screen shot. The port number will not populate or allow manual entry. I've checked the port number on ACL and it is checked and shows 1100.

<dummyfile.0.part>

Bruce W5BT


locked Re: JTAlert 2.16.8

Lawrence Godek
 

Your doing great.  We wouldn't be having this much fun without your skills and time.  Gl OM.

Larry W0OGH

On 6/26/2020 7:42 PM, HamApps Support (VK3AMA) wrote:
On 27/06/2020 3:36 am, Lawrence Godek wrote:
I find I get no constant flow of decodes on each receive cycle with this version in the decodes window. I am using it with WSJT-X v2.2.1.  If I go back to  JTAlert 2.16.7 it works as it should.
Larry/w0ogh 

Larry,

Thanks for the report.

Stay with 2.16.7 until I have been able to determine why 2.16.8 is unreliable for a small number of users. The changes made in 2.16.8 were made to address the small number of users of 2.16.7 that were experiencing problems. I can't win!

de Laurie VK3AMA

6801 - 6820 of 37312