Topics

locked ACLog shows only (incorrect) 6m freq before logging


Dev Null
 

Hi guys,
 
 
I am running FT8 with WSJT-X v2.1.2 and JTAlert 2.16.1
ACLog version 6.6
Rig - IC-7410
 
I only operate on 20, 17, 15, 10 and 6 meters.
 
Everything works fine. Except - when I call a station, ACLog populates the lower pane with "Call," "Date," "Band," and so on, as it should. Except for some reason, no matter what band I am on, it shows the band as "6" and "Frequency" as "50.3146." Even when I am actually on 6 meters (at 50.313 of course.)
 
 
But then if I actually make a QSO, it shows up in the log just fine with the correct band and all other info.
 
This usually breaks my "needed" and "B4" status over in ACLog, because it always thinks I am on 6.
 
Rig control is disabled in ACLog.
 
Tried changing the only setting I can find in JTAlert that seems like it would have anything to do with this: I toggled "clear ACLog fields prior to logging," a few times, but this did not affect the problem.
 
First of all, I sure can't guess where "50.3146" is coming from. It sure isn't coming from the rig. I am pretty sure this is an ACLog problem, any suggestions? Thanks.
 
 
Larry N8KU


HamApps Support (VK3AMA)
 

On 29/03/2020 9:05 am, Dev Null wrote:
Hi guys,
 
 
I am running FT8 with WSJT-X v2.1.2 and JTAlert 2.16.1
ACLog version 6.6
Rig - IC-7410
 
I only operate on 20, 17, 15, 10 and 6 meters.
 
Everything works fine. Except - when I call a station, ACLog populates the lower pane with "Call," "Date," "Band," and so on, as it should. Except for some reason, no matter what band I am on, it shows the band as "6" and "Frequency" as "50.3146." Even when I am actually on 6 meters (at 50.313 of course.)
 
 
But then if I actually make a QSO, it shows up in the log just fine with the correct band and all other info.
 
This usually breaks my "needed" and "B4" status over in ACLog, because it always thinks I am on 6.
 
Rig control is disabled in ACLog.
 
Tried changing the only setting I can find in JTAlert that seems like it would have anything to do with this: I toggled "clear ACLog fields prior to logging," a few times, but this did not affect the problem.
 
First of all, I sure can't guess where "50.3146" is coming from. It sure isn't coming from the rig. I am pretty sure this is an ACLog problem, any suggestions? Thanks.
 
 
Larry N8KU

With rig control disabled in ACLog, then your only choice is to manually set the Band/Frequency in ACLog whenever you change bands in WSJT-X. How you do that exactly, I don't know, I only use ACLog for testing JTAlert integration.

Provided WSJT-X is correctly reporting the Band/Frequency JTAlert will always log the correct Band/Frequency.

de Laurie VK3AMA


Dev Null
 

Thank you Laurie. I had already been told to "make sure rig control is disabled" by ACLog author, so can I conclude that this problem is just a limitation of ACLog? If so, can you suggest one of the alternative logging programs that would not have this limitation?


Tom NS8K
 

Thank you Laurie. I had already been told to "make sure rig control is disabled" by ACLog author, so can I conclude that this problem is just a limitation of ACLog? If so, can you suggest one of the alternative logging programs that would not have this limitation?
Larry,

A very nice free logging program that integrates well with WSJT-X and JTAlert is Log4OM.  Recently there has been a major re-write of this logger which has really polished it up although Ver 1 worked very well too.  Because the re-write is so new, they are working on bugs in certain areas but from my perspective, nothing that affects what 95% of hams do in a logging program.  You can read about it etc. at log4om.com.  Going to their forum will give you an indication of current reported issues.

Some will probably chime in to help you correct your issue with ACLog.  It has lots of users and is highly regarded too.

Good Luck,

Tom - NS8K


Dave Garber
 

as long as I log after transmit is ended, n3fjp logs fine cat or no cat.    the new norm is to log not the frequency of the radio, but the frequency + HZ addition to it that you were transmitting on.   I dont like, but someone thought it was a better idea..


Dave Garber
VE3WEJ / VE3IE


On Sat, Mar 28, 2020 at 6:58 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 29/03/2020 9:05 am, Dev Null wrote:
Hi guys,
 
 
I am running FT8 with WSJT-X v2.1.2 and JTAlert 2.16.1
ACLog version 6.6
Rig - IC-7410
 
I only operate on 20, 17, 15, 10 and 6 meters.
 
Everything works fine. Except - when I call a station, ACLog populates the lower pane with "Call," "Date," "Band," and so on, as it should. Except for some reason, no matter what band I am on, it shows the band as "6" and "Frequency" as "50.3146." Even when I am actually on 6 meters (at 50.313 of course.)
 
 
But then if I actually make a QSO, it shows up in the log just fine with the correct band and all other info.
 
This usually breaks my "needed" and "B4" status over in ACLog, because it always thinks I am on 6.
 
Rig control is disabled in ACLog.
 
Tried changing the only setting I can find in JTAlert that seems like it would have anything to do with this: I toggled "clear ACLog fields prior to logging," a few times, but this did not affect the problem.
 
First of all, I sure can't guess where "50.3146" is coming from. It sure isn't coming from the rig. I am pretty sure this is an ACLog problem, any suggestions? Thanks.
 
 
Larry N8KU

With rig control disabled in ACLog, then your only choice is to manually set the Band/Frequency in ACLog whenever you change bands in WSJT-X. How you do that exactly, I don't know, I only use ACLog for testing JTAlert integration.

Provided WSJT-X is correctly reporting the Band/Frequency JTAlert will always log the correct Band/Frequency.

de Laurie VK3AMA


Larry Banks
 

Hi Dev (call?),
 
I use ACLog and have no problems at all.  If you would describe your problem, your rig, and your rig interface I’m sure we could help you.  Best to do it on the ACLog reflector.  I highly doubt that the issue is with ACLog.

73 -- Larry -- W1DYJ

 

From: Dev Null
Sent: Sunday, March 29, 2020 5:58
Subject: Re: [HamApps] ACLog shows only (incorrect) 6m freq before logging
 
Thank you Laurie. I had already been told to "make sure rig control is disabled" by ACLog author, so can I conclude that this problem is just a limitation of ACLog? If so, can you suggest one of the alternative logging programs that would not have this limitation?


Dev Null
 

On Sun, Mar 29, 2020 at 12:25 PM, Dave Garber wrote:
as long as I log after transmit is ended, n3fjp logs fine cat or no cat.    the new norm is to log not the frequency of the radio, but the frequency + HZ addition to it that you were transmitting on.   I dont like, but someone thought it was a better idea..
OK. There was a lot more going on than what ACLog was doing or not doing. Mostly having to do with my own lack of understanding JTAlert. Here is the full sequence of events:

I have been running WSJT-X + JTAlert + ACLog for about six months, made a couple hundred contacts over the winter that way. I do remember that I had rig control enabled on both WSJT-X and ACLog at first. That worked for a while, but eventually caused problems, and not a whole lot seemed different after I turned it off in ACLog, Of course, now I know that this is what caused my current concern - "incorrect" frequency/band on the capture window of ACLog. I am lazy, and since it put the correct info in the log, I didn't worry about it until now, because I finally had some time to get to the bottom of it.

The only thing I disliked about this arrangement was that since I was relying on ACLog for B4 status, previous QSO's etc. - that was broken. I must say - the "modular" nature of the three programs I am using, all of which overlap, is actually a big pain. To put it another way, I simply had no idea that the same functionality was in JTAlert. Until today, I just thought of it as a simple utility that lets WSJT-X talk to other software. You will, in fact, see many such reference on line. Little did I know.

So - I decided to give DXkeeper (another) try. I had used it for many years, back in my CW DX days, from around 2005 to 2012. I still have the MDBs from back then, but unfortunately that doesn't get me much without an export. Not really a problem, as LOTW is my real log now.

So I spent about 4 hours today making that change. Everything works. I also now have JTAlert showing some of the information that I was expecting ACLog to handle. My needs are simple -
is it a new one?
Is it a new state on FT8?
Is it a new state on this band on FT8?
Is it a new country on FT8?
Is it a new country on this band with FT8?
And so on.

I actually am still not really answering all those questions the way I would like. Even with this arrangement, the only way I can get some of this is by pretending to call someone. What I really want is for JTAlert to show all that before I transmit. Somehow. It probably can. So I will spend some more time studying JTAlert, which is an awesome program. 

Finally. DXKeeper is overkill for me in my old age. That is why I went to ACLog in the first place. Been using it for FD since the 90's. Scott has a real sense of simplicity, and no unnecessary features. I may go back. In fact, now that I have massaged my log data with DXKeeper, doing a clean install of ACLog and exporting back would be a snap.

All other comments are welcome, thanks guys!

Larry N8KU


WB8ASI Herb
 

You'll like JTAlert.  I have JTA initiating the logging, providing all alerts and alert colors.  Only use WSJTX for the decoding.  Keeps it simple and works great.  Good luck. 73, Herb WB8ASI

On March 29, 2020 at 5:40 PM Dev Null <aptget@...> wrote:

On Sun, Mar 29, 2020 at 12:25 PM, Dave Garber wrote:
as long as I log after transmit is ended, n3fjp logs fine cat or no cat.    the new norm is to log not the frequency of the radio, but the frequency + HZ addition to it that you were transmitting on.   I dont like, but someone thought it was a better idea..
OK. There was a lot more going on than what ACLog was doing or not doing. Mostly having to do with my own lack of understanding JTAlert. Here is the full sequence of events:

I have been running WSJT-X + JTAlert + ACLog for about six months, made a couple hundred contacts over the winter that way. I do remember that I had rig control enabled on both WSJT-X and ACLog at first. That worked for a while, but eventually caused problems, and not a whole lot seemed different after I turned it off in ACLog, Of course, now I know that this is what caused my current concern - "incorrect" frequency/band on the capture window of ACLog. I am lazy, and since it put the correct info in the log, I didn't worry about it until now, because I finally had some time to get to the bottom of it.

The only thing I disliked about this arrangement was that since I was relying on ACLog for B4 status, previous QSO's etc. - that was broken. I must say - the "modular" nature of the three programs I am using, all of which overlap, is actually a big pain. To put it another way, I simply had no idea that the same functionality was in JTAlert. Until today, I just thought of it as a simple utility that lets WSJT-X talk to other software. You will, in fact, see many such reference on line. Little did I know.

So - I decided to give DXkeeper (another) try. I had used it for many years, back in my CW DX days, from around 2005 to 2012. I still have the MDBs from back then, but unfortunately that doesn't get me much without an export. Not really a problem, as LOTW is my real log now.

So I spent about 4 hours today making that change. Everything works. I also now have JTAlert showing some of the information that I was expecting ACLog to handle. My needs are simple -
is it a new one?
Is it a new state on FT8?
Is it a new state on this band on FT8?
Is it a new country on FT8?
Is it a new country on this band with FT8?
And so on.

I actually am still not really answering all those questions the way I would like. Even with this arrangement, the only way I can get some of this is by pretending to call someone. What I really want is for JTAlert to show all that before I transmit. Somehow. It probably can. So I will spend some more time studying JTAlert, which is an awesome program. 

Finally. DXKeeper is overkill for me in my old age. That is why I went to ACLog in the first place. Been using it for FD since the 90's. Scott has a real sense of simplicity, and no unnecessary features. I may go back. In fact, now that I have massaged my log data with DXKeeper, doing a clean install of ACLog and exporting back would be a snap.

All other comments are welcome, thanks guys!

Larry N8KU

 


HamApps Support (VK3AMA)
 

On 30/03/2020 8:40 am, Dev Null wrote:
The only thing I disliked about this arrangement was that since I was relying on ACLog for B4 status, previous QSO's etc. - that was broken.

Simple workaround, two-mouse clicks when you change a Band.

With WSJT-X controlling your radio and Cat control disabled in ACLog, ACLog is not following any Band Changes which is to be expected. When a Callsign is sent to ACLog by JTAlert ACLog does its lookups based on the Band set in ACLog which may not be the operating Band. All you need to do is change the Band in ACLog, a single click on the Band combo box. The actual frequency is not important, only the Band for the ACLog lookup purposes. You just need to get in the habit of changing the Band in ACLog whenever you change the WSJT-X Band. If you forget, no harm as the correct Band/Frequency is always logged as that comes from WSJT-X which is communicating with your rig.

   
Alternatively, you can type the Band number into that field.

de Laurie VK3AMA


Dev Null
 

On Mon, Mar 30, 2020 at 12:26 AM, HamApps Support (VK3AMA) wrote:
Simple workaround, two-mouse clicks when you change a Band.
Actually, the above did NOT apply/work... in reality I had to change both band and frequency - and I still had the problem of B4 status not working.
Just now I updated to 2.16.3 (from 2.16.1) and ALL problems went away, including B4 status!