Date   

Re: FW: Yaesu FT-757GX Cat interface

W4HRA - Rick Spears
 

Thank you Dave.

On Oct 28, 2020, at 3:41 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

Hello. New to group hope this is ok to send here.

+ Welcome to DXLab, Rick!


I have searched in Group and all info is at least 10 years old.

Using Yaesu FT-757GX (not II) and cannot get it work with Commander. Using Windows 10.

I am using a CAT interface to USB cable showing up as Com 6 on my PC. PC configured to recommended 4800 baud rate, word length 8,
stop bits 2 etc. Set up for PC port config and in Commander.

Any thoughts or suggestions would be appreciated.

+ Step-by-step instructions are here:

<https://www.dxlabsuite.com/dxlabwiki/TranceiverControlYaesu>

+ As stated in the " Model-specific notes" of this article,

"The FT-736R and FT-757GX do not provide CAT commands that enable Commander to track its frequency and mode; the FT-757GXII does
provide these CAT commands."

+ Thus Commander is able to set your transceiver's frequency and mode, but cannot track and display these parameters.

73,

Dave, AA6YQ







Spot Collector & My Call

segwin
 

Hello All,

Been out of radio for a while but retired now and getting back into it.

I'm running WSJT-X, JTAlert and Spot Collector. Looking at the FT8 mode in Spot Collector all I see is my call for the source - no other calls. Am I spamming Spot Collector? I'm not quite sure how I'm placing these as well.

Feel like such a noob.

Thanks

K8TJM / Terry


Re: FW: Yaesu FT-757GX Cat interface

Dave AA6YQ
 

+ AA6YQ comments below

Hello. New to group hope this is ok to send here.

+ Welcome to DXLab, Rick!


I have searched in Group and all info is at least 10 years old.

Using Yaesu FT-757GX (not II) and cannot get it work with Commander. Using Windows 10.

I am using a CAT interface to USB cable showing up as Com 6 on my PC. PC configured to recommended 4800 baud rate, word length 8,
stop bits 2 etc. Set up for PC port config and in Commander.

Any thoughts or suggestions would be appreciated.

+ Step-by-step instructions are here:

<https://www.dxlabsuite.com/dxlabwiki/TranceiverControlYaesu>

+ As stated in the " Model-specific notes" of this article,

"The FT-736R and FT-757GX do not provide CAT commands that enable Commander to track its frequency and mode; the FT-757GXII does
provide these CAT commands."

+ Thus Commander is able to set your transceiver's frequency and mode, but cannot track and display these parameters.

73,

Dave, AA6YQ


FW: Yaesu FT-757GX Cat interface

W4HRA - Rick Spears
 

Hello. New to group hope this is ok to send here. I have searched in Group and all info is at least 10 years old.

Using Yaesu FT-757GX (not II) and cannot get it work with Commander. Using Windows 10.

I am using a CAT interface to USB cable showing up as Com 6 on my PC. PC configured to recommended 4800 baud rate, word length 8, stop bits 2 etc. Set up for PC port config and in Commander. 

 

Any thoughts or suggestions would be appreciated.

 

Thanks. Rick


Re: Lotw & RAT

Dave AA6YQ
 

I was updating my records today and noticed that some QSOs are shown as verified in my LoTW account but not so in DXK's RAT. These
were paper QSLs. My understanding is that paper QSLs do not show up in LoTW with a QSL date under the "Your QSOs" tab. Under these
circumstances is it correct then that I must manually change the QSO's QSL record in DXK from "C" to "V" when it is verified by
LoTW? It appears so, but I want to be certain I haven't missed something. Thanks.

+ If you use DXKeeper's "DXCC Submission" mechanism to choose the confirmed QSOs you submit for DXCC award credit, then when that
credit is granted, you can "promote" the status of those QSOs from "submitted" to "credit granted" (aka "verified") with a single
action. See

<https://www.dxlabsuite.com/dxlabwiki/GenerateSubmission>

+ If you didn't use DXKeeper's DXCC Submission" mechanism, you can use DXKeeper's "DXCC Credit Manager" to download all of your DXCC
credits and update your logged QSOs to reflect DXCC credit granted. However, about 25% of your credits will require manual action to
compensate for shortcuts taken and data entry errors made by ARRL personnel when entering data from QSL cards (unless you submit
using "DXCC Online"). See

<https://www.dxlabsuite.com/dxlabwiki/ManageDXCCCredits>

+ For a handful of QSOs to which DXCC credit has been granted, manually updating your logged QSOs may be faster.

73,

Dave, AA6YQ


Lotw & RAT

w3qt_mike
 

I was updating my records today and noticed that some QSOs are shown as verified in my LoTW account but not so in DXK’s RAT.  These were paper QSLs.  My understanding is that paper QSLs do not show up in LoTW with a QSL date under the “Your QSOs” tab.  Under these circumstances is it correct then that I must manually change the QSO’s QSL record in DXK from “C” to “V” when it is verified by LoTW?  It appears so, but I want to be certain I haven’t missed something.  Thanks.

 

73,

Mike, W3QT


Re: spot collector was slowing down

Dave AA6YQ
 

+ AA6YQ comments below
Wow am I thankful I found this thread on SC.  You guys may have solved all 5 or 6 of my problems I was having.  Didn't know about the pruning thing, that file was humongous!  Under control now.  

Thanks so much!!!! 

+ Take a look at this article:

<https://www.dxlabsuite.com/dxlabwiki/OptimizeSCPerformance>

           73,

                  Dave, AA6YQ


Re: spot collector was slowing down

Ed K0iL
 

Wow am I thankful I found this thread on SC.  You guys may have solved all 5 or 6 of my problems I was having.  Didn't know about the pruning thing, that file was humongous!  Under control now.  

Thanks so much!!!! 
--
73, de ed -K0iL
Omaha, NE


Re: Message at startup

Knut Meland
 

Problem solved.

Thanks, Dave!

Den 27.10.2020 20.32, skrev Dave AA6YQ:

+ AA6YQ comments below

When I start DXLab from Launcher, I get this message:
CI-V Commander aborting device data load operation - missing or invalid frequency: 2020-10-01 21.47.36 > CI-V Commander ver 14.7.1

+ You have Commander configured to load information from a file for a frequency-dependent device. The file you've specified contains invalid data.

+ See

<https://www.dxlabsuite.com/commander/Help/Configuration.htm#Device%20tabs>

73,

Dave, AA6YQ






Re: Message at startup

Dave AA6YQ
 

+ AA6YQ comments below

When I start DXLab from Launcher, I get this message:
CI-V Commander aborting device data load operation - missing or invalid frequency: 2020-10-01 21.47.36 > CI-V Commander ver 14.7.1

+ You have Commander configured to load information from a file for a frequency-dependent device. The file you've specified contains invalid data.

+ See

<https://www.dxlabsuite.com/commander/Help/Configuration.htm#Device%20tabs>

73,

Dave, AA6YQ


Re: Blank WAS Check Progress report

Matt Foster
 

Disregard. I just found that ALL of the bands for WAS had somehow become unchecked. Progress is working fine again.

Sorry for the spam.

--
73, Matt, N0EYE


Blank WAS Check Progress report

Matt Foster
 

I recently migrated to a new computer, and while most everything with the DXLabs suite is working fine, the WAS Check Progress function is not. The report is essentially blank. By that, I mean it is not completely blank...it does have my callsign and the current date at the top, the note about it being 'Limited to QSOs with "My QTHs" whose WAS box is checked', along with the list of states. There are not any bands listed nor marks for states confirmed on each band. I double-checked that my current QTH does have the WAS box checked on the myQTHs tab, and there are QSOs (many, actually) that have that QTH selected.

This worked prior to moving to my new computer (I actually should have 47/50 confirmed on 20m), so I'm guessing that is somehow related, but I can't figure out what the issue is.

Any suggestions are appreciated!

--
73, Matt, N0EYE


Message at startup

Knut Meland
 

When I start DXLab from Launcher, I get this message:
CI-V Commander aborting device data load operation - missing or invalid frequency: 2020-10-01 21.47.36 > CI-V Commander ver 14.7.1

I use to click it away, and everything looks fine. It is just annoying to get this every time i start DXLab.

73 de Knut LA9RY


Re: New question: QRZ Logging

Dave AA6YQ
 

+ AA6YQ comments below

I agree 100%. I am a subscriber to QRZ and I couldn’t be happier with Log Publisher as an add on to DXKEEPER. The only thing I use to have to try to remember to open the program.

+ You can configure the DXLab Launcher to automatically start non-DXLab applications: the Configuration window's "Apps Started Before DXLab Apps" and "Apps Started After DXLab Apps" tabs provide Start buttons that enable you to start individual non-DXLab applications.

<https://www.dxlabsuite.com/Launcher/Help/ControllingApplications.htm>

73,

Dave, AA6YQ


Re: New question: QRZ Logging

Rob Kivell
 

I agree 100%. I am a subscriber to QRZ and I couldn’t be happier with Log Publisher as an add on to DXKEEPER. The only thing I use to have to try to remember to open the program. Finally I said gotta fix that. I then added it to my start up menu. Life is now good.

Rob kk4eun


On Oct 26, 2020, at 11:57 AM, KD2HCE via groups.io <KD2HCE@...> wrote:

I've been using the latter method Jim states above. DXKeeper is main log, it sends out to LoTW and eQSL, takes info FROM them and updates itself, of course after a 15 minute wait on LoTW. Then as QRZ is FREE to DOWNLOAD from LoTW (QRZ only costs you to UPload to LoTW,) even still the XML subscription is worth the non-worry of too many lookups per day, you just do a download FROM LotW every 15 minutes as QRZ now has a timer installed. I think that would be an issue for DXKeeper to instantly update QRZ, it would have to sniff out that remaining time to query LoTW again.
Also: The best ~$13 (10Euro) ever spent, was on LogPublisher by DL9HO, the PITA factor went to zero if you use HRDLog. Automates everything. EVEN SENDS QSOs instantly TO QRZ, but I've found the download from LoTW is much more accurate, and negates any dupes when you do download from LoTW for confirmations. The method Jim uses seems to be the best overall for now. I've been doing it this way for over a year now.
Hope this helps,
73,
Chris - KD2HCE


Re: N1MM-DXKeeper Gateway version 1.1.6

Dave AA6YQ
 

# more AA6YQ comments below

+ Are you reporting that you experienced the above error message while running version 1.1.6 of the Gateway?
i was responding in concurrence with the "stealing focus" issue, which (because it made it unusable) forced me to back down to v114.

i will look thru the error log (which has 116 and 114 entries in it) for the DDE error to be sure it only occurred when 114 was in place. If 116 replaced DDE with TCP, obviously it cannot be happening.

# DDE is still used to detect whether DXKeeper is running, but DDE errors should not occur when a QSO is being conveyed from N1MM to DXKeeper. Note that this change from DDE to TCP was made because of the interference between UDP and DDE, not because anyone other than you ever reported DDE errors.


i wrote a couple apps to work with DDE years ago, and it had similar issues where it would not work in maybe 1 of 1000 times. i dont recall the details, its far too long ago. in my case I had to write a DDE server for a customer's DDE reporting client for some stat updates, and it missed one once and a while. In our case, it didnt make much diff as the next update would re-write the stale entry anyways and it wasnt a deal killer problem. missing a single update just wasn't critical. we moved on later with an entirely different mechanism as well, never getting the the bottom of the DDE issue.


# DXLab applications have relied heavily on DDE for interoperation since their introduction in 2001. Other than in cases where Windows is under duress, DDE has been reliable. Because DDE typically involves collaboration among more than one asynchronous process, concurrency defects in applications -- e.g. race conditions, starvation, unanticipated code paths -- often produce intermittent errors that are erroneously blamed on DDE.


my windows box here (not a vm) has far more resources available than is required so hard to imagine it was "in trouble".

the thing is dedicated to the ham radio chores alone, and is coasting in cpu cycles, awash in memory & disk (storage, I/O). There wasn't much running on it other than n1mm/dxlab.

# Windows employs many data structures that are limited in size or capacity. If one or more of these data structures run low or become exhausted, trouble ensues. Absent a course in Windows Internals and constant monitoring with appropriate tools, users should reboot Windows at a frequency that maintains reliable operation. I reboot weekly.


exploring options a little bit, I did go to LA0FA's web site http://www.la0fa.com/content/home/default4.asp?Content_ID=14 (which is also v116) and downloaded the GW zip he has there thinking maybe I'd fiddle with it a bit. but i no longer have a vb6 environment to play in and saw this topic so i abandoned any ideas for diddling with it since its fixed. getting rid of DDE was/is the answer...

# That code base is several years out of date.


if 116 replaced DDE IPC mechanism with TCP, I would think thats the end of it... RIP DDE... glad the conversion was made.

+ As I posted here last week, version 1.1.6 of the N1MM-DXKeeper Gateway
+ uses TCP (instead of DDE) to convey QSOs to DXKeeper.
+ https://groups.io/g/DXLab/message/196903>

agreed - if you depend on delivery with UDP the appl itself must be responsible for implementing reliability, where TCP its guaranteed. while UDP on the same box should be very reliable, still no way to guarantee delivery...

# The observed behavior was that if the Gateway version 1.1.5 process was in DDE rendezvous delivering a QSO to DXKeeper when a new UDP message arrived from N1MM, Windows discarded the UDP message -- which is perfectly legal. This only became problematic when N1MM began emitting 4 UDP messages for a logged QSO that specifies 4 counties.

73,

Dave, AA6YQ


Re: DXKeeper Changing Windows focus

Dave AA6YQ
 

+ AA6YQ comments below

As far as I recall it has always done this - it just became more annoying to me in the last few days.

I am not aware of any "keyboard helper" application installed (I don't recall installing anything since a PC rebuild earlier in the year after a disk fault).

I cannot see what happens in Safe Mode as DXKeeper appears to start off screen (not really a surpise as I normally have dual screens at much higher resolution than the single screen appears in Safe Mode).

+ To overcome that,

1. reboot Windows into "Safe mode with networking"

2. start the Launcher

3. start DXKeeper

4. at the bottom of the Launcher's Configuration window, click the Reset button; DXKeeper will display its window(s) on the primary monitor.

73,

Dave, AA6YQ


Re: N1MM-DXKeeper Gateway version 1.1.6

Kent N6WT
 

Dave

I think it said something about a TCP error and that the call sign had not been logged. I did not take much note of since I did not notice as it happened but a few call signs later. 

There was no error log. 

Thanks
73
Kent
N6WT


On Mon, Oct 26, 2020 at 3:19 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

During the CQ-WW-SSB contest, I was a really being casual. I was only looking for DX that I need to fill bands that I needed for the year. For the contest I only logged 117 Q's. I did have 2 instances of a TCP error that showed up in the gateway where a qso was not transferred into DXK, one right after the other, but after that no other problems.

+ What was the text of the error message?

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

aa6yq (at) ambersoft.com

        73,

                Dave, AA6YQ







Re: N1MM-DXKeeper Gateway version 1.1.6

Dave AA6YQ
 

+ AA6YQ comments below

During the CQ-WW-SSB contest, I was a really being casual. I was only looking for DX that I need to fill bands that I needed for the year. For the contest I only logged 117 Q's. I did have 2 instances of a TCP error that showed up in the gateway where a qso was not transferred into DXK, one right after the other, but after that no other problems.

+ What was the text of the error message?

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

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Re: Apparent Bug in Commander?

Dave AA6YQ
 

+ AA6YQ comments below

When typing into the 'Memory notes' fields, characters that match modes (F == FM, A == AM, etc) will change the mode on the radio.

I have replicated this on purpose, and otherwise repeatedly.

To reproduce (100%):

Be tuned in to a frequency and in SSB mode. Select "Memory Banks" and then the "Memory Notes" screen. Click on an empty field and observe field is selected and cursor is evident in field. Type 'F' and radio changes to FM. The "F" character appears in the "Memory Notes" section. Type "A", radio switches to AM. Characters "FA" appear in "Memory Notes". Repeat with R (RTTY), C (CW) and P (PSK). Characters "FARCP" appear in "Memory Notes" section.


+ In DXKeeper 14.5.8, I added a set of keyboard short cuts activated by depressing the Shift key while striking the A, B, C, D, F, L, M, P, Q, R, U, or X keys. As documented in

<https://www.dxlabsuite.com/commander/Help/KeyboardShortcuts.htm>

+ some of these initiate a mode change (and move keyboard focus to VFO A or the Main VFO), and some of them perform other actions. Unfortunately, these keyboard shortcuts are also active in the "Memory Bank" panel. I have corrected this defect in the next version of Commander, and emailed this version to you.

73,

Dave, AA6YQ

11061 - 11080 of 208048