Re: PTT Issue with IC-756 Pro2


CSM\(r\) Gary Huber - AB9M
 

Paul,

I can't come up with any 'documentation', I only have about 20 years working with telecom circuits.... typically computer serial connections to modem devices (TNCs) over telephone copper circuits or radio connections. 9600 baud was the maximum reliable speed we ran over terrestrial circuits, in part because of the timing of the ACK / NAK on circuits over about 12,000 feet, an issue we saw when trying to run IBM mainframe remotes over longer distances. That all having been said, anytime I have a USB to serial adapter, I just limit the speed to 9600 baud and use software flow control and let it go.... I'll give up a bit of speed for reliability.

If you are limited to the three (2 wire and ground) wires, you can tie the RTS/CTS and DTR/DSR pins together in the connector to make your terminal program happy but then you don't have any flow control when there's lots of data or when the receiving device slows down. I believe this is a real issue when USB connections are serviced by a Windows OS based computer. Your mileage may vary.... good luck.

73 & DX,

Gary - AB9M


From: Paul M Dunphy
Sent: Sunday, October 26, 2008 10:12 AM
To: DXLabs
Subject: Re: [dxlab] PTT Issue with IC-756 Pro2


At 10:53 AM 10/26/2008, you wrote:
One thing to consider when trouble shooting serial communications problems;
legacy serial communications over three wires (TX, RX, and Signal Ground)
with software flow control is limited to 9600 baud. When trying to run at
19,200 and higher speeds, hardware flow control (and five wires) is needed;
so if you only have three wires you are limited to 9600 baud or less and
software flow control.

73 & DX,

Gary - AB9M
Gary,

I'm running Commander at 19,200 Baud with a PROIII with no
problems. That's the fastest the PRO3 will go, or I'd try even
faster. It only has two wires RX/TX and a ground. I am running this
through a Rat Shack USB Scanner programming cable, which basically
allows Commander to see the USB port as a serial port. The default
was 9600 baud, but I upped it to 19,200 and have seen no problems.

I know that historically if one increased the baud rate above
9600 with a plain old DB-25 <--> DB-25 RS232C using software flow
control, problems can occur. This is especially true with longer
cable runs. I think this is implementation dependent. RF is a big
factor in Ham implementations at any speed.

Putting RF issues aside, isn't the problem with high speed
RS-232 flow caused by capacitance and inductance in the
conductors? I recall one of our engineers "fixing" data loss when we
were communicating with a serial device at 38,400 baud by putting
capacitors (trial and error method regarding the value) across the
TX/RX ends of the cables until the signals settled down. This was to
match the inductance introduced by the cable. With a scope, we could
see the rounding of the wave forms and "ringing" dramatically reduced
as the capacitors were added. (I was just the programmer, not the
electronics guru, but this was how it was cured -- and it was on a
ship at sea so we couldn't re-design much -- it was just a quick fix.)

This was all using software flow control. I believe if you get
a distortion of the signals in the lines, hardware control such as
DTS/RTS would be just as susceptible as the data lines, wouldn't it?

73, Paul VE1DX

Join DXLab@groups.io to automatically receive all group messages.