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
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.
HTH,
73, de Nate >>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Jim/W3FA
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
String.
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:
String.
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:
String.
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:
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:
http://tentecwiki.org/doku.php?id=536addr
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.
HTH,
73, de Nate >>
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.
Jim/W3FA