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

Re: [linuxham] Partial success

Expand Messages
  • w1hkj
    1. I found that I had entered /dev/tty/USB0 instead of /dev/ttyUSB0. Ans. Linux treats every serail port in a uniform way. All device drivers are located in
    Message 1 of 16 , Jun 4, 2007
    • 0 Attachment
      1. I found that I had entered /dev/tty/USB0 instead of /dev/ttyUSB0.

      Ans. Linux treats every serail port in a uniform way.  All device drivers are located in the /dev directory.  The tty part of the name indicates a terminal device that obeys certain character oriented rules for the data stream.  The Sx (S0, S1 etc) indicate that the hardware is a serial port  ergo ttyS0, ttyS1 etc.  If the device name is appended with the USBx it indicates the the hardware is a USB type which give the names ttyUSB0, ttyUSB1 etc.  The determination of which physical device is designated by 0, 1, 2 etc is made during boot when the OS discovers what hardware is on the machine.  If you replace a USB device the OS can find most on a plug and play basis.  If you added a COM type of serial device that discovery must be made at boot time.

      2. Is this /dev/ttyUSBx the USB side of the port only or is this associated with the COM port?

      Ans.  You can learn more about which physical device is associated with which logical device  on an Ubuntu based system using the Device Manager gui application.  My mother board sound system, an AC'97 audio controller from Intel, shows up as /dev/dsp1 and /dev/mixer1 for the sound and mixer.  The SignaLink USB interface is a USB Audio interface, Texas Insturments Japan, and is logical device(s) /dev/dsp and /dev/mixer

      3. If I am using Hamlib, do I need to enter a /dev/tty/Sx? Or just check on the highlight box for Hamlib on the left side?

      Ans.   Remember that the device name is /dev/ttySx.  If you are using hamlib and not the rig.xml (rigcat) access method to gain access to the rig then you will need to specify the port associated with the serial device that hamlib will find the rig.  That is entered on the right hand side of the RigCtl panel.  A caveat ... the hamlib interface code for the Icom rigs was written with the expectation that you would have a real CI-V interface and not one which steals power from the DTR or RTS pin.  rigcat i/o recognizes the need to retain DTR at +12V when the rig.xml file so specifies.  rigcat can therefore be used with your homebrew interface and not hamlib.

      4. What is normal response time for the updating of the rig display frequency? It often takes a very long time, >5 to 10 seconds to update
      but sometimes very quickly.
      5. Is this possibly due to the fact that I am not providing the right power to the transistor circuitry because I don't have the /dev/tty/Sx
      on the right setting?

      Ans.  The rig is queried every 50 msec for new data.  I have tested this on an IC-756PRO-II and have seen no problems associated with latency.  I am controlling the rig via /dev/ttyS0 which is physically connected to a homebrew CI-V interface which steals power from DTR.  If you are using the rig.xml file which I provided on a private email I suggest leaving the left hand side of the RigCtl panel blank with the exception of the selection of RigCAT for push to talk.

      6. I still can not get the audio to connect up to the program. I am pretty sure I am inputting it OK on the Line in and Line out. I have the OSS simulation installed for my ALSA audio.

      Ans.  Try the audio editor Audacity ( http://audacity.sourceforge.net ) to see if you're sound system is working OK with the OS.

      Dave, W1HKJ

    • Rick
      1. I found that I had entered /dev/tty/USB0 instead of /dev/ttyUSB0. It turns out that you can quickly tell which command to use since the rig on the task bar
      Message 2 of 16 , Jun 4, 2007
      • 0 Attachment
        1. I found that I had entered /dev/tty/USB0 instead of /dev/ttyUSB0. It
        turns out that you can quickly tell which command to use since the rig
        on the task bar will become active as soon as you enter the right
        combination and initialize. Maybe this is in the docs and I missed it? I
        discovered that the old USB to COM adapter from Radio Shack is operating
        at /dev/ttyUSB0 and my newer no name ultra low cost unit (sold
        everywhere:) requires /dev/ttyUSB1.

        2. Is this /dev/ttyUSBx the USB side of the port only or is this
        associated with the COM port?

        3. If I am using Hamlib, do I need to enter a /dev/tty/Sx? Or just check
        on the highlight box for Hamlib on the left side?

        4. What is normal response time for the updating of the rig display
        frequency? It often takes a very long time, >5 to 10 seconds to update
        but sometimes very quickly. The transmit takes about 5 seconds to key up
        after clicking on either of TX buttons and it does not seem to be able
        to return to RX. Curiously, when I click on the list of stored
        frequencies, it always switches instantly to the correct freq. Same for
        mode changes.

        5. Is this possibly due to the fact that I am not providing the right
        power to the transistor circuitry because I don't have the /dev/tty/Sx
        on the right setting?

        6. I still can not get the audio to connect up to the program. I am
        pretty sure I am inputting it OK on the Line in and Line out. I have the
        OSS simulation installed for my ALSA audio.

        Thanks for all the help,

        73,

        Rick, KV9U
      • Rick
        If I look in the /dev directory, I can not begin to understand what I would need to look at to determine the ports that are in use. Even using the KDE Info
        Message 3 of 16 , Jun 5, 2007
        • 0 Attachment
          If I look in the /dev directory, I can not begin to understand what I
          would need to look at to determine the ports that are in use. Even using
          the KDE Info Center was of minimal help as it does not specify what is
          active. It does find the specific name of the USB manufacturers product.

          I am not clear on whether or not I need to have the exact correct COM
          port specified on the left side if I am using hamlib. I have the hamlib
          checked on the right side and the highlighted red activation on the left
          side.

          In other words, if I have the DTR +12 v checked, is the program going to
          provide the required voltage or does it need to know the COM port
          specifications?

          I discovered on the hamlib web site that you can go into terminal mode
          and run the rigctl commands. I tried this out and using the /dev/ttyUSB0
          was able to get it to work instantly. Similarly, when I use the GUI
          Hamlib commands, it responds quickly from the Hamlib side, but it is
          sluggish from the rig side back to Hamlib.

          The fldigi program then, does not respond well to frequency changes in
          the rig, taking a long time or sometimes never updating the frequency.
          Also, it can trigger PTT after a fairly long wait, but seems unable to
          unkey the PTT once it is activated.

          I am getting a consistent error on the bottom of the fldigi program
          indicating "Hamlib loop Get Mode: Hamlib getMode error" so something is
          not quite right yet.

          After getting the Audacity package installed I was finally able to track
          down the executable and run the program and it works OK picking up the
          Line Input. As mentioned earlier, I am not getting any audio to display
          on the fldigi program, so I must be missing something.

          73,

          Rick, KV9U


          w1hkj wrote:
          > 1. I found that I had entered /dev/tty/USB0 instead of /dev/ttyUSB0.
          >
          > Ans. Linux treats every serail port in a uniform way. All device
          > drivers are located in the /dev directory. The tty part of the name
          > indicates a terminal device that obeys certain character oriented
          > rules for the data stream. The Sx (S0, S1 etc) indicate that the
          > hardware is a serial port ergo ttyS0, ttyS1 etc. If the device name
          > is appended with the USBx it indicates the the hardware is a USB type
          > which give the names ttyUSB0, ttyUSB1 etc. The determination of which
          > physical device is designated by 0, 1, 2 etc is made during boot when
          > the OS discovers what hardware is on the machine. If you replace a
          > USB device the OS can find most on a plug and play basis. If you
          > added a COM type of serial device that discovery must be made at boot
          > time.
          >
          > 2. Is this /dev/ttyUSBx the USB side of the port only or is this
          > associated with the COM port?
          >
          > Ans. You can learn more about which physical device is associated
          > with which logical device on an Ubuntu based system using the Device
          > Manager gui application. My mother board sound system, an AC'97 audio
          > controller from Intel, shows up as /dev/dsp1 and /dev/mixer1 for the
          > sound and mixer. The SignaLink USB interface is a USB Audio
          > interface, Texas Insturments Japan, and is logical device(s) /dev/dsp
          > and /dev/mixer
          >
          > 3. If I am using Hamlib, do I need to enter a */dev/tty/Sx?* Or just
          > check on the highlight box for Hamlib on the left side?
          >
          > Ans. Remember that the device name is */dev/ttySx*. If you are
          > using hamlib and not the rig.xml (rigcat) access method to gain access
          > to the rig then you will need to specify the port associated with the
          > serial device that hamlib will find the rig. That is entered on the
          > right hand side of the RigCtl panel. A caveat ... the hamlib
          > interface code for the Icom rigs was written with the expectation that
          > you would have a real CI-V interface and not one which steals power
          > from the DTR or RTS pin. rigcat i/o recognizes the need to retain DTR
          > at +12V when the rig.xml file so specifies. rigcat can therefore be
          > used with your homebrew interface and not hamlib.
          >
          > 4. What is normal response time for the updating of the rig display
          > frequency? It often takes a very long time, >5 to 10 seconds to update
          > but sometimes very quickly.
          > 5. Is this possibly due to the fact that I am not providing the right
          > power to the transistor circuitry because I don't have the */dev/tty/Sx*
          > on the right setting?
          >
          > Ans. The rig is queried every 50 msec for new data. I have tested
          > this on an IC-756PRO-II and have seen no problems associated with
          > latency. I am controlling the rig via /dev/ttyS0 which is physically
          > connected to a homebrew CI-V interface which steals power from DTR.
          > If you are using the rig.xml file which I provided on a private email
          > I suggest leaving the left hand side of the RigCtl panel blank with
          > the exception of the selection of RigCAT for push to talk.
          >
          > 6. I still can not get the audio to connect up to the program. I am
          > pretty sure I am inputting it OK on the Line in and Line out. I have
          > the OSS simulation installed for my ALSA audio.
          >
          > Ans. Try the audio editor Audacity ( http://audacity.sourceforge.net
          > ) to see if you're sound system is working OK with the OS.
          >
          > Dave, W1HKJ
          >
          >
          > ------------------------------------------------------------------------
          >
          > No virus found in this incoming message.
          > Checked by AVG Free Edition.
          > Version: 7.5.472 / Virus Database: 269.8.7/830 - Release Date: 6/3/2007 12:47 PM
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.