Date   
Re: double-check the start time in the WSJT-X "Log QSO" window before clicking the OK button!

g4wjs
 

On 25/03/2019 18:42, Dave AA6YQ wrote:
+ DXKeeper and WinWarbler provide the option to automatically record the QSO start time when you record a report from your QSO partner. This eliminates inaccuracy from a "long chase".
Hi Dave,

that's about the only option that no one requested for their version of when a WSJT-X QSO starts, hi hi!



--
73

Bill

G4WJS.

Re: double-check the start time in the WSJT-X "Log QSO" window before clicking the OK button!

Dave AA6YQ
 

+ AA6YQ comments below

we have some outstanding requests to try and improve the QSO start time logic so things may change a bit.

Personally I have never understood why a QSO start time should carry any weight for anyone other than the station making the QSO. It is common to start calling a DX station well before the DX station is aware that a QSO is in progress, OTOH the end time of a successful QSO is highly likely to be similar for both stations and is most relevant to the point in time when the criteria for a complete QSO are met.

+ Both eQSL and LoTW set an upper bound on the difference between the start times uploaded by QSO partners.

+ DXKeeper and WinWarbler provide the option to automatically record the QSO start time when you record a report from your QSO partner. This eliminates inaccuracy from a "long chase".

73,

Dave, AA6YQ

Re: double-check the start time in the WSJT-X "Log QSO" window before clicking the OK button!

g4wjs
 

On 25/03/2019 18:19, Dave AA6YQ wrote:
+ AA6YQ comments below

the issue is probably not so much when the start time gets set but when it gets reset if a QSO is aborted. We have had several requests to try and give accurate start times but users have different definitions of when a QSO starts, this has resulted in quite complex logic. Aborting a QSO by hitting ESC or F4 will ensure that any recorded start time is abandoned and is most likely to result in a reasonable start time for the next QSO made.

+ Thanks, Bill! I've added your advice to

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

+ and

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

73,

Dave, AA6YQ
Hi Dave,

we have some outstanding requests to try and improve the QSO start time logic so things may change a bit.

Personally I have never understood why a QSO start time should carry any weight for anyone other than the station making the QSO. It is common to start calling a DX station well before the DX station is aware that a QSO is in progress, OTOH the end time of a successful QSO is highly likely to be similar for both stations and is most relevant to the point in time when the criteria for a complete QSO are met.

73
Bill
G4WJS.



--
73

Bill

G4WJS.

Re: double-check the start time in the WSJT-X "Log QSO" window before clicking the OK button!

Dave AA6YQ
 

+ AA6YQ comments below

the issue is probably not so much when the start time gets set but when it gets reset if a QSO is aborted. We have had several requests to try and give accurate start times but users have different definitions of when a QSO starts, this has resulted in quite complex logic. Aborting a QSO by hitting ESC or F4 will ensure that any recorded start time is abandoned and is most likely to result in a reasonable start time for the next QSO made.

+ Thanks, Bill! I've added your advice to

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

+ and

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

73,

Dave, AA6YQ

Re: double-check the start time in the WSJT-X "Log QSO" window before clicking the OK button!

g4wjs
 

On 25/03/2019 17:38, Dave AA6YQ wrote:
This morning, Björn SM7IUN and I had a QSO on 20m FT8. SpotCollector received the "QSO logged" message from WSJT-X, and directed
DXKeeper to upload the QSO information to LoTW and eQSL.

I soon received an email message from Björn pointing out that the QSO start time I'd uploaded was ~20 minutes earlier than what he
had logged. Looking at the logged QSO in DXKeeper showed a "QSO Begin" time that was ~20 minutes earlier than the "QSL End" time,
though our QSO took 1 minute from initial call to "73". Checking the WSJT-X log file revealed the same Begin and End times logged in
DXKeeper.

Bill G4WJS, I checked

<http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.0.0.html#LOGGING>

in search of what event sets the "QSO Start" time proposed by WSJT-X in the "Log QSO" window, but there's nothing mentioned. What
triggers the setting of this time in the WSJT-X "Log QSO" window?

73,

Dave, AA6YQ
Hi Dave,

the issue is probably not so much when the start time gets set but when it gets reset if a QSO is aborted. We have had several requests to try and give accurate start times but users have different definitions of when a QSO starts, this has resulted in quite complex logic. Aborting a QSO by hitting ESC or F4 will ensure that any recorded start time is abandoned and is most likely to result in a reasonable start time for the next QSO made.



--
73

Bill

G4WJS.

double-check the start time in the WSJT-X "Log QSO" window before clicking the OK button!

Dave AA6YQ
 

This morning, Björn SM7IUN and I had a QSO on 20m FT8. SpotCollector received the "QSO logged" message from WSJT-X, and directed
DXKeeper to upload the QSO information to LoTW and eQSL.

I soon received an email message from Björn pointing out that the QSO start time I'd uploaded was ~20 minutes earlier than what he
had logged. Looking at the logged QSO in DXKeeper showed a "QSO Begin" time that was ~20 minutes earlier than the "QSL End" time,
though our QSO took 1 minute from initial call to "73". Checking the WSJT-X log file revealed the same Begin and End times logged in
DXKeeper.

Bill G4WJS, I checked

<http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.0.0.html#LOGGING>

in search of what event sets the "QSO Start" time proposed by WSJT-X in the "Log QSO" window, but there's nothing mentioned. What
triggers the setting of this time in the WSJT-X "Log QSO" window?

73,

Dave, AA6YQ

Re: WSJT-X 2.0 will not trigger PTT thru DX Lab Commander

Jerome Sodus
 

Hello Ed K0IL,
Since you are using SignaLink-USB, I recommend that you call Jason at Signalink for assistance.
Two weeks ago, he helped me with a circumstance somewhat similar to yours.
He can be reached at 541.862.2639 on Monday, Wednesday, Friday from 4pm to 8pm ET.
Just leave a message; he'll return your call and take as much time as needed to fix the issue.
73 Jerry KM3K

Re: WSJT-X 2.0 will not trigger PTT thru DX Lab Commander

Dave AA6YQ
 

An Icom IC-756 cannot be switched between RX and TX by sending it CAT commands.

If appropriately configured, your Signalink USB should provide RX-TX switching using VOX. See

<http://www.tigertronics.com/files/slusbmanual_win7810.pdf>

WSJT-X must then be configured to use VOX for PTT.


Alternatively, you can enable Commander to switch your transceiver between RX and TX by providing an interface between the Primary
CAT serial port's RTS or DTR signal and your IC-756's SEND input. See the sample circuits shown in the

"If your transceiver requires an external interface for RX-TX switching"

section near the end of

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

Then configure Commander's Primary CAT Port's RTS or DTR selector accordingly:

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

To test this, click the TX button in the PTT panel on the General tab of Commander's Configuration window, and your IC-756 should
switch from RX to TX.

73,

Dave, AA6YQ

WSJT-X 2.0 will not trigger PTT thru DX Lab Commander

Ed K0iL
 

Sorry if this has been covered already, but I am behind on reading DX Lab posts.   But did not see this in the last 100 posts.   

 

Trying to set up WSJT-X 2.0 configurations to work with my DX Lab suite Commander radio controls. 

 

I get to the point in the manual instructions (and wiki instructions too) to “Test CAT”, and that goes green showing it works.

 

Then I try to perform the “Test PTT”, and the button turns red, but no matter how long I wait, it never keys up the radio to TX. 

 

I’ve tried changing the PTT Method from CAT to VOX, and again the “Test CAT” works with green indication, but the “Test PTT” is greyed out so try “Tune”  from the main window. Still; no TX response. 

 

Here are the radio “settings”:
Rig: DX Lab Suite Commander
Poll Interval: 1s

PTT Method: CAT or VOX (tried both)

Mode: USB

Split Op: Rig

 

General settings:

Checked:

Blank line between decoding periods

Tx messages to Rx freq window

Double-click on call sets Tx enable

Disable Tx after sending 73

Allow Tx freq changes while transmitting

Tx watchdog: 6 min

 

The receiver side is working, and I am watching lots of folks making QSOs, but I’m not able to transmit in FT8 mode during the configuration settings TX tests. 

 

WinWarbler keys up my radio in CW mode using WinKey with no problems.  So I think my Commander is set to do that.  Radio is Icom 756 (not pro models).  Using SingalLink USB. 

 

Any ideas what I am missing here? 

 

73, de ed -K0iL

Omaha, NE

 

Re: Database recovery after a few year absents

Dan Scott
 

Dave,

 

It worked Great!

 

I have a few things to fix, which were likely there anyway.  Just a hand full of “Broken: invalid primary or secondary subdivision” message that I need to research (all 1X1 calls)

 

It is so nice getting this all back 😊

 

Thanks for the help!

 

Dan

 

Sent from Mail for Windows 10

 

From: Dave AA6YQ
Sent: Sunday, March 24, 2019 5:33 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Database recovery after a few year absents

 

Thanks for the responses. Here's my advice.

 

1. With DXKeeper running on your current computer,

 

1a. On the main window's "Log QSOs" tab, click the Filter panel's X button so that all QSOs are present in the Log Page Display

 

1b. on the Main window's "Export QSOs" panel,

 

1b-i set the "Options" panel's to "Export standard ADIF"

 

1b-ii check the "Export QTH definitions" box

 

1b-iii check the "Export callsigns with leading !" box

 

1b-iv click the Start button, and save the export ADIF to a file named W0RO-recent.ADI

 

2. Terminate DXKeeper

 

3. In your new computer's C:\DXLab\DXKeeper\Databases folder, rename the file

 

W0RO.mdb

 

to

 

W0R0-recent.mdb

 

4. Copy the file W0R0.mdb from

 

D:\Old-DXKeeper-Log\W0RO.mdb

 

into your new computer's C:\DXLab\DXKeeper\Databases folder

 

5. start DXKeeper, and confirm that it contains the QSOs made on your old computer

 

6. on the "Import QSO's" tab

 

6a. clear all boxes in the "options" panel except "Recor import errors in error file"

 

6b. set the "ADIF style options" panel to "standard ADIF"

 

6c. clear the boxes in the "Duplicate checking", "Substitution options", and "Replacement options" panels.

 

6d. click the Start button, and select the ADIF file your imported in step 1.b-iv above

 

7. On the Main window's "Log QSO" tab, confirm that both your old and recent QSOs are present

 

8. On the Main window's "my QTHs" panel, confirm that the "myQTH" from your recent log file is present.

 

          73,

 

            Dave, AA6YQ

 

 

 

 

-----Original Message-----

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dan Scott

Sent: Sunday, March 24, 2019 4:19 PM

To: DXLab@groups.io

Subject: Re: [DXLab] Database recovery after a few year absents

 

Sorry for the delay in response.  Out of town meetings/travel.

 

 

1.            Assumptions are correct

 

                a.            Fresh install.

                b.            All apps configured in that fresh install

                c.             No need to bring configuration files across

 

2.            No log file overlap – Also the location (MyQTH) of the new installation is unique

3.

 

 

 

 

From: Dave AA6YQ <mailto:aa6yq@...>

Sent: Monday, March 18, 2019 5:37 PM

To: DXLab@groups.io

Subject: Re: [DXLab] Database recovery after a few year absents

 

 

+ AA6YQ comments below

 

 

After moving from a house then through a series of apartments,  I have gotten on the air via in-apartment antenna.

 

 

*             I did a fresh install of the DX Suite about 4 months back and started using DXkeeper.   At the same time, my old “radio” computer was in storage.

 

 

+ I assume that you created a new log file on your current computer, and began logging QSOs in that new log file. I also assume that you've already configured each of your DXLab apps on your current computer, and thus have no need of settings from your "old radio computer".

 

<W0RO> Correct

 

 

*             My old “radio” computer did not survive all the moves, but the drive is recoverable.  Based on the timestamps the last update with my old computer was June 2016.

 

 

+ You have two log files that don't overlap in time. Before I describe the procedure for combining their contents into a single log file, some questions:

 

1.            what is the name of the log file on your "old radio computer"?

 

DB old computer:

 

D:\Old-DXKeeper-Log\W0RO.mdb

 

Size:  4,904 KB

 

Approx contacts: 1000 to 1500

 

 

2.            what is the name of the log file on your current computer?

 

Current DB:

 

C:\DXLab\DXKeeper\Databases\W0RO.mdb

 

Size:  992 KB

 

Approx contacts: 50

 

 

3.            how many "my QTHs" are defined in the log on your "old radio computer"?

 

I do not know.  My guess is no more that 20

 

 

4.            how many "my QTHs" are defined in the log on your new computer?

 

                a.            1 – The myQTH in the new install is Unique when compared to the old install

 

 

73,

 

Dan

 

 

 

 

 

 

 

 

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>             Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>   

 

 

 

 

 

 

Re: Database recovery after a few year absents

Dave AA6YQ
 

Thanks for the responses. Here's my advice.

1. With DXKeeper running on your current computer,

1a. On the main window's "Log QSOs" tab, click the Filter panel's X button so that all QSOs are present in the Log Page Display

1b. on the Main window's "Export QSOs" panel,

1b-i set the "Options" panel's to "Export standard ADIF"

1b-ii check the "Export QTH definitions" box

1b-iii check the "Export callsigns with leading !" box

1b-iv click the Start button, and save the export ADIF to a file named W0RO-recent.ADI

2. Terminate DXKeeper

3. In your new computer's C:\DXLab\DXKeeper\Databases folder, rename the file

W0RO.mdb

to

W0R0-recent.mdb

4. Copy the file W0R0.mdb from

D:\Old-DXKeeper-Log\W0RO.mdb

into your new computer's C:\DXLab\DXKeeper\Databases folder

5. start DXKeeper, and confirm that it contains the QSOs made on your old computer

6. on the "Import QSO's" tab

6a. clear all boxes in the "options" panel except "Recor import errors in error file"

6b. set the "ADIF style options" panel to "standard ADIF"

6c. clear the boxes in the "Duplicate checking", "Substitution options", and "Replacement options" panels.

6d. click the Start button, and select the ADIF file your imported in step 1.b-iv above

7. On the Main window's "Log QSO" tab, confirm that both your old and recent QSOs are present

8. On the Main window's "my QTHs" panel, confirm that the "myQTH" from your recent log file is present.

73,

Dave, AA6YQ

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dan Scott
Sent: Sunday, March 24, 2019 4:19 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Database recovery after a few year absents

Sorry for the delay in response. Out of town meetings/travel.



1. Assumptions are correct

a. Fresh install.
b. All apps configured in that fresh install
c. No need to bring configuration files across

2. No log file overlap – Also the location (MyQTH) of the new installation is unique
3.







From: Dave AA6YQ <mailto:@AA6YQ>
Sent: Monday, March 18, 2019 5:37 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Database recovery after a few year absents



+ AA6YQ comments below



After moving from a house then through a series of apartments, I have gotten on the air via in-apartment antenna.



* I did a fresh install of the DX Suite about 4 months back and started using DXkeeper. At the same time, my old “radio” computer was in storage.



+ I assume that you created a new log file on your current computer, and began logging QSOs in that new log file. I also assume that you've already configured each of your DXLab apps on your current computer, and thus have no need of settings from your "old radio computer".

<W0RO> Correct



* My old “radio” computer did not survive all the moves, but the drive is recoverable. Based on the timestamps the last update with my old computer was June 2016.



+ You have two log files that don't overlap in time. Before I describe the procedure for combining their contents into a single log file, some questions:

1. what is the name of the log file on your "old radio computer"?

DB old computer:

D:\Old-DXKeeper-Log\W0RO.mdb

Size: 4,904 KB

Approx contacts: 1000 to 1500



2. what is the name of the log file on your current computer?

Current DB:

C:\DXLab\DXKeeper\Databases\W0RO.mdb

Size: 992 KB

Approx contacts: 50



3. how many "my QTHs" are defined in the log on your "old radio computer"?

I do not know. My guess is no more that 20



4. how many "my QTHs" are defined in the log on your new computer?

a. 1 – The myQTH in the new install is Unique when compared to the old install



73,

Dan














<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Re: question regarding com port baud rate

Dave AA6YQ
 

+ AA6YQ comments below

This sounds complicated to me.
Can i change any card or slot in a new card to shunt the problem around?

+ The procedure described below will reliable determine whether the computer or radio is at fault.

+ You could take a wild guess that the USB interface in your computer is at fault, purchase a device like this one

<https://www.amazon.com/StarTech-com-Port-PCI-Express-Card/dp/B00WJOVQB2/ref=asc_df_B00WJOVQB2/?tag=hyprod-20&linkCode=df0&hvadid=319185484784&hvpos=1o2&hvnetw=g&hvrand=4242802553258170515&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9001879&hvtargid=pla-441200318528&psc=1&tag=&ref=&adgrpid=63609080556&hvpone=&hvptwo=&hvadid=319185484784&hvpos=1o2&hvnetw=g&hvrand=4242802553258170515&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9001879&hvtargid=pla-441200318528>

+ and plug the IC-7300 cable into it, but if Commander still can't control the radio at 115,200 baud, you will have only ruled out one of several potential causes of the problem.

73,

Dave, AA6YQ

Re: Database recovery after a few year absents

Dan Scott
 

Sorry for the delay in response.  Out of town meetings/travel.

 

  1. Assumptions are correct
    1. Fresh install.
    2. All apps configured in that fresh install
    3. No need to bring configuration files across
  2. No log file overlap – Also the location (MyQTH) of the new installation is unique
  3.  

 

 

 

From: Dave AA6YQ
Sent: Monday, March 18, 2019 5:37 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Database recovery after a few year absents

 

+ AA6YQ comments below

 

After moving from a house then through a series of apartments,  I have gotten on the air via in-apartment antenna.

 

*             I did a fresh install of the DX Suite about 4 months back and started using DXkeeper.   At the same time, my old “radio” computer was in storage. 

 

+ I assume that you created a new log file on your current computer, and began logging QSOs in that new log file. I also assume that you've already configured each of your DXLab apps on your current computer, and thus have no need of settings from your "old radio computer".

<W0RO> Correct

 

*             My old “radio” computer did not survive all the moves, but the drive is recoverable.  Based on the timestamps the last update with my old computer was June 2016. 

 

+ You have two log files that don't overlap in time. Before I describe the procedure for combining their contents into a single log file, some questions:

  1. what is the name of the log file on your "old radio computer"?

DB old computer:

D:\Old-DXKeeper-Log\W0RO.mdb

Size:  4,904 KB

Approx contacts: 1000 to 1500

 

  1. what is the name of the log file on your current computer?

Current DB:

C:\DXLab\DXKeeper\Databases\W0RO.mdb

Size:  992 KB

Approx contacts: 50

 

  1. how many "my QTHs" are defined in the log on your "old radio computer"?

I do not know.  My guess is no more that 20

 

  1. how many "my QTHs" are defined in the log on your new computer?
    1. 1 – The myQTH in the new install is Unique when compared to the old install

 

73,

Dan

 

 

 

 

 

 

Re: question regarding com port baud rate

ghassan chammas
 

This sounds complicated to me.
Can i change any card or slot in a new card to shunt the problem around?

Od5ya



Sent from Samsung tablet.

-------- Original message --------
From: Dave AA6YQ <aa6yq@...>
Date: 24/03/2019 19:52 (GMT+02:00)
To: DXLab@groups.io
Subject: Re: [DXLab] question regarding com port baud rate

+ AA6YQ comments below

I meant commander - radio handshake is lost. I.e beyond 9600 bauds commander loses control over the radio.

Please note that the ic 7300 is connected to pc via a usb cable.
Pc is a i3 with 8gb ram
No antivirus is intalled yet and firewall is disabled.

+ You don't specify the i3's clock frequency or cache organization, but I'd be surprised if any i3 would be unable to keep up with 115,200 baud.

+ Assuming that Commander and the radio are both correctly configured, debugging this would require using a serial port analyzer to monitor the signal received from the USB interface internal to the IC-7300 when operated at 9600 baud and when operated at 115,200 baud. This would reveal whether the information being received from the PC is correctly formatted, and whether the radio is correctly responding.

           73,

                Dave, AA6YQ




Re: question regarding com port baud rate

Dave AA6YQ
 

+ AA6YQ comments below

I meant commander - radio handshake is lost. I.e beyond 9600 bauds commander loses control over the radio.

Please note that the ic 7300 is connected to pc via a usb cable.
Pc is a i3 with 8gb ram
No antivirus is intalled yet and firewall is disabled.

+ You don't specify the i3's clock frequency or cache organization, but I'd be surprised if any i3 would be unable to keep up with 115,200 baud.

+ Assuming that Commander and the radio are both correctly configured, debugging this would require using a serial port analyzer to monitor the signal received from the USB interface internal to the IC-7300 when operated at 9600 baud and when operated at 115,200 baud. This would reveal whether the information being received from the PC is correctly formatted, and whether the radio is correctly responding.

73,

Dave, AA6YQ

Re: question regarding com port baud rate

Greg Engle
 

Do you have the radio  CI-V Baud rate set correctly on the radio. (Page 12-8 in the manual). If it’s set to AUTO try one of the fixed settings.

 

Set Function/CI-V Baud Rate.

 

Just a guess…

 

Greg

NZ6E

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of ghassan chammas via Groups.Io
Sent: Saturday, March 23, 2019 10:13 PM
To: DXLab@groups.io
Subject: Re: [DXLab] question regarding com port baud rate

 

Hello Dave

 

I meant commander - radio handshake is lost. I.e beyond 9600 bauds commander loses control over the radio.

 

Please note that the ic 7300 is connected to pc via a usb cable.

Pc is a i3 with 8gb ram

No antivirus is intalled yet and firewall is disabled. 

 

Regards

Ghassan

 

 

 

Sent from Samsung tablet.

 

-------- Original message --------

From: Dave AA6YQ <aa6yq@...>

Date: 24/03/2019 02:29 (GMT+02:00)

To: DXLab@groups.io

Subject: Re: [DXLab] question regarding com port baud rate

 

+ AA6YQ comments below

I have 2 qth and 2 similar setups with 2 icom 7300 and 2 (Almost) similar win 7 pc.
In my qth1 i have dxlab installed and running perfectly, with the commander waterfall  running smoothly at the baud rate of 115000.

In qth2, same setup with same workspace and same ic7300 setup, however i cannot run the fom port but at 9600 bauds. If i go one notch higher i loose the commander-pc handshake.

+ What do you mean by "lose the Commander-PC handshake"? Exactly what happens?

So in qth2 i am unable to run the waterfall.

My question is :

In a pc, what determines the capability to run a com port at a high baud rate?

+ 115,200 baud is approximately 10K characters per second, which from a computing perspective is slow, and should not be problematic. There are many possible factors. Pending your answer to my question above, I suggest starting by temporarily disabling your firewall and anti-malware apps.

        73,

                Dave, AA6YQ



Re: question regarding com port baud rate

ghassan chammas
 

Hello Dave

I meant commander - radio handshake is lost. I.e beyond 9600 bauds commander loses control over the radio.

Please note that the ic 7300 is connected to pc via a usb cable.
Pc is a i3 with 8gb ram
No antivirus is intalled yet and firewall is disabled. 

Regards
Ghassan



Sent from Samsung tablet.

-------- Original message --------
From: Dave AA6YQ <aa6yq@...>
Date: 24/03/2019 02:29 (GMT+02:00)
To: DXLab@groups.io
Subject: Re: [DXLab] question regarding com port baud rate

+ AA6YQ comments below

I have 2 qth and 2 similar setups with 2 icom 7300 and 2 (Almost) similar win 7 pc.
In my qth1 i have dxlab installed and running perfectly, with the commander waterfall  running smoothly at the baud rate of 115000.

In qth2, same setup with same workspace and same ic7300 setup, however i cannot run the fom port but at 9600 bauds. If i go one notch higher i loose the commander-pc handshake.

+ What do you mean by "lose the Commander-PC handshake"? Exactly what happens?

So in qth2 i am unable to run the waterfall.

My question is :

In a pc, what determines the capability to run a com port at a high baud rate?

+ 115,200 baud is approximately 10K characters per second, which from a computing perspective is slow, and should not be problematic. There are many possible factors. Pending your answer to my question above, I suggest starting by temporarily disabling your firewall and anti-malware apps.

        73,

                Dave, AA6YQ




Re: question regarding com port baud rate

Dave AA6YQ
 

+ AA6YQ comments below

I have 2 qth and 2 similar setups with 2 icom 7300 and 2 (Almost) similar win 7 pc.
In my qth1 i have dxlab installed and running perfectly, with the commander waterfall running smoothly at the baud rate of 115000.

In qth2, same setup with same workspace and same ic7300 setup, however i cannot run the fom port but at 9600 bauds. If i go one notch higher i loose the commander-pc handshake.

+ What do you mean by "lose the Commander-PC handshake"? Exactly what happens?

So in qth2 i am unable to run the waterfall.

My question is :

In a pc, what determines the capability to run a com port at a high baud rate?

+ 115,200 baud is approximately 10K characters per second, which from a computing perspective is slow, and should not be problematic. There are many possible factors. Pending your answer to my question above, I suggest starting by temporarily disabling your firewall and anti-malware apps.

73,

Dave, AA6YQ

Re: question regarding com port baud rate

Carl - WC4H
 
Edited

What are your other CAT parameters set at?

Normally a quad core processor (or better) and at least 8GB RAM.

I run it on an older Quad Core (AMD A8-3850 APU 2.90 GHz) with 12 GB RAM & 2 TB H/D with no problems.

73.
Carl - WC4H

question regarding com port baud rate

ghassan chammas
 


Hi Dave
I have 2 qth and 2 similar setups with 2 icom 7300 and 2 (Almost) similar win 7 pc.
In my qth1 i have dxlab installed and running perfectly, with the commander waterfall  running smoothly at the baud rate of 115000.

In qth2, same setup with same workspace and same ic7300 setup, however i cannot run the fom port but at 9600 bauds. If i go one notch higher i loose the commander-pc handshake. So in qth2 i am unable to run the waterfall.

My question is :

In a pc, what determines the capability to run a com port at a high baud rate? It should be the pc because radio and radio setups are the same and dxlab setup is exactly the same. In other words what should be done to my set up in qth2 to run the waterfall?

Thank you very much

Yours
Ghassan
Od5ya
Beirut






Sent from Samsung tablet.