FTdx101D RIT, XIT, PTT v o chnaging behvious

[Ian-G3VPX]

piWebCAT has the means for the user to configure selected controls
to be repetitively updated from the corresponding rig status.
( Selected ... because to do them all would use too much CAT bandwidth)

When I switched the rig to Sub Rcvr, I noticed the receiver selection oscillating
between Main and Sub receivers.
I found that the guilty items were PTT (obligatory) adn RIT and XIT (user optional)

Part of the problem was that these are NOT receiver specific commands
and so I was using Main as a dummy parameter. eg: j Main

The careful investigion report below explains the oscillatory behaviour:
-- see j Main with rcvr = Sub

All other none-reciever-specific controls have no problem with using
Main as a dummy parameter. eg: l Main NR

An obvious option from the rigctl command line based report is to use Sub as the
dummy prameter rather than Main..... as no rcvr chnage was noted.
However, the behaviour was different with rigctld in piWebCAT and I still
had the ocillatory behavior.

piWebCAT web browser client sends a vx parameter to the server from a button,
a button group or a slider control.
This is 'X' if none-rcvr-specific or 'A' or 'B' if rcvr specific.
For 'A' and 'B' the server has two records, 'A' and' 'B'.
My first thought was to duplicate each of ptt, rit and xit for A and B (Main and Sub)
... but that doesn't work. .. as illustrated by the report below see below .
... j Main on Main rcvr will switch it to the sub

I haven't checked out set commands T, J and Z yet - thats another job.!

Investigation report - Observed scope decode command sequences are consistent with behaviour.

Rcvr = Main rigctl at command line

RIT
j Sub  >   stays on Main      		scope: IF;
j Main >   switches to Sub rcvr 	scope: IF; VS0; ID; IF; VS1; ID;
                    and stays there

PTT
t Sub > stays on Main rcvr scope: TX; (TX0; returned)
t Main > switches to Sub rcvr scope: IF; VS0; ID; TX; IF; VS1; ID;
and stays there
XIT
z Sub > stays on Msain rcvr scope: IF;
z Main > switches to Sub rcvr scope: IF; VS0; ID; If; VS1; ID;j Main
and stays there

Rcvr = Sub rigctl at command line

RIT
j Sub > stays on Sub
j Main > flashes to Main and back to Sub

PTT
t Sub > stays on Sub
t Main > flashes to Main and back to Sub

XIT

z Sub  >   stays on Sub
z Main >   flashes to Main and back to Sub

Ian Sumner
G3VPX

jtzMainSub.txt

[Ian-G3VPX]

FTdx101D RIT XIT PTT - inappropriate VFO swapping/oscillating fixed

• Thanks

Now we have:

J Main fff and J Sub fff both act on current VFO's RIT offset

... That's fine - becuase that's how the rig behaves

ie:
each rcvr has its own Rx and Tx Clar switch setting
but there is only one pair of switches on the rig
... XIT and RIT buttons on the rig act on the current VFO

each rcvr has its own offsets but there is only one control whcih act on curretn VFO

All the above holds true even when SPLIT is on

BUT

j Main and j Sub report the Main Rcvr RIT offset irrespective of VFO selection

.... So there is no way that I can read Sub rcvr offset

Ian
G3VPX

jMainsubRITXIT.txt

[Ian-G3VPX]

I think j Sub is ok BUT see the following - all rigctl at command line:

RIT on both VFOs and zerod

1. Main selected J Main 300 > Main to 300 OK

2.         "              J Sub    700    >    Sub to 700     OK
   

3.         "             J Sub 80           >    Sub to 80    Flash to Sub and back
   

4. Sub Selected J Sub 900 > Sub to 900 CHANGES to Main VFO !

5. Sub reselected J Main 500 > Sub to 500

6. Sub Selected J Sub 600 > Sub to 600 CHANGES to Main VFO

Decode on 6 - 9 commands! (two without a gap)

   IF;     VS1;      ID;     RC;RU0600;     ID;     IF;     VSO;     ID;

Clearly, the VS0; is swapping to Main VFO

3. repeated for decode
   Main Selected J Sub 80 . Sub to 80 Flashes to Sub and back to main

Decode: IF; VS1; ID; RC;RU0080; ID; IF; VS0; ID;

VS1;    and VS0; flash to Sub and back

Ian
G3VPX

[mdblack98]

I'll need to hook up to fix that one.  Can you set it up so I can access? On Wednesday, November 11, 2020, 03:08:07 PM CST, Ian-G3VPX <notifications@github.com> wrote: I think j Sub is ok BUT see the following - all rigctl at command line: RIT on both VFOs and zerod - Main selected J Main 300 > Main to 300 OK - " J Sub 700 > Sub to 700 OK - " J Sub 80 > Sub to 80 Flash to Sub and back - Sub Selected J Sub 900 > Sub to 900 CHANGES to Main VFO ! - Sub reselected J Main 500 > Sub to 500 - Sub Selected J Sub 600 > Sub to 600 CHANGES to Main VFO Decode on 6 - 9 commands! (two without a gap) IF; VS1; ID; RC;RU0600; ID; IF; VSO; ID; Clearly, the VS0; is swapping to Main VFO - repeated for decode Main Selected J Sub 80 . Sub to 80 Flashes to Sub and back to main Decode: IF; VS1; ID; RC;RU0080; ID; IF; VS0; ID; VS1; and VS0; flash to Sub and back Ian G3VPX — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[mdblack98]

I'm not seeing this behavior at all. Setting on the same VFO doesn't swapSetting on opposite VFO will cause VFO swapping back and forth since RIT is not VFO addressable.Any command which has to change VFO will come back to the original VFO. Rig command: v Rig command: J Sub 100VFO: Rig command: vVFO: Sub Rig command: J Main 100VFO: Rig command: vVFO: Sub VFO: Sub Rig command: J Sub 100VFO: Rig command: vVFO: Sub On Wednesday, November 11, 2020, 03:08:07 PM CST, Ian-G3VPX <notifications@github.com> wrote: I think j Sub is ok BUT see the following - all rigctl at command line: RIT on both VFOs and zerod - Main selected J Main 300 > Main to 300 OK - " J Sub 700 > Sub to 700 OK - " J Sub 80 > Sub to 80 Flash to Sub and back - Sub Selected J Sub 900 > Sub to 900 CHANGES to Main VFO ! - Sub reselected J Main 500 > Sub to 500 - Sub Selected J Sub 600 > Sub to 600 CHANGES to Main VFO Decode on 6 - 9 commands! (two without a gap) IF; VS1; ID; RC;RU0600; ID; IF; VSO; ID; Clearly, the VS0; is swapping to Main VFO - repeated for decode Main Selected J Sub 80 . Sub to 80 Flashes to Sub and back to main Decode: IF; VS1; ID; RC;RU0080; ID; IF; VS0; ID; VS1; and VS0; flash to Sub and back Ian G3VPX — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[mdblack98]

Bill Somerville g4wjs@classdesign.com
To:
hamlib-developer@lists.sourceforge.net

Wed, Dec 2 at 5:42 AM

Hi All,

since commit c70d841.
make dumpmem.exe testrig.exe testtrn.exe testbcd.exe testfreq.exe listrigs.exe testloc.exe rig_bench.exe cachetest.exe cachetest2.exe testrig.sh testfreq.sh testbcd.sh testloc.sh
make[3]: Entering directory '/c/build/hamlib/mingw_64/release/tests'
CC dumpmem.o
C:/Users/bill/src/hamlib/tests/dumpmem.c: In function 'dump_chan':
C:/Users/bill/src/hamlib/tests/dumpmem.c:168:35: warning: passing argument 2 of 'rig_get_channel' makes integer from pointer without a cast [-Wint-conversion]
status = rig_get_channel(rig, &chan, 1);
^~~~~
In file included from C:/Users/bill/src/hamlib/tests/dumpmem.c:27:
C:/Users/bill/src/hamlib/include/hamlib/rig.h:2569:38: note: expected 'vfo_t' {aka 'unsigned int'} but argument is of type 'channel_t *' {aka 'struct channel *'}
vfo_t vfo,
~~~~~~^~~
C:/Users/bill/src/hamlib/include/hamlib/rig.h:74:33: note: in definition of macro 'HAMLIB_PARAMS'

define HAMLIB_PARAMS(protos) protos

                             ^~~~~~

C:/Users/bill/src/hamlib/tests/dumpmem.c:168:42: warning: passing argument 3 of 'rig_get_channel' makes pointer from integer without a cast [-Wint-conversion]
status = rig_get_channel(rig, &chan, 1);
^
In file included from C:/Users/bill/src/hamlib/tests/dumpmem.c:27:
C:/Users/bill/src/hamlib/include/hamlib/rig.h:2570:43: note: expected 'channel_t *' {aka 'struct channel *'} but argument is of type 'int'
channel_t *chan, int read_only));
~~~~~~~~~~~^~~~
C:/Users/bill/src/hamlib/include/hamlib/rig.h:74:33: note: in definition of macro 'HAMLIB_PARAMS'

define HAMLIB_PARAMS(protos) protos

                             ^~~~~~

C:/Users/bill/src/hamlib/tests/dumpmem.c:168:14: error: too few arguments to function 'rig_get_channel'
status = rig_get_channel(rig, &chan, 1);
^~~~~~~~~~~~~~~
In file included from C:/Users/bill/src/hamlib/tests/dumpmem.c:27:
C:/Users/bill/src/hamlib/include/hamlib/rig.h:2568:1: note: declared here
rig_get_channel HAMLIB_PARAMS((RIG *rig,
^~~~~~~~~~~~~~~
make[3]: *** [Makefile:762: dumpmem.o] Error 1
make[3]: Leaving directory '/c/build/hamlib/mingw_64/release/tests'
make[2]: *** [Makefile:1306: check-am] Error 2
make[2]: Leaving directory '/c/build/hamlib/mingw_64/release/tests'
make[1]: *** [Makefile:1309: check] Error 2
make[1]: Leaving directory '/c/build/hamlib/mingw_64/release/tests'
make: *** [Makefile:534: check-recursive] Error 1
73
Bill
G4WJS.

---

Hamlib-developer mailing list
Hamlib-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer