Re: [wsjt-devel] 6665 Decode Button Stuck

Resolved in 6669. 6972 adds new issue - bilingual decodes (JT65/9) fail - JT9 is decoded, but not JT65. When switching to JT65 only mode, just a few decodes make it out of many visible in waterfall. Switched to single decode mode and got "error starting or running (path)/jt9 -s" error at decode

Re: [wsjt-devel] 6665 Decode Button Stuck

On 04/05/2016 03:28, George J Molnar wrote: > Built 6665 for OS X tonight - after the first decode cycle, the Decode > button lights and stays lit. No further decodes. Hi George, the most likely reason for this is a crash of the decoder component of WSJT-X. If this is readily reproducible,

Re: [wsjt-devel] r6665 and mode flag

On 04/05/2016 09:43, SM0THU wrote: > in r6665 the mode flag for JT65 has changed from # to *. It’s visible in the > Band Activity table and also sent in the UDP network messages. Is this > intentional? > > In my application, JT-Bridge, I translate this to e.g. JT65. Are there any > other

Re: [wsjt-devel] r6665

On 04/05/2016 05:03, Michael Black wrote: > Double-clicking an entry which should change mode from the current > mode does not change mode. > > Seems both directions are broken JT65->JT9 and JT9->JT65 Hi Mike, this should be repaired now, at least for HF operating. 73 Bill G4WJS.

Re: [wsjt-devel] Double-click on blank area

On 05/05/2016 01:37, Joe Taylor wrote: > It seems that the correct behavior for double-click on any blank line > should be to do nothing, right?? Hi Joe, this should be fixed by r6670. 73 Bill G4WJS. -- Find and fix

Re: [wsjt-devel] Double-click on blank area

On 05/05/2016 01:37, Joe Taylor wrote: > It seems that the correct behavior for double-click on any blank line > should be to do nothing, right?? Hi Joe, yes definitely. that has probably been that way for a long time. I can have a look at that now as I am working with the decodes processing

[wsjt-devel] Double-click on blank area

Hi Bill and all, I've just noticed the following unwanted behavior. It may have been present for a long time. With both decoded text areas erased and the "Tx even/1st" box checked, double-clicking in either text window will uncheck the box. It seems that the correct behavior for double-click

Re: [wsjt-devel] WSJT-X: Using with I/Q data

On 04/05/16 18:07, Bill Somerville wrote: > Am I right in assuming that transmitting using the input CODEC is not going > to produce a faithful signal given that the SDR hardware is expecting > I/Q data rather than PCM audio? Yes. This will produce a DSB signal to the detriment of other band

Re: [wsjt-devel] WSJT-X: Using with I/Q data

Both is more accurately correct ... The i/q audio ,left & right channels are time domain shifted to produce a image rejection in the mixed (more accurate to say added by transformer) output of the sdr. As long as the audio frequency is not shifted a few kHz from where the image rejection is

[wsjt-devel] WSJT-X: Using with I/Q data

Hi all, I have been helping out Jim W6JHB build a Linux version of WSJT-X with support for the custom USB Hamlib devices. This is because he has an OmniaSDR device which is a reincarnation of the AE9RB Peaberry v2 SDR. This device is controlled by a few custom USB commands including setting

Re: [wsjt-devel] r6665 and mode flag

I should probably mention that I use OS X > On 04 May 2016, at 10:43, SM0THU wrote: > > Hi all, > > in r6665 the mode flag for JT65 has changed from # to *. It’s visible in the > Band Activity table and also sent in the UDP network messages. Is this > intentional? > > In

[wsjt-devel] r6665 and mode flag

Hi all, in r6665 the mode flag for JT65 has changed from # to *. It’s visible in the Band Activity table and also sent in the UDP network messages. Is this intentional? In my application, JT-Bridge, I translate this to e.g. JT65. Are there any other changes or values that I should be aware