Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: WSQ2 new version uploaded

To: [email protected]
Subject: Re: LF: WSQ2 new version uploaded
From: wolf_dl4yhf <[email protected]>
Date: Sun, 09 Mar 2014 23:38:03 +0100
Authentication-results: mx.google.com; spf=neutral (google.com: 195.171.43.25 is neither permitted nor denied by best guess record for domain of [email protected]) smtp.mail=[email protected]
Delivered-to: [email protected]
In-reply-to: <[email protected]>
References: <006b01cf3969$43a83480$caf89d80$@de> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
Hi Tobias,

Ok, thanks for testing. Compared to some other modifications, the serial port issue should be easy to fix.


You wrote:

suggestion :
K1JT's programs do open the serial port just at the start of each transmit sequence and close the serial port immediately after the end of this transmission. By this feature more than one program can run at a time using the same serial port for PTT, as long as only one program wants to transmit at any time. i.e. you can run WSPR-x and WSJT-x simultaneously without the need to deactivate the (same) serial port of the program that is on receive only. It would be nice if WSQ would behave similar.

Ok, makes sense.. and lines up with Michel's reply which just arrived here ... but will the port's RTS and DTR output remain safely in the 'receive' state when WSQ closes the serial port after each transmit-over ? One may assume that, when closing the port all outputs switch back to the default state - or leave them as-is, until another call of the 'EscapeCommFunction'.

Further experimentation will show...

73 and good night,
  Wolf .






<Prev in Thread] Current Thread [Next in Thread>