Date   

Re: Export UQF(.asc) file

Bob
 

Aki, born Japanese, or granted citizenship? 73.

On October 14, 2019 at 8:50 PM ja1nlx <ayoshida0205@...> wrote:

Bob

It is true that almost all have Japanese nationality. They are actually Japanese.

73

On 2019/10/15 9:25, Bob wrote:

Ken, I will look at this tomorrow, but while you wait, answer me this question ... I Googled this: How many of the Japanese rugby team are actually Japanese ... Google said this: 




Do you think maybe they're trying to avoid answering the question? SeventyThree(s).


On October 14, 2019 at 7:37 PM Ken JN7FAH <jn7fah@...> wrote:

Bob,

I found bugs in [File] menu, Export Logs/Export UQF(.asc) file.

As shown below, when I chose this menu the box showing 
"Including this end date" isn't the present date. 
UQF_Export01.JPG
Then, I pull down date selection window as shown below, it
is apparent that, in this section, L32 refers the last two digits
of system year for DAY and system day for YEAR.

It is 8:00 in the local time 1 hour behind 2019-10-15 00:00 UTC. 
I think, you know why the present date of L32 is a day before UTC.
UQF_Export02.JPG

Next, the extension of UQF exported file is not .asc, but
it is .uqf as shown below. 
The file name should be "20191014.asc".

UQF_Export05.JPG
 
This function is quite useful to export QSO records of
a certain station.
If possible, let me request to add callsign or country
selection appears in Exporting ADIF(.adi) file section.  
UQF_Export04.JPG

73
Ken JN7FAH
ex JA0RYN, JA0RYN/7, DL/JA0RYN
--
73 de aki
JA1NLX


 


 


Re: Export UQF(.asc) file

Bob
 

Changes made for the next auto-update. UQF? I don't even remember what the acronym stood for.  I think it goes back to 198something when I wrote an Apple II logging program while in Singapore. Some Swedish stations needed an abbreviated export for QSO printing. Now, of course, we have ADIF which has assumed a life of its own. SeventyThree(s).

On October 14, 2019 at 7:37 PM Ken JN7FAH <jn7fah@...> wrote:

Bob,

I found bugs in [File] menu, Export Logs/Export UQF(.asc) file.

As shown below, when I chose this menu the box showing 
"Including this end date" isn't the present date. 
UQF_Export01.JPG
Then, I pull down date selection window as shown below, it
is apparent that, in this section, L32 refers the last two digits
of system year for DAY and system day for YEAR.

It is 8:00 in the local time 1 hour behind 2019-10-15 00:00 UTC. 
I think, you know why the present date of L32 is a day before UTC.
UQF_Export02.JPG

Next, the extension of UQF exported file is not .asc, but
it is .uqf as shown below. 
The file name should be "20191014.asc".

UQF_Export05.JPG
 
This function is quite useful to export QSO records of
a certain station.
If possible, let me request to add callsign or country
selection appears in Exporting ADIF(.adi) file section.  
UQF_Export04.JPG

73
Ken JN7FAH
ex JA0RYN, JA0RYN/7, DL/JA0RYN


Re: Export UQF(.asc) file

Gerry VE6LB
 


Ever been near a Sumo match Bob? Macks NA rugby players look tiny.

73, LB

On 14/10/2019 18:50, ja1nlx wrote:

Bob

It is true that almost all have Japanese nationality. They are actually Japanese.

73

On 2019/10/15 9:25, Bob wrote:

Ken, I will look at this tomorrow, but while you wait, answer me this question ... I Googled this: How many of the Japanese rugby team are actually Japanese ... Google said this: 




Do you think maybe they're trying to avoid answering the question? SeventyThree(s).


On October 14, 2019 at 7:37 PM Ken JN7FAH <jn7fah@...> wrote:

Bob,

I found bugs in [File] menu, Export Logs/Export UQF(.asc) file.

As shown below, when I chose this menu the box showing 
"Including this end date" isn't the present date. 
UQF_Export01.JPG
Then, I pull down date selection window as shown below, it
is apparent that, in this section, L32 refers the last two digits
of system year for DAY and system day for YEAR.

It is 8:00 in the local time 1 hour behind 2019-10-15 00:00 UTC. 
I think, you know why the present date of L32 is a day before UTC.
UQF_Export02.JPG

Next, the extension of UQF exported file is not .asc, but
it is .uqf as shown below. 
The file name should be "20191014.asc".

UQF_Export05.JPG
 
This function is quite useful to export QSO records of
a certain station.
If possible, let me request to add callsign or country
selection appears in Exporting ADIF(.adi) file section.  
UQF_Export04.JPG

73
Ken JN7FAH
ex JA0RYN, JA0RYN/7, DL/JA0RYN
--
73 de aki
JA1NLX
--
73, Gerry VE6LB ve6lb@... ve6lb.ve6hams.com


Re: Export UQF(.asc) file

ja1nlx
 

Bob

It is true that almost all have Japanese nationality. They are actually Japanese.

73

On 2019/10/15 9:25, Bob wrote:

Ken, I will look at this tomorrow, but while you wait, answer me this question ... I Googled this: How many of the Japanese rugby team are actually Japanese ... Google said this: 




Do you think maybe they're trying to avoid answering the question? SeventyThree(s).


On October 14, 2019 at 7:37 PM Ken JN7FAH <jn7fah@...> wrote:

Bob,

I found bugs in [File] menu, Export Logs/Export UQF(.asc) file.

As shown below, when I chose this menu the box showing 
"Including this end date" isn't the present date. 
UQF_Export01.JPG
Then, I pull down date selection window as shown below, it
is apparent that, in this section, L32 refers the last two digits
of system year for DAY and system day for YEAR.

It is 8:00 in the local time 1 hour behind 2019-10-15 00:00 UTC. 
I think, you know why the present date of L32 is a day before UTC.
UQF_Export02.JPG

Next, the extension of UQF exported file is not .asc, but
it is .uqf as shown below. 
The file name should be "20191014.asc".

UQF_Export05.JPG
 
This function is quite useful to export QSO records of
a certain station.
If possible, let me request to add callsign or country
selection appears in Exporting ADIF(.adi) file section.  
UQF_Export04.JPG

73
Ken JN7FAH
ex JA0RYN, JA0RYN/7, DL/JA0RYN
--
73 de aki
JA1NLX


Re: Export UQF(.asc) file

Bob
 

Ken, I will look at this tomorrow, but while you wait, answer me this question ... I Googled this: How many of the Japanese rugby team are actually Japanese ... Google said this: 




Do you think maybe they're trying to avoid answering the question? SeventyThree(s).


On October 14, 2019 at 7:37 PM Ken JN7FAH <jn7fah@...> wrote:

Bob,

I found bugs in [File] menu, Export Logs/Export UQF(.asc) file.

As shown below, when I chose this menu the box showing 
"Including this end date" isn't the present date. 
UQF_Export01.JPG
Then, I pull down date selection window as shown below, it
is apparent that, in this section, L32 refers the last two digits
of system year for DAY and system day for YEAR.

It is 8:00 in the local time 1 hour behind 2019-10-15 00:00 UTC. 
I think, you know why the present date of L32 is a day before UTC.
UQF_Export02.JPG

Next, the extension of UQF exported file is not .asc, but
it is .uqf as shown below. 
The file name should be "20191014.asc".

UQF_Export05.JPG
 
This function is quite useful to export QSO records of
a certain station.
If possible, let me request to add callsign or country
selection appears in Exporting ADIF(.adi) file section.  
UQF_Export04.JPG

73
Ken JN7FAH
ex JA0RYN, JA0RYN/7, DL/JA0RYN


Export UQF(.asc) file

Ken JN7FAH
 

Bob,

I found bugs in [File] menu, Export Logs/Export UQF(.asc) file.

As shown below, when I chose this menu the box showing 
"Including this end date" isn't the present date. 
UQF_Export01.JPG
Then, I pull down date selection window as shown below, it
is apparent that, in this section, L32 refers the last two digits
of system year for DAY and system day for YEAR.

It is 8:00 in the local time 1 hour behind 2019-10-15 00:00 UTC. 
I think, you know why the present date of L32 is a day before UTC.
UQF_Export02.JPG

Next, the extension of UQF exported file is not .asc, but
it is .uqf as shown below. 
The file name should be "20191014.asc".

UQF_Export05.JPG
 
This function is quite useful to export QSO records of
a certain station.
If possible, let me request to add callsign or country
selection appears in Exporting ADIF(.adi) file section.  
UQF_Export04.JPG

73
Ken JN7FAH
ex JA0RYN, JA0RYN/7, DL/JA0RYN


Re: UDP Bandmap Highlight Worked Before

Bob
 

Art, there is a 'Calling me' BandMap. I have never tried/used it, but you may be able to reply to stations that do not show on the BandMap (if it filters stations previously worked) by clicking on the 'Calling me' BandMap. Have fun, and let you mouse do the talking. SeventyThree(s).



On October 12, 2019 at 6:11 PM Art - VE3UTT / W1AJT <W1AJT@...> wrote:

Thanks to those who responded.  I will see if I can bold the "X".  I did not want to "Block Callsigns Worked Before" however, I might re-think that.  I don't call those worked before but I do receive repeat calls and normally QSO them.

Thanks Again,
Art - W1AJT / VE3UTT


Re: UDP Bandmap Highlight Worked Before

Art - VE3UTT / W1AJT
 

Thanks to those who responded.  I will see if I can bold the "X".  I did not want to "Block Callsigns Worked Before" however, I might re-think that.  I don't call those worked before but I do receive repeat calls and normally QSO them.

Thanks Again,
Art - W1AJT / VE3UTT


Re: Problem

Bob
 

Two things - First point, the option to set WSJT/JTDX on-top must be configured. On the UDP BandMap Click START (or STOP). Click SETUP SHORTCUTS. At the bottom of the SETUP START MENUS check START WSJT/JTDX ON-TOP option. Click the APPLY button. If this option is checked, then starting WSJT/JTDX from Logger32 will send the command to WSJT/JTDX to be on-top. Second point, when Logger32 starts WSJT/JTDX (you will notice after four/five seconds that The caption of WSJT/JTDX changes to be WSJT/JTDX & LOGGER32. If/when you see this, you know Logger has successfully started WSJT/JTDX and is able to send commands to the main Window. First it sends a command to change the caption. Second it sends a command to disable the X (top right corner button), and third it sends a command to place the WSJT/JTDX window on-top. If WSJT/JTDX does as it is told, yay! If it doesn't, so sad. SeventyThree(s).

On October 12, 2019 at 1:15 PM Dave Colliau <n8dc-8@comcast.net> wrote:


My friend is running win7 and he says even with the box checked for wsjt-x and jtdx to run on top wsjt-x keeps hiding if he clicks somewhere else in Logger 32.
I have win10 and its fine here ?
Any ideas.
Dave N8DC



Problem

Dave Colliau
 

My friend is running win7 and he says even with the box checked for wsjt-x and jtdx to run on top wsjt-x keeps hiding if he clicks somewhere else in Logger 32.
I have win10 and its fine here ?
Any ideas.
Dave N8DC


Re: Error Message

Colin
 

OK, problem solved, I think.

The offset frequency of 21141.72 was appearing in the logbook page but the band wasn't appearing.   Changing the entry in the Band/Modes table from 21140 -21140 to 21140 - 21142 seems to have solved it.

Thanks for pointing me in the right direction BoB.

73

Colin, G3PSM


On Sat, 12 Oct 2019 at 14:48, Bob <k4cy@...> wrote:

... the error message text should be:

I am about to reset the complex keys in the database and have temporarily lost track of data for your QSO with callsign on band mode 


I see no band in your report. So, Logger32 didn't see 15M in the modified record and decided not to change the QSO as requested. SeventyThree(s).

On October 12, 2019 at 9:20 AM Colin <colin.g3psm@...> wrote:


Hi all,

I have suddenly started getting the following error message, strangely
enough when I started using FT4 on 21140 kHz.   That might be
coincidence though -

"It's my fault, I'm getting old and forgetful

I am about to reset the complex keys in the database and have
temporarily lost track of data for your QSO with (whatever callsign) on FT4.

dbBusy flag is set to false

I have not modified your logbook.   Please try this again."

Thoughts please?

73

Colin, G3PSM



Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#77803): https://groups.io/g/hamlogger/message/77803
Mute This Topic: https://groups.io/mt/34510691/849411
Group Owner: hamlogger+owner@groups.io
Unsubscribe: https://groups.io/g/hamlogger/leave/defanged [k4cy@...]


Re: Error Message

Bob
 

... the error message text should be:

I am about to reset the complex keys in the database and have temporarily lost track of data for your QSO with callsign on band mode 


I see no band in your report. So, Logger32 didn't see 15M in the modified record and decided not to change the QSO as requested. SeventyThree(s).

On October 12, 2019 at 9:20 AM Colin <colin.g3psm@...> wrote:


Hi all,

I have suddenly started getting the following error message, strangely
enough when I started using FT4 on 21140 kHz.   That might be
coincidence though -

"It's my fault, I'm getting old and forgetful

I am about to reset the complex keys in the database and have
temporarily lost track of data for your QSO with (whatever callsign) on FT4.

dbBusy flag is set to false

I have not modified your logbook.   Please try this again."

Thoughts please?

73

Colin, G3PSM



Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#77803): https://groups.io/g/hamlogger/message/77803
Mute This Topic: https://groups.io/mt/34510691/849411
Group Owner: hamlogger+owner@groups.io
Unsubscribe: https://groups.io/g/hamlogger/leave/defanged [k4cy@...]


Re: Error Message

Bob
 

... what were you attempting to do when the error occurred? It looks like you were attempting to modify a previously entered QSO in the Logbook. Before actually making the change, Logger32 checked that there was a callsign, a band, and a mode in the new record it was going to overwrite the existing. One of those three fields was missing. It's probably not a good idea to change the QSO with one of those three missing. Did you try again, and what happened? SeventyThree(s).

On October 12, 2019 at 9:20 AM Colin <colin.g3psm@gmail.com> wrote:


Hi all,

I have suddenly started getting the following error message, strangely
enough when I started using FT4 on 21140 kHz.   That might be
coincidence though -

"It's my fault, I'm getting old and forgetful

I am about to reset the complex keys in the database and have
temporarily lost track of data for your QSO with (whatever callsign) on FT4.

dbBusy flag is set to false

I have not modified your logbook.   Please try this again."

Thoughts please?

73

Colin, G3PSM





Error Message

Colin
 

Hi all,

I have suddenly started getting the following error message, strangely enough when I started using FT4 on 21140 kHz.   That might be coincidence though -

"It's my fault, I'm getting old and forgetful

I am about to reset the complex keys in the database and have temporarily lost track of data for your QSO with (whatever callsign) on FT4.

dbBusy flag is set to false

I have not modified your logbook.   Please try this again."

Thoughts please?

73

Colin, G3PSM


Re: UDP Bandmap Highlight Worked Before

Bob
 

Is there any way to highlight a station worked before in the UDP bandmap other than the "X" that appears next to the call sign?


Yes, click the option SHOW/BLOCK CALLSIGNS WORKED BEFORE. Then check the option BLOCK SELECTED CALLSIGNS QSOD B4. With this combination you only see stations not worked B4. SeventyThree(s).

On October 11, 2019 at 4:57 PM Gary Hinson <Gary@...> wrote:

The bold X works fine for me, Art, coupled with the multicolour highlighting of ‘new ones’ (new DXCCs or grid on this band, new this mode, new this year, ATNOs …), bold text for stations that have been CQing, and the green blobs for LoTW users (or rather, in my case, FOC members).

 

A quick glance down the column tells me that, so far this year, I’ve already worked just 4 of the 20+ stations on 20m FT8 right now …

 

 

… while the absence of coloured highlighting tells me there are no new DXCCs or FOC members to work at the moment, unfortunately.

 

If you are hinting at maybe using coloured highlighting or text to indicate ‘worked before’, that would need fit in with the ‘new DXCC’ indications, which are already quite complex.  Bob has given us loads of useful info already: for me, as a keen DXer, it’s one of the best features of Logger32 to be able to see juicy morsels of DX hiding among the krill.   Or not.

 

73

Gary  ZL2iFB

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Art - VE3UTT / W1AJT
Sent: 12 October 2019 01:12
To: hamlogger@groups.io
Subject: [hamlogger] UDP Bandmap Highlight Worked Before

 

Hello,
Is there any way to highlight a station worked before in the UDP bandmap other than the "X" that appears next to the call sign?  For FT modes it would enable quicker identification of stations worked before.  I know the grids can be highlighted for various characteristics and that works well.

Thanks & 73,
Art - W1AJT / VE3UTT

 



 


 


Re: UDP Bandmap Highlight Worked Before

Gary Hinson
 

The bold X works fine for me, Art, coupled with the multicolour highlighting of ‘new ones’ (new DXCCs or grid on this band, new this mode, new this year, ATNOs …), bold text for stations that have been CQing, and the green blobs for LoTW users (or rather, in my case, FOC members).

 

A quick glance down the column tells me that, so far this year, I’ve already worked just 4 of the 20+ stations on 20m FT8 right now …

 

 

… while the absence of coloured highlighting tells me there are no new DXCCs or FOC members to work at the moment, unfortunately.

 

If you are hinting at maybe using coloured highlighting or text to indicate ‘worked before’, that would need fit in with the ‘new DXCC’ indications, which are already quite complex.  Bob has given us loads of useful info already: for me, as a keen DXer, it’s one of the best features of Logger32 to be able to see juicy morsels of DX hiding among the krill.   Or not.

 

73

Gary  ZL2iFB

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Art - VE3UTT / W1AJT
Sent: 12 October 2019 01:12
To: hamlogger@groups.io
Subject: [hamlogger] UDP Bandmap Highlight Worked Before

 

Hello,
Is there any way to highlight a station worked before in the UDP bandmap other than the "X" that appears next to the call sign?  For FT modes it would enable quicker identification of stations worked before.  I know the grids can be highlighted for various characteristics and that works well.

Thanks & 73,
Art - W1AJT / VE3UTT


UDP Bandmap Highlight Worked Before

Art - VE3UTT / W1AJT
 

Hello,
Is there any way to highlight a station worked before in the UDP bandmap other than the "X" that appears next to the call sign?  For FT modes it would enable quicker identification of stations worked before.  I know the grids can be highlighted for various characteristics and that works well.

Thanks & 73,
Art - W1AJT / VE3UTT


Re: Time sync error

Bob
 

Jim, I connect to ROLEX.USG.EDU. To simulate your report, I changed the address to ROLEX.USG.EDUXX. Now, I see this error




It would appear that your Chernobyl like Error 5 is not caused by simple failure to connect, but by receipt of unexpected data (which I have never seen from USG.EDU). Shooting in the dark, I have added additional error checking to the SNTP code. SeventyThree(s).

On October 10, 2019 at 6:08 AM Jim Altman <jaltman636@...> wrote:

Lately, if you have the ‘set time on udp bandmap open’ ticked, if it fails to get the time, it generates a runtime error 5 and the program crashes.

 

73

 

 

Jim Altman

jaltman636@...

 


 


 


logger problem corrected

larry fields
 

Wish to thank N2AMG for his work last night and help in correcting my logging program. I been trying to correct some problems and kept getting multi boxes of Password/Name not correct. When I attempted to use XML the password was in CAPS vice the other HTTP was not. As a result was where the boxes were coming up.

After 1 1/2 hours we came to the conclusion that the 2 passwords were the problem and once changed it came up each time.

since then I have managed to add 2000 Grids and eliminate other problems.

N2AMG Thanks for the help on this and I am back to normal(or semi normal) 


Time sync error

Jim Altman
 

Lately, if you have the ‘set time on udp bandmap open’ ticked, if it fails to get the time, it generates a runtime error 5 and the program crashes.

 

73

 

 

Jim Altman

jaltman636@...

 

6121 - 6140 of 83916