Thread: [Hamlib-developer] IC-736 backend status and converter power
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Andrea B. <bo...@st...> - 2003-02-18 15:16:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello. I'm trying to get rigctl to talk to my IC-736 but I can't get it to work so I wonder: is it really supported? ~From reading the sources of 1.1.3 I think it is, but I can't find out how to tell hamlib/rigctrl to toggle RTS always-on to supply power to my homemade converter, not even in the ml archives. TIA to anyone who can help me, 73 de Andrea IZ4FHT. - -- Undergraduate student of Computer Science @ University of Bologna Key fingerprint: 4037 9711 85C6 F9F9 A505 FA0A BB62 3A3C F7BA 9B13 ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE+Uk5MKhgqEyuO+p4RAimIAKCaWk2yrIVSe3ZrgBels/lfUzRwIQCgl4jA +VRbZpOPK0tqVxD8TGCqqo0= =AYx8 -----END PGP SIGNATURE----- |
|
From: Stephane F. <f8...@fr...> - 2003-02-19 23:39:12
|
On Tue, Feb 18, 2003, Andrea Borgia wrote: > I'm trying to get rigctl to talk to my IC-736 but I can't get it to work > so I wonder: is it really supported? It isn't in Hamlib 1.1.3. However, I've just added it right now in the cvs repository, so it will be part of future 1.1.4 if you care to test it. > ~From reading the sources of 1.1.3 I think it is, but I can't find out > how to tell hamlib/rigctrl to toggle RTS always-on to supply power to my > homemade converter, not even in the ml archives. This is a good question, and interresting feature. I guess if hardware handshake is not to be used, Hamlib should allow RTS optional setting through some rig_set_conf parameter. I'll try to come up with a patch, unless you want to provide yours. 73 Stephane |
|
From: Andrea B. <bo...@st...> - 2003-02-20 07:57:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Fillod wrote: > It isn't in Hamlib 1.1.3. However, I've just added it right now > in the cvs repository, so it will be part of future 1.1.4 if you > care to test it. Oh, good, I will! Thanks 8-) > I'll try to come up with a patch, unless you want to provide yours. By the time(*) I get up to speed on the architecture of the library and find a moment to write a decent patch, you'll have already coded it, so go ahead, I'll test the cvs and report back. If I get there first, I'll send it to you. BTW, RTS is not the only case: other converters use DTS or even a combination of control lines as power source, so the option should be as general as possible, both for the choice of the affected lines and for the related radios (homemade converters for Yaesu use this trick, too). 73 Andrea. (*) considering that tomorrow is the first day I'm allowed to operate with full privileges and the new callsign I guess pc-related activities will have to share my brain-time somewhat ;-) - -- Undergraduate student of Computer Science @ University of Bologna Key fingerprint: 4037 9711 85C6 F9F9 A505 FA0A BB62 3A3C F7BA 9B13 ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+VIo3KhgqEyuO+p4RAiNcAKDbk5znc22Efx5MCOuMN5zoOMYIIgCffxk7 ySaWYl3xPS5Avcpq3vP8QlU= =4/37 -----END PGP SIGNATURE----- |
|
From: Stephane F. <f8...@fr...> - 2003-02-23 22:32:29
|
> >It isn't in Hamlib 1.1.3. However, I've just added it right now > >in the cvs repository, so it will be part of future 1.1.4 if you > >care to test it. > Oh, good, I will! Thanks 8-) It's in cvs, and there should be a http://hamlib.org/bleeding-edge/ snapshot by tomorrow. > BTW, RTS is not the only case: other converters use DTS or even a > combination of control lines as power source, so the option should be as > general as possible, both for the choice of the affected lines and for > the related radios (homemade converters for Yaesu use this trick, too). So far, I can only see RTS and DTR as a power source. Let me know if you see others. Here is how it works with rigctl for your IC-736: rigctl -vvvvvv -Crts_state=ON -m 320 There's also a config 'dtr_state' param. You can check them all with the -L option. Let me know if this solves your powering problem. > (*) considering that tomorrow is the first day I'm allowed to operate > with full privileges and the new callsign I guess pc-related activities > will have to share my brain-time somewhat ;-) Congrats for your upgrade! I haven't heard you on the French SSB contest "Coupe du REF" this week-end. Anyway, the propagation was not at its best. 73 Stephane |
|
From: Andrea B. <bo...@st...> - 2003-02-24 12:42:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Fillod wrote: > So far, I can only see RTS and DTR as a power source. Let me know if > you see others. This is an example: http://www.g3vgr.co.uk/civ.htm I guess catering for RTS and DTR should cover most cases, but I remember seeing circuits (the one above is just an example) which used 3 control-lines strung together as power source. > Congrats for your upgrade! I haven't heard you on the French SSB > contest "Coupe du REF" this week-end. Anyway, the propagation was not > at its best. I have my doubts you'll hear me and my barefoot 736 connected to an 11-year-old cb quarter wave ;-( Antenna upgrade is in my plans, but right now I'd just be happy to start operating in CW and I still have a few characters (punctuation and ligatures) to learn before that. I'll get back here with the results of my tests once I get a free moment. Thanks, Andrea. - -- Undergraduate student of Computer Science @ University of Bologna Key fingerprint: 4037 9711 85C6 F9F9 A505 FA0A BB62 3A3C F7BA 9B13 ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+WhLzKhgqEyuO+p4RAtJ1AJ4wxHnJewGfR5ZoRc32rHHVcx/LRQCfRSPt kLfPczDyLAlTTIlhAbaRJNg= =Wnho -----END PGP SIGNATURE----- |
|
From: Andrea B. <bo...@st...> - 2003-03-02 21:53:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Fillod wrote: | rigctl -vvvvvv -Crts_state=ON -m 320 | There's also a config 'dtr_state' param. You can check them all with | the -L option. Let me know if this solves your powering problem. Funny thing is, minicom does read some garbage when turning the VFO knob, so apparently it is not a hw problem, but rigctl doesn't work, this is what I get: - -cut-cut- [andrea@deunan]/local/hamlib-1.1.4cvs-030227/tests$ ./rigctl -vvvvvv -r /dev/rig -Crts_state=ON -m 320 -L -s 9600 rigctl, Hamlib version 1.1.4cvs-030227 Report bugs to <ham...@li...> rig:rig_init called rig: loading backend icom icom: _init called rig_register (309) rig_register (310) rig_register (311) rig_register (313) rig_register (314) rig_register (319) rig_register (320) rig_register (321) rig_register (330) rig_register (326) rig_register (327) rig_register (347) rig_register (334) rig_register (344) rig_register (335) rig_register (340) rig_register (342) rig_register (304) rig_register (307) rig_register (352) rig_register (353) rig_register (351) civaddr: "Transceiver's CI-V address" ~ Default: 0, Value: 64 ~ Range: 0.0..255.0, step 1.0 mode731: "CI-V operating frequency data length, needed for IC731 and IC735" ~ Default: 0, Value: 0 rig_pathname: "Path name to the device file of the rig" ~ Default: /dev/rig, Value: /dev/rig 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 serial_speed: "Serial port baud rate" ~ Default: 0, Value: 9600 ~ 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 serial_handshake: "Serial port handshake" ~ Default: None, Value: None ~ Combo: None, XONXOFF, Hardware vfo_comp: "VFO compensation in ppm" ~ Default: 0, Value: 0.000000 ~ Range: 0.0..1000.0, step 0.0 rts_state: "Serial port set state of RTS signal for external powering" ~ Default: Unset, Value: ON ~ Combo: Unset, ON, OFF dtr_state: "Serial port set state of DTR signal for external powering" ~ Default: Unset, Value: Unset ~ Combo: Unset, ON, OFF rig:rig_open called Opened rig model 320, 'IC-736' Backend version: 0.2, Status: New Rig command: f TX 6 bytes 0000 fe fe 40 e0 03 fd ..@... read_string: timedout without reading a character get_freq: error = Communication bus error - -cut-cut- Where should I look to get a clue of what's going on? I gather you do not have a 736 so I'll do the tests. Andrea. - -- Undergraduate student of Computer Science @ University of Bologna Key fingerprint: 4037 9711 85C6 F9F9 A505 FA0A BB62 3A3C F7BA 9B13 ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE+Yn1jKhgqEyuO+p4RArI7AJ9SVaIgxNFfOaEJ0Mz8uyYLNxmfiACgjpM+ kGvIx4ixPRPZAPerouWkYQw= =iPvl -----END PGP SIGNATURE----- |
|
From: Chuck H. <n2...@am...> - 2003-03-04 08:25:53
|
ci-v interfaces have the transmit and receive are tied together on the ci-v side. Because of this they echo the commands sent to it back to the computer (with or without a radio connected) The reason your getting a RIG_BUSERROR is because hamlib is not seeing the echo. That can be caused by several things 1. wrong serial port 2. wrong interrupt 3. problems with ci-v interface 4. radio causing problems on ci-v bus (shorted, constant voltage, constant collisions) One way to check these might be to disconnect the radio from the ci-v bus, and either check for a different hamlib error, or see if characters echo in your favorite serial program. You might also try disconnecting the radio to see if there are any changes. For some reason I couldn't view the URL you gave http://www.g3vgr.co.uk/civ.htm so I'm not sure if the circuit your using is using a serial driver chip or something else. However, if your trying to drive the chip using power from the serial port I would check the voltages your getting and make sure enough is making it to the chip. I started off trying to power my interface from the serial port and decided after a little checking to power it externally since at least one of my serial ports was putting out +5 volts and after a diode (in case the pin went negative) and a voltage regulator (in case the pin was a +12 volts) I wasn't going to have enough power to drive the chip (because it wasn't a low voltage chip, it wanted about +5 volts) I also had a problem where it would work on one computer but not the other and I finally traced it down to the fact that I mis-read the chip docs and put caps where this chip wanted jumpers so it was putting out about +-.6 volts. The RS-232 spec says that: +3 to +15 is mark -3 to -15 is space (or is the other way around) +3 to -3 is undefined back in the old days things tended to use +12 and -12 to drive the lines and you could run cables all over the place. These days many things use +5 and -5 to drive the lines because they assume the things connected are going to be close by and because it's cheaper. However this gives you less power to work with if your trying to power something from the serial port. I've also included part of an email I sent when I was working on cleaning up some of the icom error handling. It probably should end up as part of the documentation sometime. However right now it is sort of icom specific. I'm not sure where it would go. Feel free to ask if you have any more questions or problems. --- As promised, here is my ideas for improved error checking for icom_transaction and icom_decode. To make it easier for the user to distinguish between problems, I added two new error codes (Do you have any better ideas?): RIG_BUSERROR This means something is wrong talking on the CI-V bus. (such as transmitted characters did not echo) If this is received at program startup, it probably means the computer is not talking on the CI-V bus. (wrong serial port, problems with CI-V interface) RIG_BUSBUSY Detected collision on CI-V bus. I also used existing error codes: RIG_ETIMEOUT Timeout talking to the radio. If this is received at program startup, it probably means there is a problem talking to the radio. (wrong speed, no power to radio, radio not on CI-V) RIG_EPROTO Something else unexpected happened In doing my quick testing: 1. With the radio off, I got a RIG_ETIMEOUT 2. With the power removed from the CI-V interface, I got a RIG_BUSERROR 3. I caused some collisions and got a RIG_BUSBUSY |
|
From: Andrea B. <bo...@st...> - 2003-03-04 08:53:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Hemker wrote: | ci-v interfaces have the transmit and receive are tied together on the ci-v | side. Because of this they echo the commands sent to it back to the computer | (with or without a radio connected) Hold it, timeout! ;-) I forgot to mention one important thing: my circuit and my radio are working perfectly fine under W2K with the DXLab suite (http://www.qsl.net/dxlab/download.htm) The circuit I am using is available online at: http://www.students.cs.unibo.it/~borgia/Ham That's why I'm puzzled, because I've already tested the hardware separetely from hamlib. Andrea. - -- Undergraduate student of Computer Science @ University of Bologna Key fingerprint: 4037 9711 85C6 F9F9 A505 FA0A BB62 3A3C F7BA 9B13 ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE+ZGmOKhgqEyuO+p4RAol1AKDauZTeUbUQUZ1qbu91EyZJrC7s2gCfS+la d5JcupsxBfuVDfl9YyGQebE= =1c/9 -----END PGP SIGNATURE----- |
|
From: Andrea B. <bo...@st...> - 2003-03-19 10:47:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Hemker wrote: > As promised, here is my ideas for improved error checking for icom_transaction > and icom_decode. I don't know what I changed, but now hamlib is working, more or less. Many commands in rigctl, however, return "not available"; how can I tell whether a given command is really supported by the radio or not? Andrea - -- Undergraduate student of Computer Science @ University of Bologna Key fingerprint: 4037 9711 85C6 F9F9 A505 FA0A BB62 3A3C F7BA 9B13 ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+eEpVKhgqEyuO+p4RAvfHAJ4i32C4SdFhbmQCOmN8B2k+ACi+4gCgocBo cm8XTwSE9xb8jSX5X3RNcpQ= =U+3z -----END PGP SIGNATURE----- |
|
From: Stephane F. <f8...@fr...> - 2003-03-19 21:29:57
|
On Wed, Mar 19, 2003, Andrea Borgia wrote: > I don't know what I changed, but now hamlib is working, more or less. excellent news! > Many commands in rigctl, however, return "not available"; how can I tell > whether a given command is really supported by the radio or not? Have a look at the last pages of the IC736 user manual. You should see a table with supported commands. This is all your Icom can do, nothing more. Trying functions not in table will make Hamlib return "not available". Rem: if you get a "not available" but the function IS in the table, then Hamlib has to be fixed :) 73's Stephane |
|
From: Andrea B. <bo...@st...> - 2003-03-20 09:30:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Fillod wrote: > Have a look at the last pages of the IC736 user manual. You should see a > table with supported commands. This is all your Icom can do, nothing more. Ehr, that's exactly the problem: there's no such table in the manual. All I see in the manual is a generic listing of frequencies and operating modes, but no mention of specific commands. Anyone with an IC-736 who can shed some light into the matter? TIA, Andrea. - -- Undergraduate student of Computer Science @ University of Bologna Key fingerprint: 4037 9711 85C6 F9F9 A505 FA0A BB62 3A3C F7BA 9B13 ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+eX49KhgqEyuO+p4RAr3jAKCIRCRDDJzr7rOHW+XrD+Z411mHtgCePpeP xijcDbZZZcO8bXvBkkEnhiw= =ylpS -----END PGP SIGNATURE----- |
Thanks for helping keep SourceForge clean.
X