I was able to set those parameters and save them in /etc/xdg/WSJT-X/. I
tinkered around with different settings. It didn't change the rig response, but
I was able to confirm that my rig is of a type that has a different byte length
response. You're right. There are two hardware types. The byte length of the
rig response is different for each, and I'm not sure the manual has any of the
information right on either rig. I don't know if this has any impact upon the
issue or not.
Nothing I did changed the behavior of the rig. Any command, whether PTT or set
frequency causes the rig to pause at least a poll cycle or two, then jump 10
Hz. I'm not sure why flrig/fldigi doesn't cause the same issue. That's my
next series of experiments.
Shane
AE5SS
________________________________
From: wsjt-devel-requ...@lists.sourceforge.net
<wsjt-devel-requ...@lists.sourceforge.net>
Sent: Saturday, February 23, 2019 3:31 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 60, Issue 48
------------------------------
Message: 2
Date: Sat, 23 Feb 2019 11:13:58 +0000
From: Bill Somerville <g4...@classdesign.com>
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Yaesu FT-847 unidirectional CAT
Message-ID: <dfd6b5c8-fdee-563e-2141-0ed3df54d...@classdesign.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 23/02/2019 06:26, Shane Stroud wrote:
> I don't want to confuse anybody, so I'll say up front that I have an
> FT-747GX and two FT-847 rigs. The 747 is a whole other issue, in a
> message I just sent.
>
> I have an early production FT-847 that has unidirectional CAT, and a
> later production model that has bidirectional CAT.? I know we had
> started a discussion on this issue an I think it got mixed up with the
> FT-840, then died out.? At present, the early FT-847s cannot use
> wsjt-x because the software doesn't understand that early models had
> unidirectional CAT.? The software sets the frequency and mode, but the
> rig cannot acknowledge that change. It sets the parameters, but never
> reports back to the software that it's done.? Basically, I'm asking if
> that being worked on in any way.? I haven't heard anything on it in a
> while.? Do we need a guinea pig?? I'm willing to test software (Linux
> only, as that's all I have) on either FT-847 to make sure it all works.
>
> L. Shane Stroud
> AE5SS
Hi Shane,
the next release of WSJT-X will include a version of Hamlib that has
support for early model FT-847s with one-way CAT communications.
73
Bill
G4WJS.
------------------------------
Message: 3
Date: Sat, 23 Feb 2019 11:31:06 +0000
From: Bill Somerville <g4...@classdesign.com>
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Yaesu FT-747GX
Message-ID: <1c9b52cb-a7c0-4e85-f349-3e3036498...@classdesign.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 23/02/2019 06:12, Shane Stroud wrote:
> I discovered something interesting about the FT-747GX, and I'm not
> sure if it belongs here or in a hamlib devel group, but I'll give this
> a shot.
>
> Each time I set a new band, TX, or send any other command from wsjt-x
> to the rig, it jumps 10 Hz. I believe this is due to settings for the
> byte interval and command interval, or perhaps a lack thereof.? I
> tinkered around with those settings and discovered the same thing
> happens in fldigi and flrig. However, when I set the byte interval to
> 15 ms and the command interval to 50 ms, this stops happening.? The
> rig stays dead on frequency, regardless of commands issued.
>
> From some reading I've done online, the default byte interval in
> hamlib is zero, so it makes sense that an older, slower rig might
> suffer some confusion.? I have attached the flrig settings I used to
> cure this issue.? Note that this byte interval is outside what the
> FT-747GX manual recommends.? I have discovered through additional
> reading that this is quite obviously wrong in the manual. Any attempt
> to set the byte interval above 20 ms results in a locked up radio, and
> locked up control program.
>
> L. Shane Stroud
> AE5SS
Hi Shane,
it is possible to adjust Hamlib configuration parameters with WSJT-X.
Create a file in the WSJT-X configuration directory (the same as the log
files directory on Windows, see the User Guide for other platforms)
called hamlib_settings.json .
The contents of that file would be as follows to set the parameter
values you suggest:
{
"config": {
"write_delay": "15",
"post_write_delay": "50"
}
}
BTW the Hamlib defaults for the FT-747 are write_delay=5mS and
post_write_delay=5mS . You can see these and other parameters available
using the rigctl command and specifying the desired model on the command
line:
C:\>\WSJT\wsjtx\bin\rigctl-wsjtx.exe -m105 -L
rig_pathname: "Path name to the device file of the rig"
Default: /dev/rig, Value: \\.\COM1
String.
*write_delay: "Delay in ms between each byte sent out"****Default: 0,
Value: 5****Range: 0.0..1000.0, step 1.0****post_write_delay: "Delay in
ms between each command sent out"****Default: 0, Value: 5****Range:
0.0..1000.0, step 1.0***timeout: "Timeout in ms"
Default: 0, Value: 2000
Range: 0.0..10000.0, step 1.0
retry: "Max number of retry"
Default: 0, Value: 0
Range: 0.0..10.0, step 1.0
itu_region: "ITU region this rig has been manufactured for (freq. band plan)"
Default: 0, Value: 2
Range: 1.0..3.0, step 1.0
vfo_comp: "VFO compensation in ppm"
Default: 0, Value: 0.000000
Range: 0.0..1000.0, step 0.0
poll_interval: "Polling interval in millisecond for transceive emulation"
Default: 500, Value: 500
Range: 0.0..1000000.0, step 1.0
ptt_type: "Push-To-Talk interface type override"
Default: RIG, Value: RIG
Combo: RIG, DTR, RTS, Parallel, CM108, GPIO, GPION, None
ptt_pathname: "Path name to the device file of the Push-To-Talk"
Default: /dev/rig, Value:
String.
ptt_bitnum: "Push-To-Talk GPIO bit number"
Default: 2, Value: 0
Range: 0.0..7.0, step 1.0
dcd_type: "Data Carrier Detect (or squelch) interface type override"
Default: RIG, Value: None
Combo: RIG, DSR, CTS, CD, Parallel, CM108, GPIO, GPION, None
dcd_pathname: "Path name to the device file of the Data Carrier Detect (or
squelch)"
Default: /dev/rig, Value:
String.
lo_freq: "Frequency to add to the VFO frequency for use with a transverter"
Default: 0, Value:
Range: 0.0..1000000000.0, step 0.1
serial_speed: "Serial port baud rate"
Default: 0, Value: 4800
Range: 300.0..115200.0, step 1.0
data_bits: "Serial port data bits"
Default: 8, Value: 8
Range: 5.0..8.0, step 1.0
stop_bits: "Serial port stop bits"
Default: 1, Value: 2
Range: 0.0..3.0, step 1.0
serial_parity: "Serial port parity"
Default: None, Value: None
Combo: None, Odd, Even, Mark, Space
serial_handshake: "Serial port handshake"
Default: None, Value: None
Combo: None, XONXOFF, Hardware
rts_state: "Serial port set state of RTS signal for external powering"
Default: Unset, Value: Unset
Combo: Unset, ON, OFF
dtr_state: "Serial port set state of DTR signal for external powering"
Default: Unset, Value: Unset
Combo: Unset, ON, OFF
rig_open: error = IO error
I suspect these parameters have been tested and found to be working,
perhaps there are variations between rigs or maybe interface hardware.
73
Bill
G4WJS.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------
End of wsjt-devel Digest, Vol 60, Issue 48
******************************************
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
