Serial communication failure

Help
2006-12-02
2013-01-15
  • Tehrasha Darkon

    Tehrasha Darkon - 2006-12-02

    Not sure where to start here..

    Running Hamlib 1.2.5, Ubuntu 6.10 and controlling an Icom-706 MkIIg (311)

    When using gRig I see S-Meter movement and can read and change freq on the rig for about 30 seconds, then the S-Meter freezes.  I can still send frequency command to the radio for a short time, but eventually all communication with the rig fails. 

    Running Grig in debug results in an endless stream this after the fail.

    2006/12/02 07:46:53;;HAMLIB;;3;;read_string: timedout without reading a character

    I have tried forcing slower serial bus speeds all the way down to 300baud, but the failure remains.

    Here is the output of a typical session in rigctl.

    ------------------------------------------------------------

    Opened rig model 311, 'IC-706MkIIG'
    Backend version: 0.3, Status: Beta

    Rig command: f
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    RX 6 characters
    0000     fe fe 58 e0 03 fd      ..X...
    RX 11 characters
    0000     fe fe e0 58 03 00 00 88 01 00 fd       ...X.......
    Frequency: 1880000

    Rig command: f
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    RX 6 characters
    0000     fe fe 58 e0 03 fd      ..X...
    RX 11 characters
    0000     fe fe e0 58 03 00 00 88 01 00 fd       ...X.......
    Frequency: 1880000

    Rig command: f
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    read_string: timedout without reading a character
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    read_string: timedout without reading a character
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    read_string: timedout without reading a character
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    read_string: timedout without reading a character
    get_freq: error = Communication bus error

    Rig command: F
    Frequency: 1881000
    TX 11 bytes
    0000     fe fe 58 e0 05 00 10 88 01 00 fd       ..X........
    read_string: timedout without reading a character
    TX 11 bytes
    0000     fe fe 58 e0 05 00 10 88 01 00 fd       ..X........
    read_string: timedout without reading a character
    TX 11 bytes
    0000     fe fe 58 e0 05 00 10 88 01 00 fd       ..X........
    read_string: timedout without reading a character
    TX 11 bytes
    0000     fe fe 58 e0 05 00 10 88 01 00 fd       ..X........
    read_string: timedout without reading a character
    set_freq: error = Communication bus error

    Rig command: f
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    read_string: timedout without reading a character
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    read_string: timedout without reading a character
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    read_string: timedout without reading a character
    TX 6 bytes
    0000     fe fe 58 e0 03 fd      ..X...
    read_string: timedout without reading a character
    get_freq: error = Communication bus error

    Rig command: q
    rig:rig_close called
    rig:rig_cleanup called

    ------------------------------------------------------------

    That last 'F' command does change the freq of the radio, but it will not read the value back to the computer.

    Any clues?

    --Teh

     
    • Spaceman Spiff

      Spaceman Spiff - 2006-12-03

      Hmm?  I've never seen it before.  I've never used gRig so I don't know how they access the hamlib.  I doubt it is a serial speed problem.  It appears that either your rig is not responding to the interface or for some reason hamlib is not seeing what it thinks it should. Is your rig in trancieve or normal mode? What is your physical interface? (CIV converter)?

      Does it happen if you don't run gRig first? ie On a newly booted system? Just run rigctl?

      Can you access the CVS?  We are close to releasing a 1.2.6 version. 

      I will have to look at the gRig code.

       
      • Spaceman Spiff

        Spaceman Spiff - 2006-12-04

        Yes, that is what transcieve mode is designed for.  When you make a change on the rig it sends command without expecting ack to other connected rigs to change the same paramenters.  It does this at least for frequency and operating mode.  I don't know if it does so for other commands.  It's not well documented. But in hamlib it also serve the function  for asynchronus communication.  Hamlib has 3 modes: transcieve (true anynchronus), polled and standard.  It is designed to let you control the rig from either the program or the rig.  I haven't played much with the transcieve and polled modes, they seem to work with okay in my limited experience. But, both hamilib and the rig need to be in the same mode. 
        What does gRig expect????  Teh said he had the same problem under windows.  I would recommend turning off the transcieve mode to test it under rigctl and windows.  (ie turn it off at the radio.  The rigctl transcieve command changes what rigctl expects it doesn't change the rig itself).

        Who made your serial CIV converter?

        AD7AI

         
        • Alexandru Csete

          Alexandru Csete - 2006-12-05

          Grig simply executes read/write commands synchronously and does not use the transceive feature at all. That should not cause any problems even with transceive mode ON, since hamlib would simply trash the incoming transceive messages, I suppose.

          73
          Alex OZ9AEC

           
        • Tehrasha Darkon

          Tehrasha Darkon - 2006-12-05

          The converter was built by G8XGG.  He has -several- on eBay.

          http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=320058271114

          It is a two transitor type, and does not use the Max232 chip.

          I turned the tranceive off, but I still get the same failure. :(

          --Teh

           
          • Spaceman Spiff

            Spaceman Spiff - 2006-12-06

            Which Windows programs have you tried.  I can recommend the Ham Radio Deluxe program if you haven't tried it.  If it doesn't work with windows, that would suggest a hardware problem.

            AD7AI

             
            • Tehrasha Darkon

              Tehrasha Darkon - 2006-12-17

              It turned out to be a hardware problem.

              The capacitor mentioned in a previous responce had been installed backwards.  With its polarity reversed, it could not maintain the minimum voltage for RS232 operation.  It would charge immediately, but as time went by it slowly bled out till communication ceased.  Broke out my soldering iron, reversed the part and all is well.

              Ive been running gRig for over an hour now without a hiccup.

               
    • Tehrasha Darkon

      Tehrasha Darkon - 2006-12-04

      In answer to your questions...

      I am using a serial-CIV converter.
      The rig -IS- in tranceive mode.
      It happens no matter what order I try diff apps.
      And, no, I do not have access (or know how to use) CVS.

      On the bright(?) side, I have since found that the rig fails in the same way using a Windows control app.
      I am now looking into the possibility that the converter itself is the issue.
      I will keep you posted on my results.

      --Teh

       
      • Olaf

        Olaf - 2006-12-04

        Hello Tehrasha,

        Maybe you can find an answer to your problem at the
        FAQs of HAMLIB. Please look under:
        "- The serial port keeps on getting timeout, the rig works fine under DOS. What's wrong?"

        vy 73

        Olaf, DL4DZ

         
        • Tehrasha Darkon

          Tehrasha Darkon - 2006-12-05

          I saw that bit in the FAQ.  Bu the problem it describes appears to be the opposite of mine.

          The FAQ talks about failure at first, until the capacitors charge.
          My problem is that it works fine at first, and eventually stops.

          --Teh

           
      • Alexandru Csete

        Alexandru Csete - 2006-12-04

        I'm no expert in ICOM CI-V, but isn't transceive mode something you use when you connect two or more ICOM rigs together? If so, it sound like asynchronous communication between two devices and should be turned OFF when trying to control one transceiver from a computer.

        73
        Alex OZ9AEC

         

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks