Re: [wsjt-devel] Remote WSJT

2024-02-28 Thread Tom M0LTE via wsjt-devel 
This is, effectively, one and the same.

To be frank, a ground-up rewrite, with a headless service, a
well-documented network-accessible API, and a UI, perhaps but not
necessarily using the existing one, would be a highly worthy project in its
own right.

Could be a nice opportunity for rationalisation.

Cheers
Tom

On Wed, 28 Feb 2024 at 19:01, Alex, VE3NEA via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Splitting the UI and data processing code would mean a major rewrite of
> the project. It might be much easier to implement some
> API, e.g. REST-based, for the functions that are currently performed via
> the UI. Then WSJT-X would run with its main window
> minimized or hidden on the remote system, and the controlling app with UI
> would run in the shack.
>
> 73 Alex VE3NEA
>
>
> On 2024-02-28 13:12, Rafael Pinto via wsjt-devel wrote:
> > William,
> >
> > You got the architecture right. The point is not having to render images
> and treat UI events, thus having all processing power
> > for mathematical computation. X Windows System and Wayland are memory
> and CPU hogs and in some cases those resources are at a
> > premium...
> >
> > As I read the code, trying to figure out how WSTJ-X works, I notice how
> tightly coupled UI and data processing are. I understand
> > it can be easier to show things on the GUI, but decoupling those could
> allow for some different UX  (text-only, for example) or,
> > as I suggested, some "smart" remoting.
> >
> > To be 100% honest, the distributed processing approach I proposed is
> just a thought experiment on how to decouple the many
> > modules. Having each "module" on a different machine is usually how I
> think when I try to decouple complex stuff.
> >
> > I'll keep studying the code to try and figure out how it would be
> possible...
> >
> > 73
> >
> > Rafael
> >
> > On Wed, Feb 28, 2024 at 1:01 PM William Smith via wsjt-devel <
> wsjt-devel@lists.sourceforge.net
> > > wrote:
> >
> > I get what you were trying to do, and it is not a perfect solution,
> but many people use VNC or some other kind of remote
> > desktop protocol to remotely control the computer that is running
> WSJT.
> >
> > Yes, it would be much better to unload the GUI and the output video
> requirements from the poor Raspberry Pi and let that run
> > on some machine that has a lot more available horsepower. However,
> as you are determining, that is a lot of work, and the
> > remote desktop thing has the advantage of not requiring any coding
> at all from the WSJT team.
> >
> > 73, Willie N1JBJ
> >
> >
> >  > On Feb 28, 2024, at 7:11 AM, Rafael Pinto via wsjt-devel <
> wsjt-devel@lists.sourceforge.net
> > > wrote:
> >  >
> >  > 
> >  > Hello folks
> >  >
> >  > Sorry if this has already been discussed!
> >  >
> >  > I am Rafael, PU1OWL, and I was thinking if it would be possible
> to detach the GUI frontend from the
> > modulation/audio/realtime backend of WSJT-X so we can make it a
> remote module
> >  >
> >  > The architecture I envision is having a remote processor (e.g.,
> some bulky raspberry pi, a PicoITX i9 board...) dealing
> > with the mathematical heavy lifting while not having to put CPU into
> presenting its GUI. The GUI could be remote, on a PC or
> > another raspberry pi, or something even lighter... Or maybe even
> some audio sink board, forwarding to a hugely capable math
> > processor, to a lightweight GUI...
> >  >
> >  > I started studying the source code, but I cannot find somewhere
> to split the code. Has it been tried before?
> >  >
> >  > 73 de PU1OWL
> >  >
> >  > Rafael Pinto
> >  > ___
> >  > wsjt-devel mailing list
> >  > wsjt-devel@lists.sourceforge.net  wsjt-devel@lists.sourceforge.net>
> >  > https://lists.sourceforge.net/lists/listinfo/wsjt-devel <
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net  wsjt-devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel <
> 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] Callsign Security

2023-10-05 Thread Tom M0LTE via wsjt-devel 
Broken in 60 seconds by looking at the source code. See APRS-IS.

On Thu, 5 Oct 2023 at 09:36, Adrian via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> As a victim of another local foundation ham (caught) unlawfully using my
> callsign on 20m FT8 recently, and reports
>
> heard of other fake and unauthorized callsign use, I wonder about the
> possibility
>
> of a digital Mode database setup & registered to , with license proof
> etc, similar to QRZ.
>
> A hex code only then secure issued to the ham passing this test for
> software use.
>
> Wsjtx would be coded to have a code entry near Callsign field, and only
> accepting on correct code entered.
>
> This would go a long way to providing confidence that the callsign
> worked is genuine (DXPeditions etc), and protecting
>
>   your own callsign from mis-use.
>
>
> 73
>
>
> vk4tux
>
>
>
> ___
> 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

2023-05-14 Thread Tom M0LTE via wsjt-devel 
Hey Jim

Kubuntu 18.04 went out of support in May 2021. Time to upgrade…

Best wishes
Tom

On Sun, 14 May 2023 at 01:58, Jim Shorney via wsjt-devel <
wsjt-devel@lists.sourceforge.net> 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] Hamlib Beta Testing Group needed

2023-05-13 Thread 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

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

2023-05-13 Thread 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

Re: [wsjt-devel] FT-991A WSJT-X unusable for me

2022-01-16 Thread Tom M0LTE via wsjt-devel 
Probably one for the main mailing list (https://wsjtx.groups.io/g/main)
rather than the dev mailing list

That said, can you describe your whole cable setup please? The issue may be
obvious.

Tom M0LTE

On Sun, 16 Jan 2022 at 16:06, Richard Shaw via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Fedora Linux 35
> hamlib master (as of a couple of days ago)
> WSJT-X 2.5.4
>
> That being said, this has been a problem for some time for me over the
> last couple of hamlib releases and several WSJT-X releases. Mike has worked
> with me a couple of times to fix this, but it never STAYS fixed.
>
> When trying to TX in WSJT-X I get rapid relay clatter. Sometimes it's only
> been when using flrig, sometimes with both flrig and hamlib, which is the
> case right now.
>
> Running Flrig + Fldigi works fine.
> Running rigctl{,d} and putting the radio in TX works fine.
> Trying "Test PTT" in WSJT-X works fine
>
> But anytime I try to make a contact or press the PTT button I get rapid TX
> relay clatter. The audio is turned all the way down so it can't be too much
> audio signal, and anyway that usually goes into TX fine and then shuts down
> the radio when that happens.
>
> Here's a link to the rigctl log:
> https://www.dropbox.com/s/js4fiixbnzm9tsg/WSJT-X_RigControl.log
>
> Thanks,
> Richard
> KF5OIM
>
> ___
> 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] wsjtx-2.5.2-win32.exe

2021-11-05 Thread Tom M0LTE via wsjt-devel 
Installation packages are linked from the WSJT-X website:

https://physics.princeton.edu/pulsar/k1jt/wsjtx.html

This question probably better suited for the users mailing list:
https://groups.io/g/WSJTX

Regards
Tom


On Fri, 5 Nov 2021 at 08:17, Hilik Poleg via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hello developer friend
>
> Just received an email about an update to 2.5.2 version.
>
> When trying to download, I have received a popup message preventing me
> from processing.
>
> Only then  I have realized that the update is for win 32., while my system
> is 64.
> is ther another link to be compatible with my system
>
> Thanks
>
> Hilik 4X4OE
> ___
> 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