Locked Trouble with Yaesu FT-747GX CAT #windows11 #Cat_RigControl #hamlib


kedrot@...
 

I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly starts transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the appropriate frequency. A couple of seconds later, when the system polls the current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.


David Herring
 

A couple of quick things to try...Try using 1 stop bit. Failing that, try a slower baud rate.

73,
Dave - N5DCH

On Aug 16, 2022, at 7:11 PM, kedrot@... wrote:

I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly starts transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the appropriate frequency. A couple of seconds later, when the system polls the current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.





Joe Subich, W4TV
 

FT-747GX is fixed at 4800,N,8,2 ... there is no option to change
any of that.

73,

... Joe, W4TV

On 2022-08-17 11:06 AM, David Herring wrote:
A couple of quick things to try...Try using 1 stop bit. Failing that, try a slower baud rate.
73,
Dave - N5DCH

On Aug 16, 2022, at 7:11 PM, kedrot@... wrote:

I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly starts transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the appropriate frequency. A couple of seconds later, when the system polls the current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.





Michael Black
 

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move the file that way.

If you're not familiar with that here's a video on the file browser - https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB

On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly starts transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the appropriate frequency. A couple of seconds later, when the system polls the current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets to 7,074.000 Two seconds later,  it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.


Mauricio A. Taslik
 

I confirm the error exactly as described. when it must read 7.000 MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps happening
since more than a year in all wsjtx versions until the last one I tried
some months ago, and it looks like it keeps happening. Quick "fix": use an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io (mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move the
file that way.

If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the
appropriate frequency. A couple of seconds later, when the system polls the
current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets
to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.











kedrot@...
 

Unfortunately that leads into a weirder behavior; it initially set my
rig to the right frequency , but then it started to drift from 707,46
to 74,6000 to 746000 and so on, then it randomly started enabling PTT.

I'd send debug info but I don't know how to obtain that from Windows' WSXJT.

On Wed, 17 Aug 2022 at 13:45, Michael Black via groups.io
<mdblack98@...> wrote:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move the file that way.

If you're not familiar with that here's a video on the file browser - https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly starts transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the appropriate frequency. A couple of seconds later, when the system polls the current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.










Tordek <kedrot@...>
 

I can confirm that 2.2.0 does work and 2.4.0 doesn't; I haven't tested others.

On Wed, 17 Aug 2022 at 16:00, Mauricio A. Taslik <mautas@...> wrote:

I confirm the error exactly as described. when it must read 7.000 MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps happening
since more than a year in all wsjtx versions until the last one I tried
some months ago, and it looks like it keeps happening. Quick "fix": use an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io (mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move the
file that way.

If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the
appropriate frequency. A couple of seconds later, when the system polls the
current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets
to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.














Mauricio A. Taslik
 

Well, it seems like he found the place in the code where this is happenning
but the fix is not still right. It seems to be all about getting qrg from
the poll and doing the right thing with it: not scaling it up (original
bug) and not scaling it down (Michael's fix bug)

On Aug 18, 2022 2:27 AM, "Tordek" <kedrot@...> wrote:

Unfortunately that leads into a weirder behavior; it initially set my
rig to the right frequency , but then it started to drift from 707,46
to 74,6000 to 746000 and so on, then it randomly started enabling PTT.

I'd send debug info but I don't know how to obtain that from Windows' WSXJT.

On Wed, 17 Aug 2022 at 13:45, Michael Black via groups.io
<mdblack98@...> wrote:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move
the file that way.

If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly
starts transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the
appropriate frequency. A couple of seconds later, when the system polls the
current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets
to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.










Tordek <kedrot@...>
 

Since we both seem to be Spanish speakers, my brother offers a
thought... maybe there's a locale issue and it's parsing the wrong
decimal separator?

On Wed, 17 Aug 2022 at 16:00, Mauricio A. Taslik <mautas@...> wrote:

I confirm the error exactly as described. when it must read 7.000 MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps happening
since more than a year in all wsjtx versions until the last one I tried
some months ago, and it looks like it keeps happening. Quick "fix": use an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io (mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move the
file that way.

If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the
appropriate frequency. A couple of seconds later, when the system polls the
current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets
to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.














Tordek <kedrot@...>
 

A bit of source digging later, I believe it's been caused by a change
between 2.3.1 and 2.4.0, where these lines were changed from:

#if defined (Q_OS_WIN)
std::locale::global (std::locale ("C"));
#else
std::locale::global (std::locale ("en_US.UTF-8"));
#endif

to

// reset the C+ & C global locales to the classic C locale
std::locale::global (std::locale::classic ());

Versions up to 2.3.1 work correctly, and 2.4.0 exhibits the bug.
Unfortunately there isn't a 2.4.0-rc4-win64 available to try, which is
the latest tag before the change.

On Thu, 18 Aug 2022 at 09:27, Tordek <kedrot@...> wrote:

Since we both seem to be Spanish speakers, my brother offers a
thought... maybe there's a locale issue and it's parsing the wrong
decimal separator?

On Wed, 17 Aug 2022 at 16:00, Mauricio A. Taslik <mautas@...> wrote:

I confirm the error exactly as described. when it must read 7.000 MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps happening
since more than a year in all wsjtx versions until the last one I tried
some months ago, and it looks like it keeps happening. Quick "fix": use an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io (mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move the
file that way.

If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to the
appropriate frequency. A couple of seconds later, when the system polls the
current frequency, it's 100 times higher and it ends in 48. E.g.: 40m sets
to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.














Mauricio A. Taslik
 

Yeah, I think that could be the reason. In that case, just switch to some
english locale like US and see how it goes...

El jue, 18 ago 2022 a la(s) 10:37, Tordek (kedrot@...) escribió:

Since we both seem to be Spanish speakers, my brother offers a
thought... maybe there's a locale issue and it's parsing the wrong
decimal separator?

On Wed, 17 Aug 2022 at 16:00, Mauricio A. Taslik <mautas@...> wrote:

I confirm the error exactly as described. when it must read 7.000 MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps happening
since more than a year in all wsjtx versions until the last one I tried
some months ago, and it looks like it keeps happening. Quick "fix": use
an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io
(mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move
the
file that way.

If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly
starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to
the
appropriate frequency. A couple of seconds later, when the system
polls the
current frequency, it's 100 times higher and it ends in 48. E.g.: 40m
sets
to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.


















Michael Black
 

The locale has nothing to do with it.
Try the latest 64-bit DLL here
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0

I checked the history and there were some changes to the 747GX that broke this.
Mike W9MDB

On Thursday, August 18, 2022 at 10:34:13 AM CDT, Mauricio A. Taslik <mautas@...> wrote:

Yeah, I think that could be the reason. In that case, just switch to some
english locale like US and see how it goes...


El jue, 18 ago 2022 a la(s) 10:37, Tordek (kedrot@...) escribió:

Since we both seem to be Spanish speakers, my brother offers a
thought... maybe there's a locale issue and it's parsing the wrong
decimal separator?

On Wed, 17 Aug 2022 at 16:00, Mauricio A. Taslik <mautas@...> wrote:

I confirm the error exactly as described. when it must read 7.000 MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps happening
since more than a year in all wsjtx versions until the last one I tried
some months ago, and it looks like it keeps happening. Quick "fix": use
an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io
(mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move
the
file that way.

If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly
starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to
the
appropriate frequency. A couple of seconds later, when the system
polls the
current frequency, it's 100 times higher and it ends in 48. E.g.: 40m
sets
to 7,074.000 Two seconds later,  it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.


















Tordek <kedrot@...>
 

Hi, Michael

I just tried this version but it still behaves incorrectly; the only
apparent difference is that now it returns 040 for the last few bits
of the frequency instead of 048.

On Thu, 18 Aug 2022 at 13:04, Michael Black via groups.io
<mdblack98@...> wrote:

The locale has nothing to do with it.
Try the latest 64-bit DLL here
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0

I checked the history and there were some changes to the 747GX that broke this.
Mike W9MDB




On Thursday, August 18, 2022 at 10:34:13 AM CDT, Mauricio A. Taslik <mautas@...> wrote:

Yeah, I think that could be the reason. In that case, just switch to some
english locale like US and see how it goes...


El jue, 18 ago 2022 a la(s) 10:37, Tordek (kedrot@...) escribió:

Since we both seem to be Spanish speakers, my brother offers a
thought... maybe there's a locale issue and it's parsing the wrong
decimal separator?

On Wed, 17 Aug 2022 at 16:00, Mauricio A. Taslik <mautas@...> wrote:

I confirm the error exactly as described. when it must read 7.000 MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps happening
since more than a year in all wsjtx versions until the last one I tried
some months ago, and it looks like it keeps happening. Quick "fix": use
an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io
(mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move
the
file that way.

If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly
starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to
the
appropriate frequency. A couple of seconds later, when the system
polls the
current frequency, it's 100 times higher and it ends in 48. E.g.: 40m
sets
to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.



























Tordek <kedrot@...>
 

I just realized this, but, if it were a hamlib issue I could copy the
library from 2.3.1 and paste onto the 2.5.4 installation; however it
still breaks and shows this error. So, more than likely, the issue is
with WSJT

On Thu, 18 Aug 2022 at 15:39, Tordek via groups.io
<kedrot@...> wrote:

Hi, Michael

I just tried this version but it still behaves incorrectly; the only
apparent difference is that now it returns 040 for the last few bits
of the frequency instead of 048.

On Thu, 18 Aug 2022 at 13:04, Michael Black via groups.io
<mdblack98@...> wrote:

The locale has nothing to do with it.
Try the latest 64-bit DLL here
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0

I checked the history and there were some changes to the 747GX that broke this.
Mike W9MDB




On Thursday, August 18, 2022 at 10:34:13 AM CDT, Mauricio A. Taslik <mautas@...> wrote:

Yeah, I think that could be the reason. In that case, just switch to some
english locale like US and see how it goes...


El jue, 18 ago 2022 a la(s) 10:37, Tordek (kedrot@...) escribió:

Since we both seem to be Spanish speakers, my brother offers a
thought... maybe there's a locale issue and it's parsing the wrong
decimal separator?

On Wed, 17 Aug 2022 at 16:00, Mauricio A. Taslik <mautas@...> wrote:

I confirm the error exactly as described. when it must read 7.000 MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps happening
since more than a year in all wsjtx versions until the last one I tried
some months ago, and it looks like it keeps happening. Quick "fix": use
an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io
(mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser and move
the
file that way.

If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT, kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also correctly
starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly set to
the
appropriate frequency. A couple of seconds later, when the system
polls the
current frequency, it's 100 times higher and it ends in 48. E.g.: 40m
sets
to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig disconnects.

Any help is appreciated.






























Mauricio A. Taslik
 

It would be nice to have this fixed. It's a shame that this renders the
FT-747 unusable for latest wsjtx versions.

El jue, 18 ago 2022 a la(s) 19:07, Tordek (kedrot@...) escribió:

I just realized this, but, if it were a hamlib issue I could copy the
library from 2.3.1 and paste onto the 2.5.4 installation; however it
still breaks and shows this error. So, more than likely, the issue is
with WSJT

On Thu, 18 Aug 2022 at 15:39, Tordek via groups.io
<kedrot@...> wrote:

Hi, Michael

I just tried this version but it still behaves incorrectly; the only
apparent difference is that now it returns 040 for the last few bits
of the frequency instead of 048.

On Thu, 18 Aug 2022 at 13:04, Michael Black via groups.io
<mdblack98@...> wrote:

The locale has nothing to do with it.
Try the latest 64-bit DLL here
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0

I checked the history and there were some changes to the 747GX that
broke this.
Mike W9MDB




On Thursday, August 18, 2022 at 10:34:13 AM CDT, Mauricio A.
Taslik <mautas@...> wrote:

Yeah, I think that could be the reason. In that case, just switch to
some
english locale like US and see how it goes...


El jue, 18 ago 2022 a la(s) 10:37, Tordek (kedrot@...) escribió:

Since we both seem to be Spanish speakers, my brother offers a
thought... maybe there's a locale issue and it's parsing the wrong
decimal separator?

On Wed, 17 Aug 2022 at 16:00, Mauricio A. Taslik <mautas@...>
wrote:

I confirm the error exactly as described. when it must read 7.000
MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps
happening
since more than a year in all wsjtx versions until the last one I
tried
some months ago, and it looks like it keeps happening. Quick
"fix": use
an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io
(mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help
this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please
provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any
Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser
and move
the
file that way.

If you're not familiar with that here's a video on the file
browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT,
kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also
correctly
starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly
set to
the
appropriate frequency. A couple of seconds later, when the system
polls the
current frequency, it's 100 times higher and it ends in 48.
E.g.: 40m
sets
to 7,074.000 Two seconds later, it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig
disconnects.

Any help is appreciated.


































Michael Black
 

It's been fixed...still trying to improve it though.  The rig takes some 800ms to read freq and mode and ptt.
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0

Mike W9MDB

On Friday, August 19, 2022 at 11:14:33 AM CDT, Mauricio A. Taslik <mautas@...> wrote:

It would be nice to have this fixed. It's a shame that this renders the
FT-747 unusable for latest wsjtx versions.


El jue, 18 ago 2022 a la(s) 19:07, Tordek (kedrot@...) escribió:

I just realized this, but, if it were a hamlib issue I could copy the
library from 2.3.1 and paste onto the 2.5.4 installation; however it
still breaks and shows this error. So, more than likely, the issue is
with WSJT

On Thu, 18 Aug 2022 at 15:39, Tordek via groups.io
<kedrot@...> wrote:

Hi, Michael

I just tried this version but it still behaves incorrectly; the only
apparent difference is that now it returns 040 for the last few bits
of the frequency instead of 048.

On Thu, 18 Aug 2022 at 13:04, Michael Black via groups.io
<mdblack98@...> wrote:

The locale has nothing to do with it.
Try the latest 64-bit DLL here
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0

I checked the history and there were some changes to the 747GX that
broke this.
Mike W9MDB




    On Thursday, August 18, 2022 at 10:34:13 AM CDT, Mauricio A.
Taslik <mautas@...> wrote:

  Yeah, I think that could be the reason. In that case, just switch to
some
english locale like US and see how it goes...


El jue, 18 ago 2022 a la(s) 10:37, Tordek (kedrot@...) escribió:

Since we both seem to be Spanish speakers, my brother offers a
thought... maybe there's a locale issue and it's parsing the wrong
decimal separator?

On Wed, 17 Aug 2022 at 16:00, Mauricio A. Taslik <mautas@...>
wrote:

I confirm the error exactly as described. when it must read 7.000
MHz it
reads 7,000 MHz and that makes it impossible to use it. Keeps
happening
since more than a year in all wsjtx versions until the last one I
tried
some months ago, and it looks like it keeps happening. Quick
"fix": use
an
old versión from early 2019.


El mié, 17 ago 2022 a la(s) 13:45, Michael Black via groups.io
(mdblack98=
yahoo.com@groups.io) escribió:

Please try this DLL....I just made a change that should help
this....
https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0


And if it still is wrong (which it likely will be) please
provide debug
info

New hamlib for installation directions

#1 Shut down WSJTX

Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/\
Note: If compiling on Unix-like systems please uninstall any
Hamlib
package you have before installing the new build

#2 If you don't save directly you need to open a file browser
and move
the
file that way.

If you're not familiar with that here's a video on the file
browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk

Mike W9MDB









On Wednesday, August 17, 2022 at 12:47:55 AM CDT,
kedrot@... <
kedrot@...> wrote:





I'm trying to setup CAT to control my rig; my settings are:

COM4
8 data bits
2 stop bits
no handshake
other pins on default

The Test CAT button works, it sets to green, and PTT also
correctly
starts
transmitting.

The issues:

When selecting a band from the dropdown, the rig is correctly
set to
the
appropriate frequency. A couple of seconds later, when the system
polls the
current frequency, it's 100 times higher and it ends in 48.
E.g.: 40m
sets
to 7,074.000 Two seconds later,  it becomes 707,400.048.

A few seconds later, I get a timeout error and the rig
disconnects.

Any help is appreciated.