Date   

Re: Commander interoperability

Dave AA6YQ
 

In the message below, I meant to say "I'm assuming that if there are Commander issues, Bill G4WJS will let me know."

73,

Dave, AA6YQ

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Thursday, September 03, 2015 8:39 PM
To: dxlab@...
Subject: RE: [dxlab] Re: Commander interoperability

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Thursday, September 03, 2015 6:09 PM
To: dxlab@...
Subject: [dxlab] Re: Commander interoperability

One more, perhaps the last, piece of the puzzle - Even when bridge and fldigi are terminated Commander still sends MD3 when there is a wsjt-x TX cursor change.

Stopping and restarting wsjt-x does not clear the MD3 issue.

Stopping Commander and wsjt-x then restarting both does clear the MD3 issue.

I'm assuming that there are Commander issues, Bill G4WJS will let me know.
You should not be simultaneously running two autonomous applications that direct Commander to make transceiver changes.
73,

Dave, AA6YQ



------------------------------------
Posted by: " Dave AA6YQ" <aa6yq@...>
------------------------------------


------------------------------------

Yahoo Groups Links


Re: Commander interoperability

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Thursday, September 03, 2015 6:09 PM
To: dxlab@...
Subject: [dxlab] Re: Commander interoperability

One more, perhaps the last, piece of the puzzle - Even when bridge and fldigi are terminated Commander still sends MD3 when there is a wsjt-x TX cursor change.

Stopping and restarting wsjt-x does not clear the MD3 issue.

Stopping Commander and wsjt-x then restarting both does clear the MD3 issue.

I'm assuming that there are Commander issues, Bill G4WJS will let me know.
You should not be simultaneously running two autonomous applications that direct Commander to make transceiver changes.
73,

Dave, AA6YQ


Re: Managing Multiple Operating Locations

w6de
 

Nice going Dave! Making the best even better.

Regards,
Dave, w6de

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: 03 September, 2015 04:02
To: dxlab@...
Subject: [dxlab] Managing Multiple Operating Locations

Up to now, the subject of "Managing Multiple Operating Locations" was
exclusively covered by this section of DXKeeper's Reference
documentation:

<http://www.dxlabsuite.com/dxkeeper/Help/MultipleQTHs.htm>

While there are no reported gaps, inaccuracies, or ambiguities in this
section, complementing Reference documentation with step-by-step
goal-oriented documentation has been proven helpful for new and long-time
users alike. To that end, there's a new article in "Getting Started with
DXLab" entitled "Managing Multiple Operating Locations":

<http://www.dxlabsuite.com/dxlabwiki/ManageMultipleQTHs>

This article explains the need for "my QTHs", and describes five usage
scenarios:

1. Defining a "my QTH"

2. Logging QSOs from a "my QTH"

3. Importing QSOs made from a "my QTH"

4. Updating Logged QSOs to Reflect the "my QTH" from which they were made

5. Including "my QTH" information on generated QSL cards or labels

This article also links to the articles "Handling Multiple Callsigns and
Operating Locations with LotW, in

<http://www.dxlabsuite.com/dxlabwiki/LotWMultipleCallsignsLocations>

and "Managing Multiple eQSL.cc Accounts with DXKeeper", in

<http://www.dxlabsuite.com/dxlabwiki/ManagingEqslAccounts>

The latter article has been expanded to include sections for

"Uploading QSOs when Nicknames and 'my QTH IDs' are Not Identical"

"Uploading QSOs when Nicknames and 'my QTH IDs' are Identical"

If you have the time to peruse these articles and notice deficiencies of any
kind, please let me know.

73,

Dave, AA6YQ





------------------------------------
Posted by: " Dave AA6YQ" <aa6yq@...>
------------------------------------


------------------------------------

Yahoo Groups Links


Re: ve7cc ?

Richard B Drake
 

I don't know why you are having a problem but I have been connecting to VE7CC every day on port 23.

73, Rich - W3ZJ
http://www.w3zj.com

On 9/3/2015 5:56 PM, 'Anthony W. DePrato' wa4jqs@... [dxlab] wrote:
\
dont think that is it the problem.. been this way for a couple of weeks now. can not connect to ve7cc via S.C. tried all the settings for the node i could find on the net.. both ports  23 and 7300  no luck..
what node settings are you using..?

73 Tony


Re: Commander interoperability

a.durbin@...
 

One more, perhaps the last, piece of the puzzle - Even when bridge and fldigi are terminated Commander still sends MD3 when there is a wsjt-x TX cursor change.

Stopping and restarting wsjt-x does not clear the MD3 issue.

Stopping Commander and wsjt-x then restarting both does clear the MD3 issue.


73,
Andy k3wyc


Re: ve7cc ?

Anthony W. DePrato
 

\
dont think that is it the problem.. been this way for a couple of weeks now. can not connect to ve7cc via S.C. tried all the settings for the node i could find on the net.. both ports  23 and 7300  no luck..
what node settings are you using..?

73 Tony


Anthony W.DePrato WA4JQS since 1962
CQ DX HALL OF FAME # 35
DXCC HONOR ROLL
VP8SSI 3Y0PI VP8BZL V31SS
ZD8JQS WA4JQS/ZS1 WA4JQS/KC4





No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6086 / Virus Database: 4409/10569 - Release Date: 09/03/15

Anthony W.DePrato WA4JQS since 1962
CQ DX HALL OF FAME  # 35
DXCC HONOR ROLL
VP8SSI 3Y0PI VP8BZL V31SS
ZD8JQS WA4JQS/ZS1 WA4JQS/KC4


Re: Commander interoperability

a.durbin@...
 

I was able to isolate why I could not reproduce the problem.

If fldigi is in BPSK mode (any mode other than CW) when started by bridge then MD2 is passed not MD3.

If fldigi is then set to CW mode - MD3 is passed for every wsjt-x TX cursor change

If fldigi mode is changed back to BPSK -  MD3 is still passed for every wsjt-x TX cursor change.


So the summary is that -

With wsjt-x 1.5 running with commander only - MD2 is sent even with MODE=NONE
With wsjt-x 1.5 running with commander and bridge, and with fldigi in CW mode - MD3 is sent even with MODE=NONE.
When flidigi is changed from CW mode to BPSK mode - MD3 is sent even with MODE=NONE.

73,
Andy k3wyc


Re: Commander interoperability

a.durbin@...
 

"He has the option in WSJT-X to not set the rig mode enabled, this means that WSJT-X sends no change mode commands to Commander."


As Bill knows from the screen snapshot I provided, the mode setting was set to "NONE".  It has never been set to anything else.

When Commander is the only DXLab app that is running, the commander CAT traffic log shows that MD2 is sent every time the wsjt-x TX cursor is moved. (this is with wsjt-x MODE = NONE)

I tried various application start sequences to try to isolate which one, or which sequence, caused the CW mode command but was not able to reproduce it this time.

I do have saved logs that show MD3 was being sent by commander for the cases that the TX VFO was being sent to CW mode.

If I should not expect Commander to support bridge and wsjt-x at the same time then no issue, but I'd like to know that is the case.

I'll try to pin down what case results in MD3 being sent instead of MD2.  I think it depends on the order in which apps are started.  I also like to understand why MD2 is being sent when MODE=NONE but that is likely a wsjt-x issue rather than being caused by Commander.


73,
Andy k3wyc


Re: Commander interoperability

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Thursday, September 03, 2015 1:01 PM
To: dxlab@...
Subject: RE: [dxlab] Commander interoperability

I have already communicated with Andy about this issue. He has the option in WSJT-X to not set the rig mode enabled, this means that WSJT-X sends no change mode commands to Commander. Even if it did send a mode set command it would not be to CW, it only has the ability to set USB or DATA-U.

Thanks, Bill!
73,

Dave, AA6YQ


Re: Commander interoperability

g4wjs
 

Hi Dave,

I have already communicated with Andy about this issue. He has the option in WSJT-X to not set the rig mode enabled, this means that WSJT-X sends no change mode commands to Commander. Even if it did send a mode set command it would not be to CW, it only has the ability to set USB or DATA-U.

73
Bill
G4WJS.


Re: Commander interoperability

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Thursday, September 03, 2015 12:07 PM
To: dxlab@...
Subject: [dxlab] Commander interoperability

I use Commander with fldigi bridge and also with wsjt-x. With version 1.3 of wsjt-x I could leave the bridge and fldigi running. With ver 1.5 of wsjt-x, if the bridge is running, my TX VFO is forced from USB mode to CW mode every time wsjt-x communicates with my TS-590S.

Should I expect the bridge and wsjt-x to work correctly when both are connected to Commander or must I always terminate the bridge and fldigi before using wsjt-x ver 1.5?

There are many WSJT-X users here, so you may get an answer to your question, but the WSJT-X support forum might yield a faster response.
73,

Dave, AA6YQ


Re: Major Reason To Use DX Lab

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Thursday, September 03, 2015 9:33 AM
To: dxlab@...
Subject: [dxlab] Re: Major Reason To Use DX Lab

snip<
I tried the club log feature but things got all twisted up (I probably did something wrong) and may look at it again so that I can just use 1 log program.

Step-by-step instructions for uploading QSOs to Club Log are here:
<http://www.dxlabsuite.com/dxlabwiki/ClubLogUpload>

If you need assistance, don't hesitate to ask.
73,

Dave, AA6YQ


Re: MouseWheelControl.ocx error

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Thursday, September 03, 2015 7:50 AM
To: dxlab@...
Subject: Re: [dxlab] MouseWheelControl.ocx error

I like your first solution.

I don't, which is why I didn't employ it in DXKeeper. As I said, it prevents re-reregistration of a component that has become uninstalled.
Is this documented more somewhere? I searched the registry but was unable to find where this setting might be. Or is this a change in the DXKeeper executable code, which I actually would have no idea how to fix?

The behavior is governed by DXKeeper's code, which us not user-modifiable.
My advice is to contact Microsoft Support and identify the root cause of this behavior.
73,

Dave, AA6YQ

On Wed, Sep 2, 2015 at 9:47 PM, ' Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:





>>>AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Wednesday, September 02, 2015 10:26 PM
To: dxlab@...
Subject: Re: [dxlab] MouseWheelControl.ocx error

Dave, sorry about the delay in responding. Life...

1) I disabled Windows Defender using the Local Group Policy Editor per the directions here: http://www.sevenforums.com/tutorials/3652-local-group-policy-editor-open.html
I confirmed that all services related to Windows Defender are stopped.
I confirmed that Malware Bytes related services are stopped.
I confirmed that the Windows Firewall service is stopped.

2) All Windows Startup items are disabled (the Startup tab in the Task Manager shows Status "Disabled" for all entries

The error is still generated when DXKeeper is launched.
Interestingly, the mouse wheel does work in DXKeeper.

This is a curious one. I'd just keep ignoring the error, but it's annoying me now!

>>>I understand.

>>>One alternative would be to modify DXKeeper to remember (in the Windows Registry) that the MouseWheelControl was successfully registered (in your case, while in Safe mode), and not try to register if the "already registered" flag is set. Some DXLab applications still do that, but I stopped using this technique because if a component becomes un-registered, the user must use the Registry Editor to reset the "already registered" flag so that the application will re-register it, or they must use the regsvr32 applications to manually re-register the component.

>>>Yours is the first case in which re-registering an already-registered component is failing. You could contact Microsoft Support, explain that you have an application that invokes an OCX component's DllRegisterServer method, and that this invocation succeeds in Safe mode, but fails in Normal mode. That may be enough information for them to track down the root cause and suggest the necessary changes to settings.

73,

Dave, AA6YQ


Commander interoperability

a.durbin@...
 

I use Commander with fldigi bridge and also with wsjt-x.   With version 1.3 of wsjt-x I could leave the bridge and fldigi running.  With ver 1.5 of wsjt-x, if the bridge is running, my TX VFO is forced from USB mode to CW mode every time wsjt-x communicates with my TS-590S.

Should I expect the bridge and wsjt-x to work correctly when both are connected to Commander or must I always terminate the bridge and fldigi before using wsjt-x ver 1.5?

Thanks and 73,
Andy k3wyc



Re: ve7cc ?

Joe
 

Lee had a MAJOR power failure at his QTH....Major storm effected his whole area....Last heard (yesterday) he was
running on batteries w/a generator.� Generator gave out and he's down.�
Just checked and was able to connect to VE7CC's site Ok.
Joe, KX4JR

On 9/3/2015 10:55, 'Anthony W. DePrato' wa4jqs@... [dxlab] wrote:
�


>just wondering ve7cc stopped working in spot collecter. i have tried
>a couple different node configs.. but only get a winsock error.. all
>other nodes connect and work great..

did i miss something on this node.

love dxlab.. thank you Dave...
73 Tony WA4JQS

Anthony W.DePrato WA4JQS since 1962
CQ DX HALL OF FAME # 35
DXCC HONOR ROLL
VP8SSI 3Y0PI VP8BZL V31SS
ZD8JQS WA4JQS/ZS1 WA4JQS/KC4



Re: ve7cc ?

Richard B Drake
 

When I started up SC this morning one of my 5 spot sources was slow to connect. It may have been VE7CC but they are up and running now with Skimmer/RBN spots coming from them at the usual rate.

73, Rich - W3ZJ
http://www.w3zj.com

On 9/3/2015 10:55 AM, 'Anthony W. DePrato' wa4jqs@... [dxlab] wrote:
>just wondering ve7cc stopped working in spot collecter. i have tried 
>a couple different node configs.. but only get a winsock error.. all 
>other nodes connect and work great..
did i miss something  on this node.

love dxlab.. thank you Dave...
73 Tony WA4JQS


ve7cc ?

Anthony W. DePrato
 

just wondering ve7cc stopped working in spot collecter. i have tried a couple different node configs.. but only get a winsock error.. all other nodes connect and work great..
did i miss something on this node.

love dxlab.. thank you Dave...
73 Tony WA4JQS


Anthony W.DePrato WA4JQS since 1962
CQ DX HALL OF FAME # 35
DXCC HONOR ROLL
VP8SSI 3Y0PI VP8BZL V31SS
ZD8JQS WA4JQS/ZS1 WA4JQS/KC4


Re: Major Reason To Use DX Lab

wd0bfo@...
 

Joe I agree 100% with what you say but the last.  
The backup is a safety consideration so nothing does get lost.
I did the upgrade and it converted everything fine so did not need to import the backup.
I use DXK for logging but I use N3FJP for net logs and club logs.  I tried the club log feature but things got all twisted up (I probably did something wrong) and may look at it again so that I can just use 1 log program.  I like you think the integration is sweet.

73 All, Tom WD0BFO


Major Reason To Use DX Lab

Joe WB9SBD
 

I have for all my Amateur Life when software comes out, I try it. This being said I know what I like, what I do not like, and all that too.
When it comes to logging programs I still have the main three big players, DXK of course and HRD and AC Log of N3FJP.

Now they all do the job of course. I like DXK the best, mainly because of the integration with all the other parts of the suite. Way cool!
Another small Like is the cost IT'S FREAKING FREE!!
Scotts N3FJP has a small cost so not bad.
HRD welll, I won't even go there with that cost!

So Program preference based on cost DKX Wins with N3FJP a second and HRD bringing up the rear.

BUT yesterday,, N3FJP just lost the competition to me 100% it's dead and gone.

I love the way the DXL suite does it's Up-Grades.

N3FJP just came out with an Up-Grade for the AC logger. Of course as with all of Scotts programs the Up-Grade is FREE.

And after literally spending years entering QSL cards ,, and paper logs, The thought of throwing it all away if some error happened is the straw that broke the camels back for me.

To do the Up-Grade you need to take your old log and make a backup. and store it safely someplace. Then you have to remove the old version of ACLog in it's entirety and then install the Up-Grade and them hopefully import your back up to populate the log.

Way too scary for me, Sorry! Nope.

Joe WB9SBD
--

The Original Rolling Ball Clock
Idle Tyme
Idle-Tyme.com
http://www.idle-tyme.com


Re: MouseWheelControl.ocx error

Joe N9OK
 

I like your first solution. Is this documented more somewhere? I searched the registry but was unable to find where this setting might be. Or is this a change in the DXKeeper executable code, which I actually would have no idea how to fix?

Thanks for your patience, Dave

73, Joe N9OK

On Wed, Sep 2, 2015 at 9:47 PM, ' Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:
 

>>>AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Wednesday, September 02, 2015 10:26 PM
To: dxlab@...
Subject: Re: [dxlab] MouseWheelControl.ocx error

Dave, sorry about the delay in responding. Life...

1) I disabled Windows Defender using the Local Group Policy Editor per the directions here: http://www.sevenforums.com/tutorials/3652-local-group-policy-editor-open.html
I confirmed that all services related to Windows Defender are stopped.
I confirmed that Malware Bytes related services are stopped.
I confirmed that the Windows Firewall service is stopped.

2) All Windows Startup items are disabled (the Startup tab in the Task Manager shows Status "Disabled" for all entries

The error is still generated when DXKeeper is launched.
Interestingly, the mouse wheel does work in DXKeeper.

This is a curious one. I'd just keep ignoring the error, but it's annoying me now!

>>>I understand.

>>>One alternative would be to modify DXKeeper to remember (in the Windows Registry) that the MouseWheelControl was successfully registered (in your case, while in Safe mode), and not try to register if the "already registered" flag is set. Some DXLab applications still do that, but I stopped using this technique because if a component becomes un-registered, the user must use the Registry Editor to reset the "already registered" flag so that the application will re-register it, or they must use the regsvr32 applications to manually re-register the component.

>>>Yours is the first case in which re-registering an already-registered component is failing. You could contact Microsoft Support, explain that you have an application that invokes an OCX component's DllRegisterServer method, and that this invocation succeeds in Safe mode, but fails in Normal mode. That may be enough information for them to track down the root cause and suggest the necessary changes to settings.

73,

Dave, AA6YQ


59321 - 59340 of 208968