Date   
Icom 7610 Command Sequence for Preamp 1, 2 & Off

Rich
 

I am using a command sequence for my IC-7610 to turn the preamp1 on and off.


The 7610 has two preamps. Is it possible to add preamp 2 to the sequence? I tried but it just changes between two, Doesn't get the third.


I would like one button for the preamp and be able to alternate between off, 1 and 2.


What can I add in the sequence if this is possible?


<name:3>Pre<LEDenabled:1>1<LEDcolor:3>Red

<tooltip:6>Preamp


<tooltip click to enable preamp>


<ifled green,10>

enable Pre

FEFE<CIV>E0160201FD


<led green>


<tooltip click to disable preamp>


<end>







disable Pre

FEFE<CIV>E0160200FD


<led red>


<tooltip click to enable preamp>


<end>


TIA,

Rich, K0PIR

Re: Scripts - QSO Date usage

David Simpson
 

Thanks Dave!

Awesome products and support.

73,
David / KD4ADC

Re: missing .exe file

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, February 12, 2018 10:42 AM
To: dxlab@...
Subject: [dxlab] missing .exe file

get an error message telling me:

DXLab&#92;DXKeeper.exe does not exist. This same thing occurs with each of the other attendant files in Launcher. But otherwise Launcher seems OK.

I am running WIN 10, 8M memory, etc.

I have searched my computer and can't find one instance of this file.

Help

Unless you have a history of deleting files in your sleep, that's most likely the result of a misconfigured anti-malware application deciding to quarantine your DXKeeper executable.
In your DXKeeper folder, you should see a file named
DXKeeper1446.exe

Make a copy of this file, and rename the copy
DXKeeper.exe

That should restore your ability to run DXKeeper, but if my suspicion above is correct, this restoration may be temporary.
73,

Dave, AA6YQ

Re: Commander - Integration of TS-590S and KPA500

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, February 12, 2018 10:24 AM
To: dxlab@...
Subject: [dxlab] Commander - Integration of TS-590S and KPA500

I've been using DXlabs for a while and have Commander integrated with my TS-590S. That integration includes several user defined controls. I recently added an Elecraft KPA500 to my station and this presents new integration challenges.

I want to detect that the KPA500 has been switched from Standby to Operate and use that information to control the TS-590 output power level. I currently have a user defined TS-590 power control and it appears that Commander could read KPA500 status with the "OS" interrogation.

User-defined controls do not have the ability to extract data and make decisions based on the extraction results. That would require a full-fledged programming language, along with a suitable debugging environment.
It would also be desirable to implement a user defined KPA500 OPER/STBY button that toggled the KPA500 mode and set the user defined power level for each mode state.

That you could likely accomplish with a user-defined command sequence. Start small: first develop a sequence that toggles the KPA500's operating/standby mode.
73,

Dave, AA6YQ

Re: Bold font for callsign in Log page and Capture

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, February 12, 2018 10:06 AM
To: dxlab@...
Subject: [dxlab] Bold font for callsign in Log page and Capture

With lots on the monitor, and my eyesight not getting any better, I set the font in DXKeeper to bold. I use this for Spotcollector also.

This is quite helpful, but the callsign in both the log and capture window are not bold. Is this separately controlled? It's a small thing, but a vital piece of information to see well. :-)

Callsigns that are needed or on the Special Callsign List are rendered in bold font; otherwise, they are rendered in non-bold font.
73,

Dave, AA6YQ

Re: Scripts - QSO Date usage

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, February 12, 2018 10:13 AM
To: dxlab@...
Subject: RE: [dxlab] Scripts - QSO Date usage



OK that worked, thanks!

In the help file https://www.dxlabsuite.com/dxkeeper/Help/Scripts.htm#Modify, it says the following:


Within the new value, you can reference the contents of any other item in the QSO by enclosing that item's ADIF name in angle brackets. Thus the commands

Filter true
Modify PROP_MODE <COMMENT>

would set every QSO's propagation mode to the contents of its comment item.


On the log items screen https://www.dxlabsuite.com/dxkeeper/Help/Items.htm, it lists the ADIF name for QSO_End is:

QSO_Date

Time_Off


Hence my confusion.

That's a documentation defect. It's corrected in
<http://www.dxlabsuite.com/dxkeeper/Help/Scripts.htm>

73,

Dave, AA6YQ

missing .exe file

roamer
 

 get an error message telling me:

DXLab\DXKeeper.exe does not exist.  This same thing occurs with each of the other attendant files in Launcher.  But otherwise Launcher seems OK.

I am running WIN 10, 8M memory, etc.

I have searched my computer and can't find one instance of this file.

Help

Dean, K7NO

Commander - Integration of TS-590S and KPA500

a.durbin@...
 

I've been using DXlabs for a while and have Commander integrated with my TS-590S.  That integration includes several user defined controls.  I recently added an Elecraft KPA500 to my station and this presents new integration challenges.   


I want to detect that the KPA500 has been switched from Standby to Operate and use that information to control the TS-590 output power level.  I currently have a user defined TS-590 power control and it appears that Commander could read KPA500 status with the "OS" interrogation.  


It would also be desirable to implement a user defined KPA500 OPER/STBY button that toggled the KPA500 mode and set the user defined power level for each mode state.


 Anyone done this or something similar?


73,

Andy k3wyc

Re: Scripts - QSO Date usage

David Simpson
 

OK that worked, thanks!

In the help file https://www.dxlabsuite.com/dxkeeper/Help/Scripts.htm#Modify, it says the following:

Within the new value, you can reference the contents of any other item in the QSO by enclosing that item's ADIF name in angle brackets. Thus the commands

    Filter true
    Modify PROP_MODE <COMMENT>

would set every QSO's propagation mode to the contents of its comment item.


On the log items screen https://www.dxlabsuite.com/dxkeeper/Help/Items.htm, it lists the ADIF name for QSO_End is:

QSO_Date

Time_Off


Hence my confusion.

Thanks for the info.
David / KD4ADC



Bold font for callsign in Log page and Capture

Mark Killmon
 

With lots on the monitor, and my eyesight not getting any better, I set the font in DXKeeper to bold. I use this for Spotcollector also.

This is quite helpful, but the callsign in both the log and capture window are not bold. Is this separately controlled? It's a small thing, but a vital piece of information to see well. :-)

Thanks!

--
73, Mark, K4SO
www.k4so.com

Re: Scripts - QSO Date usage

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, February 11, 2018 9:58 PM
To: dxlab@...
Subject: [dxlab] Scripts - QSO Date usage

I've been successful with scripts, modifying data as needed, but one thing that I would like to accomplish eludes me. There are cases where I would like to modify the QSO_Begin to equal the QSO_End, but the ADIF name QSO Date components of Time On and Time Off are giving me fits. In short, neither of the following will work.

Modify QSO_Begin <QSO Date Time Off>

Modify QSO_Begin <QSO Date>

What is the proper syntax?

The correct script syntax for setting each QSO's "QSO Begin" time to its "QSO End" time is
Modify QSO_Begin <QSO_End>

73,

Dave, AA6YQ

Re: eqsl update button stopped working

Dave AA6YQ
 

Yours is the first report of this behavior.

Are you using more than one monitor?

Is there an errorlog.txt file in your DXKeeper folder? If so, please attach it to an email message an send it to me via 

aa6yq (at) ambersoft.com

      73,

          Dave, AA6YQ

Re: Increment Serial #'s.

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, February 12, 2018 1:15 AM
To: dxlab@...
Subject: RE: [dxlab] Re: Increment Serial #'s.

I'll admit I'm not as sharp as I use to be, so this was confusing to me.

It's a surprisingly complex topic, and the design may be a bit over-weighted towards flexibility over simplicity.
73,

Dave, AA6YQ

eqsl update button stopped working

Jeff Fladng
 

When trying to enter my eqsl User name and PW, the update button on the eqsl config screen produces no action.  Tried rebooting.  Screen button "depresses" but no update action or access to enter user name and password.  This used to work - weeks ago.


Is this a known issue with a known fix?

Re: Increment Serial #'s.

Jim - KR9U
 

Thanks Dave,

I'll admit I'm not as sharp as I use to be, so this was confusing to me.

Jim - KR9U

Re: LoTW confirmations not syncing

Dave Fugleberg
 

Now that I understand what happened, I did some checking and determined that I had over 400 QSOs made as W0ZF/R (my VHF Rover call) that were in the same boat for the same reason. I'm in the process right now of fixing that. I'm breaking it into smaller batches by adding date ranges to the filter. Once that's done my log should be in sync with LoTW from here on out.
Thanks again.

On Sun, Feb 11, 2018 at 9:53 PM 'Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...> wrote:
>>>AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, February 11, 2018 10:47 PM
To: dxlab@...
Subject: RE: [dxlab] LoTW confirmations not syncing

Perfect. It just finished and all is right with the world.

>>>Great! Given the configuration change you made, the "Sync LoTW QSOs" and "Sync LoTW QSLs" functions will from now on sync all of your QSOs, not just those made as W0ZF.

      73,

            Dave, AA6YQ




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


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

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/dxlab/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/dxlab/join
    (Yahoo! ID required)

<*> To change settings via email:
    dxlab-digest@...
    dxlab-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    dxlab-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Re: Spectrum-Waterfall Display and Commander's multiradio capability

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Friday, February 09, 2018 2:50 AM
To: DXLab forum
Subject: [dxlab] Spectrum-Waterfall Display and Commander's multiradio capability

Like probably a few other IC-7610 owners I also own a IC-7300. I use them interchangeably using Commander's excellent multiradio capability. It all works really well (even for digital modes) with one exception - the Spectrum-Waterfall display.

The REF level on the IC-7610 and IC-7300 are 10dB "off". The IC-7610 REF level goes from +10 to -30dB whereas the IC-7300 goes from +20 to -20dB. In absolute terms, -10dB on the IC-7610 seems roughly equivalent with 0dB on the IC-7300. Since the IC-7851 has the same range as the IC-7300 I would assume them to behave the same.

I have noticed that the Spectrum-Waterfall Display use the same settings regardless of radio. This is perfectly fine except for the REF level since its definition may differ between radios.

Perhaps represent an extreme minority (if so, feel free to ignore this, Dave) but I would like very much if Commander could handle this inconsistency between radios.. (I would assume that once Commander is expanded to support also other radios Spectrum-Waterfall capability the need will be more obvious).

A very pragmatic solution would be to simply "translate" a -20dB to +20dB slider scale into -30dB to +10dB settings for the IC-7610 only. This could of course be slightly confusing for the user.

Another solution would be to have one set of REF values per "multiradio".

Regardless, it would be really nice if Commander could handle this inconsistency between Waterfall-capable radios.

The MultiRadio tab on Commander's Configuration window enables you to specify settings for each of the four primary transceivers that Commander can control. When you select a new primary transceiver, Commander copies the settings for that new primary transceiver from the MultiRadio tab to appropriate settings on the Configuration window's General and Ports tab, and updates the user-defined sequences and sliders as specified in the new primary transceiver's "User-defined Control Set".
Commander's "Spectrum-Waterfall Configuration" window enables you to specify 12 reference levels for each of 3 sub-bands and the full band -- a total of 48 reference levels. Taking the above-described approach with reference levels would thus require extending the Configuration window's MultiRadio tab to enable the specification of 192 reference levels (48 for each of 4 primary transceivers). This would not be practical.
Performing arithmetic on reference levels when moving from one transceiver to another might work among transceivers with the same manufacturer, but seems unlikely to work among transceivers with different manufacturers.
To address this issue, I propose an alternative approach. If MultiRadio support is enabled for primary transceiver X (where X is between 1 and 4), Commander will also store its 48 reference levels in the Windows Registry in a section specific to transceiver X. When you switch primary transceivers from X to Y, Commander will load the "Spectrum-Waterfall Configuration" window's 48 reference levels from the 48 reference levels in the Windows Registry associated with transceiver Y. When you change a reference level for the current primary transceiver, both the existing Registry settings and the Registry settings for the current primary transceiver will be updated. This approach would provide the desired result -- independent reference levels for each primary transceiver - in a practical manner.
Concerns? Objections? Better ideas?
73,

Dave, AA6YQ

Re: LoTW confirmations not syncing

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, February 11, 2018 10:47 PM
To: dxlab@...
Subject: RE: [dxlab] LoTW confirmations not syncing

Perfect. It just finished and all is right with the world.

Great! Given the configuration change you made, the "Sync LoTW QSOs" and "Sync LoTW QSLs" functions will from now on sync all of your QSOs, not just those made as W0ZF.
73,

Dave, AA6YQ

Re: LoTW confirmations not syncing

Dave Fugleberg
 

Perfect. It just finished and all is right with the world.  Thanks again for not only the best logging suite in the world, but the best support. Believe me, I deal with software companies professionally all the time with high priced support contracts who are not anywhere close to this level of support.

73 de W0ZF

Re: LoTW confirmations not syncing

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, February 11, 2018 10:04 PM
To: dxlab@...
Subject: RE: [dxlab] LoTW confirmations not syncing

There are 207 total N0A QSOs. LoTW shows that 91 are confirmed so far. My DxKeeper log shows only two confirmed (those were just in the past day or so). Sorry for the delay in responding- I had to go find this thread in the Yahoo archives, as your reply never made it to my email.

Then I suggest that you
1. filter the Log Page Display to contain only your N0A QSOs

2. on the Main window's QSL tab,

2a. set the "QSL Via" panel to LoTW

2b. click the "Update from LoTW" button, and confirm that you wish to proceed

Expect this operation to take ~10 minutes.
73,

Dave, AA6YQ