Hamlib startup in Linux question

Jim Bruce
  • Jim Bruce

    Jim Bruce - 2012-01-03

    OK, Confirmed that the Delta II communicates with the computer thru the
    FTDI USB Serial>TTL cable in windows using TR4W (TR Log). N1MM and
    HamRadio Delux (HRD) did not communicate. This showed some verification
    that computer, cable and radio worked and talked to each other.
    On to Linux- Finally got the comms working to test using "rigctl -r /dev/ttyUSB0 -m 364 -s 1200 -c 4". In order for this to work I needed to add "-s 1200 -c 4" as without this there was no communications with the Delta II. I have added the "-L" option
    at the end of this. I have TLF, xlog and other logging programs that use Hamlib and they are set to use Hamlib with the radio id 364 and they do not display the freq. which indicates to me that there is no communications between the logging programs and Hamlib, or Hamlib is not talking to the radio, possibly leaving off the speed (-s) and/or address (-c 4) when it is called by the logging program. Could it also be me? Does Hamlib need to be started independent of the logging  rogram and how?
    Ubuntu 10.04LTS
    Hamlib 1.2.10
    FTDI USB>232 TTL cable  Icom USB CI-V Cat CT-17 Cable
    TenTec Delta II

    rigctl -r /dev/ttyUSB0 -m 364 -s 1200 -c 4

    Rig command: f

    Frequency: 28465150

    Rig command: m

    get_mode: error = Protocol error

    Rig command: ^C

    jim@Contest:~$ rigctl -r /dev/ttyUSB0 -m 364 -s 1200 -c 4 -L

    rig_pathname: "Path name to the device file of the rig"

    Default: /dev/rig, Value: /dev/ttyUSB0


    write_delay: "Delay in ms between each byte sent out"

    Default: 0, Value: 0

    Range: 0.0..1000.0, step 1.0

    post_write_delay: "Delay in ms between each command sent out"

    Default: 0, Value: 0

    Range: 0.0..1000.0, step 1.0

    timeout: "Timeout in ms"

    Default: 0, Value: 200

    Range: 0.0..10000.0, step 1.0

    retry: "Max number of retry"

    Default: 0, Value: 3

    Range: 0.0..10.0, step 1.0

    itu_region: "ITU region this rig has been manufactured for (freq. band

    Default: 0, Value: 2

    Range: 1.0..3.0, step 1.0

    vfo_comp: "VFO compensation in ppm"

    Default: 0, Value: 0.000000

    Range: 0.0..1000.0, step 0.0

    poll_interval: "Polling interval in millisecond for transceive emulation"

    Default: 500, Value: 500

    Range: 0.0..1000000.0, step 1.0

    ptt_type: "Push-To-Talk interface type override"

    Default: RIG, Value:

    Combo: RIG, DTR, RTS, Parallel, None

    ptt_pathname: "Path name to the device file of the Push-To-Talk"

    Default: /dev/rig, Value:


    dcd_type: "Data Carrier Detect (or squelch) interface type override"

    Default: RIG, Value:

    Combo: RIG, DSR, CTS, CD, Parallel, None

    dcd_pathname: "Path name to the device file of the Data Carrier Detect (or

    Default: /dev/rig, Value:


    serial_speed: "Serial port baud rate"

    Default: 0, Value: 1200

    Range: 300.0..115200.0, step 1.0

    data_bits: "Serial port data bits"

    Default: 8, Value: 8

    Range: 5.0..8.0, step 1.0

    stop_bits: "Serial port stop bits"

    Default: 1, Value: 1

    Range: 0.0..3.0, step 1.0

    serial_parity: "Serial port parity"

    Default: None, Value: None

    Combo: None, Odd, Even, Mark, Space

    serial_handshake: "Serial port handshake"

    Default: None, Value: None

    Combo: None, XONXOFF, Hardware

    rts_state: "Serial port set state of RTS signal for external powering"

    Default: Unset, Value: Unset

    Combo: Unset, ON, OFF

    dtr_state: "Serial port set state of DTR signal for external powering"

    Default: Unset, Value: Unset

    Combo: Unset, ON, OFF

    civaddr: "Transceiver's CI-V address"

    Default: 0, Value: 4

    Range: 0.0..255.0, step 1.0

    mode731: "CI-V operating frequency data length, needed for IC731 and

    Default: 0, Value: 1

    Check button.

    Rig command:

  • Nate Bargmann

    Nate Bargmann - 2012-01-03

    Hi Jim.

    It appears to me that the issue is the CI-V address.  The Delta II backend has a default value of 0x01 and you're using 0x04.which appears to be the rig default per:


    The backend serial rate is 1200bps so you should not need to specify that on command line/to the logging program.  The serial rate is confirmed by:

    rigctl -m 364 -L

    As to setting the CI-V address, I can easily change the delta2 backend default to 0x04 so it won't be an issue in the future.  In the mean time, you can do the following in xlog:

    Go to Settings then Preferences
    Click the Hamlib tab
    Tick the Enable hamlib support checkbox (you probably have done so)
    In the box titled, "Comma separated list of commands…" enter :civaddr=4' (without the quotes)
    If need be you could also put 'serial_speed=1200' in it as well, but I don't think you need to.  If you put more than one parameter in the box, separate them with commas.

    TLF may have a similar configuration option.

    The names are listed in the rigctl man page (man rigctl) as the long option names along with the short options.  The names also appear in the -L output.


    73, de Nate >>

  • Jim Bruce

    Jim Bruce - 2012-01-15

    I appear to be getting reliable connections from rigctl command. What are the available commands for the Delta 2 so that I can test them? I am creating a spreadsheet to compare the results using rigctl, grig, tlf, xlog and other programs?

    I would not change the CI-V address yet now that I now what hamlib is using. Contrasting documentation from various web sites and software programs may be the issue there. Some programs still prefer the 04 address.

    My goal is to be able to test it and report back to you that it's status can go from "Untested" to "tested, Good, Confirmed or whatever for the benefit of other Delta 2 users. I am not sure how much difference there is in the windows side but I will be testing using Ubuntu 10.04LTS x86 which is preferred. Not sure how long till I make a move to Ubuntu 12.04LTS.



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

Sign up for the SourceForge newsletter:

No, thanks