Re: [wsjt-devel] Remote WSJT

2024-02-28 Thread lmc--- via wsjt-devel 
Keybindings definitely needs some revision, also am I the only who finds the best S+P button behavior erratic? Won't be more appropriate a checkbox ?El 28 feb. 2024 21:48, Tom M0LTE via wsjt-devel  escribió: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.CheersTomOn Wed, 28 Feb 2024 at 19:01, Alex, VE3NEA via wsjt-devel  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 
> 
> 
>     ___
>     wsjt-devel mailing list
>     wsjt-devel@lists.sourceforge.net 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] 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] Remote WSJT

2024-02-28 Thread Kevin McQuiggin (SFU) via wsjt-devel 
That’s what we did for Linux on my project, but it’s kind of a kludge.  Better to have WSJT-X be able to handle audio IQ natively.On the Mac I used netcat and the “Blackhole” virtual audio driver.  I pointed WSJT-X at the virtual audio device.73,KevinSent from my iPadOn Feb 28, 2024, at 11:15, Thomas Reynolds via wsjt-devel  wrote:In the Linux world you can use PulseAudio to transport soundcard audio from a remote RPi and radio over the net to a local desktop running WSJT-X.  I do this.  It works fine provided that the latency is not too large.On Wed, Feb 28, 2024 at 11:03 AM Alex, VE3NEA via wsjt-devel  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 
> 
> 
>     ___
>     wsjt-devel mailing list
>     wsjt-devel@lists.sourceforge.net 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 listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel___
wsjt-devel mailing list

Re: [wsjt-devel] Remote WSJT

2024-02-28 Thread Thomas Reynolds via wsjt-devel 
In the Linux world you can use PulseAudio to transport soundcard audio from
a remote RPi and radio over the net to a local desktop running WSJT-X.  I
do this.  It works fine provided that the latency is not too large.


On Wed, Feb 28, 2024 at 11:03 AM 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] Remote WSJT

2024-02-28 Thread Alex, VE3NEA via wsjt-devel 
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 > 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 
mailto: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 

 > 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] Remote WSJT

2024-02-28 Thread Rafael Pinto via wsjt-devel 
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
> > 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] Remote WSJT (IQ I/O for WSJT-X)

2024-02-28 Thread Kevin McQuiggin via wsjt-devel 
Hi All:

A perfect solution would be to uncouple WSJT-X from sound cards and simply 
allow it to send and receive audio IQ data over the net.  This would allow 
WSJT-X to run anywhere, as long as it could send/receive the audio IQ.  A 
straightforward interface at the radio end of the link would interact with a 
WSJT-X IP connection to send and receive the IQ.

You could run a local copy of WSJT-X to connect to a radio anywhere.

I have code that provides the “radio end” of this functionaltiy that I 
developed as part of a software-based EME SDR project here.  It’s an 
software-based solution that uses an Ettus SDR as the front end.  It generates 
IQ audio output for a specific frequency and bandwidth, and accepts audio IQ 
input which gets up-converted and transmitted.  The RF frequency and bandwidth 
are controllable by WSJT-X or through a control port.  You just telnet to my 
server, but it has a hamlib emulator as well so that WSJT-X can interact with 
it.  WSJT-X thinks it is talking with a rig.

However, because WSJT-X cannot currently work on IQ data I have to shoe-horn 
the IQ data through a virtual sound card to keep WSJT-X happy.  This would be 
an unnecessary step  if WSJT-X could work with IQ audio directly.

I have mentioned this to the WSJT-X team in the past (say 2-3 years ago) but 
with the passing of Bill Sommerville I don’t know if anyone is still aware of, 
or working on the idea.
for a specific frequency and bandwidth

73,

Kevin

> On Feb 28, 2024, at 4:08 AM, Rafael Pinto via wsjt-devel 
>  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
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Remote WSJT

2024-02-28 Thread Luis Miguel Castañeda via wsjt-devel 


I guess you can use X forwarding

On Wednesday, February 28 2024, 09:59:11, William Smith via 
wsjt-devel 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 
 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
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



--
Every ceiling reached becomes a floor.
 --- Aldous Huxley



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

Re: [wsjt-devel] Remote WSJT

2024-02-28 Thread William Smith via wsjt-devel 
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 
>  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
> 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] Remote WSJT

2024-02-28 Thread Black Michael via wsjt-devel 
Depend on what you are trying to seperate -- sounds like the GUI FFT processing 
is you concern perhaps the decoding too?
Here's the flow
RigAudio -> PC -> GUI (both fft and collect for decoder -> wav file -> decoder 
(e.g. JT9.EXE) -> GUI
And you are talking aboutRigAudio -> PicoITX -> GUIWhere PicoITX could do FFT 
display data and decoding.
Moving the decoder to a separate processor would be the easer step as JT9.EXE 
just processes a WAV file and returns the decodes.Moving the FFT processing in 
the GUI would be more complicated.
Mike W9MDB 

On Wednesday, February 28, 2024 at 06:15:16 AM CST, Rafael Pinto via 
wsjt-devel  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
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] Remote WSJT

2024-02-28 Thread Rafael Pinto via wsjt-devel 
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
https://lists.sourceforge.net/lists/listinfo/wsjt-devel