Date   
Re: problem closing L32

Bob <k4cy@...>
 

... my apologies, the devil made me do it. I will unsubscribe from the reflector. seventyThree(s)

On February 19, 2020 at 9:26 PM Bob <k4cy@...> wrote:

Still five weeks unil April 1st. We're starting early this year. SeventyThree(s).
On February 19, 2020 at 9:15 PM alan < zl3kr.alan@...> wrote:


After a recent windows crash and reinstallation of windows 10

I seem to have Logger32 working ok

computer is an I3  windows 10 pro

I use the utility program to load FLdigi and Log Sync and everything
appears o be working ok.

My problem is when I try to exit the program it fails to do so whether i
use the exit command

or click on the X to shut it down and I finish up force closing it. It
doesnt appear to do any harm

as it boots up fine next ime.

Is there something I have missed setting it up again or where would I
look to find

what is causing it.

It is not a major problem as everything seems to be working ok otherwise.

Thanks in advance for any help

Alan  ZL3KR




 

Re: problem closing L32

Bob <k4cy@...>
 

Still five weeks unil April 1st. We're starting early this year. SeventyThree(s).

On February 19, 2020 at 9:15 PM alan < zl3kr.alan@...> wrote:


After a recent windows crash and reinstallation of windows 10

I seem to have Logger32 working ok

computer is an I3  windows 10 pro

I use the utility program to load FLdigi and Log Sync and everything
appears o be working ok.

My problem is when I try to exit the program it fails to do so whether i
use the exit command

or click on the X to shut it down and I finish up force closing it. It
doesnt appear to do any harm

as it boots up fine next ime.

Is there something I have missed setting it up again or where would I
look to find

what is causing it.

It is not a major problem as everything seems to be working ok otherwise.

Thanks in advance for any help

Alan  ZL3KR



problem closing L32

alan
 

After a recent windows crash and reinstallation of windows 10

I seem to have Logger32 working ok

computer is an I3  windows 10 pro

I use the utility program to load FLdigi and Log Sync and everything appears o be working ok.

My problem is when I try to exit the program it fails to do so whether i use the exit command

or click on the X to shut it down and I finish up force closing it. It doesnt appear to do any harm

as it boots up fine next ime.

Is there something I have missed setting it up again or where would I look to find

what is causing it.

It is not a major problem as everything seems to be working ok otherwise.

Thanks in advance for any help

Alan  ZL3KR

Re: L32 runtime error

Bob <k4cy@...>
 

Oops, possibly/probably something hosed up in the Logger32.INI. Rename it Logger32.INI.OLD. When you start Logger32, a new one will be created, but without all your personal settings. If this solves your runtime error problem, then I'll tell you how to get you original INI settings back. 73.

On February 19, 2020 at 6:22 PM "Andy M0NKR via Groups.Io" <andrewgoldsmith22=yahoo.co.uk@groups.io> wrote:



For some reason and I don’t know why l32 is experiencing a run time error.

It pops up when I try to load l32 up,
The error is error 13 - type mismatch.

Anyone have any ideas nothing has change setup wise, been stable until now.

Tried a reboot etc no different. Anyone any ideas?

Version 3.50.407

73
Andy
M0NKR




L32 runtime error

Andy M0NKR
 

For some reason and I don’t know why l32 is experiencing a run time error.

It pops up when I try to load l32 up,
The error is error 13 - type mismatch.

Anyone have any ideas nothing has change setup wise, been stable until now.

Tried a reboot etc no different. Anyone any ideas?

Version 3.50.407

73
Andy
M0NKR

Re: 4RE: [hamlogger] L32 and SDR Console

Chuck Miller
 

Bob;
Thanks again for all your help. I did learn a lot about SDRs and logger 32 configuration. I looked at some other loggers to see if they might work. In the end, I made up my mind that if it was a choice between Logger32 and the SDR. I would forego the SDR and stay with Logger32. The only other logger that I sometimes use is N1MM+ for contesting, and then import the ADIF into L32. I really appreciate you taking the time to help me figure this out and while it's working (sort of) I'm going to investigate the SDR Tx/Rx switch. One big advantage to that route would you can check other bands ( what ever your antenna covers) instead of just the one band the radio is on. I think you've got the best general purpose logger going (IMO). I've been with you since the Zakanaka days, and plan to stay.

73 my friend,
Chuck
N0NC

Re: 4RE: [hamlogger] L32 and SDR Console

Bob <k4cy@...>
 

Chuck, OK I think. I had to Google FT-1000 IF tap. If it were me, I'd simply connect the SDR to an antenna using an SDR Tx/Rx switch (I have read reports they provide in the order of 90dB isolation). Anyway, we're done, the bug is fixed. Enjoy. SeventyThree(s).

On February 18, 2020 at 4:25 PM Chuck Miller <cwmiller20@...> wrote:

Well, while that did fix the problem with the erratic frequency, it turns out that since I am using a "IF" tap from the Yaesu, Omni-Rig has to talk directly to the FT-1000mp or it doesn't get any RF at the rigs frequency. So it turned perfectly, but nothing to display because with out using Omni-rig, the radio was listening on 70.455000 Mhz ( the if freq from the Yaesu). I think I'm going to investigate using the rx antenna jack on to 1000, effectively connecting the SDR straight to the antenna which I think will then work the way Rick's installation does.

Thanks for all your help Bob
73, Chuck
N0NC

 

Re: 4RE: [hamlogger] L32 and SDR Console

Chuck Miller
 

Well, while that did fix the problem with the erratic frequency, it turns out that since I am using a "IF" tap from the Yaesu, Omni-Rig has to talk directly to the FT-1000mp or it doesn't get any RF at the rigs frequency. So it turned perfectly, but nothing to display because with out using Omni-rig, the radio was listening on 70.455000 Mhz ( the if freq from the Yaesu). I think I'm going to investigate using the rx antenna jack on to 1000, effectively connecting the SDR straight to the antenna which I think will then work the way Rick's installation does.

Thanks for all your help Bob
73, Chuck
N0NC

Re: 4RE: [hamlogger] L32 and SDR Console

Bob <k4cy@...>
 

But wait, yesterday configuration was just a simple Yaesu on the CAT port and SDR connected to the Slave port. Because the messages to the SDR where incorrectly formatted, the SDR did not QSY correctly. The problem (now fixed) was caused by older Yaesu radios giving a frequency that often had more than three decimal points. So, why is it necessary to change the configuration from yesterday?  73.

On February 18, 2020 at 4:03 PM Chuck Miller <cwmiller20@...> wrote:

Well I've finally got it to work by connecting it backwards. I can't do it the way Rick does, I don't think he uses an if tap. I have one installed in the Yaesu, and SDR-console has to talk directly to the radio through Omnirig. then I set up logger 32 to talk to SDR-console through a virtual port. The only thing I can't get to work are some buttons I programed in the radio control panel to select various filtersect, the commands aren't sent to the Yaesu, but to the sdr. Pretty much everything else works, sound card, cluster etc.

Using an if tap, SDR-Console Must control the transciever through OmniRig or it gets no rf. I think if I had used an external splitter  ( or rx antenna jack method) I could use Ricks method, but since I use an if tap,this is the only way I can get it to work.


 

Re: 4RE: [hamlogger] L32 and SDR Console

Chuck Miller
 

Well I've finally got it to work by connecting it backwards. I can't do it the way Rick does, I don't think he uses an if tap. I have one installed in the Yaesu, and SDR-console has to talk directly to the radio through Omnirig. then I set up logger 32 to talk to SDR-console through a virtual port. The only thing I can't get to work are some buttons I programed in the radio control panel to select various filtersect, the commands aren't sent to the Yaesu, but to the sdr. Pretty much everything else works, sound card, cluster etc.

Using an if tap, SDR-Console Must control the transciever through OmniRig or it gets no rf. I think if I had used an external splitter  ( or rx antenna jack method) I could use Ricks method, but since I use an if tap,this is the only way I can get it to work.

Re: Bad Adi

G4RRM Pete
 

I’m not sure what you mean Ian.

I have never had a download with a wrong call picked up in bad adi, they don’t get sent... to the best of my knowledge...

But these did

73
Pete
G4RRM

On 18 Feb 2020, at 20:27, Ian Morrison <imorrison@...> wrote:

I have had lotw reports sent to me and the Bad .Adi file says, "not in log" and sure enough the call is not in my log, not the details.
Am I missing the point here?

Ian

Sent from my mobile phone


-------- Original Message --------
Subject: [hamlogger] Bad Adi
From: G4RRM Pete
To: Logger32
CC:


Or am I wrong?

73
Pete
G4RRM

Begin forwarded message:

From: Peter Walker <pete@...>
Date: 18 February 2020 at 19:28:12 GMT
To: "hamlogger@groups.io" <hamlogger@groups.io>
Subject: Re:  [hamlogger] Bad Adi

 But it doesn’t usually work like this.. you don’t get a qsl if details aren’t  right, I’ve had instances of no matches, change a letter in call and it’s ok you get a qsl 

They have NEVER come with a wrong CALLSIGN before!!!

73
Pete
G4RRM

On 18 Feb 2020, at 19:15, Ian Morrison <imorrison@...> wrote:



I see it this way. Think of QSL cards. I can send you a QSL card even if I never contacted you. I just address it to your call saying we had a qso on such and such a date. You check your log and see that it never happened and discard the card.

LOTW is similar.  I submit a contact with your call, even if it never happened. You download all your ‘apparent’ contacts and check the download against your log. This generates a ‘bad.adi’ file  as  I am not in your log.

 

The only reason you keep getting the call again seems to be because oz3oeu was trying to fix his contacts in LOTW.

 

73, Ian

VE3EP

 

Sent from Mail for Windows 10

 

From: G4RRM Pete
Sent: Tuesday, February 18, 2020 12:10 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Bad Adi

 

I’d really like to know for curiosity why LOTW offers a match when one of the Basic elements of a QSO (Callsign) is wrong?

As I said below, I’ve had no matches before because of a wrong letter and only get a match when amended.

 

Maybe someone on here with far more LOTW knowledge than me can advise.

 

 

73

Pete

G4RRM

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of G4RRM Pete
Sent: 18 February 2020 16:50
To: Logger32 (hamlogger@groups.io)
Subject: [hamlogger] Bad Adi

 

Hi All

 

Almost got to the bottom of the issue.

I emailed the station in question and he kindly responded to my mail, via google translate (so a little bit sketchy), with a brief explanation of what he’s been doing.

 

This is what understand has happened, but not tested so I take it at face value.

 

Apparently, OZ30EU causes some issues when used in FT8.

He has been trying to register OZ3OEU on LOTW with little success, until last night.

 

So, when I check LOTW now as Mike suggested, I can see 3 QSO’s with OZ30EU in 2017 / 18 (all confirmed in LOTW already) matching with my log record.

When I Check OZ3OEU I have 2 QSO’s, they both match identically to the QSOs from 2018 Except for the callsign difference and are not in my Log and QSL’s are dated LAST NIGHT.

 

I guess he has been trying to manipulate his log, for whatever reason, and replaced the old call with the new one.

 

What I still don’t understand is why LOTW would send a match if it see’s Date, Time, Mode, Frequency as correct but with a different callsign?

When I have noticed a NO MATCH in the past because of a wrong letter in the callsign I don’t get the match until I have amended it even if all the other QSO data was correct.

 

Secondly, I have just done another LOTW download and they are still there along with some new matches !!!

 

Thirdly, I expect everyone he’s worked that used LOTW will have the same issue!

 

 

 

I’ll just delete the BAD ADI with those two QSOs and see if they stop in time..

 

 

Still a bit of a puzzler….

 

Thanks to Bob, of course it never was a Logger problem………

 

 

73

Pete

G4RRM

 

 

<55663B234EB24E658541EF18E83D0076.png>

Re: Bad Adi

Ian Morrison
 

I have had lotw reports sent to me and the Bad .Adi file says, "not in log" and sure enough the call is not in my log, not the details.
Am I missing the point here?

Ian

Sent from my mobile phone


-------- Original Message --------
Subject: [hamlogger] Bad Adi
From: G4RRM Pete
To: Logger32
CC:


Or am I wrong?

73
Pete
G4RRM

Begin forwarded message:

From: Peter Walker <pete@...>
Date: 18 February 2020 at 19:28:12 GMT
To: "hamlogger@groups.io" <hamlogger@groups.io>
Subject: Re:  [hamlogger] Bad Adi

 But it doesn’t usually work like this.. you don’t get a qsl if details aren’t  right, I’ve had instances of no matches, change a letter in call and it’s ok you get a qsl 

They have NEVER come with a wrong CALLSIGN before!!!

73
Pete
G4RRM

On 18 Feb 2020, at 19:15, Ian Morrison <imorrison@...> wrote:



I see it this way. Think of QSL cards. I can send you a QSL card even if I never contacted you. I just address it to your call saying we had a qso on such and such a date. You check your log and see that it never happened and discard the card.

LOTW is similar.  I submit a contact with your call, even if it never happened. You download all your ‘apparent’ contacts and check the download against your log. This generates a ‘bad.adi’ file  as  I am not in your log.

 

The only reason you keep getting the call again seems to be because oz3oeu was trying to fix his contacts in LOTW.

 

73, Ian

VE3EP

 

Sent from Mail for Windows 10

 

From: G4RRM Pete
Sent: Tuesday, February 18, 2020 12:10 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Bad Adi

 

I’d really like to know for curiosity why LOTW offers a match when one of the Basic elements of a QSO (Callsign) is wrong?

As I said below, I’ve had no matches before because of a wrong letter and only get a match when amended.

 

Maybe someone on here with far more LOTW knowledge than me can advise.

 

 

73

Pete

G4RRM

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of G4RRM Pete
Sent: 18 February 2020 16:50
To: Logger32 (hamlogger@groups.io)
Subject: [hamlogger] Bad Adi

 

Hi All

 

Almost got to the bottom of the issue.

I emailed the station in question and he kindly responded to my mail, via google translate (so a little bit sketchy), with a brief explanation of what he’s been doing.

 

This is what understand has happened, but not tested so I take it at face value.

 

Apparently, OZ30EU causes some issues when used in FT8.

He has been trying to register OZ3OEU on LOTW with little success, until last night.

 

So, when I check LOTW now as Mike suggested, I can see 3 QSO’s with OZ30EU in 2017 / 18 (all confirmed in LOTW already) matching with my log record.

When I Check OZ3OEU I have 2 QSO’s, they both match identically to the QSOs from 2018 Except for the callsign difference and are not in my Log and QSL’s are dated LAST NIGHT.

 

I guess he has been trying to manipulate his log, for whatever reason, and replaced the old call with the new one.

 

What I still don’t understand is why LOTW would send a match if it see’s Date, Time, Mode, Frequency as correct but with a different callsign?

When I have noticed a NO MATCH in the past because of a wrong letter in the callsign I don’t get the match until I have amended it even if all the other QSO data was correct.

 

Secondly, I have just done another LOTW download and they are still there along with some new matches !!!

 

Thirdly, I expect everyone he’s worked that used LOTW will have the same issue!

 

 

 

I’ll just delete the BAD ADI with those two QSOs and see if they stop in time..

 

 

Still a bit of a puzzler….

 

Thanks to Bob, of course it never was a Logger problem………

 

 

73

Pete

G4RRM

 

 

<55663B234EB24E658541EF18E83D0076.png>

Bad Adi

G4RRM Pete
 

Or am I wrong?

73
Pete
G4RRM

Begin forwarded message:

From: Peter Walker <pete@...>
Date: 18 February 2020 at 19:28:12 GMT
To: "hamlogger@groups.io" <hamlogger@groups.io>
Subject: Re:  [hamlogger] Bad Adi

 But it doesn’t usually work like this.. you don’t get a qsl if details aren’t  right, I’ve had instances of no matches, change a letter in call and it’s ok you get a qsl 

They have NEVER come with a wrong CALLSIGN before!!!

73
Pete
G4RRM

On 18 Feb 2020, at 19:15, Ian Morrison <imorrison@...> wrote:



I see it this way. Think of QSL cards. I can send you a QSL card even if I never contacted you. I just address it to your call saying we had a qso on such and such a date. You check your log and see that it never happened and discard the card.

LOTW is similar.  I submit a contact with your call, even if it never happened. You download all your ‘apparent’ contacts and check the download against your log. This generates a ‘bad.adi’ file  as  I am not in your log.

 

The only reason you keep getting the call again seems to be because oz3oeu was trying to fix his contacts in LOTW.

 

73, Ian

VE3EP

 

Sent from Mail for Windows 10

 

From: G4RRM Pete
Sent: Tuesday, February 18, 2020 12:10 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Bad Adi

 

I’d really like to know for curiosity why LOTW offers a match when one of the Basic elements of a QSO (Callsign) is wrong?

As I said below, I’ve had no matches before because of a wrong letter and only get a match when amended.

 

Maybe someone on here with far more LOTW knowledge than me can advise.

 

 

73

Pete

G4RRM

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of G4RRM Pete
Sent: 18 February 2020 16:50
To: Logger32 (hamlogger@groups.io)
Subject: [hamlogger] Bad Adi

 

Hi All

 

Almost got to the bottom of the issue.

I emailed the station in question and he kindly responded to my mail, via google translate (so a little bit sketchy), with a brief explanation of what he’s been doing.

 

This is what understand has happened, but not tested so I take it at face value.

 

Apparently, OZ30EU causes some issues when used in FT8.

He has been trying to register OZ3OEU on LOTW with little success, until last night.

 

So, when I check LOTW now as Mike suggested, I can see 3 QSO’s with OZ30EU in 2017 / 18 (all confirmed in LOTW already) matching with my log record.

When I Check OZ3OEU I have 2 QSO’s, they both match identically to the QSOs from 2018 Except for the callsign difference and are not in my Log and QSL’s are dated LAST NIGHT.

 

I guess he has been trying to manipulate his log, for whatever reason, and replaced the old call with the new one.

 

What I still don’t understand is why LOTW would send a match if it see’s Date, Time, Mode, Frequency as correct but with a different callsign?

When I have noticed a NO MATCH in the past because of a wrong letter in the callsign I don’t get the match until I have amended it even if all the other QSO data was correct.

 

Secondly, I have just done another LOTW download and they are still there along with some new matches !!!

 

Thirdly, I expect everyone he’s worked that used LOTW will have the same issue!

 

 

 

I’ll just delete the BAD ADI with those two QSOs and see if they stop in time..

 

 

Still a bit of a puzzler….

 

Thanks to Bob, of course it never was a Logger problem………

 

 

73

Pete

G4RRM

 

 

<55663B234EB24E658541EF18E83D0076.png>

Re: Bad Adi

G4RRM Pete
 

But it doesn’t usually work like this.. you don’t get a qsl if details aren’t  right, I’ve had instances of no matches, change a letter in call and it’s ok you get a qsl 

They have NEVER come with a wrong CALLSIGN before!!!

73
Pete
G4RRM

On 18 Feb 2020, at 19:15, Ian Morrison <imorrison@...> wrote:



I see it this way. Think of QSL cards. I can send you a QSL card even if I never contacted you. I just address it to your call saying we had a qso on such and such a date. You check your log and see that it never happened and discard the card.

LOTW is similar.  I submit a contact with your call, even if it never happened. You download all your ‘apparent’ contacts and check the download against your log. This generates a ‘bad.adi’ file  as  I am not in your log.

 

The only reason you keep getting the call again seems to be because oz3oeu was trying to fix his contacts in LOTW.

 

73, Ian

VE3EP

 

Sent from Mail for Windows 10

 

From: G4RRM Pete
Sent: Tuesday, February 18, 2020 12:10 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Bad Adi

 

I’d really like to know for curiosity why LOTW offers a match when one of the Basic elements of a QSO (Callsign) is wrong?

As I said below, I’ve had no matches before because of a wrong letter and only get a match when amended.

 

Maybe someone on here with far more LOTW knowledge than me can advise.

 

 

73

Pete

G4RRM

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of G4RRM Pete
Sent: 18 February 2020 16:50
To: Logger32 (hamlogger@groups.io)
Subject: [hamlogger] Bad Adi

 

Hi All

 

Almost got to the bottom of the issue.

I emailed the station in question and he kindly responded to my mail, via google translate (so a little bit sketchy), with a brief explanation of what he’s been doing.

 

This is what understand has happened, but not tested so I take it at face value.

 

Apparently, OZ30EU causes some issues when used in FT8.

He has been trying to register OZ3OEU on LOTW with little success, until last night.

 

So, when I check LOTW now as Mike suggested, I can see 3 QSO’s with OZ30EU in 2017 / 18 (all confirmed in LOTW already) matching with my log record.

When I Check OZ3OEU I have 2 QSO’s, they both match identically to the QSOs from 2018 Except for the callsign difference and are not in my Log and QSL’s are dated LAST NIGHT.

 

I guess he has been trying to manipulate his log, for whatever reason, and replaced the old call with the new one.

 

What I still don’t understand is why LOTW would send a match if it see’s Date, Time, Mode, Frequency as correct but with a different callsign?

When I have noticed a NO MATCH in the past because of a wrong letter in the callsign I don’t get the match until I have amended it even if all the other QSO data was correct.

 

Secondly, I have just done another LOTW download and they are still there along with some new matches !!!

 

Thirdly, I expect everyone he’s worked that used LOTW will have the same issue!

 

 

 

I’ll just delete the BAD ADI with those two QSOs and see if they stop in time..

 

 

Still a bit of a puzzler….

 

Thanks to Bob, of course it never was a Logger problem………

 

 

73

Pete

G4RRM

 

 

<55663B234EB24E658541EF18E83D0076.png>

Re: Bad Adi

Ian Morrison
 

I see it this way. Think of QSL cards. I can send you a QSL card even if I never contacted you. I just address it to your call saying we had a qso on such and such a date. You check your log and see that it never happened and discard the card.

LOTW is similar.  I submit a contact with your call, even if it never happened. You download all your ‘apparent’ contacts and check the download against your log. This generates a ‘bad.adi’ file  as  I am not in your log.

 

The only reason you keep getting the call again seems to be because oz3oeu was trying to fix his contacts in LOTW.

 

73, Ian

VE3EP

 

Sent from Mail for Windows 10

 

From: G4RRM Pete
Sent: Tuesday, February 18, 2020 12:10 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Bad Adi

 

I’d really like to know for curiosity why LOTW offers a match when one of the Basic elements of a QSO (Callsign) is wrong?

As I said below, I’ve had no matches before because of a wrong letter and only get a match when amended.

 

Maybe someone on here with far more LOTW knowledge than me can advise.

 

 

73

Pete

G4RRM

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of G4RRM Pete
Sent: 18 February 2020 16:50
To: Logger32 (hamlogger@groups.io)
Subject: [hamlogger] Bad Adi

 

Hi All

 

Almost got to the bottom of the issue.

I emailed the station in question and he kindly responded to my mail, via google translate (so a little bit sketchy), with a brief explanation of what he’s been doing.

 

This is what understand has happened, but not tested so I take it at face value.

 

Apparently, OZ30EU causes some issues when used in FT8.

He has been trying to register OZ3OEU on LOTW with little success, until last night.

 

So, when I check LOTW now as Mike suggested, I can see 3 QSO’s with OZ30EU in 2017 / 18 (all confirmed in LOTW already) matching with my log record.

When I Check OZ3OEU I have 2 QSO’s, they both match identically to the QSOs from 2018 Except for the callsign difference and are not in my Log and QSL’s are dated LAST NIGHT.

 

I guess he has been trying to manipulate his log, for whatever reason, and replaced the old call with the new one.

 

What I still don’t understand is why LOTW would send a match if it see’s Date, Time, Mode, Frequency as correct but with a different callsign?

When I have noticed a NO MATCH in the past because of a wrong letter in the callsign I don’t get the match until I have amended it even if all the other QSO data was correct.

 

Secondly, I have just done another LOTW download and they are still there along with some new matches !!!

 

Thirdly, I expect everyone he’s worked that used LOTW will have the same issue!

 

 

 

I’ll just delete the BAD ADI with those two QSOs and see if they stop in time..

 

 

Still a bit of a puzzler….

 

Thanks to Bob, of course it never was a Logger problem………

 

 

73

Pete

G4RRM

 

 

Re: Bad Adi

G4RRM Pete
 

I’d really like to know for curiosity why LOTW offers a match when one of the Basic elements of a QSO (Callsign) is wrong?

As I said below, I’ve had no matches before because of a wrong letter and only get a match when amended.

 

Maybe someone on here with far more LOTW knowledge than me can advise.

 

 

73

Pete

G4RRM

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of G4RRM Pete
Sent: 18 February 2020 16:50
To: Logger32 (hamlogger@groups.io)
Subject: [hamlogger] Bad Adi

 

Hi All

 

Almost got to the bottom of the issue.

I emailed the station in question and he kindly responded to my mail, via google translate (so a little bit sketchy), with a brief explanation of what he’s been doing.

 

This is what understand has happened, but not tested so I take it at face value.

 

Apparently, OZ30EU causes some issues when used in FT8.

He has been trying to register OZ3OEU on LOTW with little success, until last night.

 

So, when I check LOTW now as Mike suggested, I can see 3 QSO’s with OZ30EU in 2017 / 18 (all confirmed in LOTW already) matching with my log record.

When I Check OZ3OEU I have 2 QSO’s, they both match identically to the QSOs from 2018 Except for the callsign difference and are not in my Log and QSL’s are dated LAST NIGHT.

 

I guess he has been trying to manipulate his log, for whatever reason, and replaced the old call with the new one.

 

What I still don’t understand is why LOTW would send a match if it see’s Date, Time, Mode, Frequency as correct but with a different callsign?

When I have noticed a NO MATCH in the past because of a wrong letter in the callsign I don’t get the match until I have amended it even if all the other QSO data was correct.

 

Secondly, I have just done another LOTW download and they are still there along with some new matches !!!

 

Thirdly, I expect everyone he’s worked that used LOTW will have the same issue!

 

 

 

I’ll just delete the BAD ADI with those two QSOs and see if they stop in time..

 

 

Still a bit of a puzzler….

 

Thanks to Bob, of course it never was a Logger problem………

 

 

73

Pete

G4RRM

 

Bad Adi

G4RRM Pete
 

Hi All

 

Almost got to the bottom of the issue.

I emailed the station in question and he kindly responded to my mail, via google translate (so a little bit sketchy), with a brief explanation of what he’s been doing.

 

This is what understand has happened, but not tested so I take it at face value.

 

Apparently, OZ30EU causes some issues when used in FT8.

He has been trying to register OZ3OEU on LOTW with little success, until last night.

 

So, when I check LOTW now as Mike suggested, I can see 3 QSO’s with OZ30EU in 2017 / 18 (all confirmed in LOTW already) matching with my log record.

When I Check OZ3OEU I have 2 QSO’s, they both match identically to the QSOs from 2018 Except for the callsign difference and are not in my Log and QSL’s are dated LAST NIGHT.

 

I guess he has been trying to manipulate his log, for whatever reason, and replaced the old call with the new one.

 

What I still don’t understand is why LOTW would send a match if it see’s Date, Time, Mode, Frequency as correct but with a different callsign?

When I have noticed a NO MATCH in the past because of a wrong letter in the callsign I don’t get the match until I have amended it even if all the other QSO data was correct.

 

Secondly, I have just done another LOTW download and they are still there along with some new matches !!!

 

Thirdly, I expect everyone he’s worked that used LOTW will have the same issue!

 

 

 

I’ll just delete the BAD ADI with those two QSOs and see if they stop in time..

 

 

Still a bit of a puzzler….

 

Thanks to Bob, of course it never was a Logger problem………

 

 

73

Pete

G4RRM

 

Re: Bad ADi

Jim Altman
 

I'll stick my nose in here to say: 1) I rarely see errors or bad matches with LOTW. Usually I can find the cause; and, 2) I like the repetition because I have more than one way to view new matches, i.e. LOTW Look on my Android. I don't want them to go away once read as I still want them there to import into my log. I find the "older" entries fall out after a few days anyway.

73

Jim Altman
jaltman636@...

-----Original Message-----
From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Michael Harris via Groups.Io
Sent: Tuesday, February 18, 2020 10:08 AM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Bad ADi

Pete, to put your mind at rest. I have just downloaded a new lotwreport 18th, which includes a couple of QSOs already matched in a previous file 17th, and those QSOs pop up in a BAD.ADI file that have CNTY errors which I recognised, don't work too many KL7's on FT8 especially only a few days ago. It will be interesting to see if they show again in a day or two.

I now check the log for large gaps of no match, e.g. after uploading a run of 30-40Q. L32 highlight them as uploaded, TQSL says job done you may close the application, however, LoTW has lost them in cyberspace. I do a repeat upload despite protests of duplicates and auto magically LoTW spews out a load of matches. For FT8 I'm running at 86% so missing matches stand out. I'm not the only one to notice this but ARRL say it can't happen.

Regards,

Mike VP8NO

Re: Bad ADi

Michael Harris
 

Pete, to put your mind at rest. I have just downloaded a new lotwreport 18th, which includes a couple of QSOs already matched in a previous file 17th, and those QSOs pop up in a BAD.ADI file that have CNTY errors which I recognised, don't work too many KL7's on FT8 especially only a few days ago. It will be interesting to see if they show again in a day or two.

I now check the log for large gaps of no match, e.g. after uploading a run of 30-40Q. L32 highlight them as uploaded, TQSL says job done you may close the application, however, LoTW has lost them in cyberspace. I do a repeat upload despite protests of duplicates and auto magically LoTW spews out a load of matches. For FT8 I'm running at 86% so missing matches stand out. I'm not the only one to notice this but ARRL say it can't happen.

Regards,

Mike VP8NO

Re: Bad ADi

Michael Harris
 

The other thing to do is go to the LoTW site and click on the "Your QSOs" tab. On the Select QSOs to list form enter either of the call signs causing the confusion into the "Call sign worked" box and see what info comes up. Try both calls.

You should see all the QSO match details.

Regards,

Mike VP8NO

On 18/02/2020 10:45, G4RRM Pete wrote:
Well the bad adi calls are not in log to check, suspect the dates times match the call below, will check later.
His other call OZ30EU in log already have lotw match for those.
But why only flagged yesterday is a mystery when the logged entries where a long time ago and many downloads done.
Sorry for bandwidth Will QRT for a while till home to check
73
Pete
G4RRM