[chirp_devel] DTR/RTS control
Hardware flow control is tangentially related to my feature request #777. Hardware flow control uses the RTS signal line for flow control; modern amateur radio cables use RTS (and/or DTR) for power:
In classical hardware flow control (classically a terminal connected to a modem):
1. When the DTE (Data Terminal Equipment: eg a terminal) is powered on and ready to receive data, it asserts DTR (Data Terminal Ready). 2. When the DCE (Data Communications Equipment: eg, a modem, or other device communicating with the terminal) is ready, it asserts DSR (Data Set Ready). 3. In an actual modem configuration, when the modem has established a connection with a remote modem, it asserts CD (Carrier Detect). Similarly, when an idle modem receives a phone call attempt, it asserts RI (Ring Indicate). Depending upon the modem configuration and what is connected to it, the terminal may assert DTR, signalling the modem to answer the ringing phone line (and subsequently asserts CD). While this is interesting, it is normally not a factor in the case at hand; I've only included it for context. 4. Normally a terminal that is ready to send asserts RTS (Request To Send). This usually stays high for the duration of the connection (an exception would be half-duplex modems, which is not pertinent here). 5. Typically, modems could receive data from a terminal at a much higher rate than the modem could send to the remote modem, and as a result, had an internal buffer. The default state of a ready modem was to assert CTS (clear to send). However, if the buffer got too close to being full, a modem would drop CTS until it had transmitted (emptied) most of the transmit buffer.
Hardware flow control is #4 and #5 above. In the modern computer world, where the two devices are local (or simulated as same) and there is no modem, the above changes slightly:
1. DTR and DSR are asserted when the respective devices are functionally ready, and stay in that state until the communications session is over. Eg: A printer (DCE) asserts DSR when its power-on sequence in complete, until power-off. A software communications program (DTE) typically asserts DTR when the program opens the serial connection, until it closes the connection. 2. RTS and CTS are used for flow control, just as above.
When *SOFTWARE* flow control is used:
1. RTS is asserted by the DTE at the same time as it asserts DTR, and CTS is asserted by the DCE at the same time as it asserts DSR. 2. One or both of the devices sends X-off and X-on bytes to tell the other device to suspend and resume transmission, respectively.
Sometimes two DTE devices need to communicate, and a wiring change is made in the normally straight-through cable, so that what one DTE device thinks is DTR/RTS/TX, the other device sees as DSR/CTS/RX. Such is the "null modem" cable. Some manufacturers of devices don't understand this or related wiring issues, leading to the need for "gender changers", but this is not pertinent here.
One important feature of all of the above, is that each such device acquires its own power.
However, with most Amateur Radios, the radio cable usually does not bring anything except "ground" and the "TX" and "RX" data lines. This is the case for all Icom radios that I am aware of, as well as and most handhelds from other manufacturers. My Yaesu FT-897D is an exception; the serial cable provides power to its internal serial converter.
For some Icom radios (eg, the ID-880H and IC-2820H) that use the Icom OPC-1529R cable, it's a simple three-wire cable providing ground, TX, and RX. Presumably these are at RS-232C acceptable levels (that's a whole different discussion). Other cables (eg, the Yaesu one for the Yaesu FT-897D) have a little circuit board in the RS-232C/DB-9 shell that does level conversion (and needs power, except for the few radios where the cable provides the power). Still other cables, like the ones that split out TX and RX signals from a single wire, have additional circuitry for that purpose.
Both of the latter cases must get their power from the DTR and/or RTS lines from the connected computer. These signal lines were never intended to provide power, but since modern circuits draw so little power, using DTR and/or RTS for power doesn't create an issue if done correctly.
As I noted in the feature request, some cables want both DTR and RTS on, and use ground for the voltage reference base. Others want RTS low and DTR high, and some want the reverse.
On 2013-04-09 19:22, Dean Gibson AE7Q wrote:
...
For some Icom radios (eg, the ID-880H and IC-2820H) that use the Icom OPC-1529R cable, it's a simple three-wire cable providing ground, TX, and RX. Presumably these are at RS-232C acceptable levels (that's a whole different discussion). Other cables (eg, the Yaesu one for the Yaesu FT-897D) have a little circuit board in the RS-232C/DB-9 shell that does level conversion (and needs power, except for the few radios where the cable provides the power). Still other cables, like the ones that split out TX and RX signals from a single wire, have additional circuitry for that purpose.
To see the complexity of this issue, see http://www.starrsoft.com/software/win96/cables/gre_cables.htm This cable and its internal circuitry (and power) are necessary in order to separate out TX from RX in a single-wire (plus ground) radio jack (like the IC-7000 has). The cable under discussion works perfectly to communicate with the Icom IC-7000 *on my computer*, and when Radio Shack was having a close-out sale, I bought four of them (@ $2.00 each). This cable requires DTR high and RTS low in order to work. Then I found the above article, which explains the numerous complaints I have seen on the Internet about this cable (and why the price was so low). Apparently there are issues with the cable, and the lower-powered serial ports that are commonly found on laptops ...
So, I don't use them any more; I use the RT Systems CT-29A cable with the IC-7000. The CT-29A works just fine with both DTR and RTS high on one serial port I have, but works on *all* of my serial ports with DTR *low* and RTS high.
As I noted in the feature request, some cables want both DTR and RTS on, and use ground for the voltage reference base. Others want RTS low and DTR high, and some want the reverse.
From my experience, only larger CI-V (, etc) converter boxes are dependent on RTS being high to power the circuit. I've seen no reports of issues with any cable on any typical VHF/UHF type setup, so I don't believe this to be a problem for those types of radios (which, of course, are the major target market for CHIRP). Further, I believe it is the overwhelming common practice (rightly so, IMHO) for a opened serial port to assert DTR unless configured to do otherwise. I believe that is likely the reason why we've seen no reports of this being a problem until now. At least on all my systems, CHIRP opening the port asserts DTR, which powers my MAX232-based custom interface cables.
I'm hesitant to expose such a setting in the UI without any indication of need or issues in the field because it becomes one more thing that can be set incorrectly by the user and thus one more thing that we must clarify, explain, etc in order to provide support.
The other important thing to note, of course, is that probably more than 90% of CHIRP's users are utilizing cables with inbuilt USB interfaces, which are always powered from the bus and for which DTR and RTS settings (for the purposes of powering a converter) are meaningless. We have no reasonable way of determining if a device selected by the user fits into this classification, which means exposing them in the UI provides only confusion, IMHO.
What commercially-available cables require RTS low and DTR high?
Since I'm quite certain this is only a problem with HF CI-V-like interface boxes, if anything, I'd like to restrict such a setting (if we were to add it) to those drivers that are likely to have such a requirement.
I'm not really sure what my preferred path forward would be. Perhaps a documented, but low-visibility config file option that would let someone enable it for a specific need? Again, with no reports of issues with this, I'm hesitant to expose it widely.
On 2013-04-09 20:55, Dan Smith wrote:
... my MAX232-based custom interface cables ...
What commercially-available cables require RTS low and DTR high?
MAX232-based cables are apparently regarded as the cream of the crop, which may be why you have not seen any problems.
As I noted, the Radio Shack 20-289 (the cable described in the link), which was sold widely for amateur and scanner usage. However, as I said (and the link noted), the circuit in that cable is problematic for other reasons, so I'm not so concerned about that one.
However, as I said, I have the RT Systems CT-29A, which was also *very widely* sold for a number of both Icom and Yaesu radios, before people started using USB. I bought it years ago to work with the IC-7000. With some serial ports, it works fine with both DTR and RTS high. However, on the Digi serial port box I'm using (another widely sold product), the CT-29A requires RTS *high* and DTR *low*, probably due to serial port loading (why is why some cables work on some computers and not others).
If you don't want to do it, that's fine. I use RumTrol for saving memories on the IC-7000, so I don't need Chirp to do it; the only radio I use Chirp with, is the Yaesu FT-897D. However, this isn't a pipe dream of mine; both RumTrol and Ham Radio Deluxe have seen the need for quite some time, and it certainly wasn't me who prodded them; my first exposure to both programs came with the feature already there, so there must have been some demand other than my crazy idea. Further, the feature is not hidden; it's there with the serial port selection.
You already have a menu list with "Enable Developer Functions"; you could always enable it there. Or, you could create an additional item in that menu list titled "Advanced RS-232 Options".
However, as I said, I have the RT Systems CT-29A, which was also *very widely* sold for a number of both Icom and Yaesu radios, before people started using USB. I bought it years ago to work with the IC-7000. With some serial ports, it works fine with both DTR and RTS high. However, on the Digi serial port box I'm using (another widely sold product), the CT-29A requires RTS *high* and DTR *low*, probably due to serial port loading (why is why some cables work on some computers and not others).
A lot of laptop computers and many USB-to-serial adapters actually just swing +5V and 0V for the two states. It's a real problem for gear that is strict about the standard, and may be why you have problems powering that device there. Maybe the Digi box will swing to -5V for low, and that gives you 10V to power it? I've not seen any adapters that are only doing 5V that actually go to -5V on the low side, so this may mean that box wouldn't work there anyway.
If you don't want to do it, that's fine. I use RumTrol for saving memories on the IC-7000, so I don't need Chirp to do it; the only radio I use Chirp with, is the Yaesu FT-897D. However, this isn't a pipe dream of mine; both RumTrol and Ham Radio Deluxe have seen the need for quite some time, and it certainly wasn't me who prodded them; my first exposure to both programs came with the feature already there, so there must have been some demand other than my crazy idea. Further, the feature is not hidden; it's there with the serial port selection.
I know that it's exposed widely in those apps, but it's far more relevant to them, IMHO.
You already have a menu list with "Enable Developer Functions"; you could always enable it there. Or, you could create an additional item in that menu list titled "Advanced RS-232 Options".
Yeah, certainly could do that.
What do other people think? I see the options as:
1. Expose it on the clone dialog unconditionally 2. Expose it on the clone dialog if the radio selected is one of a set likely to need this (i.e. HF rigs) 3. Expose it either if developer options is enabled or if an additional toggle is set (i.e. Advanced stuff) 4. Allow for it to be set in the config file only and document it on the wiki 5. Do nothing
I don't think I want to do either #1 or #2, but I'm open to the others. Thoughts? Marco, you do a lot with the Yaesu HF rigs -- any comments on this?
I got a usb programming cable for my BAOFENG UV5R. I have the prolific 3.2.0.0 driver on Windows 7 Home Premium. It reads and writes the radio with the VIP software albeit unreliably but it will not do either with CHIRP. It reads and writes without error if I use the serial programming cable. 73, Alan - W6ARH
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: Wednesday, April 10, 2013 5:44 PM To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] DTR/RTS control
However, as I said, I have the RT Systems CT-29A, which was also *very widely* sold for a number of both Icom and Yaesu radios, before people started using USB. I bought it years ago to work with the IC-7000. the With some serial ports, it works fine with both DTR and RTS high. However, on the Digi serial port box I'm using (another widely sold product), the CT-29A requires RTS *high* and DTR *low*, probably due to serial port loading (why is why some cables work on some computers and not others).
A lot of laptop computers and many USB-to-serial adapters actually just swing +5V and 0V for the two states. It's a real problem for gear that is strict about the standard, and may be why you have problems powering that device there. Maybe the Digi box will swing to -5V for low, and that gives you 10V to power it? I've not seen any adapters that are only doing 5V that actually go to -5V on the low side, so this may mean that box wouldn't work there anyway.
If you don't want to do it, that's fine. I use RumTrol for saving memories on the IC-7000, so I don't need Chirp to do it; the only radio I use Chirp with, is the Yaesu FT-897D. However, this isn't a pipe dream of mine; both RumTrol and Ham Radio Deluxe have seen the need for quite some time, and it certainly wasn't me who prodded them; my first exposure to both programs came with the feature already there, so there must have been some demand other than my crazy idea. Further, the feature is not hidden; it's there with the serial port selection.
I know that it's exposed widely in those apps, but it's far more relevant to them, IMHO.
You already have a menu list with "Enable Developer Functions"; you could always enable it there. Or, you could create an additional item in that menu list titled "Advanced RS-232 Options".
Yeah, certainly could do that.
What do other people think? I see the options as:
1. Expose it on the clone dialog unconditionally 2. Expose it on the clone dialog if the radio selected is one of a set likely to need this (i.e. HF rigs) 3. Expose it either if developer options is enabled or if an additional toggle is set (i.e. Advanced stuff) 4. Allow for it to be set in the config file only and document it on the wiki 5. Do nothing
I don't think I want to do either #1 or #2, but I'm open to the others. Thoughts? Marco, you do a lot with the Yaesu HF rigs -- any comments on this?
-- Dan Smith www.danplanet.com KK7DS
On 2013-04-10 17:43, Dan Smith wrote:
A lot of laptop computers and many USB-to-serial adapters actually just swing +5V and 0V for the two states. It's a real problem for gear that is strict about the standard, and may be why you have problems powering that device there. Maybe the Digi box will swing to -5V for low, and that gives you 10V to power it? I've not seen any adapters that are only doing 5V that actually go to -5V on the low side, so this may mean that box wouldn't work there anyway.
I've now obtained a second Digi PortServer TS4 box from eBay, and one is apparently slightly newer. Digi made so many different minor variants, that while the two boxes run the exact same firmware (I know, because I upgraded both to the latest firmware), there are differences:
1. The newer box can be powered by external power and also Power over Ethernet (PoE). The older box does that, and also can be powered from RS-232C RI ("Ring Indicate"). However, I'm only powering both boxes with external power (which can be anything from 9-30vDC, and I'm supplying 13.8vDC). 2. Both boxes can support both RS-232C, RS-422, and RS-485 via switch settings, but only the older box has switch settings for each serial port. 3. The newer box works with all my radios with DTR and RTS high. The older box works the same, except that for the CT-29A cable, it requires RTS=high, DTR=low. If the older box sends DTR high to the CT-29A cable, the cable responds in such a way in such a way that the Digi box *locks up***(which means *all serial ports on the box go down*). The Yaesu CT-62 serial cable from the FT-897D gets its power from the radio, and the OPC-1529R cables from the Icom D-Star radios are just TX/RX/GND wires (DTR/RTS are unconnected), so those radios work just fine with either Digi box.
My reason for having both boxes is that I have one on the DMZ, and one on the local LAN. That allows me to move radio control for each radio individually between the DMZ (eg, for use from the Internet) and the LAN (protected from the world). Plus, I like spares ...
What do other people think? I see the options as:
- Expose it on the clone dialog unconditionally
- Expose it on the clone dialog if the radio selected is one of a set likely to need this (i.e. HF rigs)
- Expose it either if developer options is enabled or if an additional toggle is set (i.e. Advanced stuff)
- Allow for it to be set in the config file only and document it on the wiki
- Do nothing
I don't think I want to do either #1 or #2, but I'm open to the others. Thoughts? Marco, you do a lot with the Yaesu HF rigs -- any comments on this?
Hi all! I really like option #3, I imagine it as an additional "Advanced settings" line in Radio menu which will open a dialog.
In that dialog we can also place more settings like eg. serial timings.
my two cents
73 de IZ3GME Marco
participants (4)
-
Dan Smith -
Dean Gibson AE7Q -
IZ3GME Marco -
The Silver Fox