Loading ...
Sorry, an error occurred while loading the content.

Re: fldigi remote daemon

Expand Messages
  • vu2fly
    Hi Stelios ! ... CAT ... the ... VPN ... rigctl ... use. ... Thanks for the hints. Unfortunately last time I tried hamlib (nov/dec 2007) it did not work for my
    Message 1 of 10 , Jun 17 10:21 AM
    • 0 Attachment
      Hi Stelios !
      --- In linuxham@yahoogroups.com, Stelios Bounanos <lham@...> wrote:
      > >>>>> On Tue, 17 Jun 2008 15:15:26 -0000, "vu2fly" <vu2lid@...>
      said:
      >
      > > Adding to my post:
      > > If fldigi doesn't already have this, a nice way to add the remote
      > > daemon capability will be to use an existing external GPL program
      > > like ser2net running on the remote computer.
      >
      > > Adding an additional interfacing option to existing serial port
      CAT
      > > control (connecting to the remote TCP port controlled by ser2net)
      > > will probably take care of this (guessing here - I have not gone
      > > through the fldigi code).
      >
      > [snip]
      >
      > Fldigi supports hamlib, which already has network support.
      >
      > To use it, run rpc.rigd on the remote machine with the appropriate
      > command line switches to set the rig model, serial device etc. On
      the
      > local machine, select the HamlibRPC rig model in fldigi and set the
      > remote machine's address as the port. You should use some kind of
      VPN
      > to tunnel RPC traffic securely over the Internet.
      >
      > Another option would be to ssh into the remote machine and use
      rigctl
      > from the command line, which is trivial to set up but more work to
      use.
      > It's the other way around for the RPC method.
      >

      Thanks for the hints.

      Unfortunately last time I tried hamlib (nov/dec 2007) it did not work
      for my rig (Kenwood TS-50). I tried debugging to trace the problem a
      bit, but was not successful (due to various reasons - rig is located
      in India/VU2LID etc.) at that time.

      I thought that I will probably have better luck with fldigi's own rig
      control interface (Which I think can work without the help of hamlib
      - AFAIK). For testing I tried HRD running on VMware inside the remote
      Linux machine - this worked 100%.

      73 de salim vu2lid / n8li

      >
      > 73,
      > Stelios, M0GLD.
      >
    • vu2fly
      ... remote ... program ... CAT ... ser2net) ... On the ... the ... of VPN ... rigctl ... to use. ... rpc.rigd ... able ... toggle in ... some ... remote ...
      Message 2 of 10 , Jun 17 10:32 AM
      • 0 Attachment
        --- In linuxham@yahoogroups.com, Stelios Bounanos <lham@...> wrote:
        >
        > >>>>>> On Tue, 17 Jun 2008 17:05:46 +0100, Stelios Bounanos
        <lham@...> said:
        >
        > >>>>> On Tue, 17 Jun 2008 15:15:26 -0000, "vu2fly" <vu2lid@...>
        said:
        >
        > >> Adding to my post:
        > >> If fldigi doesn't already have this, a nice way to add the
        remote
        > >> daemon capability will be to use an existing external GPL
        program
        > >> like ser2net running on the remote computer.
        >
        > >> Adding an additional interfacing option to existing serial port
        CAT
        > >> control (connecting to the remote TCP port controlled by
        ser2net)
        > >> will probably take care of this (guessing here - I have not gone
        > >> through the fldigi code).
        >
        > > [snip]
        >
        > > Fldigi supports hamlib, which already has network support.
        >
        > > To use it, run rpc.rigd on the remote machine with the appropriate
        > > command line switches to set the rig model, serial device etc.
        On the
        > > local machine, select the HamlibRPC rig model in fldigi and set
        the
        > > remote machine's address as the port. You should use some kind
        of VPN
        > > to tunnel RPC traffic securely over the Internet.
        >
        > > Another option would be to ssh into the remote machine and use
        rigctl
        > > from the command line, which is trivial to set up but more work
        to use.
        > > It's the other way around for the RPC method.
        >
        > I should have mentioned that there are examples of how to use
        rpc.rigd
        > and rigctl in the hamlib FAQ:
        >
        > http://hamlib.sourceforge.net/faq.html
        >
        >
        > And if you also wanted to stream audio over the net, you might be
        able
        > to do this with fldigi's PulseAudio backend. You can set the remote
        > Pulse server address in the text field next to the PulseAudio
        toggle in
        > fldigi's sound settings. Google "pulseaudio over the network" for
        some
        > general setup hints.
        >
        > I would only try to do this over a fast, low latency link to the
        remote
        > PulseAudio server. I suppose that's not the kind of link you're
        likely
        > to have from the US to VU-land, but it may still be usable for
        > monitoring.
        >

        I have not yet tried PulseAudio - will try that.

        Last time I was using the Linux VOIP program IHU (http://
        packages.debian.org/sid/ihu) - this worked really well (it worked so
        well that I was able to copy some stations throgh the link which some
        local stations in India/VU were unable to copy !).

        73 de salim vu2lid / n8li

        >
        > 73,
        > Stelios, M0GLD.
        >
      • Stelios Bounanos
        ... [snip] ... I installed the Debian package for ihu to check it out. It looks like a well thought out application. With the demise of Speak Freely, it must
        Message 3 of 10 , Jun 17 11:38 AM
        • 0 Attachment
          >>>>> On Tue, 17 Jun 2008 17:32:27 -0000, "vu2fly" <vu2lid@...> said:

          [snip]

          > I have not yet tried PulseAudio - will try that.

          > Last time I was using the Linux VOIP program IHU (http://
          > packages.debian.org/sid/ihu) - this worked really well (it worked so
          > well that I was able to copy some stations throgh the link which some
          > local stations in India/VU were unable to copy !).

          I installed the Debian package for ihu to check it out. It looks like a
          well thought out application. With the demise of Speak Freely, it must
          be one of the few direct VOIP apps left. This is a useful feature in
          itself, as SIP can be a pain to get through some NAT routers.

          I noticed that it uses Speex compression, which is lossy and optimised
          for speech, and therefore probably not so good for digital modes signals
          (it should work well for voice signals, though). There doesn't seem to
          be any way to disable Speex.

          If ihu had a JACK output you could connect it directly to fldigi. It
          might still be possible to redirect its ALSA output to JACK with an ALSA
          plugin.


          73,
          Stelios, M0GLD.
        • Stelios Bounanos
          Hi Salim, ... The current release of hamlib (1.2.7.1) supports the Kenwood TS-50S. Is this the rig model that you tried to use with your TS-50 back in Dec? ...
          Message 4 of 10 , Jun 17 12:17 PM
          • 0 Attachment
            Hi Salim,

            >>>>> On Tue, 17 Jun 2008 17:21:42 -0000, "vu2fly" <vu2lid@...> said:

            > Unfortunately last time I tried hamlib (nov/dec 2007) it did not work
            > for my rig (Kenwood TS-50). I tried debugging to trace the problem a
            > bit, but was not successful (due to various reasons - rig is located
            > in India/VU2LID etc.) at that time.

            The current release of hamlib (1.2.7.1) supports the Kenwood TS-50S. Is
            this the rig model that you tried to use with your TS-50 back in Dec?

            > I thought that I will probably have better luck with fldigi's own rig
            > control interface (Which I think can work without the help of hamlib
            > - AFAIK). For testing I tried HRD running on VMware inside the remote
            > Linux machine - this worked 100%.

            You are correct that fldigi's rigCAT doesn't rely on hamlib.

            I think the most productive thing to do would be to get hamlib to play
            well with the TS-50, either by writing a new rig model or extending the
            TS-50S. Then you'd be able to use all programs that support hamlib.

            And IIRC HRD can export its rig control definition to a text file.


            73,
            Stelios, M0GLD.
          • vu2fly
            ... so ... some ... like a ... must ... in ... optimised ... signals ... seem to ... ALSA ... One of the reasons for using IHU was that it works well from
            Message 5 of 10 , Jun 17 1:26 PM
            • 0 Attachment
              --- In linuxham@yahoogroups.com, Stelios Bounanos <lham@...> wrote:
              >
              > >>>>> On Tue, 17 Jun 2008 17:32:27 -0000, "vu2fly" <vu2lid@...>
              said:
              >
              > [snip]
              >
              > > I have not yet tried PulseAudio - will try that.
              >
              > > Last time I was using the Linux VOIP program IHU (http://
              > > packages.debian.org/sid/ihu) - this worked really well (it worked
              so
              > > well that I was able to copy some stations throgh the link which
              some
              > > local stations in India/VU were unable to copy !).
              >
              > I installed the Debian package for ihu to check it out. It looks
              like a
              > well thought out application. With the demise of Speak Freely, it
              must
              > be one of the few direct VOIP apps left. This is a useful feature
              in
              > itself, as SIP can be a pain to get through some NAT routers.
              >
              > I noticed that it uses Speex compression, which is lossy and
              optimised
              > for speech, and therefore probably not so good for digital modes
              signals
              > (it should work well for voice signals, though). There doesn't
              seem to
              > be any way to disable Speex.
              >
              > If ihu had a JACK output you could connect it directly to fldigi. It
              > might still be possible to redirect its ALSA output to JACK with an
              ALSA
              > plugin.
              >

              One of the reasons for using IHU was that it works well from
              commandline, once the system has a proper config file - good for
              automatically starting a dedicated audio link.

              After going through experinces of some other hams trying to work
              digital modes through VOIP links from a remote station - I also get
              the impression that it will be difficult due to errors. This is
              probably one of the reasons why it will be good to be able to operate
              fldigi without the gui (at the remote computer) and connect to it.
              Surprisingly I was able to copy PSK31 stations well through WebSDR
              (http://websdr.ewi.utwente.nl:8901/).

              I discovered fldigi only recetly - I have not yet tried it with IHU.

              73 de salim vu2lid / n8li

              >
              > 73,
              > Stelios, M0GLD.
              >
            • vu2fly
              ... work ... problem a ... located ... 50S. Is ... Dec? The release of hamlib that I tried (Nov/Dec 2007) also said that it supports TS-50/TS-50S - but it was
              Message 6 of 10 , Jun 17 1:37 PM
              • 0 Attachment
                --- In linuxham@yahoogroups.com, Stelios Bounanos <lham@...> wrote:
                > >>>>> On Tue, 17 Jun 2008 17:21:42 -0000, "vu2fly" <vu2lid@...>
                said:
                >
                > > Unfortunately last time I tried hamlib (nov/dec 2007) it did not
                work
                > > for my rig (Kenwood TS-50). I tried debugging to trace the
                problem a
                > > bit, but was not successful (due to various reasons - rig is
                located
                > > in India/VU2LID etc.) at that time.
                >
                > The current release of hamlib (1.2.7.1) supports the Kenwood TS-
                50S. Is
                > this the rig model that you tried to use with your TS-50 back in
                Dec?

                The release of hamlib that I tried (Nov/Dec 2007) also said that it
                supports TS-50/TS-50S - but it was untested (according to the hamlib
                web page it is untested even now). Yes this was the rig model that I
                tried with rigctrl.

                >
                > > I thought that I will probably have better luck with fldigi's own
                rig
                > > control interface (Which I think can work without the help of
                hamlib
                > > - AFAIK). For testing I tried HRD running on VMware inside the
                remote
                > > Linux machine - this worked 100%.
                >
                > You are correct that fldigi's rigCAT doesn't rely on hamlib.
                >
                > I think the most productive thing to do would be to get hamlib to
                play
                > well with the TS-50, either by writing a new rig model or extending
                the
                > TS-50S. Then you'd be able to use all programs that support hamlib.
                >
                > And IIRC HRD can export its rig control definition to a text file.
                >

                Thanks !I will try this. I did copy some of the configuration
                parameters from the working HRD setup while briefly trying to debug
                without luck.

                73 de salim vu2lid / n8li

                >
                > 73,
                > Stelios, M0GLD.
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.