#15 TenTec Delta2 files are in the Icom folder

Jim Bruce

Not sure if it really is a bug but in looking for the Tentec Delta2 files I found themn in the Icom folder. Can they simply be moved or will the code need to be modified to account for the new location? Can this be remedied on the next release?

Jim W3FA


  • Jim Bruce

    Jim Bruce - 2011-12-30

    TenTec Delta2 files in Icom folder

  • Nate Bargmann

    Nate Bargmann - 2011-12-30

    I'm not an expert in the Icom area but a cursory looks shows that the delta2 backend is dependent on icom.h and icom_defs.h and so is a direct derivative of the Icom backend. Perhaps Martin or Stephane can provide a more definitive answer.

  • Stéphane Fillod

    • status: open --> open-rejected
  • Stéphane Fillod

    Indeed, the Tentec Delta2 is based on Icom's CI-V protocol, hence its source location in the icom backend group.
    However, the backend is appropriately listed under Tentec as manufacturer (e.g. riglist -l, ..).

    BTW Jim, do you own a Tentec Delta2? Can you confirm us that Hamlib works fine with this rig?

  • Jim Bruce

    Jim Bruce - 2011-12-31
    • priority: 5 --> 3
  • Jim Bruce

    Jim Bruce - 2011-12-31

    Thanks all. I wasn't sure if it was something that was inadvertantly left there or for a reason.

    fillods- Yes have owned it for 10 or so years and finally got to the point of interfacing it to the computer in Ubuntu Linux and windows. My first step was to find if it was supported (yes- thanks) and to find the rigid. I am at the point of testing it using an FTDI usb>ttl cable. The computer and radio are not talking and I believe the radio may not be responding but I need to confirm this. I have the address for the radio set and the address, port and baud rate set in TLF, N1MM, xdx, and xlog but radio info is not being displayed or followed. Once I get the comms corrected I will let you know the results as I look forward to using Hamlib.

  • 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 all items 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 independant of the logging program and how?

    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 plan)"

    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 squelch)"

    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 IC735"

    Default: 0, Value: 1
    Check button.

    Rig command:

  • Nate Bargmann

    Nate Bargmann - 2012-01-29
    • status: open-rejected --> open
  • Jim Bruce

    Jim Bruce - 2012-03-02

    Here are the results of my testing using my Delta II. I can say that it is confirmed working with the results below. The "Y/n" column indicates either Yes or no if the command functioned.
    Jim W3FA

    Command Function Desc Y/N Notes/Comments
    F set_freq “Frequency” Set Freq in Hz Y
    f get_freq Get freq in Hz Y
    M set_mode “Mode” “Passband” Y
    m get_mode Get “Mode” “Passband” Y Mode changes, passband stays at 2400.
    V set_vfo “VFO” Y
    v get_vfo Get current VFO n “Feature not available” returned
    J set_rit “RIT” Set RIT in Hz
    j get_rit Get RIT in Hz n “Feature not available” returned
    Z set_xit “XIT”
    z get_xit n “Feature not available” returned
    T set_ptt “PTT”
    t get_ptt
    0x8b get_dcd Get DCD(squelch) status
    R set_rptr_shift
    r get_rptr_shift get_rptr_shift n “Feature not available” returned
    O set_rptr_offs
    o get_rptr_offs Get “Rptr offset” in Hz n
    C set_ctcss_tone Set CTCSS tone in tenths of Hz
    c get_ctcss_tone Get CTCSS tone in tenths of Hz n
    D set_dcs_tone Set DCS code
    d get_dcs_tone Get DCS code
    I (lower case I) get_split_freq Y
    x get_split_mode Y gets mode and passband
    n n “Feature not available” returned
    u Y? not sure entry to put in for functions
    l Y? not sure entry to put in for functions
    B ? No errors returned
    E Y? No errors returned
    e n “Feature not available” returned
    g n “Feature not available” returned
    h n “Command rejected by rig”
    A Y appears to be working, get_trn returns what was set
    a Y
    y n “Feature not available” returned
    * reset
    _ get_info Y “Info: None” returned”
    2 ? “power2mw: error = Invalid paramater”
    w send_cmd

    rigctl -r 364 -r /dev/ttyUSB0


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

Sign up for the SourceForge newsletter:

No, thanks