Re: [wsjt-devel] Candidate Release WSJT-X 2.7.0-rc1 Linux compile

[Jim Shorney via wsjt-devel]

That's not trivial either. But with 18.04 going end of support it is 
inevitable. I'm just looking for an easy fix, as usual. I did find a qt515 ppa 
for Bionic but I have no clue how to make it work.

Going to try asking Mr. Google again Then maybe off to the Ubuntu forums.


73

-Jim
NU0C



On Sun, 14 May 2023 01:27:33 +
Stan Gammons via wsjt-devel  wrote:

> Looks like on Kubuntu 22.04, I have QT packages from versions 5.15.3 to
> 5.15.9
> 
> Maybe time to upgrade to a later OS version?
> 
> 
> 73
> 
> Stan
> KM4HQE
> 
> 
> On 5/13/23 20:03, Alex Lelievre via wsjt-devel wrote:
> > I believe you need 5.15.8_3 which is what I used for the Mac M1 build.
> >
> > best,
> > alex K6LOT
> >
> >  
> >> On May 13, 2023, at 5:58 PM, Jim Shorney via wsjt-devel 
> >>  wrote:
> >>
> >> 
> >> 2.7.0-rc1 fails to compile in Kubuntu 18.04 with the following errors:
> >>
> >> [ 98%] Building CXX object qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o
> >> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp: In 
> >> constructor `MainWindow::MainWindow(QWidget*)`:
> >> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:184:32:
> >>  error: `class QScopedPointer` has no member named `get`
> >>connect (m_wide_graph_window.get (), ::freezeDecode2, this, 
> >> ::freezeDecode);
> >> ^~~
> >> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:185:32:
> >>  error: `class QScopedPointer` has no member named `get`
> >>connect (m_wide_graph_window.get (), ::f11f12, this, 
> >> ::bumpDF);
> >> ^~~
> >> qmap/CMakeFiles/qmap.dir/build.make:233: recipe for target 
> >> 'qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o' failed
> >>
> >> My Qt version is 5.9.5. There is no newer version available in the 
> >> repository. Getting a newer version by other means does not appear to be a 
> >> trivial task.
> >>
> >> 73
> >>
> >> -Jim
> >> NU0C
> >>
> >>
> >> ___
> >> wsjt-devel mailing list
> >> 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 mailing list
> 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

Re: [wsjt-devel] Candidate Release WSJT-X 2.7.0-rc1 Linux compile

[Stan Gammons via wsjt-devel]

Looks like on Kubuntu 22.04, I have QT packages from versions 5.15.3 to
5.15.9

Maybe time to upgrade to a later OS version?


73

Stan
KM4HQE


On 5/13/23 20:03, Alex Lelievre via wsjt-devel wrote:
> I believe you need 5.15.8_3 which is what I used for the Mac M1 build.
>
> best,
> alex K6LOT
>
>
>> On May 13, 2023, at 5:58 PM, Jim Shorney via wsjt-devel 
>>  wrote:
>>
>> 
>> 2.7.0-rc1 fails to compile in Kubuntu 18.04 with the following errors:
>>
>> [ 98%] Building CXX object qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o
>> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp: In 
>> constructor `MainWindow::MainWindow(QWidget*)`:
>> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:184:32:
>>  error: `class QScopedPointer` has no member named `get`
>>connect (m_wide_graph_window.get (), ::freezeDecode2, this, 
>> ::freezeDecode);
>> ^~~
>> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:185:32:
>>  error: `class QScopedPointer` has no member named `get`
>>connect (m_wide_graph_window.get (), ::f11f12, this, 
>> ::bumpDF);
>> ^~~
>> qmap/CMakeFiles/qmap.dir/build.make:233: recipe for target 
>> 'qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o' failed
>>
>> My Qt version is 5.9.5. There is no newer version available in the 
>> repository. Getting a newer version by other means does not appear to be a 
>> trivial task.
>>
>> 73
>>
>> -Jim
>> NU0C
>>
>>
>> ___
>> wsjt-devel mailing list
>> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Candidate Release WSJT-X 2.7.0-rc1 Linux compile

[Alex Lelievre via wsjt-devel]

I believe you need 5.15.8_3 which is what I used for the Mac M1 build. 

best,
alex K6LOT 


> On May 13, 2023, at 5:58 PM, Jim Shorney via wsjt-devel 
>  wrote:
> 
> 
> 2.7.0-rc1 fails to compile in Kubuntu 18.04 with the following errors:
> 
> [ 98%] Building CXX object qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o
> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp: In 
> constructor `MainWindow::MainWindow(QWidget*)`:
> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:184:32: 
> error: `class QScopedPointer` has no member named `get`
>   connect (m_wide_graph_window.get (), ::freezeDecode2, this, 
> ::freezeDecode);
>^~~
> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:185:32: 
> error: `class QScopedPointer` has no member named `get`
>   connect (m_wide_graph_window.get (), ::f11f12, this, 
> ::bumpDF);
>^~~
> qmap/CMakeFiles/qmap.dir/build.make:233: recipe for target 
> 'qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o' failed
> 
> My Qt version is 5.9.5. There is no newer version available in the 
> repository. Getting a newer version by other means does not appear to be a 
> trivial task.
> 
> 73
> 
> -Jim
> NU0C
> 
> 
> ___
> wsjt-devel mailing list
> 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

Re: [wsjt-devel] Candidate Release WSJT-X 2.7.0-rc1 Linux compile

[Jim Shorney via wsjt-devel]

2.7.0-rc1 fails to compile in Kubuntu 18.04 with the following errors:

[ 98%] Building CXX object qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o
/home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp: In 
constructor `MainWindow::MainWindow(QWidget*)`:
/home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:184:32: 
error: `class QScopedPointer` has no member named `get`
   connect (m_wide_graph_window.get (), ::freezeDecode2, this, 
::freezeDecode);
^~~
/home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:185:32: 
error: `class QScopedPointer` has no member named `get`
   connect (m_wide_graph_window.get (), ::f11f12, this, 
::bumpDF);
^~~
qmap/CMakeFiles/qmap.dir/build.make:233: recipe for target 
'qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o' failed

My Qt version is 5.9.5. There is no newer version available in the repository. 
Getting a newer version by other means does not appear to be a trivial task.

73

-Jim
NU0C


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[Dennis W1UE via wsjt-devel]

George

What operating system are you using?

Since you're the first with a 7610, I"d like to include you as a tester.

Dennis W1UE




On Sat, May 13, 2023 at 5:01 PM WB5JJJ via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> This also affected the IC-7610, but the new file fixed the problem.
>
> 73's
> George - WB5JJJ
> HoIP - 100105
>
>
> On Sat, May 13, 2023 at 3:29 AM Tom M0LTE via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> Hey Uwe
>>
>> While manual testing could probably never be eliminated in the case of
>> hamlib, has there been any consideration of creating test harnesses to
>> remove/reduce the need for manual testing?
>>
>> It strikes me that there could be potential to capture test cases from
>> manual testing with real rigs, then at least there would be regression
>> tests. Future bug fixes could have test cases added to prevent further
>> regression, again without requiring physical radios and manual testing.
>>
>> Apologies if I am not the first to ask this question.
>>
>> Kind regards
>> Tom M0LTE
>>
>> On Sat, 13 May 2023 at 08:11, Uwe, DG2YCB via wsjt-devel <
>> wsjt-devel@lists.sourceforge.net> wrote:
>>
>>> Dear WSJT-X users,
>>>
>>> Please allow me to summarize again here on this email reflector a topic
>>> that is very important to me and to all of us. My original post was on
>>> https://groups.io/g/wsjtgroup, so maybe it's best if you join the
>>> discussion there.
>>>
>>> Despite great personal commitment of the hamlib developers it has
>>> unfortunately happened very often that immediately after a new WSJT-X
>>> release serious problems with one or another hamlib rig driver become
>>> apparent. If something like this happens over and over again, it shows that
>>> there is a *systematic* error somewhere. In my opinion this is due to
>>> the fact that *too few* users try the current development versions of
>>> hamlib, so that errors are detected *too late*. Keep in mind that
>>> hamlib drivers often change as they evolve.
>>>
>>> So I* would like to ask you all that enough OMs act as hamlib bata
>>> tester in the future.* For those who own one of the rigs below and work
>>> on Windows, just do the following every 2, 3 or 4 weeks:
>>>
>>>1. Download the daily updated libhamlib-4.dll file available on
>>>https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll.
>>>2. Copy the file to the bin folder of your WSJT-X installation (i.e.
>>>usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll file
>>>beforehand so you can use it again later.
>>>3. Start WSJT-X (or the respective variant), connect your rig via
>>>hamlib (i.e. *not* via OmniRig, HRD, DXLabSuite, etc.) and check if
>>>the CAT control runs properly.
>>>4. If anything is not working properly, please contact Mike W9MDB
>>>via direct email, so he or his team can fix the bug in time.
>>>5. If everything works fine, keep the new libhamlib-4.dll file,
>>>otherwise delete it and rename the previously used one.
>>>6. In the future I would like to contact you before a new WSJT-X or
>>>wsjt-x_improved release to be able to choose a bug free hamlib version.
>>>
>>> In my opinion, at least the following rigs need to be tested regularly
>>> regarding hamlib:
>>>
>>>- Yaesu: FT-991, FT-101, FT-847
>>>- Kenwood: which models?
>>>- Icom: IC-7300, IC-9100, IC-9700, IC-705
>>>- Elecraft: KX3, what else?
>>>- FlexRadio: which models?
>>>- Anything else?
>>>
>>> *Now, the most important thing is that **one of you* * organizes it*. I
>>> can't do it myself because of time constraints, and Mike W9MDB is also
>>> overloaded with work.
>>>
>>> For example, what about the people who have stood out so intensively in
>>> the last few days with posts about something trivial? Wouldn't one of you
>>> like to take over and invest your energy there? *Seriously: Who?* *Y*
>>> *ou are now requested! *
>>> I mean, what needs to be done is evident:
>>>
>>>1. Create a list of commonly used rig models.
>>>2. Find beta testers for each of these models and assign
>>>responsibilities.
>>>3. Get an overview of the status quo and summarize the results
>>>clearly.
>>>
>>> Something like this can be done e.g. with a simple Excel file:
>>>
>>>
>>>
>>>
>>> It's sad enough that obviously, the hamlib development team can't do
>>> something so essential themselves. But *this definitely has to come now*,
>>> because we can't get the next frustration after every new WSJT-X release.
>>> Makes no sense!
>>>
>>> So, again:
>>>
>>> *Who of you will take this in hand and organize such a systematic beta
>>> testing? *I do not want to see one more "stupid" post as long as this
>>> problem is not solved, hi, hi!
>>>
>>> 73 de Uwe, DG2YCB
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>> 

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc1

[Dennis W1UE via wsjt-devel]

John

What is your operating system?

Thanks!

Dennis W1UE


On Sat, May 13, 2023 at 8:38 AM g4kla--- via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Mike,
>
> No problem with Hamlib-4.6 on Kenwood TS870s.  Working correctly with dual
> VFOs (Split Operation: Rig)
>
> — John G4KLA
>
> ___
> wsjt-devel mailing list
> 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

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc1

[WB5JJJ via wsjt-devel]

This also affected the IC-7610, but the new file fixed the problem.

73's
George - WB5JJJ
HoIP - 100105


On Fri, May 12, 2023 at 2:43 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Try this dll please
>
> https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0
>
> Mike W9MDB
>
>
>
>
>
>
>
>
> On Friday, May 12, 2023 at 12:37:02 PM CDT, Gerald Smith via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>
>
>
>
> Hi Mike,
>
> Thanks for the link.
>
> Well, I placed the dll file in this directory C:\WSJT\wsjtx\bin, and
> rebooted the computer, but I am still getting the error.
>
> So, then I tried re-installing 2.7.0-rc1, and rebooting the computer
> again, I still have the error.
>
> Sorry.
>
> 73 de WA3ZSC - Jerry
>
>
> On 5/12/2023 13:07, Black Michael via wsjt-devel wrote:
> > Direct link
> >
> > https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=1
> >
> > Mike W9MDB
> >
> >
> >
> >
> >
> >
> >
> >
> > On Friday, May 12, 2023 at 12:01:57 PM CDT, Black Michael via wsjt-devel<
> wsjt-devel@lists.sourceforge.net>  wrote:
> >
> >
> >
> >
> >
> > Please try this DLL
> >
> > https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0
> >
> > Mike W9MDB
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Friday, May 12, 2023 at 11:55:54 AM CDT, Gerald Smith via wsjt-devel<
> wsjt-devel@lists.sourceforge.net>  wrote:
> >
> >
> >
> >
> >
> >
> > Hi Joe,
> >
> > Sorry, but I get this error with WSJT-X 2.7.0-rc1.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Radio IC-7700, interface - Timewave Navigator.
> >
> > WSJT-X 2.6.1 works fine though thought that I should let you know.
> >
> > 73 de WA3ZSC - Jerry
> >
> >
> >
> >
> >
> >
> >
> >
> > On 5/12/2023 11:20, Joe Taylor via wsjt-devel wrote:
> >
> >
> >> We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc1 is
> >> ready for download by beta testers.
> >>
> >>
> >>
> >>
> >> ___
> >> wsjt-devel mailing list
> >> 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 mailing list
> > 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 mailing list
> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[WB5JJJ via wsjt-devel]

This also affected the IC-7610, but the new file fixed the problem.

73's
George - WB5JJJ
HoIP - 100105


On Sat, May 13, 2023 at 3:29 AM Tom M0LTE via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hey Uwe
>
> While manual testing could probably never be eliminated in the case of
> hamlib, has there been any consideration of creating test harnesses to
> remove/reduce the need for manual testing?
>
> It strikes me that there could be potential to capture test cases from
> manual testing with real rigs, then at least there would be regression
> tests. Future bug fixes could have test cases added to prevent further
> regression, again without requiring physical radios and manual testing.
>
> Apologies if I am not the first to ask this question.
>
> Kind regards
> Tom M0LTE
>
> On Sat, 13 May 2023 at 08:11, Uwe, DG2YCB via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> Dear WSJT-X users,
>>
>> Please allow me to summarize again here on this email reflector a topic
>> that is very important to me and to all of us. My original post was on
>> https://groups.io/g/wsjtgroup, so maybe it's best if you join the
>> discussion there.
>>
>> Despite great personal commitment of the hamlib developers it has
>> unfortunately happened very often that immediately after a new WSJT-X
>> release serious problems with one or another hamlib rig driver become
>> apparent. If something like this happens over and over again, it shows that
>> there is a *systematic* error somewhere. In my opinion this is due to
>> the fact that *too few* users try the current development versions of
>> hamlib, so that errors are detected *too late*. Keep in mind that hamlib
>> drivers often change as they evolve.
>>
>> So I* would like to ask you all that enough OMs act as hamlib bata
>> tester in the future.* For those who own one of the rigs below and work
>> on Windows, just do the following every 2, 3 or 4 weeks:
>>
>>1. Download the daily updated libhamlib-4.dll file available on
>>https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll.
>>2. Copy the file to the bin folder of your WSJT-X installation (i.e.
>>usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll file
>>beforehand so you can use it again later.
>>3. Start WSJT-X (or the respective variant), connect your rig via
>>hamlib (i.e. *not* via OmniRig, HRD, DXLabSuite, etc.) and check if
>>the CAT control runs properly.
>>4. If anything is not working properly, please contact Mike W9MDB via
>>direct email, so he or his team can fix the bug in time.
>>5. If everything works fine, keep the new libhamlib-4.dll file,
>>otherwise delete it and rename the previously used one.
>>6. In the future I would like to contact you before a new WSJT-X or
>>wsjt-x_improved release to be able to choose a bug free hamlib version.
>>
>> In my opinion, at least the following rigs need to be tested regularly
>> regarding hamlib:
>>
>>- Yaesu: FT-991, FT-101, FT-847
>>- Kenwood: which models?
>>- Icom: IC-7300, IC-9100, IC-9700, IC-705
>>- Elecraft: KX3, what else?
>>- FlexRadio: which models?
>>- Anything else?
>>
>> *Now, the most important thing is that **one of you* * organizes it*. I
>> can't do it myself because of time constraints, and Mike W9MDB is also
>> overloaded with work.
>>
>> For example, what about the people who have stood out so intensively in
>> the last few days with posts about something trivial? Wouldn't one of you
>> like to take over and invest your energy there? *Seriously: Who?* *Y*
>> *ou are now requested! *
>> I mean, what needs to be done is evident:
>>
>>1. Create a list of commonly used rig models.
>>2. Find beta testers for each of these models and assign
>>responsibilities.
>>3. Get an overview of the status quo and summarize the results
>>clearly.
>>
>> Something like this can be done e.g. with a simple Excel file:
>>
>>
>>
>>
>> It's sad enough that obviously, the hamlib development team can't do
>> something so essential themselves. But *this definitely has to come now*,
>> because we can't get the next frustration after every new WSJT-X release.
>> Makes no sense!
>>
>> So, again:
>>
>> *Who of you will take this in hand and organize such a systematic beta
>> testing? *I do not want to see one more "stupid" post as long as this
>> problem is not solved, hi, hi!
>>
>> 73 de Uwe, DG2YCB
>> ___
>> wsjt-devel mailing list
>> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Volunteers Needed- Hamlib Reviews

[Glenn Williams via wsjt-devel]

Hi Dennis,

I can test with this if you need help with this combination:  Windows 10 
22H2, Kenwood TS590SG, USB cable controlled.  Do you need more specifics

on Version numbers of anything?

So far I have had no hamlib trouble with this combination with 2.2.2, 
2.5.4, 2.6.1.


--73, Glenn, AF8C

On 5/13/2023 8:44 AM, Dennis W1UE via wsjt-devel wrote:
I'm looking to get a group of ops together to review Hamlib files prior 
to the release of new ones.  Any op with any rig is eligible to apply.


If you're interested, please specify your rig, version of Windows (or 
your OS), and any other specifics that may be applicable.


Our immediate task is to review the last several Hamlib files, and see 
if we have a "best working"  file that can be released with the upcoming 
version of WSJT-improved.  After that, we will be looking to check out 
Hamlib files PRIOR to their

release.  Instructions will be provided on how to do the testing.

Dennis W1UE





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] [wsjtgroup] Volunteers Needed- Hamlib Reviews

[Hisashi T Fujinaka via wsjt-devel]

I should clarify: only the K3 is turned on at the moment, but I'd be
happy to test.

On Sat, 13 May 2023, Black Michael wrote:


Looks for any errors at all during startup or normal operations.

In particular using Fake It or Rig Split

Mike W9MDB







On Saturday, May 13, 2023 at 09:35:42 AM CDT, Hisashi T Fujinaka via wsjt-devel 
 wrote:





I have an Elecraft K3 and an Elecraft K4 and I'm running MacOS.

I could test but I haven't had much problem and I'm not entirely sure
what we're testing. The only thing I ever check to make sure is tht the
band is changing. I've never been on the QA side of software
development.

On Sat, 13 May 2023, Dennis W1UE wrote:


I'm looking to get a group of ops together to review Hamlib files prior to
the release of new ones.  Any op with any rig is eligible to apply.

If you're interested, please specify your rig, version of Windows (or your
OS), and any other specifics that may be applicable.

Our immediate task is to review the last several Hamlib files, and see if
we have a "best working"  file that can be released with the upcoming
version of WSJT-improved.  After that, we will be looking to check out
Hamlib files PRIOR to their
release.  Instructions will be provided on how to do the testing.

Dennis W1UE


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#282): https://groups.io/g/wsjtgroup/message/282
Mute This Topic: https://groups.io/mt/98867433/239357
Group Owner: wsjtgroup+ow...@groups.io
Unsubscribe: 
https://groups.io/g/wsjtgroup/leave/12257253/239357/1979070917/xyzzy 
[ht...@twofifty.com]
-=-=-=-=-=-=-=-=-=-=-=-








--
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error Loading LOTW Users Data

[Uwe, DG2YCB via wsjt-devel]

Hi Jim,

This is something for Brian, N9ADG. He programmed this feature. Have you
followed the steps described in chapter 3.1 of the user guide and
installed the Windows OpenSSL Packages
?

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 13.05.2023 um 16:34 schrieb Jim Preston via wsjt-devel:

Using WSJT-X 2.7.0-rc1.
Windows 11

When I click "Fetch Now" in the "Logbook of the World User Validation
section, I get an error stating:

Error Loading LOTW Users Data
TLS initialization failed.

73,

Jim N6VH


___
wsjt-devel mailing list
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

Re: [wsjt-devel] Compiling new hamlib

[Black Michael via wsjt-devel]

What do you mean "it does not find my Hamlib net rigctld,"  -- is there some 
error message?

Mike W9MDB






On Saturday, May 13, 2023 at 09:41:27 AM CDT, jarmo  wrote: 





Sat, 13 May 2023 12:42:20 + (UTC)
Black Michael via wsjt-devel 
kirjoitti:
Hi Mike &

No, I did git pull on to existing hamlib. Renamed it and With clean
git clone, everything went ok. Compiled and is running.

Now BUT...
When I take wsjtx, git clone etc... Seems to go ok, compilation
and install. Start wsjtx, I see version 2.6.1 still? And what
worse, it does not find my Hamlib net rigctld, my logprog, CqrLog
works ok with new hamlib.

No panic... sure find solution..

jarmo, oh1mrr
> Do you have an old libhamlib sitting around?  Did you uninstall the
> hamlib package?
> 
> Mike W9MDB
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Saturday, May 13, 2023 at 04:35:41 AM CDT, jarmo via wsjt-devel
>  wrote: 
> 
> 
> 
> 
> 
> Just started trying compile hamlib in Fedora 38.
> Got error
> make[1]: Siirrytään hakemistoon ”/home/oh1mrr/Hamlib/c++”
>   CXXLD    libhamlib++.la
> /usr/bin/ld: cannot find
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/crti.o: No such
> file or directory /usr/bin/ld: cannot find
> /usr/lib/gcc/x86_64-redhat-linux/12/crtbeginS.o: No such file or
> directory collect2: error: ld returned 1 exit status
> 
> But, find /usr/ -name crti*
> /usr/lib64/crti.o
> 
> find /usr/ -name crtbeginS*
> /usr/lib/gcc/x86_64-redhat-linux/13/crtbeginS.o
> /usr/lib/gcc/x86_64-redhat-linux/13/32/crtbeginS.o
> 
> As known, I don't "speak nerd" well :), if I could get
> easy way out?
> I see that ld is looking first hand /12/, but F38 has /13/.
> 
> Any solution???
> 
> Jarmo, oh1mrr
> 
> 
> ___
> wsjt-devel mailing list
> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Compiling new hamlib

[jarmo via wsjt-devel]

Sat, 13 May 2023 12:42:20 + (UTC)
Black Michael via wsjt-devel 
kirjoitti:
Hi Mike &

No, I did git pull on to existing hamlib. Renamed it and With clean
git clone, everything went ok. Compiled and is running.

Now BUT...
 When I take wsjtx, git clone etc... Seems to go ok, compilation
and install. Start wsjtx, I see version 2.6.1 still? And what
worse, it does not find my Hamlib net rigctld, my logprog, CqrLog
works ok with new hamlib.

No panic... sure find solution..

jarmo, oh1mrr
> Do you have an old libhamlib sitting around?  Did you uninstall the
> hamlib package?
> 
> Mike W9MDB
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Saturday, May 13, 2023 at 04:35:41 AM CDT, jarmo via wsjt-devel
>  wrote: 
> 
> 
> 
> 
> 
> Just started trying compile hamlib in Fedora 38.
> Got error
> make[1]: Siirrytään hakemistoon ”/home/oh1mrr/Hamlib/c++”
>   CXXLD    libhamlib++.la
> /usr/bin/ld: cannot find
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/crti.o: No such
> file or directory /usr/bin/ld: cannot find
> /usr/lib/gcc/x86_64-redhat-linux/12/crtbeginS.o: No such file or
> directory collect2: error: ld returned 1 exit status
> 
> But, find /usr/ -name crti*
> /usr/lib64/crti.o
> 
> find /usr/ -name crtbeginS*
> /usr/lib/gcc/x86_64-redhat-linux/13/crtbeginS.o
> /usr/lib/gcc/x86_64-redhat-linux/13/32/crtbeginS.o
> 
> As known, I don't "speak nerd" well :), if I could get
> easy way out?
> I see that ld is looking first hand /12/, but F38 has /13/.
> 
> Any solution???
> 
> Jarmo, oh1mrr
> 
> 
> ___
> wsjt-devel mailing list
> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] [wsjtgroup] Volunteers Needed- Hamlib Reviews

[Black Michael via wsjt-devel]

Looks for any errors at all during startup or normal operations.

In particular using Fake It or Rig Split

Mike W9MDB







On Saturday, May 13, 2023 at 09:35:42 AM CDT, Hisashi T Fujinaka via wsjt-devel 
 wrote: 





I have an Elecraft K3 and an Elecraft K4 and I'm running MacOS.

I could test but I haven't had much problem and I'm not entirely sure
what we're testing. The only thing I ever check to make sure is tht the
band is changing. I've never been on the QA side of software
development.

On Sat, 13 May 2023, Dennis W1UE wrote:

> I'm looking to get a group of ops together to review Hamlib files prior to
> the release of new ones.  Any op with any rig is eligible to apply.
>
> If you're interested, please specify your rig, version of Windows (or your
> OS), and any other specifics that may be applicable.
>
> Our immediate task is to review the last several Hamlib files, and see if
> we have a "best working"  file that can be released with the upcoming
> version of WSJT-improved.  After that, we will be looking to check out
> Hamlib files PRIOR to their
> release.  Instructions will be provided on how to do the testing.
>
> Dennis W1UE
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#282): https://groups.io/g/wsjtgroup/message/282
> Mute This Topic: https://groups.io/mt/98867433/239357
> Group Owner: wsjtgroup+ow...@groups.io
> Unsubscribe: 
> https://groups.io/g/wsjtgroup/leave/12257253/239357/1979070917/xyzzy 
> [ht...@twofifty.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
>

-- 
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee


___
wsjt-devel mailing list
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] Error Loading LOTW Users Data

[Jim Preston via wsjt-devel]

Using WSJT-X 2.7.0-rc1.
Windows 11

When I click "Fetch Now" in the "Logbook of the World User Validation 
section, I get an error stating:


Error Loading LOTW Users Data
TLS initialization failed.

73,

Jim N6VH
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] [wsjtgroup] Volunteers Needed- Hamlib Reviews

[Hisashi T Fujinaka via wsjt-devel]

I have an Elecraft K3 and an Elecraft K4 and I'm running MacOS.

I could test but I haven't had much problem and I'm not entirely sure
what we're testing. The only thing I ever check to make sure is tht the
band is changing. I've never been on the QA side of software
development.

On Sat, 13 May 2023, Dennis W1UE wrote:


I'm looking to get a group of ops together to review Hamlib files prior to
the release of new ones.  Any op with any rig is eligible to apply.

If you're interested, please specify your rig, version of Windows (or your
OS), and any other specifics that may be applicable.

Our immediate task is to review the last several Hamlib files, and see if
we have a "best working"  file that can be released with the upcoming
version of WSJT-improved.  After that, we will be looking to check out
Hamlib files PRIOR to their
release.  Instructions will be provided on how to do the testing.

Dennis W1UE


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#282): https://groups.io/g/wsjtgroup/message/282
Mute This Topic: https://groups.io/mt/98867433/239357
Group Owner: wsjtgroup+ow...@groups.io
Unsubscribe: 
https://groups.io/g/wsjtgroup/leave/12257253/239357/1979070917/xyzzy 
[ht...@twofifty.com]
-=-=-=-=-=-=-=-=-=-=-=-





--
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.7.0-rc1 Mac build changes

[Hisashi T Fujinaka via wsjt-devel]

Yes, I did the same. I sent the diffs to Uwe.

So far, there are a few quirks in the rc. Mostly with jt-bridge
integration not working the same as before. Double clicking on a
non-CQing station doesn't seem to populate the DX call but can put your
station into "Enable TX" so instead of calling DX after clicking on
their "RR73", it put me into CQ mode.

Oh, and sometimes TX1 was greyed out so the only thing I could send was
TX2.

Both sound like they could be part of the "improved" code. I didn't go
poking around in that code yet.

On Fri, 12 May 2023, Alex Lelievre via wsjt-devel wrote:


If the team would be willing to accept some diffs for the Mac build under MacOS 
SDK 13-

The main issue on Mac is that sprintf is deprecated and treated as an error. 
The second issue are a few variables that are declared and incremented but not used anywhere.


In qmap/astro.cpp there are several calls to sprintf that I updated to snprintf.

qmap/soundin.cpp:   in SoundInThread::inputUDP() there is a variable ?nBusy' 
that is not used (I just commented it out).

Same with models/FrequencyList.cpp:  in FrequencyList_v2_101::from_json_file(), 
there?s ?valid_entry_count' and ?skipped_entry_count? variables which are not 
used.  Also commented out.

These all cause build errors and it would be great if the code base could 
include these changes.

Thanks again for a new version.  So far so good!
alex K6LOT

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[Adrian via wsjt-devel]

I agree on Uwes position over '''Rejnos, certainty...

On 13/5/23 22:59, Tom M0LTE via wsjt-devel wrote:

Hey Reino

I fully understand your concerns. Clearly this idea has been 
considered. Conceptually I believe a slightly different approach might 
overcome some of those difficulties, however I am conscious of 
derailing Uwe’s thread, so I won’t.


Uwe, good luck with the search.

Best wishes
Tom

On Sat, 13 May 2023 at 11:05, Reino Talarmo via wsjt-devel 
 wrote:


> From: Tom M0LTE via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net]
> Sent: lauantai 13. toukokuuta 2023 10.58
>While manual testing could probably never be eliminated in the
case of hamlib, has there been any consideration of creating test
harnesses to remove/reduce the need for manual testing?

>It strikes me that there could be potential to capture test cases
from manual testing with real rigs, then at least there would be
regression tests. Future bug fixes could have test cases added to
prevent further regression, again without requiring physical
radios and manual testing.

Hi Tom,

Your proposal could work in an ideal world.
There are just minor requirements before it is easily done.
#1 There should be a (well) defined and agreed CAT protocol that
all rig manufactures follow.
#2 All rigs should have tested against that protocol.
#3 Resources to design and prepare the test program.
#4 Resources to design and prepare the Hamlib testing harness
against the agreed CAT protocol.

On #1 we have a subset of commands that are commonly used. Even no
agreed minimum responses to commands are agreed. There is no
performance requirements such as timing.
The #2 is a farfetched dream.
The #3, hups, did I mentioned this?
The #4, just what!

In addition there are in some implementations bugs and the public
CAT command set behaves differently than assumed. All those deal
to a situation that the manual testing of most radios is the best
way to perform this testing task. For that we need is the famous
'somebody' to keep it going and reporting to the Hamlib task force.

Sorry of being to pessimistic, I have some experience on that kind
of issue and now safely retired.

73, Reino OH3mA



___
wsjt-devel mailing list
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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Hamlib hotfixes

[Uwe, DG2YCB via wsjt-devel]

Hi all,

As a help for those of you having problems with CAT control of your rig
with v2.7.0-rc1, I have copied the latest hamlib hotfixes to the folder
listed below. You will find there not only files for Windows but also
for macOS and Raspberry Pi.

https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.0/hamlib/

73 de Uwe, DG2YCB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[Tom M0LTE via wsjt-devel]

Hey Reino

I fully understand your concerns. Clearly this idea has been considered.
Conceptually I believe a slightly different approach might overcome some of
those difficulties, however I am conscious of derailing Uwe’s thread, so I
won’t.

Uwe, good luck with the search.

Best wishes
Tom

On Sat, 13 May 2023 at 11:05, Reino Talarmo via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> > From: Tom M0LTE via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
>
> > Sent: lauantai 13. toukokuuta 2023 10.58
> >While manual testing could probably never be eliminated in the case of
> hamlib, has there been any consideration of creating test harnesses to
> remove/reduce the need for manual testing?
>
> >It strikes me that there could be potential to capture test cases from
> manual testing with real rigs, then at least there would be regression
> tests. Future bug fixes could have test cases added to prevent further
> regression, again without requiring physical radios and manual testing.
>
> Hi Tom,
>
> Your proposal could work in an ideal world.
> There are just minor requirements before it is easily done.
> #1 There should be a (well) defined and agreed CAT protocol that all rig
> manufactures follow.
> #2 All rigs should have tested against that protocol.
> #3 Resources to design and prepare the test program.
> #4 Resources to design and prepare the Hamlib testing harness against the
> agreed CAT protocol.
>
> On #1 we have a subset of commands that are commonly used. Even no agreed
> minimum responses to commands are agreed. There is no performance
> requirements such as timing.
> The #2 is a farfetched dream.
> The #3, hups, did I mentioned this?
> The #4, just what!
>
> In addition there are in some implementations bugs and the public CAT
> command set behaves differently than assumed. All those deal to a situation
> that the manual testing of most radios is the best way to perform this
> testing task. For that we need is the famous 'somebody' to keep it going
> and reporting to the Hamlib task force.
>
> Sorry of being to pessimistic, I have some experience on that kind of
> issue and now safely retired.
>
> 73, Reino OH3mA
>
>
>
> ___
> wsjt-devel mailing list
> 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] Volunteers Needed- Hamlib Reviews

[Dennis W1UE via wsjt-devel]

I'm looking to get a group of ops together to review Hamlib files prior to
the release of new ones.  Any op with any rig is eligible to apply.

If you're interested, please specify your rig, version of Windows (or your
OS), and any other specifics that may be applicable.

Our immediate task is to review the last several Hamlib files, and see if
we have a "best working"  file that can be released with the upcoming
version of WSJT-improved.  After that, we will be looking to check out
Hamlib files PRIOR to their
release.  Instructions will be provided on how to do the testing.

Dennis W1UE
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Compiling new hamlib

[Black Michael via wsjt-devel]

Do you have an old libhamlib sitting around?  Did you uninstall the hamlib 
package?

Mike W9MDB









On Saturday, May 13, 2023 at 04:35:41 AM CDT, jarmo via wsjt-devel 
 wrote: 





Just started trying compile hamlib in Fedora 38.
Got error
make[1]: Siirrytään hakemistoon ”/home/oh1mrr/Hamlib/c++”
  CXXLD    libhamlib++.la
/usr/bin/ld: cannot find 
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/crti.o: No such file or 
directory
/usr/bin/ld: cannot find /usr/lib/gcc/x86_64-redhat-linux/12/crtbeginS.o: No 
such file or directory
collect2: error: ld returned 1 exit status

But, find /usr/ -name crti*
/usr/lib64/crti.o

find /usr/ -name crtbeginS*
/usr/lib/gcc/x86_64-redhat-linux/13/crtbeginS.o
/usr/lib/gcc/x86_64-redhat-linux/13/32/crtbeginS.o

As known, I don't "speak nerd" well :), if I could get
easy way out?
I see that ld is looking first hand /12/, but F38 has /13/.

Any solution???

Jarmo, oh1mrr


___
wsjt-devel mailing list
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

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc1

[g4kla--- via wsjt-devel]

Mike,

No problem with Hamlib-4.6 on Kenwood TS870s.  Working correctly with dual VFOs 
(Split Operation: Rig)

— John G4KLA



smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Head of a new Hamlib Beta Testing Group found

[Uwe, DG2YCB via wsjt-devel]

Hi all,

I am pleased to announce that Dennis, W1UE has agreed to take
responsibility for hamlib beta testing.

So: *I hereby appoint him as our new official head of the Hamlib Beta
Testing Group!*

Concrete next steps of the new Hamlib Beta Testing Group should be the
following:

1. Find beta testers for the most widely used, say 12 to 25 rigs and
   assign the responsibilities.
2. *The first concrete task of the Hamlib Beta Testing Group is to find
   as soon as possible (realistically within 2 to 3 weeks) _one_ hamlib
   version that runs on all these "key rigs" without problems.* As
   before, technical problems should be solved in close cooperation
   with Mike W9MDB, whose work and expertise I greatly appreciate. But
   this is something else than systematic testing and bug finding, and
   we need both.
3. Then I can use this version for the next update of WSJT-X or
   wsjt-x_improved, which I plan to do in the not too distant future
   (at least for wsjt-x_improved).
4. If a date for the next release is foreseeable, I would inform Dennis
   in advance, so that he and his Hamlib Beta Testing Group can select
   the best performing hamlib version. Keep in mind, that I always need
   the hamlib source code, as well as the binaries in 64-bit and
   32-bit. So the group must make sure that these 3 files are available
   for the selected hamlib version.

So, now it is enough from me on this topic. *From now on, Dennis is
called to start with the work.* I wish from the bottom of my heart much
success!

73 de Uwe, DG2YCB


Am 13.05.2023 um 09:09 schrieb Uwe, DG2YCB via wsjt-devel:

Dear WSJT-X users,

Please allow me to summarize again here on this email reflector a
topic that is very important to me and to all of us. My original post
was on https://groups.io/g/wsjtgroup, so maybe it's best if you join
the discussion there.

Despite great personal commitment of the hamlib developers it has
unfortunately happened very often that immediately after a new WSJT-X
release serious problems with one or another hamlib rig driver become
apparent. If something like this happens over and over again, it shows
that there is a *systematic* error somewhere. In my opinion this is
due to the fact that *too few* users try the current development
versions of hamlib, so that errors are detected *too late*. Keep in
mind that hamlib drivers often change as they evolve.

So I*would like to ask you all that enough OMs act as hamlib bata
tester in the future.* For those who own one of the rigs below and
work on Windows, just do the following every 2, 3 or 4 weeks:

 1. Download the daily updated libhamlib-4.dll file available on
https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll.
 2. Copy the file to the bin folder of your WSJT-X installation (i.e.
usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll
file beforehand so you can use it again later.
 3. Start WSJT-X (or the respective variant), connect your rig via
hamlib (i.e. *not* via OmniRig, HRD, DXLabSuite, etc.) and check
if the CAT control runs properly.
 4. If anything is not working properly, please contact Mike W9MDB via
direct email, so he or his team can fix the bug in time.
 5. If everything works fine, keep the new libhamlib-4.dll file,
otherwise delete it and rename the previously used one.
 6. In the future I would like to contact you before a new WSJT-X or
wsjt-x_improved release to be able to choose a bug free hamlib
version.

In my opinion, at least the following rigs need to be tested regularly
regarding hamlib:

  * Yaesu: FT-991, FT-101, FT-847
  * Kenwood: which models?
  * Icom: IC-7300, IC-9100, IC-9700, IC-705
  * Elecraft: KX3, what else?
  * FlexRadio: which models?
  * Anything else?

*Now, the most important thing is that **one of you* *organizes it*. I
can't do it myself because of time constraints, and Mike W9MDB is also
overloaded with work.

For example, what about the people who have stood out so intensively
in the last few days with posts about something trivial? Wouldn't one
of you like to take over and invest your energy there? *Seriously:
Who?* *Y**ou are now requested!
*
I mean, what needs to be done is evident:

 1. Create a list of commonly used rig models.
 2. Find beta testers for each of these models and assign
responsibilities.
 3. Get an overview of the status quo and summarize the results clearly.

Something like this can be done e.g. with a simple Excel file:




It's sad enough that obviously, the hamlib development team can't do
something so essential themselves. But *this definitely has to come
now*, because we can't get the next frustration after every new WSJT-X
release. Makes no sense!

So, again: *Who of you will take this in hand and organize such a
systematic beta testing?

*I do not want to see one more "stupid" post as long as this problem
is not solved, hi, hi!*

*73 de Uwe, DG2YCB


___
wsjt-devel mailing list

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[Black Michael via wsjt-devel]

I have been writing simulators but they do not have the nuances that the rigs 
do.  There's all sorts of oddities.

Butthe plan is to eventually incorporate those simulators in the "make 
test" in Hamlib that should catch big mistakes.

It's on my to-do list but don't hold your breath...it's a low priority.

Mike W9MDB








On Saturday, May 13, 2023 at 03:29:25 AM CDT, Tom M0LTE via wsjt-devel 
 wrote: 





Hey Uwe

While manual testing could probably never be eliminated in the case of hamlib, 
has there been any consideration of creating test harnesses to remove/reduce 
the need for manual testing?

It strikes me that there could be potential to capture test cases from manual 
testing with real rigs, then at least there would be regression tests. Future 
bug fixes could have test cases added to prevent further regression, again 
without requiring physical radios and manual testing.

Apologies if I am not the first to ask this question.

Kind regards
Tom M0LTE

On Sat, 13 May 2023 at 08:11, Uwe, DG2YCB via wsjt-devel 
 wrote:
>  
>  Dear WSJT-X users,
> 
> Please allow me to summarize again here on this email reflector a topic that 
> is very important to me and to all of us. My original post was on 
> https://groups.io/g/wsjtgroup, so maybe it's best if you join the discussion 
> there.  
> 
> Despite great personal commitment of the hamlib developers it has 
> unfortunately happened very often that immediately after a new WSJT-X release 
> serious problems with one or another hamlib rig driver become apparent. If 
> something like this happens over and over again, it shows that there is a 
> systematic error somewhere. In my opinion this is due to the fact that too 
> few users try the current development versions of hamlib, so that errors are 
> detected too late. Keep in mind that hamlib drivers often change as they 
> evolve.
> 
> So I would like to ask you all that enough OMs act as hamlib bata tester in 
> the future. For those who own one of the rigs below and work on Windows, just 
> do the following every 2, 3 or 4 weeks:
> 
> 1. Download the daily updated libhamlib-4.dll file available on 
> https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll.
> 2. Copy the file to the bin folder of your WSJT-X installation (i.e. 
> usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll file 
> beforehand so you can use it again later.
> 3. Start WSJT-X (or the respective variant), connect your rig via hamlib 
> (i.e. not via OmniRig, HRD, DXLabSuite, etc.) and check if the CAT control 
> runs properly.
> 4. If anything is not working properly, please contact Mike W9MDB via 
> direct email, so he or his team can fix the bug in time.
> 5. If everything works fine, keep the new libhamlib-4.dll file, otherwise 
> delete it and rename the previously used one.
> 6. In the future I would like to contact you before a new WSJT-X or 
> wsjt-x_improved release to be able to choose a bug free hamlib version.
> In my opinion, at least the following rigs need to be tested regularly 
> regarding hamlib:
> 
> * Yaesu: FT-991, FT-101, FT-847
> * Kenwood: which models?
> * Icom: IC-7300, IC-9100, IC-9700, IC-705
> * Elecraft: KX3, what else?
> * FlexRadio: which models?
> * Anything else?
> Now, the most important thing is that one of you  organizes it. I can't do it 
> myself because of time constraints, and Mike W9MDB is also overloaded with 
> work. 
> 
> For example, what about the people who have stood out so intensively in the 
> last few days with posts about something trivial? Wouldn't one of you like to 
> take over and invest your energy there? Seriously: Who? You are now requested!
> 
> I mean, what needs to be done is evident:
> 
> 1. Create a list of commonly used rig models.
> 2. Find beta testers for each of these models and assign responsibilities.
> 
> 3. Get an overview of the status quo and summarize the results clearly.
> 
> Something like this can be done e.g. with a simple Excel file:
> 
> 
> 
> 
> It's sad enough that obviously, the hamlib development team can't do 
> something so essential themselves. But this definitely has to come now, 
> because we can't get the next frustration after every new WSJT-X release. 
> Makes no sense!
> 
> So, again: Who of you will take this in hand and organize such a systematic 
> beta testing?
> 
> I do not want to see one more "stupid" post as long as this problem is not 
> solved, hi, hi!
> 
> 73 de Uwe, DG2YCB 
>  ___
> wsjt-devel mailing list
> 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 mailing list
wsjt-devel@lists.sourceforge.net

Re: [wsjt-devel] WSJTX Cabrillo log time

[Frode Igland via wsjt-devel]

Regarding logged time in cabrillo. Let's reason backwards:
1. Cabrillo is a file format used for submitting contest logs only.
2. Cabrillo is a file format normally created from an ADIF file that is
created by specialized logging software, say N1MM Logger+, WinTest or some
other contest software.
3. Logging softwares have no idea of when a QSO starts, because the only
input they receive is when the logging of a QSO takes place, i.e. not until
the contester finds the QSO to be complete, which is another way to say
that logging takes place at TIME-OFF.
4. Matching of contest QSOs takes place if the time difference between the
two involved logs are less than a specified time difference, which at least
in the major contests is five minutes.
5. So, if you want to submit a cabrillo contest log, you should certainly
make sure that the cabrillo file is created using TIME_OFF, no matter which
software (contest software or not) you have used to log the QSOs during the
contest. That also applies to using WSJTX_LOG.ADI as the ADIF contest log.
6. The time difference of 30 minutes allowed for QSO matching in LoTW
obviously is not relevant for the time logged in the cabrillo log. They
have two very different purposes, and LoTW has no bearing whatsoever of
what a contest sponsor will accept.
7. Based on the above, starting from the origin and purpose of a cabrillo
file, there is no reason to consider any other time than TIME_OFF for the
cabrillo log.

73, Frode LA6VQ (LC6C in contest)


Virusfri.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

lør. 13. mai 2023 kl. 07:06 skrev Reino Talarmo via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

> Hi Saku
>
> Some comments in-line. A bit long email, sri. It's time for the new
> candidate release discussion.
>
> 73, Reino OH3mA
>
> > From: Saku via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> > Sent: perjantai 12. toukokuuta 2023 21.22
>
> > if you calling CQ (TX1) and someone(s) answer to it qso starts from
> point you start first TX2 transmission (to any of answering stations).
> >It is very clear. There is no exchange happened yet, and your TX2 will
> start the exchange chain (= qso).
> > Same if you try to answer someones CQ. Once he sends first TX2 qso
> begins.
>
> Reino: LoTW states that "both QSO descriptions specify start times within
> 30 minutes of each other". So in that sense start time gets one plus point.
>
> > In case of missed TX2 receive you will get different start time than the
> opponent, that is true. However the base of qso starting definition is
> clear.
>
> Reino: That issue is a real challenge especially on pile-up situations.
> You may need to send your Tx2 even hours e.g. as a Hound, before the Fox
> picks your call into the QSO list (= potential earliest start time on the
> Fox point of view). Even the so started QSO may fail and Fox never sends
> RR73 to you. Now would it be a new QSO start, if you send even once again
> Tx2?
>
> > End time of qso is more or less unclear. It is clear (by rules) when
> both sides have exchanged reports and got confirmation to them.
> > You get confirmation with report as "R-xx" and you confirm it by sending
> "RRR" or "RR73".
>
> Reino: That is recommended in the User Guide with a potential need for a
> resending RR73 or RRR due to a repeated "R-xx". To me that is a clear point
> of time as the operator feels the QSO is completed, he has sent RR73 (RRR)
> or received RR73 or 73 and no more a reception of "R-xx". User may need to
> correct the proposed end time in that case.
>
> > What I mean "unclear" is that someone requires 73 after RRR or RR73 to
> see the qso complete, someone else do not.
> > There has been lot of conversation about this in past and I do not want
> to make another "split argue" with this.
>
> Reino: Fully agree that there are at least two strong opinions on that and
> absolutely no need to restart any discussion on that issue. As an example
> is DXpedition mode, where Fox simply logs QSO at the sending the RR73.
> There is simply no action defined in that protocol for a reception of 73.
> For that reason there are dupes, but who cares. The same applies to some
> contests, where the sending of the 73 is not defined or stated optional. If
> there is a disagreement between operators, then simply there is no QSO (a
> NIL). That's a different issue, isn't it.
>
> Reino: My comment is also "what about interleaved QSOs or QSO attempts?".
> Well, normally QSO order in a log does not matter. BUT for a program that
> generates some challenges. E.g. how may QSO attempts (sending the first
> Tx2) it needs to remember?
>
> > My 5 cents is that qso start time is easier to define so that all can
> agree with definition and should be used with Cabrillo, like it is used
> with CW and phone, too.
> 

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc1

[Gary Rogers via wsjt-devel]

Here is the most recent Hamlib libhamlib.so.4.0.6 for Raspberry Pi (RPi version 
of the .dll)

https://www.dropbox.com/s/a9gdyo3qayp86yc/libhamlib.so.4.0.6?dl=0





> On May 13, 2023, at 5:28 AM, Gary Rogers  wrote:
> 
> Here is the most recent Hamlib .dylib for MacOS (dylib is the Mac version of 
> .dll):
> 
> https://www.dropbox.com/s/0m9v3i1ceb1bv19/libhamlib.4.dylib?dl=0
> 
> To install: In Dock, go to Finder> Applications>WSJTX.app
> 
> Right click on WSJTX.app 
> 
> Click on Show Package Contents
> 
> Click on Contents> Frameworks
> 
> Paste the downloaded libhamlib.4.dylib into Frameworks
> 
> Click yes when it asks to replace the file.
> 
> Here is where it goes:
> 
> 
> 
> 
> 
> 
> 
>> On May 12, 2023, at 2:33 PM, Black Michael via wsjt-devel 
>>  wrote:
>> 
>> We had somebody who was nicely compiling MacOS versions
>> 
>> https://github.com/Hamlib/Hamlib
>> 
>> Hopefully they are still out there...
>> 
>> Mike W9MDB
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Friday, May 12, 2023 at 12:38:31 PM CDT, Greg Vatt  wrote: 
>> 
>> 
>> 
>> 
>> 
>> Mike,
>> 
>> I’m having the same problem here on MacOS M1 (13.3.1) + IC-7610. Even 
>> tried again with a clean install.
>> 
>> 
>> 
>> 
>> 
>> 
>> Greg, NC7B
>> 
>> 
>> 
>>> On May 12, 2023, at 9:57 AM, Black Michael via wsjt-devel 
>>>  wrote:
>>> 
>>> Please try this DLL
>>> 
>>> https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0
>>> 
>>> Mike W9MDB
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Friday, May 12, 2023 at 11:55:54 AM CDT, Gerald Smith via wsjt-devel 
>>>  wrote: 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Hi Joe,
>>> 
>>> Sorry, but I get this error with WSJT-X 2.7.0-rc1.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Radio IC-7700, interface - Timewave Navigator.
>>> 
>>> WSJT-X 2.6.1 works fine though thought that I should let you know.
>>> 
>>> 73 de WA3ZSC - Jerry
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 5/12/2023 11:20, Joe Taylor via wsjt-devel wrote:
>>> 
>>> 
 We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc1 is 
 ready for download by beta testers. 
 
 
 
 
 ___ 
 wsjt-devel mailing list 
 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 mailing list
>>> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc1

[John Nelson via wsjt-devel]

Mike,

No problem with Hamlib-4.6 on Kenwood TS870s.  Working correctly with dual VFOs 
(Split Operation: Rig)

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[Reino Talarmo via wsjt-devel]

> From: Tom M0LTE via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
> Sent: lauantai 13. toukokuuta 2023 10.58
>While manual testing could probably never be eliminated in the case of hamlib, 
>has there been any consideration of creating test harnesses to remove/reduce 
>the need for manual testing?

>It strikes me that there could be potential to capture test cases from manual 
>testing with real rigs, then at least there would be regression tests. Future 
>bug fixes could have test cases added to prevent further regression, again 
>without requiring physical radios and manual testing.

Hi Tom,

Your proposal could work in an ideal world.
There are just minor requirements before it is easily done.
#1 There should be a (well) defined and agreed CAT protocol that all rig 
manufactures follow.
#2 All rigs should have tested against that protocol.
#3 Resources to design and prepare the test program.
#4 Resources to design and prepare the Hamlib testing harness against the 
agreed CAT protocol.

On #1 we have a subset of commands that are commonly used. Even no agreed 
minimum responses to commands are agreed. There is no performance requirements 
such as timing.
The #2 is a farfetched dream.
The #3, hups, did I mentioned this?
The #4, just what!

In addition there are in some implementations bugs and the public CAT command 
set behaves differently than assumed. All those deal to a situation that the 
manual testing of most radios is the best way to perform this testing task. For 
that we need is the famous 'somebody' to keep it going and reporting to the 
Hamlib task force. 

Sorry of being to pessimistic, I have some experience on that kind of issue and 
now safely retired.

73, Reino OH3mA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Compiling new hamlib

[jarmo via wsjt-devel]

Just started trying compile hamlib in Fedora 38.
Got error
make[1]: Siirrytään hakemistoon ”/home/oh1mrr/Hamlib/c++”
  CXXLDlibhamlib++.la
/usr/bin/ld: cannot find 
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/crti.o: No such file or 
directory
/usr/bin/ld: cannot find /usr/lib/gcc/x86_64-redhat-linux/12/crtbeginS.o: No 
such file or directory
collect2: error: ld returned 1 exit status

But, find /usr/ -name crti*
/usr/lib64/crti.o

find /usr/ -name crtbeginS*
/usr/lib/gcc/x86_64-redhat-linux/13/crtbeginS.o
/usr/lib/gcc/x86_64-redhat-linux/13/32/crtbeginS.o

As known, I don't "speak nerd" well :), if I could get
easy way out?
I see that ld is looking first hand /12/, but F38 has /13/.

Any solution???

Jarmo, oh1mrr


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[Tom M0LTE via wsjt-devel]

Hey Uwe

While manual testing could probably never be eliminated in the case of
hamlib, has there been any consideration of creating test harnesses to
remove/reduce the need for manual testing?

It strikes me that there could be potential to capture test cases from
manual testing with real rigs, then at least there would be regression
tests. Future bug fixes could have test cases added to prevent further
regression, again without requiring physical radios and manual testing.

Apologies if I am not the first to ask this question.

Kind regards
Tom M0LTE

On Sat, 13 May 2023 at 08:11, Uwe, DG2YCB via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Dear WSJT-X users,
>
> Please allow me to summarize again here on this email reflector a topic
> that is very important to me and to all of us. My original post was on
> https://groups.io/g/wsjtgroup, so maybe it's best if you join the
> discussion there.
>
> Despite great personal commitment of the hamlib developers it has
> unfortunately happened very often that immediately after a new WSJT-X
> release serious problems with one or another hamlib rig driver become
> apparent. If something like this happens over and over again, it shows that
> there is a *systematic* error somewhere. In my opinion this is due to the
> fact that *too few* users try the current development versions of hamlib,
> so that errors are detected *too late*. Keep in mind that hamlib drivers
> often change as they evolve.
>
> So I* would like to ask you all that enough OMs act as hamlib bata tester
> in the future.* For those who own one of the rigs below and work on
> Windows, just do the following every 2, 3 or 4 weeks:
>
>1. Download the daily updated libhamlib-4.dll file available on
>https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll.
>2. Copy the file to the bin folder of your WSJT-X installation (i.e.
>usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll file
>beforehand so you can use it again later.
>3. Start WSJT-X (or the respective variant), connect your rig via
>hamlib (i.e. *not* via OmniRig, HRD, DXLabSuite, etc.) and check if
>the CAT control runs properly.
>4. If anything is not working properly, please contact Mike W9MDB via
>direct email, so he or his team can fix the bug in time.
>5. If everything works fine, keep the new libhamlib-4.dll file,
>otherwise delete it and rename the previously used one.
>6. In the future I would like to contact you before a new WSJT-X or
>wsjt-x_improved release to be able to choose a bug free hamlib version.
>
> In my opinion, at least the following rigs need to be tested regularly
> regarding hamlib:
>
>- Yaesu: FT-991, FT-101, FT-847
>- Kenwood: which models?
>- Icom: IC-7300, IC-9100, IC-9700, IC-705
>- Elecraft: KX3, what else?
>- FlexRadio: which models?
>- Anything else?
>
> *Now, the most important thing is that **one of you* * organizes it*. I
> can't do it myself because of time constraints, and Mike W9MDB is also
> overloaded with work.
>
> For example, what about the people who have stood out so intensively in
> the last few days with posts about something trivial? Wouldn't one of you
> like to take over and invest your energy there? *Seriously: Who?* *Y*
> *ou are now requested! *
> I mean, what needs to be done is evident:
>
>1. Create a list of commonly used rig models.
>2. Find beta testers for each of these models and assign
>responsibilities.
>3. Get an overview of the status quo and summarize the results clearly.
>
> Something like this can be done e.g. with a simple Excel file:
>
>
>
>
> It's sad enough that obviously, the hamlib development team can't do
> something so essential themselves. But *this definitely has to come now*,
> because we can't get the next frustration after every new WSJT-X release.
> Makes no sense!
>
> So, again:
>
> *Who of you will take this in hand and organize such a systematic beta
> testing? *I do not want to see one more "stupid" post as long as this
> problem is not solved, hi, hi!
>
> 73 de Uwe, DG2YCB
> ___
> wsjt-devel mailing list
> 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] Hamlib Beta Testing Group needed

[Uwe, DG2YCB via wsjt-devel]

Dear WSJT-X users,

Please allow me to summarize again here on this email reflector a topic
that is very important to me and to all of us. My original post was on
https://groups.io/g/wsjtgroup, so maybe it's best if you join the
discussion there.

Despite great personal commitment of the hamlib developers it has
unfortunately happened very often that immediately after a new WSJT-X
release serious problems with one or another hamlib rig driver become
apparent. If something like this happens over and over again, it shows
that there is a *systematic* error somewhere. In my opinion this is due
to the fact that *too few* users try the current development versions of
hamlib, so that errors are detected *too late*. Keep in mind that hamlib
drivers often change as they evolve.

So I*would like to ask you all that enough OMs act as hamlib bata tester
in the future.* For those who own one of the rigs below and work on
Windows, just do the following every 2, 3 or 4 weeks:

1. Download the daily updated libhamlib-4.dll file available on
   https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll.
2. Copy the file to the bin folder of your WSJT-X installation (i.e.
   usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll file
   beforehand so you can use it again later.
3. Start WSJT-X (or the respective variant), connect your rig via
   hamlib (i.e. *not* via OmniRig, HRD, DXLabSuite, etc.) and check if
   the CAT control runs properly.
4. If anything is not working properly, please contact Mike W9MDB via
   direct email, so he or his team can fix the bug in time.
5. If everything works fine, keep the new libhamlib-4.dll file,
   otherwise delete it and rename the previously used one.
6. In the future I would like to contact you before a new WSJT-X or
   wsjt-x_improved release to be able to choose a bug free hamlib version.

In my opinion, at least the following rigs need to be tested regularly
regarding hamlib:

 * Yaesu: FT-991, FT-101, FT-847
 * Kenwood: which models?
 * Icom: IC-7300, IC-9100, IC-9700, IC-705
 * Elecraft: KX3, what else?
 * FlexRadio: which models?
 * Anything else?

*Now, the most important thing is that **one of you* *organizes it*. I
can't do it myself because of time constraints, and Mike W9MDB is also
overloaded with work.

For example, what about the people who have stood out so intensively in
the last few days with posts about something trivial? Wouldn't one of
you like to take over and invest your energy there? *Seriously: Who?*
*Y**ou are now requested!
*
I mean, what needs to be done is evident:

1. Create a list of commonly used rig models.
2. Find beta testers for each of these models and assign responsibilities.
3. Get an overview of the status quo and summarize the results clearly.

Something like this can be done e.g. with a simple Excel file:




It's sad enough that obviously, the hamlib development team can't do
something so essential themselves. But *this definitely has to come
now*, because we can't get the next frustration after every new WSJT-X
release. Makes no sense!

So, again: *Who of you will take this in hand and organize such a
systematic beta testing?

*I do not want to see one more "stupid" post as long as this problem is
not solved, hi, hi!*

*73 de Uwe, DG2YCB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel