Date   
Re: Problem in logging with duplicates

Bob
 

Huh? First, let's try to figure out where the 10K QSOs in your logbook - Did you import them from somewhere, or enter them in real-time logging in Logger32? Then, please explain what your interpretation of duplicate QSOs is. More than one QSO with a station on different bands/modes/times? A few pictures, of what you're seeing may help. SeventyThree(s).

On August 27, 2019 at 6:37 PM larry fields <n6hpx1@...> wrote:

   Problems with my Ham log is when I go through it I found many mistakes I never added. For example I add a VK6? or HL1? and when I do the dxcc it will show where I also worked the same station in duplicate forms, or on frequency's I never did. Many are 6 in a row. I have to go through it manually and remove some. My log is over 10,000 and last count I got 10,550. I I remove some it drops it down around 200 mistakes. 

  Anyone else have this problem.

Problem in logging with duplicates

larry fields
 

   Problems with my Ham log is when I go through it I found many mistakes I never added. For example I add a VK6? or HL1? and when I do the dxcc it will show where I also worked the same station in duplicate forms, or on frequency's I never did. Many are 6 in a row. I have to go through it manually and remove some. My log is over 10,000 and last count I got 10,550. I I remove some it drops it down around 200 mistakes. 

  Anyone else have this problem.

Re: rotor problem

Bob
 

Olivier, que vois-tu? 73.

On August 25, 2019 at 6:09 PM Bob <k4cy@...> wrote:

Olivier, mon vieux, I think what you are seeing is because when you click on the UDP BandMap the callsign is loaded into the Logbook Entry Window and the beam heading is calculated based on the callsign. The antenna starts to turn. After maybe one or two seconds the lookup of the callsign adds additional data to the Logbook Entry Window - Maybe a US State or County, maybe a gridsquare. The beam heading is recalculated based on this new information ... What does the rotor do? Experiment with this ... on the Rotator setup Window (at the bottom) are options to delay the start of turning the beam ... For example, if you delay 3 seconds (maybe two, or one), them hopefully the additional data from the callsign lookup has populated the Logbook Entry Window and the calculations will be correct the first time the rotor is turned. Avoir du sens? SeventyThree(s).

On August 25, 2019 at 5:34 PM Olivier F4FQH <unit365@...> wrote:

Hi Bob,
 
Well will try to explain but next time i will check carefully the problem.
 
I’ve started to use the UDP band plan windows now, to select calls which interest me. In JTDX, it not showing correctly what is made or not, so the UDP windows is nice for this.
Nice also because when we clic a call, the system know when calling after a CQ or 73 from the station we call.
 
Before i clicked only on calls in JTDX and never saw this issue.
 
When i clic a call in the UDP windows, it fill the logbook entry, and turn the rotator in direction of the call QTH clicked. Untill this, it’s ok.
But, during the QSO the rotor move alone. Sometime it move just a bit, some degrees more or less, it seem the rotator not stopped in the good direction the first time. Somtime moving anywhere...
But this not all the time.
I will check this better, and report you a better explanation.
Or if i can i will make video and send you a link to watch it, because it will be big i think.
 
Interesting bug but all is usable, just boring,  that’s why i search on my side before asking something, but as i saw some have nearly the same issue, so i told it.
 
Will investigate a bit more Bob, my problem is i resume work tomorow so the time will be short in next days....
 
73s
 
Olivier
F4FQH
 
From: Bob
Sent: Sunday, August 25, 2019 7:33 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] rotor problem
 

Oliver, please explain. I have no idea what you said. 73.

On August 25, 2019 at 1:27 PM Olivier F4FQH <unit365@...> wrote:

Hi
 
I have the same issue here, rotor is moving alone when the sation is called.
The rotor change direction just a bit
 
73s
Olivier
F4FQH
 
From: Bob
Sent: Sunday, August 25, 2019 4:27 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] rotor problem
 

Jim, please explain what you mean by ... but not when you click on a call in FT8 Where do you click? 73.

On August 25, 2019 at 10:14 AM Jim Cox <jcox123@...> wrote:

Bob, I have the rotator box set ok in the band plan menu for FT8.  Strange behavior as sometimes the rotator will work ok but not when you click on a call in FT8 but will change directions when the station is first called and the xmitter keys..  This is evident also by the rotator debug screen.  All worked fine until a week or so ago when I first noticed this behavior.  Jim K4JAF
 
From: Bob
Sent: Sunday, August 25, 2019 8:55 AM
To: hamlogger@groups.io
Subject: Re: [hamlogger] rotor problem
 

Click TOOLS | SETUP BANDS & MODES. You are now looking at your personalized BandPlan. Look at the FT4 and FT8 rows ... All the way over to the next to last column is where the Rotor # goes. No number = no rotor. So, when operating FT4 or FT8 the frequency changes to the appropriate row in the table. No number = no rotor.  SeventyThree(s).

On August 25, 2019 at 9:41 AM Jim Cox <jcox123@...> wrote:

I have been having this problem with the rotator --- not sure when it started, most of the time it will not work when going to JTDX but works fine outside of the program.  I can look at the rotator debug screen and no command is sent to the rotator itself from Logger32.  Again when a station is just selected from the spots screen within Logger32 it works FB.  Any ideas.  73s Jim K4JAF


 


 


 


 


 


 


 

Re: Fw: CQWPX statistics

Bob
 

Carlo, what other settings must I try? I used MIXED MODE, ALL OPERATORS. ALL QSLS. ALL CREDITS. Maybe make an ADIF file of your logbook and send it to me for testing? 73.

On August 27, 2019 at 12:53 PM Carlo Larosi <iz3etugm@...> wrote:

You are lucky Bob.
73
Carlo
 
From: Bob
Sent: Tuesday, August 27, 2019 6:46 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Fw: CQWPX statistics
 

Carlo, I do not see this. For me the listing is in alphabetical order, and the numbers are the same.

 

This is from 3.50.391:


 

This is from 3.50.393:


 

73.

On August 27, 2019 at 10:52 AM Carlo Larosi <iz3etugm@...> wrote:

 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:37 PM
To: hamlogger@groups.io
Subject: Fw: CQWPX statistics
 
 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:22 PM
To: hamlogger@groups.io
Subject: Fw: CQWPX statistics
 
 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:17 PM
To: hamlogger@groups.io
Subject: CQWPX statistics
 
Ciao to everybody
I have troubles with CQWPX statistics. Different values each version. Values of version .391 are correct.
Recalculated statistics every different version. PXF on .393 are not in alfabetical order and some cell takes the submitted color for a different situation (also empty).
In this situation the appearance of wpx not worked can be wrong.
73 de
Carlo IZ3ETU


 


 


 


 

Re: Changes in subdivision info problem

Serge Bykovsky
 

Bob.

It will be good.

Anyway..still no link from you yet.

Serge


Вы писали 27 августа 2019 г., 17:15:18:


Serge, I have spent many hours looking for the problem, and I can not reproduce it. I even loaded the Russian language pack on the PC but could not reproduce the problem. Because the PC was now all Russian, I couldn't read the menus to put it back to English ... another two hours wasted. Here's the plan - I have added additional error checking in the area where the modified CNTY field is written to the logbook. Hopefully the new code will point me to the error.  I will eMail you a download link where you can get a new Logger32.exe to test. To enable the additional error checking, please do this: Click the VIEW menu and check the ENABLE ERROR TRAPPING option. 73.
Re: Changes in subdivision info problem On August 27, 2019 at 12:45 AM "Serge Bykovsky via Groups.Io" <datatelecom@...> wrote:



All the same with all other countries. Bob.

I tried German and US callsigns. 13 mismatch.

Back to .391 - perfect work.

Thank you,

Serge Ra6ydx




Cyrillic characters? This is not what I see in the ADIF specification (look at http://www.adif.org/310/ADIF_310.htm#Primary_Administrative_Subdivision for Country 054). Please send me a CSV file (by direct eMail) of your Secondary Admin file for Eu Russia, so that I can experiment. SeventyThree(s).

On August 26, 2019 at 5:41 PM "Serge Bykovsky via Groups.Io" <datatelecom@...> wrote:

--
С уважением,
Datatelecom

Re: Fw: CQWPX statistics

Carlo Larosi
 

You are lucky Bob.
73
Carlo
 

From: Bob
Sent: Tuesday, August 27, 2019 6:46 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Fw: CQWPX statistics
 

Carlo, I do not see this. For me the listing is in alphabetical order, and the numbers are the same.

 

This is from 3.50.391:


 

This is from 3.50.393:


 

73.

On August 27, 2019 at 10:52 AM Carlo Larosi <iz3etugm@...> wrote:

 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:37 PM
To: hamlogger@groups.io
Subject: Fw: CQWPX statistics
 
 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:22 PM
To: hamlogger@groups.io
Subject: Fw: CQWPX statistics
 
 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:17 PM
To: hamlogger@groups.io
Subject: CQWPX statistics
 
Ciao to everybody
I have troubles with CQWPX statistics. Different values each version. Values of version .391 are correct.
Recalculated statistics every different version. PXF on .393 are not in alfabetical order and some cell takes the submitted color for a different situation (also empty).
In this situation the appearance of wpx not worked can be wrong.
73 de
Carlo IZ3ETU


 


 

Re: Fw: CQWPX statistics

Bob
 

Carlo, I do not see this. For me the listing is in alphabetical order, and the numbers are the same.


This is from 3.50.391:



This is from 3.50.393:



73.

On August 27, 2019 at 10:52 AM Carlo Larosi <iz3etugm@...> wrote:

 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:37 PM
To: hamlogger@groups.io
Subject: Fw: CQWPX statistics
 
 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:22 PM
To: hamlogger@groups.io
Subject: Fw: CQWPX statistics
 
 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:17 PM
To: hamlogger@groups.io
Subject: CQWPX statistics
 
Ciao to everybody
I have troubles with CQWPX statistics. Different values each version. Values of version .391 are correct.
Recalculated statistics every different version. PXF on .393 are not in alfabetical order and some cell takes the submitted color for a different situation (also empty).
In this situation the appearance of wpx not worked can be wrong.
73 de
Carlo IZ3ETU


 


 

Re: UDP frequency transfer in version .92 and .93

Bob
 

When using WSJT-X or JTDX, the frequency (and mode) in the Logbook Entry Window comes directly from WSJT-X or JTDX. It is not necessary to click on a DX Spot in the UDP BandMap. For example, Today I am using WSJT-X on FT4. The Logbook Entry Window shows 14.080 FT4. On WSJT-X I change mode to FT8. The Logbook Entry Window changes frequency to 14.074 and the mode to FT8. No need to touch anything on Logger32.


On the UDP BandMap click CONFIG and check the option ALLOW WSJT/JTDX TO SET LOGGER32 FREQUENCY/MODE. SeventyThree(s).


On August 27, 2019 at 11:04 AM on6ab <bruno.beckers@...> wrote:

Running FT8, in Logger version .92 and later, when clicking on a callsign in the bandmap, the frequency is not transferred anymore to the Logger32 input window.
If I rollback to version .091, it works again.

UDP frequency transfer in version .92 and .93

on6ab
 

Running FT8, in Logger version .92 and later, when clicking on a callsign in the bandmap, the frequency is not transferred anymore to the Logger32 input window.
If I rollback to version .091, it works again.

Re: Logger32 with Club Log problem ??

Phill Morris (G6EES)
 

Rick

 

Sorry for the late reply. The good news is that everything is now working OK (I think ! )

 

It is very strange because I had previously upgraded and the problem remained. I then deinstalled and reinstalled (and then upgraded again) all the software but the fault remained and the L32LogSync version remained at 1.5.1

So this time I uninstalled everything that was to do with L32LogSync, Logger32, etc and then searched the registry and deleted all entries in the registry to do with Logger32, L32LogSync, eQSL etc (a bit drastic and certainly risky !)

Then I started again with a completely ‘fresh’ installation and now the L32LogSync shows that it is on 2.0.0.5 and it works fine

 

I did initially have a scenario where Logger32 ‘froze’ whenever it tried to upload to ClubLog (confirmed by disabling the ClubLog auto upload and then it didn’t freeze). Although the clublog login had been working when first installed and configured, and the user name and password looked correct, there must have been something wrong with the login credentials stored in L32LogSync as I deleted the credentials, re-entered them and now all is OK – Phew 😊

 

Thanks for your heads up about the software version incompatibility

 

Phill, G6EES

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Rick Ellison
Sent: 23 August 2019 03:14
To: hamlogger@groups.io
Subject: Re: [hamlogger] Logger32 with Club Log problem ??

 

Phill..

Can you send me a screenshot of the program running on your desktop. The reason I ask this and I didn’t notice it this morning looking at your Debug. In L32Logsync I am no longer using the Chilkat Dll file. All of the uploading is done thru hand coded .net call so the debug file should not have any reference to the dll. It’s kinda funny after answering your email this morning I went out fishing and as I was sitting there staring off at the water I had this image of your Debug file pop into my head and it came to me that I’m not even using that dll anymore. So I think you are loading an old version of the program and not the latest. The current .exe file should say on the top caption L32LogSync v2.0.0.5

 

Rick

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of Phill Morris (G6EES)
Sent: Thursday, August 22, 2019 1:37 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Logger32 with Club Log problem ??

 

Here is the file which I should have attached to my post just now :-)

Phill, G6EES

Fw: CQWPX statistics

Carlo Larosi
 

 
 

From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:37 PM
To: hamlogger@groups.io
Subject: Fw: CQWPX statistics
 
 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:22 PM
To: hamlogger@groups.io
Subject: Fw: CQWPX statistics
 
 
 
From: Carlo Larosi
Sent: Tuesday, August 27, 2019 3:17 PM
To: hamlogger@groups.io
Subject: CQWPX statistics
 
Ciao to everybody
I have troubles with CQWPX statistics. Different values each version. Values of version .391 are correct.
Recalculated statistics every different version. PXF on .393 are not in alfabetical order and some cell takes the submitted color for a different situation (also empty).
In this situation the appearance of wpx not worked can be wrong.
73 de
Carlo IZ3ETU

Re: Changes in subdivision info problem

Bob
 

Serge, I have spent many hours looking for the problem, and I can not reproduce it. I even loaded the Russian language pack on the PC but could not reproduce the problem. Because the PC was now all Russian, I couldn't read the menus to put it back to English ... another two hours wasted. Here's the plan - I have added additional error checking in the area where the modified CNTY field is written to the logbook. Hopefully the new code will point me to the error.  I will eMail you a download link where you can get a new Logger32.exe to test. To enable the additional error checking, please do this: Click the VIEW menu and check the ENABLE ERROR TRAPPING option. 73.

Re: Changes in subdivision info problem On August 27, 2019 at 12:45 AM "Serge Bykovsky via Groups.Io" <datatelecom@...> wrote:



All the same with all other countries. Bob.

I tried German and US callsigns. 13 mismatch.

Back to .391 - perfect work.

Thank you,

Serge Ra6ydx




Cyrillic characters? This is not what I see in the ADIF specification (look at http://www.adif.org/310/ADIF_310.htm#Primary_Administrative_Subdivision for Country 054). Please send me a CSV file (by direct eMail) of your Secondary Admin file for Eu Russia, so that I can experiment. SeventyThree(s).
On August 26, 2019 at 5:41 PM "Serge Bykovsky via Groups.Io" <
datatelecom@...> wrote:

--
С уважением,
Datatelecom


 


 

Re: Logger 32 won't start

Ken McVie
 

Hi Bob, I have just this minute started Logger32, & it starts up ok on ver. 393. This was after I managed to get the rollback system to work, & then an auto update came thru which went ahead without a hitch. So I think I'm all good again, & yes I do have those folders in the L32 dir. I tried the 392 one but it didn't work either!! Then I went back to the Rollback system & this time the window showed the different versions to roll back to, & it worked when I chose the last one on the list. Don't ask me why they didn't show when I tried earlier [as the pic I sent shows] but magic happened & it all went ahead ok when I retried it.
Computers -- don't you just love them!!!

73
Ken ZL4NR

On 26/08/2019 9:45 PM, Bob wrote:

Ken, in the Logger32 directory there will be folders like this (picture below) the updates folders are automatically created every time you upgrade. You don't have any? 73.



On August 26, 2019 at 3:57 AM Ken McVie <kenmc@...> wrote:


Hi Bob, I don't have the option of clicking on a ver 3.50.392 !
Attached  is a screen shot of the Rollback dir. when I open the
Logger32Rollback.exe

73
Ken ZL4NR

On 26/08/2019 6:30 PM, Bob wrote:
There is a file in the Logger32 directory called Logger32Rollback.exe. Run it, check the Ver 3.50.392 option, then click Rollback. SeventyThree(s).
>> On August 25, 2019 at 11:52 PM Ken McVie <kenmc@...> wrote:
>>
>>
>> I tried to do the update for Logger 32 today from the website. It didn't
>> work, & I now have a small error window showing --
>>
>> "File Error Loading C:\Logger32\ADIF.TXT
>>            Subscript out of range
>>
>> I initially get a very quick flash of the L32 opening screen, & then
>> this error comes up. If I click on the OK at the bottom of the error
>> window I get a blank L32 screen, with all the icons along the top, but a
>> blank page beneath.
>>
>> I also tried a "Restore Point " on the computer, but that didn't help.
>> Logger 32 has been running without problems for many years, so this is a
>> surprise.
>>
>> Any help Please?
>>
>> 73
>> Ken ZL4NR
>>
>>
>>>



Re: Changes in subdivision info problem

Serge Bykovsky
 



All the same with all other countries. Bob.

I tried German and US callsigns. 13 mismatch.

Back to .391 - perfect work.

Thank you,

Serge Ra6ydx




Cyrillic characters? This is not what I see in the ADIF specification (look at http://www.adif.org/310/ADIF_310.htm#Primary_Administrative_Subdivision for Country 054). Please send me a CSV file (by direct eMail) of your Secondary Admin file for Eu Russia, so that I can experiment. SeventyThree(s).

On August 26, 2019 at 5:41 PM "Serge Bykovsky via Groups.Io" <datatelecom@...> wrote:

--
С уважением,
Datatelecom

Re: Using the Antenna ROTOR with JT modes.

Jim Cox
 

OK, I can duplicate this here just about al the time..  I did not have any of this several weeks ago.   JTDX has worked beautifully for many months before these problems arose..   Again as others have said the rotator function works FB if I clock on a spot from the DX spots screen or if I manually click on the Tracking Window.  73s Jim K4JAF
 

From: Jim Hargrave
Sent: Monday, August 26, 2019 4:59 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Using the Antenna ROTOR with JT modes.
 

Hi Jim,

 

I have not noted that condition. Give me some time to see if I can duplicate.

 

Jim – w5ifp-

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of Jim Cox
Sent: Monday, August 26, 2019 4:30 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Using the Antenna ROTOR with JT modes.

 

I see discrepancies in the actions of the rotator in JTDX here.  Using 2.0.1 rc115.

Scenarios:  1.  I click on spot in UDP map (monitoring with Rotator Debug Screen), nothing happens to rotator, then when xmitter is started because I double click on call in JTDX, the rotator will start to swing to correct position. 

Same as 1. above but nothing ever happens with rotator. 

Same as 1. above but rotator starts as soon as clicking on the spot even before double clicking in JTDX.

Same as 1, but rotator begins movement maybe on second time JTDX tries to call the spotted station. 

 

All of these actions are verified by rotator debug screen. 

 

I have everything apparently correct in band plan for rotator and frequency, mode, etc.  I use a 2 second delay in rotator screen. 

Any thoughts?   Jim K4JAF

 

 

 

From: Jim Hargrave

Sent: Monday, August 26, 2019 12:41 PM

To: hamlogger@groups.io

Subject: [hamlogger] Using the Antenna ROTOR with JT modes.

 

There is a lot of confusion surrounding what should have a simple solution.

 

Given:  The Logger32 Rotor  module does not know about JTDX/WSJT.  All Rotor setup is within Logger32.

 

To avoid more confusion, I will provide a  simple setup process for the rotor.

1)      Configure the Rotor module in Setup/Rotor/Setup rotator #1. Sample below is my setup’

 

Open Rotor port automatically,

Global capture,

3 second delay (for Callsign lookup) May vary, depends on lookup source/Internet connection/speed

 

2)      Tools/Setup bands and Modes: Rotor number is the rotor that is configured under Setup/Rotor #(x)

 

 

 

At this point, verify that the Rotor is operating as expected.

 

3)      Open the UDP port and select

 

Image removed by sender.

 

With the above setup, the following things  happen.

a)      The selected FT program started by UDP selection

b)      Logger32 automatically closes the Logger32 radio port and switches radio control to the JT program.

c)       Logger32  re-opens the radio port when JTDX/wsjt-x is closed

d)      Logger32 maintains full control of the rotor.

 

e)      Callsign is placed in the Log Entry CALL field by any of following methods.

1)      Manual

2)      DX Spot selection

3)      UDP band map selection

4)      Cherry Picker selection

5)      JTDX/wsjt-x

f)       Following is initiated by bLogger32

1)      Callsign lookup in logbook/on-line as user configured.

2)      Bands & Mode chart scanned for Mode/Radio /Rotor options

 

Opening and closing JTDX/wsjt-x is accomplished from within the UDP Bandmap START/STOP options. This keeps all the changeover actions in sync.

 

I hope this helps de-mud the water.

 

Jim – w5ifp-

.

---------- Original Message ----------
From: Jim Cox <jcox123@...>
To: hamlogger@groups.io
Date: August 25, 2019 at 10:14 AM
Subject: Re: [hamlogger] rotor problem

Bob, I have the rotator box set ok in the band plan menu for FT8.  Strange behavior as sometimes the rotator will work ok but not when you click on a call in FT8 but will change directions when the station is first called and the xmitter keys.  This is evident also by the rotator debug screen.  All worked fine until a week or so ago when I first noticed this behavior.  Jim K4JAF

 

From: Bob

Sent: Sunday, August 25, 2019 8:55 AM

To: hamlogger@groups.io

Subject: Re: [hamlogger] rotor problem

 

Click TOOLS | SETUP BANDS & MODES. You are now looking at your personalized BandPlan. Look at the FT4 and FT8 rows ... All the way over to the next to last column is where the Rotor # goes. No number = no rotor. So, when operating FT4 or FT8 the frequency changes to the appropriate row in the table. No number = no rotor.  SeventyThree(s).

On August 25, 2019 at 9:41 AM Jim Cox <jcox123@...> wrote:

I have been having this problem with the rotator --- not sure when it started, most of the time it will not work when going to JTDX but works fine outside of the program.  I can look at the rotator debug screen and no command is sent to the rotator itself from Logger32.  Again when a station is just selected from the spots screen within Logger32 it works FB.  Any ideas.  73s Jim K4JAF


 

Re: Changes in subdivision info problem

Bob
 

Cyrillic characters? This is not what I see in the ADIF specification (look at http://www.adif.org/310/ADIF_310.htm#Primary_Administrative_Subdivision for Country 054). Please send me a CSV file (by direct eMail) of your Secondary Admin file for Eu Russia, so that I can experiment. SeventyThree(s).

On August 26, 2019 at 5:41 PM "Serge Bykovsky via Groups.Io" <datatelecom@...> wrote:






--
С уважением,
Datatelecom

Re: Changes in subdivision info problem

Bob
 

Serge, my last QSO is with a station in NY and the CNTY field is ERIE. I right click on the CNTY field and select EDIT ADMIN SUBDIVISION FIELD. Just for fun, I see another CNTY just below ERIE called ESSEX. I click on ESSEX, click APPLY. The Window closes and the LogbooK Page Window changes to shoe NY and ESSEX. What am I doing wrong? SeventyThree(s).

On August 26, 2019 at 5:32 PM "Serge Bykovsky via Groups.Io" <datatelecom=bk.ru@groups.io> wrote:


Secondary. Bob.

Edit from the logbook. Right click mouse and so on.

Primary or Secondary Administration maintenance? There is no edit
option, there is Add, Delete, and Modify. Which one? Which field
causes the problem? SeventyThree(s).
On August 26, 2019 at 3:26 PM "Serge Bykovsky via Groups.Io" <datatelecom=bk.ru@groups.io> wrote:
Hello,

.392 393 when Edit Admin Subdivision Info - run time 13 error
info: Type mismatch appears. Logger shuts down . However, changing which were
made - is in place.

Thank you,

Serge Ra6ydx


Re: Using the Antenna ROTOR with JT modes.

Jim Hargrave
 

Hi Jim,

 

I have not noted that condition. Give me some time to see if I can duplicate.

 

Jim – w5ifp-

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of Jim Cox
Sent: Monday, August 26, 2019 4:30 PM
To: hamlogger@groups.io
Subject: Re: [hamlogger] Using the Antenna ROTOR with JT modes.

 

I see discrepancies in the actions of the rotator in JTDX here.  Using 2.0.1 rc115.

Scenarios:  1.  I click on spot in UDP map (monitoring with Rotator Debug Screen), nothing happens to rotator, then when xmitter is started because I double click on call in JTDX, the rotator will start to swing to correct position. 

Same as 1. above but nothing ever happens with rotator. 

Same as 1. above but rotator starts as soon as clicking on the spot even before double clicking in JTDX.

Same as 1, but rotator begins movement maybe on second time JTDX tries to call the spotted station. 

 

All of these actions are verified by rotator debug screen. 

 

I have everything apparently correct in band plan for rotator and frequency, mode, etc.  I use a 2 second delay in rotator screen. 

Any thoughts?   Jim K4JAF

 

 

 

From: Jim Hargrave

Sent: Monday, August 26, 2019 12:41 PM

To: hamlogger@groups.io

Subject: [hamlogger] Using the Antenna ROTOR with JT modes.

 

There is a lot of confusion surrounding what should have a simple solution.

 

Given:  The Logger32 Rotor  module does not know about JTDX/WSJT.  All Rotor setup is within Logger32.

 

To avoid more confusion, I will provide a  simple setup process for the rotor.

1)      Configure the Rotor module in Setup/Rotor/Setup rotator #1. Sample below is my setup’

 

Open Rotor port automatically,

Global capture,

3 second delay (for Callsign lookup) May vary, depends on lookup source/Internet connection/speed

 

2)      Tools/Setup bands and Modes: Rotor number is the rotor that is configured under Setup/Rotor #(x)

 

 

 

At this point, verify that the Rotor is operating as expected.

 

3)      Open the UDP port and select

 

Image removed by sender.

 

With the above setup, the following things  happen.

a)      The selected FT program started by UDP selection

b)      Logger32 automatically closes the Logger32 radio port and switches radio control to the JT program.

c)       Logger32  re-opens the radio port when JTDX/wsjt-x is closed

d)      Logger32 maintains full control of the rotor.

 

e)      Callsign is placed in the Log Entry CALL field by any of following methods.

1)      Manual

2)      DX Spot selection

3)      UDP band map selection

4)      Cherry Picker selection

5)      JTDX/wsjt-x

f)       Following is initiated by bLogger32

1)      Callsign lookup in logbook/on-line as user configured.

2)      Bands & Mode chart scanned for Mode/Radio /Rotor options

 

Opening and closing JTDX/wsjt-x is accomplished from within the UDP Bandmap START/STOP options. This keeps all the changeover actions in sync.

 

I hope this helps de-mud the water.

 

Jim – w5ifp-

.

---------- Original Message ----------
From: Jim Cox <jcox123@...>
To: hamlogger@groups.io
Date: August 25, 2019 at 10:14 AM
Subject: Re: [hamlogger] rotor problem

Bob, I have the rotator box set ok in the band plan menu for FT8.  Strange behavior as sometimes the rotator will work ok but not when you click on a call in FT8 but will change directions when the station is first called and the xmitter keys..  This is evident also by the rotator debug screen.  All worked fine until a week or so ago when I first noticed this behavior.  Jim K4JAF

 

From: Bob

Sent: Sunday, August 25, 2019 8:55 AM

To: hamlogger@groups.io

Subject: Re: [hamlogger] rotor problem

 

Click TOOLS | SETUP BANDS & MODES. You are now looking at your personalized BandPlan. Look at the FT4 and FT8 rows ... All the way over to the next to last column is where the Rotor # goes. No number = no rotor. So, when operating FT4 or FT8 the frequency changes to the appropriate row in the table. No number = no rotor.  SeventyThree(s).

On August 25, 2019 at 9:41 AM Jim Cox <jcox123@...> wrote:

I have been having this problem with the rotator --- not sure when it started, most of the time it will not work when going to JTDX but works fine outside of the program.  I can look at the rotator debug screen and no command is sent to the rotator itself from Logger32.  Again when a station is just selected from the spots screen within Logger32 it works FB.  Any ideas.  73s Jim K4JAF


 

Re: Using the Antenna ROTOR with JT modes.

Jim Hargrave
 

Below is a Rotor option that I omitted in my previous e-mail. This is a user option that is also available with JT modes.

This is a desirable option which  reduces operator engagement. This is especially useful when in Cherry picking mode.

 

Right click the “Rotor” box on the lower status bar.

 

 

Note: Excessive use of this function may affect Rotor component reliability.

 

Jim – w5ifp-

 

From: hamlogger@groups.io [mailto:hamlogger@groups.io] On Behalf Of Jim Hargrave
Sent: Monday, August 26, 2019 12:42 PM
To: hamlogger@groups.io
Subject: [hamlogger] Using the Antenna ROTOR with JT modes.

 

There is a lot of confusion surrounding what should have a simple solution.

 

Given:  The Logger32 Rotor  module does not know about JTDX/WSJT.  All Rotor setup is within Logger32.

 

To avoid more confusion, I will provide a  simple setup process for the rotor.

1)      Configure the Rotor module in Setup/Rotor/Setup rotator #1. Sample below is my setup’

 

Open Rotor port automatically,

Global capture,

3 second delay (for Callsign lookup) May vary, depends on lookup source/Internet connection/speed

 

2)      Tools/Setup bands and Modes: Rotor number is the rotor that is configured under Setup/Rotor #(x)

 

 

 

At this point, verify that the Rotor is operating as expected.

 

3)      Open the UDP port and select

 

 

With the above setup, the following things  happen.

a)      The selected FT program started by UDP selection

b)      Logger32 automatically closes the Logger32 radio port and switches radio control to the JT program.

c)       Logger32  re-opens the radio port when JTDX/wsjt-x is closed

d)      Logger32 maintains full control of the rotor.

 

e)      Callsign is placed in the Log Entry CALL field by any of following methods.

1)      Manual

2)      DX Spot selection

3)      UDP band map selection

4)      Cherry Picker selection

5)      JTDX/wsjt-x

f)       Following is initiated by bLogger32

1)      Callsign lookup in logbook/on-line as user configured.

2)      Bands & Mode chart scanned for Mode/Radio /Rotor options

 

Opening and closing JTDX/wsjt-x is accomplished from within the UDP Bandmap START/STOP options. This keeps all the changeover actions in sync.

 

I hope this helps de-mud the water.

 

Jim – w5ifp-

.

---------- Original Message ----------
From: Jim Cox <jcox123@...>
To: hamlogger@groups.io
Date: August 25, 2019 at 10:14 AM
Subject: Re: [hamlogger] rotor problem

Bob, I have the rotator box set ok in the band plan menu for FT8.  Strange behavior as sometimes the rotator will work ok but not when you click on a call in FT8 but will change directions when the station is first called and the xmitter keys..  This is evident also by the rotator debug screen.  All worked fine until a week or so ago when I first noticed this behavior.  Jim K4JAF

 

From: Bob

Sent: Sunday, August 25, 2019 8:55 AM

Subject: Re: [hamlogger] rotor problem

 

Click TOOLS | SETUP BANDS & MODES. You are now looking at your personalized BandPlan. Look at the FT4 and FT8 rows ... All the way over to the next to last column is where the Rotor # goes. No number = no rotor. So, when operating FT4 or FT8 the frequency changes to the appropriate row in the table. No number = no rotor.  SeventyThree(s).

On August 25, 2019 at 9:41 AM Jim Cox <jcox123@...> wrote:

I have been having this problem with the rotator --- not sure when it started, most of the time it will not work when going to JTDX but works fine outside of the program.  I can look at the rotator debug screen and no command is sent to the rotator itself from Logger32.  Again when a station is just selected from the spots screen within Logger32 it works FB.  Any ideas.  73s Jim K4JAF


 

Re: Using the Antenna ROTOR with JT modes.

Jim Cox
 

I see discrepancies in the actions of the rotator in JTDX here.  Using 2.0.1 rc115.
Scenarios:  1.  I click on spot in UDP map (monitoring with Rotator Debug Screen), nothing happens to rotator, then when xmitter is started because I double click on call in JTDX, the rotator will start to swing to correct position. 
Same as 1. above but nothing ever happens with rotator. 
Same as 1. above but rotator starts as soon as clicking on the spot even before double clicking in JTDX.
Same as 1, but rotator begins movement maybe on second time JTDX tries to call the spotted station. 
 
All of these actions are verified by rotator debug screen. 
 
I have everything apparently correct in band plan for rotator and frequency, mode, etc.  I use a 2 second delay in rotator screen. 
Any thoughts?   Jim K4JAF
 
 
 

From: Jim Hargrave
Sent: Monday, August 26, 2019 12:41 PM
To: hamlogger@groups.io
Subject: [hamlogger] Using the Antenna ROTOR with JT modes.
 

There is a lot of confusion surrounding what should have a simple solution.

 

Given:  The Logger32 Rotor  module does not know about JTDX/WSJT.  All Rotor setup is within Logger32.

 

To avoid more confusion, I will provide a  simple setup process for the rotor.

1)      Configure the Rotor module in Setup/Rotor/Setup rotator #1. Sample below is my setup’

 

Open Rotor port automatically,

Global capture,

3 second delay (for Callsign lookup) May vary, depends on lookup source/Internet connection/speed

 

2)      Tools/Setup bands and Modes: Rotor number is the rotor that is configured under Setup/Rotor #(x)

 

 

 

At this point, verify that the Rotor is operating as expected.

 

3)      Open the UDP port and select

 

 

With the above setup, the following things  happen.

a)      The selected FT program started by UDP selection

b)      Logger32 automatically closes the Logger32 radio port and switches radio control to the JT program.

c)       Logger32  re-opens the radio port when JTDX/wsjt-x is closed

d)      Logger32 maintains full control of the rotor.

 

e)      Callsign is placed in the Log Entry CALL field by any of following methods.

1)      Manual

2)      DX Spot selection

3)      UDP band map selection

4)      Cherry Picker selection

5)      JTDX/wsjt-x

f)       Following is initiated by bLogger32

1)      Callsign lookup in logbook/on-line as user configured.

2)      Bands & Mode chart scanned for Mode/Radio /Rotor options

 

Opening and closing JTDX/wsjt-x is accomplished from within the UDP Bandmap START/STOP options. This keeps all the changeover actions in sync.

 

I hope this helps de-mud the water.

 

Jim – w5ifp-

.

---------- Original Message ----------
From: Jim Cox <jcox123@...>
To: hamlogger@groups.io
Date: August 25, 2019 at 10:14 AM
Subject: Re: [hamlogger] rotor problem

Bob, I have the rotator box set ok in the band plan menu for FT8.  Strange behavior as sometimes the rotator will work ok but not when you click on a call in FT8 but will change directions when the station is first called and the xmitter keys..  This is evident also by the rotator debug screen.  All worked fine until a week or so ago when I first noticed this behavior.  Jim K4JAF

 

From: Bob

Sent: Sunday, August 25, 2019 8:55 AM

To: hamlogger@groups.io

Subject: Re: [hamlogger] rotor problem

 

Click TOOLS | SETUP BANDS & MODES. You are now looking at your personalized BandPlan. Look at the FT4 and FT8 rows ... All the way over to the next to last column is where the Rotor # goes. No number = no rotor. So, when operating FT4 or FT8 the frequency changes to the appropriate row in the table. No number = no rotor.  SeventyThree(s).

On August 25, 2019 at 9:41 AM Jim Cox <jcox123@...> wrote:

I have been having this problem with the rotator --- not sure when it started, most of the time it will not work when going to JTDX but works fine outside of the program.  I can look at the rotator debug screen and no command is sent to the rotator itself from Logger32.  Again when a station is just selected from the spots screen within Logger32 it works FB.  Any ideas.  73s Jim K4JAF