Thanks Robin, So it's not the server app that's "actively refused" the request but the OS the app is running on. I'll bear that in mind when I next drill down into my remote operating. Phil GM3ZZA On 14 September 2024, at 01:51, G8DQX <list@...> wrote: Phil, John (GW0WZL), it's not a left-right pondian issue. ¡°Actively refused¡± means that the operating system (OS) has decided not to accept any connections on, in this case, port 4532. That will be because flrig on the Pi is listening on port 12345. No server is listening on port 4532, so there is nothing for a connection to be made to. When the request to connect to port 4532 is made from computer A (the Win 10 laptop in this case) the the OS at computer B (the Pi in this case) replies ¡°request refused¡±. This is done so that computer A ¡°knows¡± that there is no point in continuing the procedure, and thus computer A may safely and cleanly abort whatever was behind the connection request (in this case log4om trying to connect to flrig on the Pi.) It is necessary for both machines to be using the same port
number as a pre-condition, but not guarantee, of success. So
what clues might these differing port numbers offer us? The first clue is that Log4OM is trying to connect to Hamlib. Modern Hamlib development includes rigctld () which acts as a server for use by other programs. The default port for rigctld is 4532. My understanding is that it is possible to run flrig and
rigctld, and one configures rigctld to talk to flrig, so that
ultimately flrig is the single program that directly talks to the
radio. There is a very clear discussion of how at ,
by AD8JL. (That link wasn't easy to find, but is essential
reading.) Now a picture's worth a thousand words, so your configured system
would look something like this, simplified slightly, to take the
least complication approach: The key point is that rigctld is configured to use flrig to
control radios &c., rather than controlling any radio directly
from itself. A possible point of confusion is that rigctld is
configured by setting flrig as the type of radio that it talking
to. Then, when required, Log4OM talks to rigctld, which in turn
talks to flrig, which then talks directly to whatever radio is in
use. flrig acts as the single point of contact with the radio. Any necessary debugging of the operation of the connected radio (FT-3000 in your case) is limited to the link between flrig and the radio. [There is a lot more to this, but that is not germane to your
troubles.] 73, HTH, Robin, G8DQX P.S. Checking, the FT-3000 supports setting & reading the
antenna state via CAT control. However, flrig does not
appear to be designed to support a radio with switchable antennas.
On 11/09/2024 22:59, Philip Rose,
GM3ZZA via wrote:
|