Date   

DX Spots (Window)

Paul Scarratt
 

Hi Guys,

I hope this makes sense, I'm trying to adjust the fonts and especially the colour of the font in the DX Spots window,

I can change the font size etc but the colour does not change but it does on the Logbook page !

I'm going to VIEW=GRID APPEARENCE=GRIDS FONT/COLOUR or is the settings for this somewhere else?

Running Windows 10 Logger32 v4.0.238 

Regards Paul G0WRE


Re: Secondary Admin Award problem

Bob
 

Pepe, right click on the callsign field of the logbook entry window. Click on SETUP | SETUP QSO MASK. The window that opens shows all the fields that are copied from previous QSOs to new QSOs. UNcheck the secondary admin field (it shows the name of the field in the logbook entry window). UN check the field at the top and bottom of the window. Click APPLY. 
 
SeventyThree(s).

On 01/30/2021 11:22 AM José L. Oliva - EA4ZQ <joseluis.oliva@...> wrote:
 
 
Spanish L32 group has created a secondary admin award file, called DVGE (Geodesic Points of Spain). It's a nice diplom with about 2000 references, most of them in countryside and mountains. (Not as sota, but funny, hi, hi...)
I had some stations that activated several places but, when I fill Subdivision Admin window with one reference. L32 changes all other references with same callsign.  ??
 
I put EC7AT/P with ref CO-002
I put EC7AT/P with ref CO-004 and changes all award references from EC7AT/P as CO-004
 
I don't know if there is a "multiple locations" option or is a bug, or anything else.
Other users said all is right, then problem is mine, but I don't know where....

Thanks.
Pepe EA4ZQ


Secondary Admin Award problem

José L. Oliva - EA4ZQ
 

Spanish L32 group has created a secondary admin award file, called DVGE (Geodesic Points of Spain). It's a nice diplom with about 2000 references, most of them in countryside and mountains. (Not as sota, but funny, hi, hi...)
I had some stations that activated several places but, when I fill Subdivision Admin window with one reference. L32 changes all other references with same callsign.  ??
 
I put EC7AT/P with ref CO-002
I put EC7AT/P with ref CO-004 and changes all award references from EC7AT/P as CO-004
 
I don't know if there is a "multiple locations" option or is a bug, or anything else.
Other users said all is right, then problem is mine, but I don't know where....

Thanks.
Pepe EA4ZQ


Re: Cluster issue

chrisgd6twf
 

Bob,

Good point about all spots. If I can get them all working I can then just filter in Logger 32 to suit

Chris


Re: Error every now and again

Paul Scarratt
 

Ok Bob I’ll keep the group informed after any updates in the future.

Dah-di-Dah

Paul G0WRE


Re: Error every now and again

Bob
 

The error is generated after a full backup is completed and Logger32 is in the process of re-numbering the backup files _001, _002, _003, etc. It appears (I can't duplicate the error here) that there is some timing problem looping through the files. I have made a code change for the next auto-update. I have no idea if it will help or not. 73.

On 01/29/2021 12:57 PM Paul Scarratt via groups.io <g0wre@...> wrote:
 
 
Hi Guys.

Running Windows 10 and Logger32 v4.0.238 and JTDX v2.2.0-rc155 also LogSync as the upload utility + GridTracker (yes all at the same time on 4 monitors)

Please see below the error message.

I thought it maybe a problem as I boot all external programs up from the Utility setup but without any delays, it works perfect on boot up but this error only occurs during the closing of Logger32.

has anyone got any opinions on this or has a similar problem/fix.

Been getting this error only over the last few days and only every now and again.

By the way I have been following developments from Bob and everyone else for many many years of using Logger32 and a big thank you to all.

Regards Paul G0WRE 



Error every now and again

Paul Scarratt
 

Hi Guys.

Running Windows 10 and Logger32 v4.0.238 and JTDX v2.2.0-rc155 also LogSync as the upload utility + GridTracker (yes all at the same time on 4 monitors)

Please see below the error message.

I thought it maybe a problem as I boot all external programs up from the Utility setup but without any delays, it works perfect on boot up but this error only occurs during the closing of Logger32.

has anyone got any opinions on this or has a similar problem/fix.

Been getting this error only over the last few days and only every now and again.

By the way I have been following developments from Bob and everyone else for many many years of using Logger32 and a big thank you to all.

Regards Paul G0WRE 



test

Jan
 

test


File /Secondary Admin data files/DME.csv uploaded #file-notice

hamlogger@groups.io Notification <noreply@...>
 

The following files have been uploaded to the Files area of the hamlogger@groups.io group.

By: ec7akv@...

Description:
Secondary Admin Subdivision Award for EA 29/01/2021 For Diploma Municipios Españoles Tnx Rick EA4M


Re: V4.0.238 - run time error

N3ST
 

Filipe,
If you have have auto-lookup enabled, try disabling it.

Thanks,
Bryan
N3ST

-------- Original Message --------
Subject: Re: [hamlogger] V4.0.238 - run time error
From: "Bob" <k4cy@comcast.net>
Date: Fri, January 29, 2021 8:37 am
To: hamlogger@groups.io


Filipe, I have no idea, I don't even know where to start looking. I need more clues. 73.

On 01/29/2021 4:02 AM Filipe Lopes <ct1ilt@gmail.com> wrote:


Hello,
After updating to V4 I keep having this error bellow, it is not specific to one action but it happens a lot when starting the log or when logging a callsign.

In this example I was logging this qso using the CW macro TU$log$ and the error came up


Anyone else having this issue?

I did not have this before with V3

thanks
FIlipe CT1ILT



Re: V4.0.238 - run time error

Bob
 

 
 
Filipe, I have no idea, I don't even know where to start looking. I need more clues. 73.

On 01/29/2021 4:02 AM Filipe Lopes <ct1ilt@...> wrote:
 
 
Hello,
After updating to V4 I keep having this error bellow, it is not specific to one action but it happens a lot when starting the log or when logging a callsign.

In this example I was logging this qso using the CW macro TU$log$ and the error came up


Anyone else having this issue?

I did not have this before with V3

thanks
FIlipe CT1ILT


Re: Logger32 go down when telnet to the cluster is ON

Alf. IT9MUO
 

Me too same problem with 2 PCs,
(Desktop and Notebook) both with W10 Pro.
73, Alf. IT9MUO

Il giorno ven 29 gen 2021 alle ore 11:49 Alex Del Chicca <ik5pwj@...> ha scritto:

Hi to all,

Bob I solved the problem .... after having done several tests I found that the WINDOWS 10 PRO operating system had problems

and I installed again on the same machine windows 10 PRO clean and after reinstalling the ver. 3.5 and later, ..... ver. 4.0.238 works perfectly.

 

For all settings .... radio rotor etc. to set it up again I don't think I will have any problems.

 

Thanks again for the work you are doing.

73 Alex ik5pwj

 

Da: hamlogger@groups.io <hamlogger@groups.io> Per conto di Alex Del Chicca via groups.io
Inviato: sabato 23 gennaio 2021 17:24
A: hamlogger@groups.io
Oggetto: [hamlogger] Logger32 go down when telnet to the cluster is ON

 

Hi to ALL,

I upgraded from the latest version 3.5 to version 4.0 without any errors.

After doing database maintenance and updating statistics, I updated to ver. 4.0.235 without problems.

 

The open windows are: Operator :, Dx Spots, Worked / Confirmed Logbook page, Previous QSOs and Telnet for IK5PWJ-6 cluster connection,

I also opened the CW Machine window.

Unfortunately after some time, sometimes 30 min. others after an hour the Logger32 program closes, leaving only the window outside

the Logger32 Window of the CW Machine open.

 

In practice the window of Logger32 disappears.

 

I then made several tests, reinstalling the logger32 vers. 4 from vers. 3.5 where I had previously deleted all the log

and then reinstalled the ik5pwj log from the previously saved adif file.

 

Unfortunately, the problem reoccurred by going the Logger32 program down and always remaining the CW Machine -Software window.

 

At this point I did a test and I disabled the connection via telnet to the cluster no longer receiving the spots both

in the Telnet window and in the DX Spot window.

 

Well .... the Logger32 program ran for hours without closing.

I am sure that the block depends on the right spots that the telnet receives and sends to the DX Spots window,

because if I reactivate the telnet connection and the spots start to arrive again, the program goes down again.

 

What's up ? and how can this problem be eliminated?

 

When I use the same configurations on the latest version of the program vers. 3.5 .... everything works,

including telnet and spot-free spots or whatever.

 

Thanks for any Help

73 Alex ik5pwj.


Re: L32 LogSync

Jeff VE3CV
 

Thanks Rick.  I had done all as you suggested before. Saw the (L32).  I did a check for updates and did the repair install.  Then I checked LOTW setup in L32Synch and found all of my past callsigns but not my Current VE3CV!  How could this have been removed?  Not to worry, all good now.
73
Jeff


Re: Logger32 go down when telnet to the cluster is ON

Alex Del Chicca
 

Hi to all,

Bob I solved the problem .... after having done several tests I found that the WINDOWS 10 PRO operating system had problems

and I installed again on the same machine windows 10 PRO clean and after reinstalling the ver. 3.5 and later, ..... ver. 4.0.238 works perfectly.

 

For all settings .... radio rotor etc. to set it up again I don't think I will have any problems.

 

Thanks again for the work you are doing.

73 Alex ik5pwj

 

Da: hamlogger@groups.io <hamlogger@groups.io> Per conto di Alex Del Chicca via groups.io
Inviato: sabato 23 gennaio 2021 17:24
A: hamlogger@groups.io
Oggetto: [hamlogger] Logger32 go down when telnet to the cluster is ON

 

Hi to ALL,

I upgraded from the latest version 3.5 to version 4.0 without any errors.

After doing database maintenance and updating statistics, I updated to ver. 4.0.235 without problems.

 

The open windows are: Operator :, Dx Spots, Worked / Confirmed Logbook page, Previous QSOs and Telnet for IK5PWJ-6 cluster connection,

I also opened the CW Machine window.

Unfortunately after some time, sometimes 30 min. others after an hour the Logger32 program closes, leaving only the window outside

the Logger32 Window of the CW Machine open.

 

In practice the window of Logger32 disappears.

 

I then made several tests, reinstalling the logger32 vers. 4 from vers. 3.5 where I had previously deleted all the log

and then reinstalled the ik5pwj log from the previously saved adif file.

 

Unfortunately, the problem reoccurred by going the Logger32 program down and always remaining the CW Machine -Software window.

 

At this point I did a test and I disabled the connection via telnet to the cluster no longer receiving the spots both

in the Telnet window and in the DX Spot window.

 

Well .... the Logger32 program ran for hours without closing.

I am sure that the block depends on the right spots that the telnet receives and sends to the DX Spots window,

because if I reactivate the telnet connection and the spots start to arrive again, the program goes down again.

 

What's up ? and how can this problem be eliminated?

 

When I use the same configurations on the latest version of the program vers. 3.5 .... everything works,

including telnet and spot-free spots or whatever.

 

Thanks for any Help

73 Alex ik5pwj.


V4.0.238 - run time error

Filipe Lopes
 

Hello,
After updating to V4 I keep having this error bellow, it is not specific to one action but it happens a lot when starting the log or when logging a callsign.

In this example I was logging this qso using the CW macro TU$log$ and the error came up


Anyone else having this issue?

I did not have this before with V3

thanks
FIlipe CT1ILT


Re: Logger 32 V4 and WSJT-X

Philip (G4OBK) Catterall
 

Thanks to Bob K4CY for a personal email with a fix for my issue of the callsign not transferring from the UDP Band Map window to the Log entry call box. 

Bob suggested I open Cherry Picker Options from the Band Map Config and check Cherry pick decoded callsign on next CQ. Now the callsign and the locator transfer from the band map window to the log entry box in L32 every time. . 

73 Phil G4OBK


Re: Logger 32 V4 and WSJT-X

Bob
 

Chris, I still have no idea what the problem is, but we're making progress. Y ou're confusing two very different/separate features/functions -  The JTDX control panel and manual calling.
 
The JTDX control panel is simply to allow the user to change JTDX band and mode and turn off TX Enable remotely (from Logger32). You'll find (I hope) that the JTDX control panel allows the user to click on a FT4/8 DX Spot and JTDX dutifully does what Logger32 tells it to do. You'll even notice that if the DX Spot includes the stations audio frequency JTDX uses that frequency as the RX frequency.
 
Now to Manual calling, here's how it works (in your case, how it is supposed to work). Click on a callsign in the UDP BandMap. Logger32now starts an automatic sequence (no operator intervention) that starts by waiting for the stations next CQ, or 73, or RRR73. When received, Logger32 tells JTDX to reply. If no reply after two calls Logger32 tells JTDX to quit calling and wait for the next opportunity to call again. This sequence is tried 5 times. If no luck after 5 tries, or after 10 minutes of trying, or after 90 seconds on not decoding the station The manual calling sequence picks up it's marbles and goes home to mummy. If/when the station answers a call the manual calling sequence quits and allows JTDX (or WSJT) to complete the contact with no user input.
 
So, what you thought was the manual calling sequence is not.
 
So the actual problem is that when you click on a callsign in the UDP BandMap you are not actually starting the sequence. So back to drawing board. The thing for you to look for is the text appearing in the manual calling event viewer or the colored box being place around the callsign you clicked on in the UDP BandMap. Once that happens, we're in business. I don't want to bother the reflector users further on this problem, so I'll take if offline. And work directly with you.
 
SeventyThree(s).

On 01/28/2021 2:39 PM Philip (G4OBK) Catterall <cq@...> wrote:
 
 

Hi Bob

 

These tests and checks have got me liking JTDX! Extra L32 features over WSJT-X, I could be a late adopter…

 

Opened the manual calling event viewer and when I click a callsign in the JTDX Band Map the event viewer window remains blank – the locator transfers to the log entry window in L32 but the callsign does not. If I initiate a QSO using AUTOTX and enable TX by clicking a callsign in the Receive or Main Control Windows JTDX will call the station and the callsign and locator goes into the log entry window. Nothing goes into the manual calling event window - it remains blank.  I know that the manual event calling window is operating correctly as if I change mode or band in the (excellent new to V4) JTDX Control panel window, the time and change is shown.

 

Whether we can fix this minor issue or not I like using JTDX!

 

73 Phil G4OBK


succesfull update to version 4,0,238

Herman Römer - PA9HR
 

Hi folks,

i just updated to version 4 and everything seems to working smoothly. I am a logger32 user for over 16 years and I am impressed by all the hard work that the logger32-team is putting into it. Thank you very much!

73 Herman Römer - PA9HR


Re: Logger 32 V4 and WSJT-X

Philip (G4OBK) Catterall
 

Hi Bob

 

These tests and checks have got me liking JTDX! Extra L32 features over WSJT-X, I could be a late adopter…

 

Opened the manual calling event viewer and when I click a callsign in the JTDX Band Map the event viewer window remains blank – the locator transfers to the log entry window in L32 but the callsign does not. If I initiate a QSO using AUTOTX and enable TX by clicking a callsign in the Receive or Main Control Windows JTDX will call the station and the callsign and locator goes into the log entry window. Nothing goes into the manual calling event window - it remains blank.  I know that the manual event calling window is operating correctly as if I change mode or band in the (excellent new to V4) JTDX Control panel window, the time and change is shown.

 

Whether we can fix this minor issue or not I like using JTDX!

 

73 Phil G4OBK


Re: Cluster issue

Bob
 

Chris, if I understand you correctly, when you look at the Cluster/Localhost window there are many spots. But only 25% of those appear to be making it to the DX Spot window.
 
If I am correct, you have configured an option to block them. Off the top of my head I can think of three places where this is happening.
 
a) The blocking filters setup window. Right click on the DX SPOT window. Click SETUP | DX SPOT BLOCKING/PASS FILTERS. Countless options there.
 
b) If your VE7CC connection in on the Localhost socket, there is an option to filter RBN duplicate spots (and the vast majority of them are duplicates). Right click on the Localhost pane of the Cluster window. Click SETUP LOCALHOST & RBN CONNECTIONS. There are two filter options there. If you change either of them, click APPLY FILTERS.
 
c) On the DX Spot window there is an option where DX Spots that are already visible on the DX Spot window are not simple appended to the bottom of window, but simply overwrite the existing entry. Right click the DX Spot window. Click SETUP | APPEARANCE. Check or UNcheck the option as you like.
 
Editorial note: You might want to seriously consider to NOT have every single DX Spot received from VE7CC populate the DX Spot. It is a  waste of bandwidth, oxygen, and CPU cycles. 
 
SeventyThree(s).

On 01/28/2021 12:48 PM chrisgd6twf <gd6twf@...> wrote:
 
 
I am using the latest version of VE7CC and Logger32 v4.0.235. The issue I have is that only a percentage of the spots are feeding into Logger 32 when I compare the Logger 32 cluster window to the spots on Logger 32. There is no time delay between VE7CC and Logger 32. 

I am receiving spots across all bands but only about 1 in 4 of total spots. 

Thanks
Chris GD6TWF

2361 - 2380 of 84674