Re: [wsjt-devel] Experimental changes in r8125

> On Sep 29, 2017, at 1:10 PM, Bill Somerville wrote: > > I understand that there will always be a group of users who insist that the > old "Lock Tx=Rx" option is needed Bill, you seem to be under the false impression that everyone wants to work split and cares about

Re: [wsjt-devel] Experimental changes in r8125

+1 73 de Sebastian, W4AS > On Sep 29, 2017, at 4:30 PM, Richard Lamont wrote: > > On 29/09/17 20:10, Bill Somerville wrote: > >> I am failing to see why most of the existing automatic behaviour when >> double-clicking decodes has to be given up just for a number of >>

[wsjt-devel] r8144: Answering a CQ from JTAlert.

Bill, I was checking JTAlert to see what had changed, but it's working again on r8144. Not sure if it's related, just an FYI. 73 de Vince, VA3VF -- Check out the vibrant tech community on one of the world's most

Re: [wsjt-devel] Unable to Build

That did it Richard. Sometimes a little judicial brute force is all that's needed. Thanks. __ Dan - K4SHQ -Original Message- From: Richard Stanley via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] Sent: Friday, September 29, 2017 5:14 PM To: WSJT software development

[wsjt-devel] r8144: Lock Tx.

Thank you, K1JT. I think you found a good compromise for all the Tx=RX related wants and needs. 73 de Vince, VA3VF -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org!

[wsjt-devel] Solve For Calibration Parameters: Suggestion

r8144 When the pop up window shows the results of the calibration run with Slope and Intercept presented, wouldn't it be nice to have a button or check box that says: "Apply Calibration Results Now"...or some such? Right now OK, closes the window, which is fine, but it would save a lot of

[wsjt-devel] Repeating Crash When Changing Slope and Intercept

Every time I either zero out or change the slope and intercept after doing a calibration run, I get a program crash, and stale lock. When I restart, the new values are in place and things run fine. This has been last several versions since I've been playing with FreqCal Currently r8144 73,

Re: [wsjt-devel] Unable to Build

Hello Richard, That did it!  Thanks for your help. 73, ---Paul AK1P PS I checked the log and we've only had one QSO on JT65 so I'll be looking for you on FT8. On 9/29/2017 6:14 PM, Richard Stanley via wsjt-devel wrote: It is a corrupt file somewhere, rename C:/JTSDK/src/wsjtx to say

Re: [wsjt-devel] Experimental changes in r8125 & 8144

Where are you getting the 8144 rc 3 at? gary ww8o On Friday, September 29, 2017 3:07 PM, AB1NJ wrote: Using 8144 here now.  I don't usually post a lot, but I feel as if I have to say something now. Concerning these changes...I really think that: 1) it is now overly

Re: [wsjt-devel] Unable to Build

It is a corrupt file somewhere, rename C:/JTSDK/src/wsjtx to say C:/JTSDK/src/wsjtx1 Then try build-wsjtx rinstall and it will build just fine and update after that. Richard g7oed -Original Message- From: Dan Malcolm Sent: Friday, September 29, 2017 7:37 PM To: 'WSJT software

Re: [wsjt-devel] Unable to Build

I have the same issue here but only for 1.7 If I do build-wsjtx -b dev -n wsjtx-1.8 -c release -t install It updates (to 8084) just fine but build-wsjtx rinstall or build-wsjtx -b dev -n wsjtx -c release -t install both give the same sourceforge update error ? Not over fussed myself as not keen

Re: [wsjt-devel] Auto seq while answering split

Hi folks, I'd like to revisit this topic. I do agree that working split does increase the success rate. However I'm constantly needing to click the Halt Tx button when the CQing station answers another station. The reason as I see it is that the Auto-sequence stop only follows the TX (RED).

Re: [wsjt-devel] Auto-sequence and JT65/JT9

Hello, I strongly agree with Pino. ( I planned to write the same request this week end). JT modes bands become desertic, and the QRP contact is more and more difficult. I understand why automatic sequence was implemented in FT8 only, but the reality is that QSO in JT mode become more dificult to

Re: [wsjt-devel] Experimental changes in r8125

On 29/09/17 20:10, Bill Somerville wrote: > I am failing to see why most of the existing automatic behaviour when > double-clicking decodes has to be given up just for a number of > operators who think that by default one's Tx offset should not be moved > when replying to a CQ or QRZ call. To be

[wsjt-devel] New Internal FreqCal Mode with Solve For ...

r8144 for reference First of all WONDERFUL. Makes all that writing I did superflous. An important reminder (I think): If you are going to do repeated runs using different frequencies (for example, eliminating 20 MHz wwv for a night run, or eliminating 2.5 MHz wwv for a day run), be sure to ZERO

Re: [wsjt-devel] Experimental changes in r8125 & 8144

I fully agree, Rob. It made a 2 handed operation out of a simple mouse click. At least looks like we are going to have an option! On 9/29/2017 3:06 PM, AB1NJ wrote: Using 8144 here now.  I don't usually post a lot, but I feel as if I have to say something now. Concerning these changes...I

Re: [wsjt-devel] Experimental changes in r8125

Just ran across maybe an unintended behavior - Had the "double click on calls sets TX and RX freqs" box checked and was working when double clicking on stations but when I used shift to select a frequency off of another station, everything worked great (I shift-clicked off frequency to avoid

Re: [wsjt-devel] Auto-sequence and JT65/JT9

Auto sequence was implemented with FT8 because of the tight timeframes required to determine which part of the sequence to follow next. There is no such need with JT65 and JT9. Jim S. N2ADV On 9/29/2017 3:09 PM, Pino Zollo wrote: Please, Add autosequence also to JT65/JT9 modes With

Re: [wsjt-devel] Experimental changes in r8125

On 27/09/2017 13:47, Joe Taylor wrote: Experimental new behavior for "Lock Tx=Rx" and for clicking on waterfall and decoded text. Hi Joe, I am failing to see why most of the existing automatic behaviour when double-clicking decodes has to be given up just for a number of operators who think

[wsjt-devel] Auto-sequence and JT65/JT9

Please, Add autosequence also to JT65/JT9 modes With the arrive of FT8 these modes are deadbut I think that they are excellent for QRP Now on FT8 a see big powers...knowing my power and seeing the difference of reports. 73 de Pino ZP4KFX

Re: [wsjt-devel] Experimental changes in r8125 & 8144

Using 8144 here now.  I don't usually post a lot, but I feel as if I have to say something now. Concerning these changes...I really think that: 1) it is now overly complicated, and 2) it worked better before. I always have been one of those that never checked the LockTX=RX box, and liked the

Re: [wsjt-devel] Experimental changes in r8125

Just tested - works great running my shack PC remotely from my iPad. Jim S. N2ADV On 9/29/2017 2:01 PM, Joe Taylor wrote: After further testing in the field, the experimental changes introduced in r8125 and later will now become permanent. In r8144 I have added an option to enforce simplex

Re: [wsjt-devel] Split Operation

Thanks for the good wishes, Morris! I am gradually feeling better...this was my first "high-dose" flu shot and probably my last! The amount of antigen is four times a standard flu shot. Ed, K0KC k0kc@arrl.nethttp://k0kc.us/ On Friday, September 29, 2017, 2:22:29 PM EDT, Morris Wideman

Re: [wsjt-devel] Split Operation

Gary, I agree that people should notice the red line, but I think they tend to get tuned-in to the right-hand window when looking for a response. I know that I have missed a couple myself. Ed, K0KC k0kc@arrl.nethttp://k0kc.us/ On Friday, September 29, 2017, 2:37:26 PM EDT, Gary McDuffie

Re: [wsjt-devel] Experimental changes in r8125

Thanks, Joe!  Building 8144 now and will report back. Jim S. N2ADV On 9/29/2017 2:01 PM, Joe Taylor wrote: After further testing in the field, the experimental changes introduced in r8125 and later will now become permanent. In r8144 I have added an option to enforce simplex operation (thus

Re: [wsjt-devel] Unable to Build

Bill, I have the exact same problem. If I skip the svn update, r8123 will compile just fine. It's only svn that seems to not work. I tried just 'svn cleanup' which (no surprise) did nothing, but then I don't know what arguments to give it. I'm sure there is a path as part of the cleanup

Re: [wsjt-devel] Split Operation

> On Sep 29, 2017, at 12:21 PM, Morris Wideman via wsjt-devel > wrote: > > This is where more and better filters would also be useful when the left > screen is full of calls that have nothing to do with your call or QSO. Hope > you get to feeling better Ed.

Re: [wsjt-devel] Split Operation

This is where more and better filters would also be useful when the left screen is full of calls that have nothing to do with your call or QSO. Hope you get to feeling better Ed.73 Morris wa4mit On Friday, September 29, 2017, 11:03:39 AM CDT, Ed Wilson via wsjt-devel

Re: [wsjt-devel] Experimental changes in r8125

Hi Tim, ... I see that it says not to use “this feature” on the air in the r8120 commit comments, but does that mean we should not use any release r8120 or above on the air? Or is it something that we have to specifically do to use “RR73 NOW” and “NIL NOW”, like enter those into Tx 4

Re: [wsjt-devel] Experimental changes in r8125

After further testing in the field, the experimental changes introduced in r8125 and later will now become permanent. In r8144 I have added an option to enforce simplex operation (thus moving both Tx and Rx frequency) when you double-click a decoded text line. This option allows simpler

[wsjt-devel] Double-click on decoded message

Forwarded Message Subject: [wsjtgroup] Double-click on decoded message Date: Fri, 29 Sep 2017 13:06:11 -0400 From: Joe Taylor j...@princeton.edu [wsjtgroup] Reply-To: Joe Taylor To: Lance Collister, W7GJ ,

[wsjt-devel] Double-click on decoded message

Hi Lance, You must have wondered for a long time why for you, double-clicking on some decoded JT65 messages does not copy the callsign to DX Call, the locator to Dx Grid, and populate the Tx message boxes. Or maybe you figured it out by now. Anyway, I just happened upon the reason and

Re: [wsjt-devel] Experimental changes in r8125

I just deleted the draft email I was composing literally just now about this exact subject - I tend to operate remotely (99% of the time)  While a lot of that is done using a small laptop, I also use my iPad to remotely control my home machine which gets me on the air otherwise I would hardly

Re: [wsjt-devel] Experimental changes in r8125

On 9/29/2017 10:39 AM, George J Molnar wrote: One point about using control-clicks that hasn’t been raised, but might affect usability is the growing number of tablet and other touch screens in use. Double clicking for setting both RX/TX, unless TX Lock is on, is the simplest, most natural

[wsjt-devel] Split Operation

I have been using WSJT-X since its inception and JT65-HF before that. I was always one of those "bad guys" who checked the Tx=Rx box unless I was trying to contact a DX station where dozens of others were probably calling him or her and it made sense to call off-frequency. Over the past couple

Re: [wsjt-devel] Experimental changes in r8125

I just deleted the draft email I was composing literally just now about this exact subject - I tend to operate remotely (99% of the time)  While a lot of that is done using a small laptop, I also use my iPad to remotely control my home machine which gets me on the air otherwise I would hardly

Re: [wsjt-devel] Experimental changes in r8125

One point about using control-clicks that hasn’t been raised, but might affect usability is the growing number of tablet and other touch screens in use. Double clicking for setting both RX/TX, unless TX Lock is on, is the simplest, most natural gesture without a keyboard. At least on my end.

Re: [wsjt-devel] Experimental changes in r8125

It seems to me that an option in the settings for 1) Transceive default (previous "normal") or 2) Split default (DXing/Contest use) might keep both camps happy. Inherently, there are differing default behaviors (and their variations, accomplished by CNTL and ALT clicks) that make sense in each

Re: [wsjt-devel] Unable to Build

On 29/09/2017 12:10, Paul Maciel wrote: I'm not able to build the latest release and keep getting the message that sourceforge is down even though they appear to be back up. Hi Paul, I have checked the SF svn servers a few times over the last hour or so and they seem to be up and stable.

[wsjt-devel] Unable to Build

Hello Everyone, I'm not able to build the latest release and keep getting the message that sourceforge is down even though they appear to be back up.  SVN Check JTSDK Option: Auto SVN Update Enabled