Date   

Re: FT4 Transmit Failing Through Commander

 

Thanks Rich.  I was indeed using "Rig."  I changed it to "Fake It" and I am now seeing a full TX cycle.  I do wonder why such a significant delay when using Rig, but that is another discussion.  I will post this solution in the FT4/FT8 Facebook group to share the solution.

73, Greg, KM5GT


Re: FT4 Transmit Failing Through Commander

g4wjs
 

On 01/05/2019 15:46, ve3ki wrote:
In WSJT-X, if you have "Split Operation" set to "Rig", try changing it to "Fake It". The RX-to-TX transition with the "Rig" setting seems to be very slow when using another program (like Commander) as the rig control intermediary.

73,
Rich VE3KI
Hi Rich,

in general that is not the case. For some rigs it is true. I did not think the IC-7300 was one of those so I suspect some non-fatal configuration setting is at play. Maybe some throughput impact if the OP is using the DX Lab Suite waterfall repeater for that rig, maybe some setting on the rig like having "CI-V Transceive Mode" enabled, maybe an excessive command interval setting in Commander, ... . Perhaps Dave, AA6YQ, can tell us more when he has dome time by analysing a debug trace from Commander.

73
Bill
G4WJS.



--
73

Bill

G4WJS.


Re: FT4 Transmit Failing Through Commander

ve3ki
 

In WSJT-X, if you have "Split Operation" set to "Rig", try changing it to "Fake It". The RX-to-TX transition with the "Rig" setting seems to be very slow when using another program (like Commander) as the rig control intermediary.

73,
Rich VE3KI


On Wed, May 1, 2019 at 10:25 AM, Greg Tilford wrote:
I'm sure I have a configuration error in Commander that has just shown itself through testing FT4.  I am configured as WSJT-X -> Commander -> IC-7300 CAT.  I have been using this configuration for some time with no issues.  However, when I tried to use FT4 my transmission was never copied.  PSKReporter never indicated that anyone decoded my transmission.  FT8 worked fine, and I was able to decode and report FT4 just fine.  Upon investigation I found that my TX time is being truncated to around 2.4-2.5 seconds.  Clearly not the "4.48" seconds required by FT4.

I then bypassed Commander and went directly from WSJT-X to my IC-7300 via CAT and everything worked correctly.  My stopwatch shows TX engaged for 4.8 seconds with the direct connection.  Closing the loop, I switched the configuration back through Commander with the original results.  A truncated TX of around 2.5 seconds.

I'm sure I have something misconfigured in Commander.  Any suggestions?

73, Greg, KM5GT


Re: FT4 Transmit Failing Through Commander

Andrew OBrien
 

FT4 with Commander working fine here 
Andy K3UK


On May 1, 2019, at 10:25 AM, Greg Tilford <GregTilford@...> wrote:

I'm sure I have a configuration error in Commander that has just shown itself through testing FT4.  I am configured as WSJT-X -> Commander -> IC-7300 CAT.  I have been using this configuration for some time with no issues.  However, when I tried to use FT4 my transmission was never copied.  PSKReporter never indicated that anyone decoded my transmission.  FT8 worked fine, and I was able to decode and report FT4 just fine.  Upon investigation I found that my TX time is being truncated to around 2.4-2.5 seconds.  Clearly not the "4.48" seconds required by FT4.

I then bypassed Commander and went directly from WSJT-X to my IC-7300 via CAT and everything worked correctly.  My stopwatch shows TX engaged for 4.8 seconds with the direct connection.  Closing the loop, I switched the configuration back through Commander with the original results.  A truncated TX of around 2.5 seconds.

I'm sure I have something misconfigured in Commander.  Any suggestions?

73, Greg, KM5GT


FT4 Transmit Failing Through Commander

 

I'm sure I have a configuration error in Commander that has just shown itself through testing FT4.  I am configured as WSJT-X -> Commander -> IC-7300 CAT.  I have been using this configuration for some time with no issues.  However, when I tried to use FT4 my transmission was never copied.  PSKReporter never indicated that anyone decoded my transmission.  FT8 worked fine, and I was able to decode and report FT4 just fine.  Upon investigation I found that my TX time is being truncated to around 2.4-2.5 seconds.  Clearly not the "4.48" seconds required by FT4.

I then bypassed Commander and went directly from WSJT-X to my IC-7300 via CAT and everything worked correctly.  My stopwatch shows TX engaged for 4.8 seconds with the direct connection.  Closing the loop, I switched the configuration back through Commander with the original results.  A truncated TX of around 2.5 seconds.

I'm sure I have something misconfigured in Commander.  Any suggestions?

73, Greg, KM5GT


Re: Update: Commander and SmartSDR v3

Dave AA6YQ
 

+ AA6YQ comments below


On Fri, Apr 26, 2019 at 11:34 AM, Dave AA6YQ wrote:

The first problem encountered was that the current version of Commander does not correctly handle new items added in SmartSDR v3 to
the RX-TX interlock status message, causing Commander and the radio to disconnect. This is what prevented the TX-to-RX transition
from working correctly. For the record, the new interlock status items were added to v3 in an upward-compatible manner, so this
should be considered a defect in Commander.

Correcting this Commander defect has exposed unexpected behavior in SmartSDR v3, specifically the presence of clients and
panadaptors that Commander did not request be created. Flex engineers are working to track down the root cause of this behavior.

Reminder: the objective is to enable Commander to control a Flex Signature transceiver running SmartSDR v3, but without the use of
multiFlex.

The addition of multiFlex support will be considered after we achieve the first objective.

+ Flex engineers have corrected several defects in SmartSDR v3. Jamie WW3S and I are now testing a new version of Commander with a new version of SmartSDR v3.

        73,

             Dave, AA6YQ


Re: Excess DXKeeper files in C:/DXLab/DXKeeper

Mark W2OR <reston2010mm-orders@...>
 

More progress made here.  Thanks.   

Continuing from the last update, those mis-placed SpotCollector.exe app files (see last note) have now been moved back into the SpotCollector Folder where they belonged.  Also made the corresponding change in DXLab Launcher to reflect the change for SC.exe location.  Things appear to be back to 'normal'.

Thanks again and 73, Dave. 
de Mark
.w2or


Re: Excess DXKeeper files in C:/DXLab/DXKeeper

Mark W2OR <reston2010mm-orders@...>
 

Thank you, Dave.  And thank you, Mike.   This is helpful,and quite educational, especially the lengthy background explanations.

I have now pruned all but the main unnumbered .exe and two of the more recent .exe app revisions, for all seven DXLab apps.  I'm stuck on one remaining question before I do anything further :  

The main unnumbered SpotCollector.exe and two of the more recent SC .exe revisions, are not in the SC Folder where they should be found, rather, they are in the main C:\DXLab  folder.  Searching further, I found inside the regular SC Folder two very old SpotCollector .exe updates, dated from years 2006 and 2010.  So, before I go ahead and delete the old 2006 / 2010 updates, and then move the other three .exe from C:\DXLab to C:\DXLab\SpotCollector, thought it a good idea to check with the experts.  Thanks.


Re: How to add mode to FT4 QSO records in DXKeeper?

Andy k3wyc <a.durbin@...>
 

On Tue, Apr 30, 2019 at 01:03 PM, Dave AA6YQ wrote:
+ A selector can only display "legal values". 

Ok, I get it now, thanks.   

73,
Andy, k3wyc


Re: How to add mode to FT4 QSO records in DXKeeper?

Dave AA6YQ
 

+ AA6YQ comments below

+ The QSO panel at the top of the "Log QSOs" tab of DXKeeper's Main window can be used for both logging new QSOs and for displaying the contents of logged QSOs. Since the Log Page Display is also present on this tab (providing visibility to the contents of a logged QSOs Mode item, as described above), the QSO panel's Mode selector is optimized to minimize data entry errors: it's limited the modes defined in your Modes.txt or DefaultModes.txt file.

I have no issue at all with the QSO panel's Mode selector being limited to the allowed modes. What I still don't understand is how the QSO panel's Mode indication can be different from the log panel mode indication. The mode is either in the log or it isn't.

+ A selector can only display "legal values". If a logged QSO's "Mode" item contains FOO but you haven't defined FOO in your Modes.txt or DefaultModes.txt file, then when this logged QSO is selected in the Log Page Display, the QSO panel's Mode selector will be empty because FOO isn't a "legal value". However, the Log Page Display will show FOO in the QSO's Mode column.

73,

Dave, AA6YQ


Re: How to add mode to FT4 QSO records in DXKeeper?

W9MR Mike
 

Dave, Does the exact mode match really matter since there is no new modes being recognized for individual bands by LOTW? When FT8 was introduced I spoke to ARRL as t when it would be added to the list of available modes for WAS. They stated that they would not be adding new modes but would consider all digital modes as one WAS award per band. To this day FT8 is still not listed by band for WAS award only as a general digital mode WAS. 
 
They do offer an FT8 endorsement of the main digital WAS award. So it an assumption, but seemingly likely they would add an endorsement for FT4 in the future. While not for a "for band" award, it is still something that may end up being counted in the future


73,
Mike ND9G


On Tue, Apr 30, 2019 at 2:44 PM n4qwf . <N4QWF@...> wrote:
Dave, Does the exact mode match really matter since there is no new modes being recognized for individual bands by LOTW? When FT8 was introduced I spoke to ARRL as t when it would be added to the list of available modes for WAS. They stated that they would not be adding new modes but would consider all digital modes as one WAS award per band. To this day FT8 is still not listed by band for WAS award only as a general digital mode WAS.


Re: How to add mode to FT4 QSO records in DXKeeper?

Andy k3wyc <a.durbin@...>
 

On Tue, Apr 30, 2019 at 11:52 AM, Dave AA6YQ wrote:
+ The QSO panel at the top of the "Log QSOs" tab of DXKeeper's Main window can be used for both logging new QSOs and for displaying the contents of logged QSOs. Since the Log Page Display is also present on this tab (providing visibility to the contents of a logged QSOs Mode item, as described above), the QSO panel's Mode selector is optimized to minimize data entry errors: it's limited the modes defined in your Modes.txt or DefaultModes.txt file.
I have no issue at all with the QSO panel's Mode selector being limited to the allowed modes.  What I still don't understand is how the QSO panel's Mode indication can be different from the log panel mode indication.   The mode is either in the log or it isn't.

73,
Andy, k3wyc


Re: How to add mode to FT4 QSO records in DXKeeper?

Dave AA6YQ
 

+ AA6YQ comments below

Dave, Does the exact mode match really matter since there is no new modes being recognized for individual bands by LOTW? When FT8 was introduced I spoke to ARRL as t when it would be added to the list of available modes for WAS. They stated that they would not be adding new modes but would consider all digital modes as one WAS award per band. To this day FT8 is still not listed by band for WAS award only as a general digital mode WAS.

+ If there are no awards that require an "exact mode match" for FT4, then there's no need to resubmit FT4 QSOs mapped to DATA after LoTW begins accepting unmapped FT4 QSOs.

73,

Dave, AA6YQ


Re: How to add mode to FT4 QSO records in DXKeeper?

n4qwf .
 

Dave, Does the exact mode match really matter since there is no new modes being recognized for individual bands by LOTW? When FT8 was introduced I spoke to ARRL as t when it would be added to the list of available modes for WAS. They stated that they would not be adding new modes but would consider all digital modes as one WAS award per band. To this day FT8 is still not listed by band for WAS award only as a general digital mode WAS.


Re: Excess DXKeeper files in C:/DXLab/DXKeeper

Dave AA6YQ
 

+ AA6YQ comments below

EXCESS DXKEEPER FILES. Screen Shots and Notes below

I'd be interested to know what others have done in the way of pruning some of the unnecessary files in C:/DXLab/DXKeeper.

In line of background, in this old, 11-year old main computer here, inside the C:/DXLab/DXKeeper files, there appears to be an overabundance of useless files. These include 129 large, separate DXKeeper.exe files. These .exe files range from the earliest, created in Year 2008 with 6800 KB, to the latest DXKeeper.exe file, created 3.15.2019, with 13,800 KB. There are 129 of these large files, and I have no idea what setting has allowed their repeated creation. As an aside, DXKeeper is open and closed about once each week; the start process takes about 50 seconds before the main log appears. Having so many large .exe files is worrisome to me. As you can probably tell from this writing, I'm not computer literate, and so not sure what's going on. (I've created screen shots of the beginning, and the end, of this large DXKeeper file.) It would be good to know what can be deleted of these .exe files, and what should stay. Or perhaps do a log backup, remove most everything in DXKeeper, then re-install from scratch for a fresh start. If there's a setting or two to be changed, to prevent the creation of further unnecessary files, that would be good to know. I'd be interested in what other have done. Thanks.

+ The current public version of DXKeeper is 14.8.5

+ If you inspect your DXKeeper folder, you will find the files

DXKeeper.exe

and

DXKeeper1485.exe

+ These two files are identical. When you direct the Launcher to start DXKeeper, it will run the file DXKeeper.exe

+ When the next version of DXKeeper becomes available - say 14.9.0 - then when you direct the Launcher to upgrade DXKeeper, it will

1. delete the existing DXKeeper.exe

2. download the file DXKeeper1490.exe into your DXKeeper folder

3. make a copy of DXKeeper1490.exe and name that copy DXKeeper.exe

+ Thus DXKeeper.exe always contains the current version of DXKeeper, which is what the Launcher invokes when you direct it to start DXKeeper.

+ Note that after upgrading to DXKeeper 14.9.0, the file DXKeeper1485.exe remains in your DXKeeper folder. This is intentional; why? because despite our best efforts, DXKeeper 14.9.0 may fail when you attempt to start it, or may contain a latent defect that interferes with your operation. To prevent such an event from impeding your DXing, you can immediately revert to DXKeeper 14.8.5 by performing these actions in your DXKeeper folder:

A. delete the file DXKeeper.exe

B. make a copy of the file DXKeeper1485.exe and name this copy DXKeeper.exe

+ Now when you direct the Launcher to start DXKeeper, it will start DXKeeper 14.8.5.

+ This approach leaves a "trail" of old versions of DXKeeper executables in your DXKeeper folder. How many of these you keep is up to you. My recommendation is to retain the last two versions that you've been using and delete the rest. You can do this pruning after each DXKeeper upgrade, or monthly, or annually.

+ Note that the process described above for DXKeeper also applies to the other 7 DXLab applications.

+ Extending the DXLab Launcher to automate the old version pruning process ("retain the most recent X versions of each DXLab applications") is on the list, but not imminent.

73,

Dave, AA6YQ


Re: Excess DXKeeper files in C:/DXLab/DXKeeper

W9MR Mike
 

These files are a result of the upgrade process of the applications in DX Lab Suite. Which is detailed here.


You definitely do not need to keep that many of the previous versions, but you probably want to keep at least the previous 2-3, in case there was a regression in a version that you need to go back to correct. 

You should not go through the process of uninstalling/fresh install to clean these files.

73,
Mike ND9G


On Tue, Apr 30, 2019 at 1:47 PM Mark W2OR via Groups.Io <reston2010mm-orders=yahoo.com@groups.io> wrote:

EXCESS  DXKEEPER  FILES.   Screen Shots and Notes below

 

     I'd be interested to know what others have done in the way of pruning some of the unnecessary files in C:/DXLab/DXKeeper.

     In line of background, in this old, 11-year old main computer here, inside the  C:/DXLab/DXKeeper files, there appears to be an overabundance of useless files.  These include 129 large, separate DXKeeper.exe files.  These .exe files range from the earliest, created in Year 2008 with 6800 KB, to the latest DXKeeper.exe file, created 3.15.2019, with 13,800 KB.  There are 129 of these large files, and I have no idea what setting has allowed their repeated creation.  As an aside, DXKeeper is open and closed about once each week; the start process takes about 50 seconds before the main log appears.  Having so many large .exe files is worrisome to me.  As you can probably tell from this writing, I'm not computer literate, and so not sure what's going on.   (I've created screen shots of the beginning, and the end, of this large DXKeeper file.)  It would be good to know what can be deleted of these .exe files, and what should stay.   Or perhaps do a log backup, remove most everything in DXKeeper, then re-install from scratch for a fresh start.  If there's a setting or two to be changed, to prevent the creation of further unnecessary files, that would be good to know.   I'd be interested in what other have done.   Thanks.


Re: How to add mode to FT4 QSO records in DXKeeper?

Dave AA6YQ
 

+ AA6YQ comments below

The experimental WSJT-X version appears to work as designed. It's helpmate, JTAlert, can't decode these new transmissions but it does serve as a stable transfer medium for sending QSOs from JSJT-X into DXKeeper. DXKeeper of course can't write FT4 as a mode into its log, so the mode is left blank in the DXK log record.

+ That's not correct. DXKeeper will log a QSO whose mode is FOO if that's what is specified in the ADIF or tab-delimited record imported from a file, or received from another application. You'll be able to see this by selecting the QSO in DXKeeper's Log Page Display and inspecting the contents of its Mode column.

It seems to be a bit more obscure than that.

I made a few FT4 QSO and they were logged to DXK by JTAlertX. I added a new TQSL mapping FT4>DATA and uploaded these FT4 QSO and several FT8 QSO to LotW. I checked later and saw R status for the FT8 QSO but U status for the FT4 QSO.

When I looked more carefully at my FT4 QSO log entries I found that the tabular display of my QSO showed mode as FT4 but the QSO panel mode was blank for each of the FT4 QSO.

Why does DXK show FT4 in one mode display but blank in another mode display for the same QSO record? (other than because I didn't add the mode to DXK)

+ The Mode column of DXKeeper's Log Page Display shows the Mode item present in the logged QSO, whether the logged Mode is defined in your Modes.txt or DefaultModes.txt file or not.

+ DXKeeper's Capture window is exclusively used for logging new QSOs. To minimize data entry errors, its Mode selector is limited to the modes defined in your Modes.txt or DefaultModes.txt file.

+ The QSO panel at the top of the "Log QSOs" tab of DXKeeper's Main window can be used for both logging new QSOs and for displaying the contents of logged QSOs. Since the Log Page Display is also present on this tab (providing visibility to the contents of a logged QSOs Mode item, as described above), the QSO panel's Mode selector is optimized to minimize data entry errors: it's limited the modes defined in your Modes.txt or DefaultModes.txt file.

73,

Dave, AA6YQ


Excess DXKeeper files in C:/DXLab/DXKeeper

Mark W2OR <reston2010mm-orders@...>
 

EXCESS  DXKEEPER  FILES.   Screen Shots and Notes below

 

     I'd be interested to know what others have done in the way of pruning some of the unnecessary files in C:/DXLab/DXKeeper.

     In line of background, in this old, 11-year old main computer here, inside the  C:/DXLab/DXKeeper files, there appears to be an overabundance of useless files.  These include 129 large, separate DXKeeper.exe files.  These .exe files range from the earliest, created in Year 2008 with 6800 KB, to the latest DXKeeper.exe file, created 3.15.2019, with 13,800 KB.  There are 129 of these large files, and I have no idea what setting has allowed their repeated creation.  As an aside, DXKeeper is open and closed about once each week; the start process takes about 50 seconds before the main log appears.  Having so many large .exe files is worrisome to me.  As you can probably tell from this writing, I'm not computer literate, and so not sure what's going on.   (I've created screen shots of the beginning, and the end, of this large DXKeeper file.)  It would be good to know what can be deleted of these .exe files, and what should stay.   Or perhaps do a log backup, remove most everything in DXKeeper, then re-install from scratch for a fresh start.  If there's a setting or two to be changed, to prevent the creation of further unnecessary files, that would be good to know.   I'd be interested in what other have done.   Thanks.


Re: How to add mode to FT4 QSO records in DXKeeper?

Andy k3wyc <a.durbin@...>
 
Edited

On Tue, Apr 30, 2019 at 11:12 AM, Jim Wysocki wrote:
I think you've answered your own question
I don't think so.   What I reported seems to be another case of DXK displaying log data that is inconsistent with the rules that DXK is applying to the displayed log.  Both cases are the result of JtTAlertX writing log data to DXK.

The cases I have seen are - 

1.  A log filter is being applied and JTAlertX appends a QSO to the log.  The appended QSO does not meet the log filter criteria but is still shown in the filtered log window.
2. A QSO with a mode not known to DXK is appended to the log.  The QSO is displayed in the log window with a mode that is not known to DXK and which is not used in the LotW upload.

Neither is a real issue for me but both could be an indication of a problem with the way JTALert log data are processed and displayed.

73,
Andy, k3wyc


Re: How to add mode to FT4 QSO records in DXKeeper?

Dave AA6YQ
 

+ AA6YQ comments below

I've just added FT4 to DXKeeper's mode file and also mapped FT4 to the DATA mode in tQSL. LotW has accepted my latest update and it took the new log records without any problems.

eQSL was a different story. Their system didn't like the new FT4 mode and rejected all of my log records. I only send records to these folks to help out those who are pursuing eQSL awards, so I'm content to wait until after the eQSL staff fixes their "new FT4 mode" problem before I make any more submissions to them.

+ eQSL is likely waiting for FT4 to be added to the ADIF specification; the ADIF discussion is under way.

The important thing right now is that the migration path for getting FT4 QSOs into LotW is working exactly as it is should. Sooner or later the LotW technical gurus will add an FT4 mode.

+ They will do that as soon as ADIF is added to the ADIF specification.

Then I suppose we can resubmit these records as FT4 QSOs.

I'm really happy about how well problems get resolved in this work group.

+ Me too! Not only is there great participation from the user community, but the interactions are friendly and helpful. I'm as proud of this group as I am of DXLab.

73,

Dave, AA6YQ

25621 - 25640 of 211082