Re: [wsjt-devel] WSJT-X: Rig control updates and more.

On 07/04/2016 23:58, Bill Somerville wrote: > I believe that the few rigs that appear not to have a way of setting > mode without touching bandwidth actually do. For example early CI-V > Icoms have the 06 command to set mode and bandwidth but the bandwidth > part can be omitted which is not

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

On 07/04/2016 23:43, Michael Black wrote: > But why couldn't you just remember the bw from get_mode and keep using > that rather than wholesale changes to hamlib? > And allowing the user to put bandwidth in the rig settings too so, for > examle, you don't have to reset all the bands on your rig

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

That works. Started with both VFOs on LSB and Mode=USB and rig split. On band change it switched to USB and left bandwidth alone. But why couldn't you just remember the bw from get_mode and keep using that rather than wholesale changes to hamlib? And allowing the user to put bandwidth in the rig

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

On 07/04/2016 22:33, Bill Somerville wrote: > I know what is happening now. The issue is due to using a new Hamlib API > function to set split frequency and mode together in one step. This is > essential for many rigs because setting the two separately takes many > VFO swaps which is disruptive to

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

On 07/04/2016 21:40, Michael Black wrote: > In 6589 no bandwidth change Hi Mike, I suggested a minimal test of: "A minimal test is probably to set the rig to something other than USB then start WSJT-X, you may need to select a band in WSJT-X to get it to change the rig mode depending on

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

On 07/04/2016 20:52, Michael Black wrote: > However, on 6597 if I switch split to None and Mode=USB, then the > bandwidth does not change. Hi Mike, assuming this sets the rig mode to USB then a trace of that would be interesting. That is because I don't see how it can avoid changing the

Re: [wsjt-devel] wsjtx 1.5 & 1.6 no longer build on armhf

On 07/04/2016 20:56, Richard Bown wrote: > Thanks Bill > Thats going to be a real PITA. > I'll see what I can do, but I can forecast total disinterest from them. That would surprise me. Being unable to build a Qt application is a big problem that many will report. 73 Bill G4WJS.

Re: [wsjt-devel] wsjtx 1.5 & 1.6 no longer build on armhf

Reply at end On Thu, 7 Apr 2016 20:33:41 +0100 Bill Somerville wrote: > On 07/04/2016 20:08, Richard Bown wrote: > > Hi > > WSJTX 1.5 & 1.6 no longer building on a ARMHF 32 bit plaform:- > > > > /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopenglfunctions.h: In member >

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

I've been using USB/Rig Split for a LONG time. 6590 started changing the bandwidth. Changing to Mode=None stopped it. (still on rig split) 6596 still shows that behavior 6597 still shows that behavior. However, on 6597 if I switch split to None and Mode=USB, then the bandwidth does not

Re: [wsjt-devel] wsjtx 1.5 & 1.6 no longer build on armhf

On 07/04/2016 20:08, Richard Bown wrote: > Hi > WSJTX 1.5 & 1.6 no longer building on a ARMHF 32 bit plaform:- > > /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopenglfunctions.h: In member > function 'void QOpenGLFunctions::glVertexAttrib4fv(GLuint, const GLfloat*)': >

[wsjt-devel] wsjtx 1.5 & 1.6 no longer build on armhf

Hi WSJTX 1.5 & 1.6 no longer building on a ARMHF 32 bit plaform:- /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopenglfunctions.h: In member function 'void QOpenGLFunctions::glVertexAttrib4fv(GLuint, const GLfloat*)': /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopenglfunctions.h:2126:5: error:

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

On 06/04/2016 19:07, Michael Black wrote: > USB > > I found the setting in Advanced for the JT65 receiver bandwidth affects it. ... > > On Wed, Apr 6, 2016 at 1:04 PM, Bill Somerville wrote: >> >On 06/04/2016 19:01, Michael Black wrote: >>> >>First problem I ran into. >>>

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

On 07/04/2016 14:06, George J Molnar wrote: > MLDX talks to the rig directly. In this case, using CAT over serial. It also > provides a UDP interface for other apps. FLDIGI, for example, interacts with > MLDX this way, so frequency display, etc., doesn't need a RigCAT or Hamlib > port

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

Hi Bill, Hope I get this right... MLDX talks to the rig directly. In this case, using CAT over serial. It also provides a UDP interface for other apps. FLDIGI, for example, interacts with MLDX this way, so frequency display, etc., doesn't need a RigCAT or Hamlib port configured. JT-Bridge

Re: [wsjt-devel] Rig control issue v6596

On 07/04/2016 11:53, James Shaver (N2ADV) wrote: > Bill, my K3/HRD6 gremlin is back now too (when split mode = "fake it" > WSJT-X sends commands through HRD and tries to throw the rig into > "split" which causes rig control to fail) Hi Jim & Rob, looks like I have messed up the HRD rig control

Re: [wsjt-devel] Rig control issue v6596

Bill, my K3/HRD6 gremlin is back now too (when split mode = "fake it" WSJT-X sends commands through HRD and tries to throw the rig into "split" which causes rig control to fail) 73, Jim S. N2ADV > On Apr 7, 2016, at 6:22 AM, Bill Somerville wrote: > >> On 07/04/2016

Re: [wsjt-devel] WSJT-X: Rig control updates and more.

On 07/04/2016 04:27, George J Molnar wrote: > OS X 10.11 using JT Bridge and MacLoggerDX. Hi George, how does DXLabs fit into that set up? 73 Bill G4WJS. -- ___ wsjt-devel