Re: [wsjt-devel] Yaesu FT-747GX
Bill, It wouldn't build on my systems. I'll admit that my compiling skills need improvement. I emailed you the errors. Thanks, Shane Hi Shane, ok, try this. Grab the wsjtx-2.0.0.tgz tarball from the project web site or the SourceForge files area and unpack it somewhere. In it there is an empty hamlib.patch file, replace that with this file: https://www.dropbox.com/s/8ypdeladz4fsfyt/hamlib.patch?dl=0 then build WSJT-X from those sources. For reference here is a recipe: mkdir -p /tmp/wsjtx-prefix/build cd !$/.. wget https://sourceforge.net/projects/wsjt/files/wsjtx-2.0.0/wsjtx-2.0.0.tgz tar xf wsjtx-2.0.0.tgz cd wsjtx-2.0.0 wget -N https://www.dropbox.com/s/8ypdeladz4fsfyt/hamlib.patch cd ../build cmake -DWSJT_SKIP_MANPAGES=ON -DWSJT_GENERATE_DOCS=OFF -DCMAKE_INSTALL_PREFIX=.. ../wsjtx-2.0.0 cmake --build . --target install -- -j /tmp/wsjtx-prefix/bin/wsjtx and see how that goes. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Yaesu FT-747GX
I can build from source most of the time. Missing libraries and dependencies sometimes cause issues. I'm on Lubuntu, so here's the system info for the system I use most of the time. I have two 32 bit systems and two 64 bit systems that I can tinker with if need be. Linux k3nw00d 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Re: [wsjt-devel] Yaesu FT-747GX<https://sourceforge.net/p/wsjt/mailman/message/36595773/> From: Bill Somerville - 2019-02-24 14:59:45 Attachments: Message as HTML<https://sourceforge.net/p/wsjt/mailman/attachment/a48d758e-d529-b124-7505-5f01747701cf%40classdesign.com/1/> On 24/02/2019 14:56, Shane Stroud wrote: > Thanks for looking into that. It's definitely walking the frequency. > During a QSO, it walks 10 Hz each time I TX. But at least now I know > what's causing it. Old rigs are sometimes fun to use, but also a pain. Hi Shane, ok, then it needs addressing. Are you able to build from sources? If not then which o/s and version are you using? 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Yaesu FT-747GX
Bill, Thanks for looking into that. It's definitely walking the frequency. During a QSO, it walks 10 Hz each time I TX. But at least now I know what's causing it. Old rigs are sometimes fun to use, but also a pain. Shane AE5SS Hi Shane, having got around to looking at the CAT protocol for the FT-747 and the Hamlib implementation, I can see what is happening. This rig has a very oddball CAT frequency arrangement which is hard to deal with. The rig has 25 Hz tuning steps but does not display them, it only displays 100 Hz steps. The CAT command to set the frequency accepts 10 Hz steps (as a BCD encoded number) but he rig internally converts the 10 of Hertz digit (least significant BCD digit) to 25 Hz steps (0, 1, 2 -> 0 Hz, 3, 4 -> 25 Hz, 5, 6, 7 -> 50 Hz, and 8, 9 -> 75 Hz). The get frequency CAT command returns a BCD number for the 100 hz steps but a 25 Hz step using the least significant two BDC digits (00, 25, 50, 75). The Hamlib driver attempts to round the frequency to be set to 25 Hz steps which are then encoded as 10 Hz steps. This makes it very difficult to round-trip a frequency value since the input and output steps are different due to the implicit conversion within the rig. The odd 10 Hz displayed in WSJT-X are not inconsistent with the actual frequency set on the rig since the rig will round that back down to 0 Hz, so despite the rather strange effect I would ignore it and not worry about it. OTOH if it does result in a walking frequency continually stepping up or down then that should be addressed although I am not sure how. WSJT-X does attempt to determine the rig's frequency resolution but in doing so it assume that it is possible to round-trip frequency set and query commands at the determined resolution, which is not the case with this rig. The only sure solution I can think of is adjust the frequency resolution determination in WSJT-X for this edge case and drop back to 50 Hz resolution since at that round-tip frequency control is possible, even that would need adjustment to Hamlib to ensure that 0 Hz, 50 Hz, 100 Hz, ... frequency steps were correctly round-tripped via the rig. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Yaesu FT-747GX
This is interesting why would it convert the frequency to be 10 Hz up? I don't have a VFO correction or offset established that I know of. Rig command: ^C root@y435u:/home/shane# rigctl -m 105 -r /dev/ttyUSB0 -s 4800 -v rigctl, Hamlib 3.1 Report bugs to rig:rig_init called yaesu: initrigs3_yaesu called rig_register (121) rig_register (127) rig_register (110) rig_register (105) rig_register (106) rig_register (107) rig_register (109) rig_register (120) rig_register (101) rig_register (122) rig_register (123) rig_register (111) rig_register (115) rig_register (113) rig_register (114) rig_register (128) rig_register (131) rig_register (116) rig_register (103) rig_register (124) rig_register (104) rig_register (125) rig_register (129) rig_register (132) rig_register (130) rig_register (117) rig_register (119) rig_register (118) rig_register (126) rig_register (133) rig_register (134) rig_register (135) ft747:ft747_init called rig:rig_open called ft747:rig_open: write_delay = 5 msec ft747:rig_open: post_write_delay = 5 msec ft747: read pacing = 0 write_block(): TX 5 bytes 00 00 00 00 0e . forced cache timeout write_block(): TX 5 bytes 00 00 00 00 10 . read_block(): RX 344 bytes 00 00 03 91 60 10 12 00 00 03 91 60 10 08 00 08 `..` 001000 14 00 00 10 08 00 00 08 10 00 10 00 00 00 10 002000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 003000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 004000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 005000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 006000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 007000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 008000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 009000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 00a000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 00b000 10 00 10 00 00 00 10 00 00 00 00 00 00 00 00 00c000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 010000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 011000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 012000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 013000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 014000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 015000 00 00 00 00 00 00 00 read_block(): Timed out 0.100526 seconds after 0 chars ft747: vfo status = 0 ft747: VFO = A Opened rig model 105, 'FT-747GX' Backend version: 0.4.1, Status: Beta Rig command: F 1400 rigctl_parse: input_line: F 1400 ft747: requested freq = 1400.00 Hz ft747: requested freq after conversion = 1410 Hz write_block(): TX 5 bytes 01 00 40 01 0a ..@.. Rig command: f rigctl_parse: input_line: f ft747:ft747_get_freq called forced cache timeout write_block(): TX 5 bytes 00 00 00 00 10 . read_block(): RX 344 bytes 00 00 14 00 00 10 15 00 00 14 00 00 10 08 00 08 001000 14 00 00 10 08 00 00 08 10 00 10 00 00 00 10 002000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 003000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 004000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 005000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 006000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 007000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 008000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 009000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 00a000 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 00b000 10 00 10 00 00 00 10 00 00 00 00 00 00 00 00 00c000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 010000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 011000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0120
Re: [wsjt-devel] Yaesu FT-747GX
Here's something interesting. I don't think it's an issue with wsjt. Below is the result of my tinkering with rigctl. Every time I try to set the VFO frequency, the rig jumps 10 Hz. This looks to be something inherent to hamlib, or perhaps the radio. It does seem odd that the radio has a minimum resolution of 10 Hz, and it coincidentally hops up 10 Hz after any frequency change. I've read that any change of frequency less than 10 Hz is ignored, or that the rig ignores the last digit. Perhaps it's related to that. I don't see how this could happen in rigctl, wsjt, and fldigi, but not when controlling with flrig. The plot thickens. But at least it doesn't seem to be wsjt that is causing it. If anybody has any buddies on the hamlib development team, I'd be curious to hear what they think. shane@y435u:/home/shane# rigctl -m 105 -r /dev/ttyUSB0 -s 4800 -v Opened rig model 105, 'FT-747GX' Rig command: F 720 rigctl_parse: input_line: F 720 Rig command: f rigctl_parse: input_line: f Frequency: 7200010 Rig command: F 3916000 rigctl_parse: input_line: F 3916000 Rig command: f rigctl_parse: input_line: f Frequency: 3916010 Shane AE5SS ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Yaesu FT-747GX
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
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 +
From: Bill Somerville
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Yaesu FT-847 unidirectional CAT
Message-ID:
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 +
From: Bill Somerville
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
[wsjt-devel] Yaesu FT-847 unidirectional CAT
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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Yaesu FT-747GX
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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Yaesu FT-847
This isn't a configuration problem to solve. It's a function of the radio's design. Check your serial number. Later models work fine. Early models (prior to the 8G serial number series) had to have the AF board replaced to work properly. It may work with HRD, but I have a laundry list of reasons I can't and won't use that software... primarily the fact that I run a 100% Linux shack. I don't run Microsoft operating systems on any of my computers. I make most other modes work with fldigi or rigctld and gpredict (for satellite ops), but wsjt won't play nice if the rig physically cannot respond to polling by design. The least painful work around is to select "none" for radio and do it all manually. I had to do that with my Heath SB-1400 (FT-747GX) because it wouldn't respond to polling during TX. That got fixed in the software. Surely this can be fixed, too. Original message From: Chris Getman Date: 10/9/18 7:54 AM (GMT-06:00) To: WSJT software development Subject: Re: [wsjt-devel] Yaesu FT-847 I use an FT-847 with WSJT, but pass control via Ham Radio Deluxe and everything works fine. Give it a try it may solve your problem. -Chris On Tue, Oct 9, 2018 at 7:18 AM mailto:kd2...@gmail.com>> wrote: While you can operate perfectly “fine” without CAT control for many digital modes (including plain vanilla FT8), you need to be mindful of the placement of your transmitted signal to ensure you aren’t bumping against the edges of your transmit filters, i.e. the high and low ends of the waterfall. Hitting the TX filter edges can cause issues with power rolling off and (more importantly) it can cause issues with signal distortion or IMD. Remember that on many bands there are quite a few signals packed into a small space and one person with a “rough” signal can ruin a whole lot of other Op’s QSO’s. CAT control simply makes this whole process easier. It’s also highly recommended when using DXPedition Mode as a “hound” (same reason as above). Jim S. N2ADV From: Alan VK2ZIW mailto:bea...@unixservice.com.au>> Sent: Monday, October 8, 2018 9:42 PM To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net>> Subject: Re: [wsjt-devel] Yaesu FT-847 Hi all, Why do you need CAT control at all? What's really needed is a rig with Stability. Any rig with a digital VFO will do. My 2c. Yes, I have an FT-840 and it's OK. Alan VK2ZIW On Mon, 8 Oct 2018 10:54:42 -0400, Karl Heinz Kremer wrote > FT-840UNI would be OK. “Early” or “NoGet” would require the user to know more > about what’s going on with these devices. > > Karl Heinz - K5KHK > > > On Oct 8, 2018, at 10:52 AM, Black Michael > mailto:mdblac...@yahoo.com>> wrote: > > What can we call these earlier rigs to make the apparent in the riglist? > > FT-840EARLY ??? > Or > FT-840UNI (unidirectional) > FT-840NOGET > > Or any better idea? > > de Mike W9MDB > > > > > > > On Monday, October 8, 2018, 9:47:05 AM CDT, Karl Heinz Kremer > mailto:k...@khk.net>> wrote: > > > > This also seems to be the case with my early Yaesu FT-840 - it can receive > CAT commands, but does not report anything back. > > > Karl Heinz - K5KHK > > > On Mon, Oct 8, 2018 at 10:44 AM Black Michael via wsjt-devel > mailto:wsjt-devel@lists.sourceforge.net>> > wrote: > > What version of WSJT-X are you using right now? > > Looks like we need a new rig entry for the earlier serial #'s and I can build > you one for testing. > > de Mike W9MDB > > > > > > > On Monday, October 8, 2018, 9:34:22 AM CDT, Shane Stroud > mailto:shanestroud1...@hotmail.com>> wrote: > > > > I have discovered that the early serial numbered models of the Yaesu FT-847 > had unidirectional CAT. Basically, the software can send frequencies and > modes to the rig, but the rig cannot respond. This applies to serial numbers > through about 8G. Mine is an 8E series. > > In any version of WSJT, under any operating system, the rig will set > frequency and mode, then error out because it cannot respond to polling. > > I'm not sure if this needs fixed in WSJT or in hamlib, but other hamlib > programs seem to work with the rig without issue. > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel Alan Evil flourishes when good men do nothing. Consi
Re: [wsjt-devel] Yaesu FT-847
CAT... because that's kinda the point with most digital modes these days. And it's an FT-847, not 840. From: Alan VK2ZIW Sent: Monday, October 8, 2018 6:41 PM To: WSJT software development Subject: Re: [wsjt-devel] Yaesu FT-847 Hi all, Why do you need CAT control at all? What's really needed is a rig with Stability. Any rig with a digital VFO will do. My 2c. Yes, I have an FT-840 and it's OK. Alan VK2ZIW On Mon, 8 Oct 2018 10:54:42 -0400, Karl Heinz Kremer wrote > FT-840UNI would be OK. “Early” or “NoGet” would require the user to know more > about what’s going on with these devices. > > Karl Heinz - K5KHK > > > On Oct 8, 2018, at 10:52 AM, Black Michael > mailto:mdblac...@yahoo.com>> wrote: > > What can we call these earlier rigs to make the apparent in the riglist? > > FT-840EARLY ??? > Or > FT-840UNI (unidirectional) > FT-840NOGET > > Or any better idea? > > de Mike W9MDB > > > > > > > On Monday, October 8, 2018, 9:47:05 AM CDT, Karl Heinz Kremer > mailto:k...@khk.net>> wrote: > > > > This also seems to be the case with my early Yaesu FT-840 - it can receive > CAT commands, but does not report anything back. > > > Karl Heinz - K5KHK > > > On Mon, Oct 8, 2018 at 10:44 AM Black Michael via wsjt-devel > mailto:wsjt-devel@lists.sourceforge.net>> > wrote: > > What version of WSJT-X are you using right now? > > Looks like we need a new rig entry for the earlier serial #'s and I can build > you one for testing. > > de Mike W9MDB > > > > > > > On Monday, October 8, 2018, 9:34:22 AM CDT, Shane Stroud > mailto:shanestroud1...@hotmail.com>> wrote: > > > > I have discovered that the early serial numbered models of the Yaesu FT-847 > had unidirectional CAT. Basically, the software can send frequencies and > modes to the rig, but the rig cannot respond. This applies to serial numbers > through about 8G. Mine is an 8E series. > > In any version of WSJT, under any operating system, the rig will set > frequency and mode, then error out because it cannot respond to polling. > > I'm not sure if this needs fixed in WSJT or in hamlib, but other hamlib > programs seem to work with the rig without issue. > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel Alan Evil flourishes when good men do nothing. Consider the Christmas child. --- Alan Beard Unix Support Technician from 1984 to today 70 Wedmore Rd. Sun Solaris, AIX, HP/UX, Linux, SCO, MIPS Emu Heights N.S.W. 2750 Routers, terminal servers, printers, terminals etc.. +61 2 47353013 (h) Support Programming, shell scripting, "C", assembler 0414 353013 (mobile) After uni, electronics tech ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Yaesu FT-847
I am still using 1.9.1 Linux amd64 deb, but I could easily be persuaded to upgrade. And I'm a willing guinea pig. Yes. An early identification tag of some kind would help. The fix wasn't just firmware. It required replacement of the entire AF board. Yaesu discontinued their practice of making the fix for free years ago. Now they just send a canned "we can't help you" email. I did reach one tech who explained that it wasn't just the firmware fix we always thought it was. Original message From: Black Michael via wsjt-devel Date: 10/8/18 9:46 AM (GMT-06:00) To: WSJT software development Cc: Black Michael Subject: Re: [wsjt-devel] Yaesu FT-847 What version of WSJT-X are you using right now? Looks like we need a new rig entry for the earlier serial #'s and I can build you one for testing. de Mike W9MDB On Monday, October 8, 2018, 9:34:22 AM CDT, Shane Stroud wrote: I have discovered that the early serial numbered models of the Yaesu FT-847 had unidirectional CAT. Basically, the software can send frequencies and modes to the rig, but the rig cannot respond. This applies to serial numbers through about 8G. Mine is an 8E series. In any version of WSJT, under any operating system, the rig will set frequency and mode, then error out because it cannot respond to polling. I'm not sure if this needs fixed in WSJT or in hamlib, but other hamlib programs seem to work with the rig without issue. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Yaesu FT-847
I have discovered that the early serial numbered models of the Yaesu FT-847 had unidirectional CAT. Basically, the software can send frequencies and modes to the rig, but the rig cannot respond. This applies to serial numbers through about 8G. Mine is an 8E series. In any version of WSJT, under any operating system, the rig will set frequency and mode, then error out because it cannot respond to polling. I'm not sure if this needs fixed in WSJT or in hamlib, but other hamlib programs seem to work with the rig without issue. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
