Elecraft

KPA500 serial interfaces

Classic

List

Threaded

14 messages Options

ANDY DURBIN

KPA500 serial interfaces

The KPA500 has two serial ports. One is assigned to PC and the other to transceiver. I'm aware that all the commands in the Programmer's Reference can be used over the PC port and have been using this interface for about a year for my data logger.

Does the transceiver port also support the full command set of the Programmer's Reference? If so, does any special care have to be taken when sending the same interrogation or command over both ports?

Thanks and 73,
Andy, k3wyc
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Elecraft mailing list

Re: KPA500 serial interfaces

No. The transceiver port is meant to receive data from a connected Elecraft or Kenwood transceiver. It acts on data responses received from those devices.
Specifically, it is looking of the following command responses from the transceiver: FA;, FB;, FR;, FT;, or IF;. The entire purpose of the XCVR port is to provide another method to obtain the operating band from the transceiver.

When it is set to poll the transceiver for data, it sends the following sequence: IF;FA;FB;

If you send any KPA500 commands, as described in the programmer’s reference to the transceiver port, they will be ignored. Likewise transceiver responses sent to the PC port will also be ignored. It is significant that the transceiver port uses a male DE9 connector - the same as used on a standard PC, While the XCVR port uses a female DE9 the same as used on peripheral equipment..

Page 4 of the KPA500 operating manual alludes to the differences in the two ports. For the XCVR port, it states: "RS232 (XVCR) connects the KPA500 to a Kenwood transceiver using a standard 9-pin serial cable. This connector cannot be used to update KPA500 firmware (see pg 20).”. While for the PC port the text is: "RS232 (PC) connects the KPA500 to your personal computer with a standard 9-pin serial cable. Required for updating the KPA500 firmware.”.
The important piece of information here is the update text. Firmware updates, and other control commands, must be sent to the KPA500’s PC port. Sending them to the XCVR port will do nothing as far as the amplifier is concerned.

73!,
Jack, W6FB

> On Feb 9, 2019, at 8:56 AM, Andy Durbin <[hidden email]> wrote:
>
> The KPA500 has two serial ports. One is assigned to PC and the other to transceiver. I'm aware that all the commands in the Programmer's Reference can be used over the PC port and have been using this interface for about a year for my data logger.
>
> Does the transceiver port also support the full command set of the Programmer's Reference? If so, does any special care have to be taken when sending the same interrogation or command over both ports?
>
> Thanks and 73,
> Andy, k3wyc
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

ANDY DURBIN

Re: KPA500 serial interfaces

Thanks Jack. I suspected that would be the case but it was better to ask than to waste my time experimenting. I'll just have to put a bit more thought into how to configure the KPA500 polling devices and the associated serial data multiplexing relay(s).

73,
Andy, k3wyc

________________________________
From: Jack Brindle <[hidden email]>
Sent: Saturday, February 9, 2019 10:39 AM
To: Andy Durbin
Cc: [hidden email]
Subject: Re: [Elecraft] KPA500 serial interfaces

No. The transceiver port is meant to receive data from a connected Elecraft or Kenwood transceiver. It acts on data responses received from those devices.
Specifically, it is looking of the following command responses from the transceiver: FA;, FB;, FR;, FT;, or IF;. The entire purpose of the XCVR port is to provide another method to obtain the operating band from the transceiver.

When it is set to poll the transceiver for data, it sends the following sequence: IF;FA;FB;

If you send any KPA500 commands, as described in the programmer’s reference to the transceiver port, they will be ignored. Likewise transceiver responses sent to the PC port will also be ignored. It is significant that the transceiver port uses a male DE9 connector - the same as used on a standard PC, While the XCVR port uses a female DE9 the same as used on peripheral equipment..

Page 4 of the KPA500 operating manual alludes to the differences in the two ports. For the XCVR port, it states: "RS232 (XVCR) connects the KPA500 to a Kenwood transceiver using a standard 9-pin serial cable. This connector cannot be used to update KPA500 firmware (see pg 20).”. While for the PC port the text is: "RS232 (PC) connects the KPA500 to your personal computer with a standard 9-pin serial cable. Required for updating the KPA500 firmware.”.
The important piece of information here is the update text. Firmware updates, and other control commands, must be sent to the KPA500’s PC port. Sending them to the XCVR port will do nothing as far as the amplifier is concerned.

73!,
Jack, W6FB

Bob Wilson, N6TV

Re: KPA500 serial interfaces

On Sat, Feb 9, 2019 at 10:51 AM Andy Durbin <[hidden email]> wrote:

> Thanks Jack. I suspected that would be the case but it was better to ask
> than to waste my time experimenting. I'll just have to put a bit more
> thought into how to configure the KPA500 polling devices and the associated
> serial data multiplexing relay(s).
>

The Serial Box <https://bit.ly/S-BOX> (S-BOX) was specifically designed to
make it easy to connect multiple devices in parallel to any transceiver's
serial port, including a PC, KPA500, KAT500, KPA1500, SteppIR Controller,
Kessler AT-Auto, Shackmaster SM-8, etc. One device is connected to Pin 3
(usually the PC running logging software to do the polling), and the rest
are wired in parallel to listen to the radio's responses on Pin 2.
AutoInfo mode may also enabled to let all devices track the transceiver's
frequency automatically when no PC or logging software is being used.

73,
Bob, N6TV
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

ANDY DURBIN

Re: KPA500 serial interfaces

"The Serial Box<https://bit.ly/S-BOX> (S-BOX) was specifically designed to make it easy to connect multiple devices in parallel to any transceiver's serial port, including a PC, KPA500, KAT500, KPA1500, SteppIR Controller, Kessler AT-Auto, Shackmaster SM-8, etc. "

My configuration requires one device to be the routine polling device but has to allow for another device to break that polling interface and insert different commands to the destination equipment.

E.g - 1. OmniRig polls my TS-590 and my TS-590/Elecraft interface listens to the responses. When I want to set the TS-590 power, or initiate a TX Tune, my TS-590/Elecraft interface disconnects OmniRig, attaches the local RS232 source, sends the power command, then returns control to OmniRig. The supplemental commands are timed to only be sent in the "window" where OmniRig is not sending a command. (It's actually a bit more complicated than that because initiating a TX Tune first inhibits the amplifier key line then, when key inhibit is confirmed, it initiates TX Tune with a specific power setting, returns TS-590 to receive mode, waits until RX mode is confirmed, then re-enables the amplifier key line.)

E.g -2. The KAT500 utility may be polling my KAT500 but I disconnect it and send the KAT500 commands to change L, C, bypass, antenna side, etc. Again this is is done without disrupting KAT500 utility polling as the commands are only sent in the "window" between the utility polls. Depending on an option setting the TS-590/Elecraft interface can be the primary KAT500 polling device and the utility is not needed.

Examples 1 and 2 were implemented a while ago and are mature and reliable. The next step is to integrate the KPA500 so OPER/STBY are fully integrated in my power control scheme.

So, sorry, but your interface doesn't come close to meeting my requirements.

73,
Andy, k3wyc
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Don Wilhelm

Re: KPA500 serial interfaces

Andy,

You are dealing with an RS-232 communications protocol, which is only
point to point and not multipoint like Ethernet.

I have no idea how your "polling" device works, but with RS-232, there
is no polling, it is direct "handshaking" between 2 devices, a DTE and a
DCE. If handshaking is implemented, Data Terminal Ready, Data Set Ready
are exchanged, then Request to Send and the Clear To Send Response are
sent. That signalling protocol is normally used only by modems.

Most ham applications do not use those handshaking signals, but rely
only on Transmit Data and Receive Data to establish communications.

For RS-232 there MUST be only one transmitter - there can be multiple
receivers, but those devices (other than the main one, either the PC or
the KPA500) can be the transmitter. It takes some complex hardware
device to switch an RS-232 bus from one transmitter to another.

This is a hardware consideration and has nothing to do with software
such as OmniRig.

Consider the RS-232 voltage levels and you will see why there can be
only one transmitter on a line. The active level is between +3.5 volts
and +25 volts while the inactive level can be from -3.5 volts to -25 volts.
Think about what happens when you connect one device producing +25 volts
directly to the output of another device producing -25 volts! That is
why only one transmitter can be used on an RS-232 signal line.

There are several devices that can be used (such as the SteppIR
controller) in an RS-232 environment, but their configuration must be
set to only listen to the traffic on the main RS-232 communications
which is normally the PC and the transceiver.

The S-Box has the transmitters hardware disabled for all but one port -
that is how it allows multiple devices to listen in on the communications.

73,
Don W3FPR

On 2/11/2019 3:04 PM, Andy Durbin wrote:

>
> "The Serial Box<https://bit.ly/S-BOX> (S-BOX) was specifically designed to make it easy to connect multiple devices in parallel to any transceiver's serial port, including a PC, KPA500, KAT500, KPA1500, SteppIR Controller, Kessler AT-Auto, Shackmaster SM-8, etc. "
>
> My configuration requires one device to be the routine polling device but has to allow for another device to break that polling interface and insert different commands to the destination equipment.
>
> E.g - 1. OmniRig polls my TS-590 and my TS-590/Elecraft interface listens to the responses. When I want to set the TS-590 power, or initiate a TX Tune, my TS-590/Elecraft interface disconnects OmniRig, attaches the local RS232 source, sends the power command, then returns control to OmniRig. The supplemental commands are timed to only be sent in the "window" where OmniRig is not sending a command. (It's actually a bit more complicated than that because initiating a TX Tune first inhibits the amplifier key line then, when key inhibit is confirmed, it initiates TX Tune with a specific power setting, returns TS-590 to receive mode, waits until RX mode is confirmed, then re-enables the amplifier key line.)
>
> E.g -2. The KAT500 utility may be polling my KAT500 but I disconnect it and send the KAT500 commands to change L, C, bypass, antenna side, etc. Again this is is done without disrupting KAT500 utility polling as the commands are only sent in the "window" between the utility polls. Depending on an option setting the TS-590/Elecraft interface can be the primary KAT500 polling device and the utility is not needed.
>
> Examples 1 and 2 were implemented a while ago and are mature and reliable. The next step is to integrate the KPA500 so OPER/STBY are fully integrated in my power control scheme.
>

ANDY DURBIN

Re: KPA500 serial interfaces

"I have no idea how your "polling" device works, but with RS-232, there is no polling, "

Point 1 is true. Point 2 is, in my opinion, not true.

A poll is a request for information. The device issuing the poll/request is the polling device. For example, sending IF; to a TS-590 is a data request, or poll, for the current IF status. The TS-590 responds with the full IF word.

Andy, k3wyc

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Doug Person-5

Re: KPA500 serial interfaces

I think the point is that RS-232 does not, as a protocol, support
polling. Nothing prevents you from doing some sort of polling
programmatically. However, multiple devices on a single RS-232 line is
beyond what the protocol was designed for. That's why there is RS-485 -
which IS designed for multi-device control.

Doug -- KJ0F

On 2/11/2019 2:55 PM, Andy Durbin wrote:

> "I have no idea how your "polling" device works, but with RS-232, there is no polling,"
>
> Point 1 is true. Point 2 is, in my opinion, not true.
>
> A poll is a request for information. The device issuing the poll/request is the polling device. For example, sending IF; to a TS-590 is a data request, or poll, for the current IF status. The TS-590 responds with the full IF word.
>
> Andy, k3wyc
>
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>

--
73 de Doug -- KJ0F

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Don Wilhelm

Re: KPA500 serial interfaces

In reply to this post by ANDY DURBIN

Andy,

"Polling" normally refers to a situation like Ethernet and others where
a response from a particular *addressed* device is requested.
For RS-232, it is "handshaking" (if implemented) telling the DTE when it
is OK to send data - since there is only one transmitter on an RS-232
signalling line, there is no need for addressing. The transmitting
device expects to communicate to only one receiving device on the other
end (although other receivers can 'listen in'.

I have worked with RS-232 for over 35 years both professionally (both
modems and DCEs for 20 years) and with ham radio gear and PCs after
retirement from that life.

If we wish for clear communication, the terms used are important. Ham
Radio "speak" often confuses the proper engineering terms. You hear of
ham radio software that "polls" the radio - in reality, it is simply
issuing a command to the radio and expects a response to that command.
That is a command/response scenerio, and is not really polling.

Don W3FPR

On 2/11/2019 3:55 PM, Andy Durbin wrote:

> "I have no idea how your "polling" device works, but with RS-232,
> thereis no polling, "
>
> Point 1 is true. Point 2 is, in my opinion, not true.
>
> A poll is a request for information. The device issuing the
> poll/request is the polling device. For example, sending IF; to a
> TS-590 is a data request, or poll, for the current IF status. The
> TS-590 responds with the full IF word.
>
> Andy, k3wyc
>
>

Andy McMullin

Re: KPA500 serial interfaces

Not wishing to get into an argument but consider Binary-Synch, Uniscope or UTS400 protocols. They are poll and response, RS232c communications systems. Used from mainframe to (dumb) terminal. They are synchronous RS232 of course rather than asynch and so use the clock and other signals ignored by the [IBM PC] cut down implementation of the RS232 connector. RS232 of course only defining the names and voltages on the connector.

From memory a Uniscope (U100) “poll” from the mainframe would be the characters: sync, sync, sync, sync, SOH, RID, SID, DID, STX, text, ETX, BCC.

Now that was dug out of the 1970’s if nothing was!

Andy, G8TQH

> On 11 Feb 2019, at 21:35, Don Wilhelm <[hidden email]> wrote:
>
> Andy,
>
> "Polling" normally refers to a situation like Ethernet and others where a response from a particular *addressed* device is requested.
> For RS-232, it is "handshaking" (if implemented) telling the DTE when it is OK to send data - since there is only one transmitter on an RS-232 signalling line, there is no need for addressing. The transmitting device expects to communicate to only one receiving device on the other end (although other receivers can 'listen in'.
>
> I have worked with RS-232 for over 35 years both professionally (both modems and DCEs for 20 years) and with ham radio gear and PCs after retirement from that life.
>
> If we wish for clear communication, the terms used are important. Ham Radio "speak" often confuses the proper engineering terms. You hear of ham radio software that "polls" the radio - in reality, it is simply issuing a command to the radio and expects a response to that command. That is a command/response scenerio, and is not really polling.
>
> Don W3FPR
>
> On 2/11/2019 3:55 PM, Andy Durbin wrote:
>> "I have no idea how your "polling" device works, but with RS-232, thereis no polling, "
>>
>> Point 1 is true. Point 2 is, in my opinion, not true.
>>
>> A poll is a request for information. The device issuing the poll/request is the polling device. For example, sending IF; to a TS-590 is a data request, or poll, for the current IF status. The TS-590 responds with the full IF word.
>>
>> Andy, k3wyc
>>
>>
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]

Elecraft mailing list

Re: KPA500 serial interfaces

Andy, in support of your comments I was an active Bell System DATEC representative back in the 70s and 80s and multipoint polled RS-232 was very common here in the colonies :)

Michael Blake
[hidden email] <mailto:[hidden email]>

> On Feb 11, 2019, at 4:54 PM, Andy McMullin <[hidden email]> wrote:
>
> Not wishing to get into an argument but consider Binary-Synch, Uniscope or UTS400 protocols. They are poll and response, RS232c communications systems. Used from mainframe to (dumb) terminal. They are synchronous RS232 of course rather than asynch and so use the clock and other signals ignored by the [IBM PC] cut down implementation of the RS232 connector. RS232 of course only defining the names and voltages on the connector.
>
> From memory a Uniscope (U100) “poll” from the mainframe would be the characters: sync, sync, sync, sync, SOH, RID, SID, DID, STX, text, ETX, BCC.
>
> Now that was dug out of the 1970’s if nothing was!
>
> Andy, G8TQH
>
>> On 11 Feb 2019, at 21:35, Don Wilhelm <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> Andy,
>>
>> "Polling" normally refers to a situation like Ethernet and others where a response from a particular *addressed* device is requested.
>> For RS-232, it is "handshaking" (if implemented) telling the DTE when it is OK to send data - since there is only one transmitter on an RS-232 signalling line, there is no need for addressing. The transmitting device expects to communicate to only one receiving device on the other end (although other receivers can 'listen in'.
>>
>> I have worked with RS-232 for over 35 years both professionally (both modems and DCEs for 20 years) and with ham radio gear and PCs after retirement from that life.
>>
>> If we wish for clear communication, the terms used are important. Ham Radio "speak" often confuses the proper engineering terms. You hear of ham radio software that "polls" the radio - in reality, it is simply issuing a command to the radio and expects a response to that command. That is a command/response scenerio, and is not really polling.
>>
>> Don W3FPR
>>
>> On 2/11/2019 3:55 PM, Andy Durbin wrote:
>>> "I have no idea how your "polling" device works, but with RS-232, thereis no polling, "
>>>
>>> Point 1 is true. Point 2 is, in my opinion, not true.
>>>
>>> A poll is a request for information. The device issuing the poll/request is the polling device. For example, sending IF; to a TS-590 is a data request, or poll, for the current IF status. The TS-590 responds with the full IF word.
>>>
>>> Andy, k3wyc
>>>
>>>
>>
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:[hidden email]
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to [hidden email] <mailto:[hidden email]>
>
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft <http://mailman.qth.net/mailman/listinfo/elecraft>
> Help: http://mailman.qth.net/mmfaq.htm <http://mailman.qth.net/mmfaq.htm>
> Post: mailto:[hidden email] <mailto:[hidden email]>
>
> This list hosted by: http://www.qsl.net <http://www.qsl.net/>
> Please help support this email list: http://www.qsl.net/donate.html <http://www.qsl.net/donate.html>
> Message delivered to [hidden email] <mailto:[hidden email]>

Brendon Whateley

Re: KPA500 serial interfaces

I always worry about what I don't know with this kind of discussion that
seems to dive into entrenched positions of pedantic certainty. Since I love
my KX3 and other Elecraft products, as well as various microcontrollers, I
was concerned that I'd missed something about RS232 which I've used for
decades. So I did a little research. And let me tell you there is so much
information out there that a pedant can basically shut down any discussion
as being inaccurate! Don't dare talk about DB9 connectors on equipment
because you probably mean DE-9P!

Reading the RS232 standard(s), it is clear that any multi-point
implementations are not technically RS232 compliant and require
non-standard wiring and/or software and hardware support that is not in the
specification. Directly connecting standard's compliant equipment will be
hit and miss and could damage some devices - strict compliance to RS232 is
short-circuit protected between pin pairs, but many devices are "sort-of"
compliant. But if you control all sides, then proprietary implementations
could be easily done. Again, that would not technically comply with the
standard. On the other hand, RS232 and RS423 support a multi-drop (multiple
listeners, one sender) format in some cases, which only allows 1 bus driver
and up to 10 receivers.

BUT. There have been many variations over the years, along with
similar-seeming RS485 which is multi-drop. RS485 is wired in a similar way
but is a current loop interface instead of voltage based. I also found
RS422 which is a long distance "drop-in-replacement" for RS232 and that has
a multi-drop version, but there seem to be so many different flavors of
wiring, it may as well be proprietary at that point.

I've found and reviewed a few dozen of the many, many specifications for
serial communications that are similar to RS232 and can find none that fit
the impression some of the earlier posts gave of having multiple devices
communicating back-and-forth on the same physical RS232 connection. The
talk of sharing connections with boxes that multiplex over an RS232
connection led me to find the products that speak SDLC to a device that
then communicates with a set of RS232 devices. I hardly think that is the
same thing, since although a single RS232 is required on the computer, it
is not speaking directly to the devices on the other end.

I looked up the Bisync protocol as well as the Uniscope equipment. It looks
like although they did use what is called RS232 connectors and wiring, they
did not follow the specification, so standards complient RS232 devices
wouldn't work in a multi-drop setting.

In summary, it seems that a degree of liberty in the use of the terms and
standards results in confusion and folks arguing across each other. There
is a large difference between what might be possible over wiring that
otherwise conforms to RS232 but is unrelated to the standard which is a
point-to-point standard for linking two devices. Then if you overlay
proprietary protocols as used by Uniscope, IBM, et.al along with the many
almost RS232 standards and we get the situation where some insist that
RS232 supports multi-point networking while others claim it doesn't. I
think the bottom line is that any fancy connections (beyond what Elecraft
specifies) between Elecraft devices will need additional software and/or
hardware to support.

Some of the references I used:

- RS232 connectors and wiring
<http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm>
- IIT course on Serial Communications
<https://nptel.ac.in/courses/Webcourse-contents/IIT%20Kharagpur/Embedded%20systems/Pdf/Lesson-25.pdf>
- Blackbox RS232 connection sharing devices
<https://az849230.vo.msecnd.net/resources/10920_20100.pdf>
- IBM SDLC protocol concepts
<http://www.textfiles.com/bitsavers/pdf/ibm/datacomm/GA27-3093-3_SDLC_Concepts_Jun86.pdf>
- IBM SDLC communications adapter manual
<http://minuszerodegrees.net/oa/OA%20-%20IBM%20SDLC%20Adapter.pdf>
- List of some Network Bus standards
<https://en.wikipedia.org/wiki/List_of_network_buses>
- EIA RS232 V24 standard
<https://www.electronics-notes.com/articles/connectivity/serial-data-communications/rs232-eia-v24-standard.php>

With a hurting brain,
73 - Brendon
KK6AYI

On Mon, Feb 11, 2019 at 2:51 PM Michael Blake via Elecraft <
[hidden email]> wrote:

> Andy, in support of your comments I was an active Bell System DATEC
> representative back in the 70s and 80s and multipoint polled RS-232 was
> very common here in the colonies :)
>
> Michael Blake
> [hidden email] <mailto:[hidden email]>
>
>
>
>
>
>
> > On Feb 11, 2019, at 4:54 PM, Andy McMullin <[hidden email]> wrote:
> >
> > Not wishing to get into an argument but consider Binary-Synch, Uniscope
> or UTS400 protocols. They are poll and response, RS232c communications
> systems. Used from mainframe to (dumb) terminal. They are synchronous RS232
> of course rather than asynch and so use the clock and other signals ignored
> by the [IBM PC] cut down implementation of the RS232 connector. RS232 of
> course only defining the names and voltages on the connector.
> >
> > From memory a Uniscope (U100) “poll” from the mainframe would be the
> characters: sync, sync, sync, sync, SOH, RID, SID, DID, STX, text, ETX,
> BCC.
> >
> > Now that was dug out of the 1970’s if nothing was!
> >
> > Andy, G8TQH
> >
> >> On 11 Feb 2019, at 21:35, Don Wilhelm <[hidden email] <mailto:
> [hidden email]>> wrote:
> >>
> >> Andy,
> >>
> >> "Polling" normally refers to a situation like Ethernet and others where
> a response from a particular *addressed* device is requested.
> >> For RS-232, it is "handshaking" (if implemented) telling the DTE when
> it is OK to send data - since there is only one transmitter on an RS-232
> signalling line, there is no need for addressing. The transmitting device
> expects to communicate to only one receiving device on the other end
> (although other receivers can 'listen in'.
> >>
> >> I have worked with RS-232 for over 35 years both professionally (both
> modems and DCEs for 20 years) and with ham radio gear and PCs after
> retirement from that life.
> >>
> >> If we wish for clear communication, the terms used are important. Ham
> Radio "speak" often confuses the proper engineering terms. You hear of ham
> radio software that "polls" the radio - in reality, it is simply issuing a
> command to the radio and expects a response to that command. That is a
> command/response scenerio, and is not really polling.
> >>
> >> Don W3FPR
> >>
> >> On 2/11/2019 3:55 PM, Andy Durbin wrote:
> >>> "I have no idea how your "polling" device works, but with RS-232,
> thereis no polling, "
> >>>
> >>> Point 1 is true. Point 2 is, in my opinion, not true.
> >>>
> >>> A poll is a request for information. The device issuing the
> poll/request is the polling device. For example, sending IF; to a TS-590
> is a data request, or poll, for the current IF status. The TS-590 responds
> with the full IF word.
> >>>
> >>> Andy, k3wyc
> >>>
> >>>
> >>
> >> ______________________________________________________________
> >> Elecraft mailing list
> >> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> >> Help: http://mailman.qth.net/mmfaq.htm
> >> Post: mailto:[hidden email]
> >>
> >> This list hosted by: http://www.qsl.net
> >> Please help support this email list: http://www.qsl.net/donate.html
> >> Message delivered to [hidden email] <mailto:[hidden email]>
> >
> >
> > ______________________________________________________________
> > Elecraft mailing list
> > Home: http://mailman.qth.net/mailman/listinfo/elecraft <
> http://mailman.qth.net/mailman/listinfo/elecraft>
> > Help: http://mailman.qth.net/mmfaq.htm <http://mailman.qth.net/mmfaq.htm
> >
> > Post: mailto:[hidden email] <mailto:[hidden email]>
> >
> > This list hosted by: http://www.qsl.net <http://www.qsl.net/>
> > Please help support this email list: http://www.qsl.net/donate.html <
> http://www.qsl.net/donate.html>
> > Message delivered to [hidden email] <mailto:[hidden email]>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]

ANDY DURBIN

KPA500 serial interfaces

In reply to this post by ANDY DURBIN

"The talk of sharing connections with boxes that multiplex over an RS232 connection led me to find the products that speak SDLC to a device that then communicates with a set of RS232 devices. I hardly think that is the same thing, since although a single RS232 is required on the computer, it is not speaking directly to the devices on the other end."

Don't know if this is related to the description of my interface but, in case it was, here is a bit more detail:

I use a relay to switch between 2 different RS232 transmitters. One is the routine interrogator of the RS232 receiver, the other is switched in circuit when I want to send a non-routine command to the receiver. The receiver doesn't know where the command came from and it doesn't care. The routine interrogator doesn't know it was taken out of circuit because the TX line is only stolen in a gap between its routine interrogations.

As an example - I can configure my system so the KAT500 Utility is the routine interrogator of my KAT500. When I change my TX frequency my controller switches the RS232 transmit source from the PC to my Arduino which sends the KAT500 a new frequency. That frequency command is in a gap between the routing KAT500 Utility interrogations.

My interface actually has 3 multiplexing relays - one for the KAT500 interrogator (KAT500 Util or my interface), one for the KPA500 interrogator (KPA500 Util or my interface), and one for my TS-590 interrogator (OmniRIg or my interface).

Works perfectly and, to the best of my knowledge, no RS232 standards were damaged.

(I wrote all of that without a single mention of "polling").

Andy, k3wyc

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

W2xj

Re: KPA500 serial interfaces

In reply to this post by Brendon Whateley

As is often the case on reflectors, things often drift of the main topic. RS232, 422. , and RS485 are among a number of electrical specifications that permits the transmission of serial data. While each has certain inherent limitations due to the electrical specification, it is really how the software involved implements the interface can be utilized.

Sent from my iPad

> On Feb 16, 2019, at 7:29 PM, Brendon Whateley <[hidden email]> wrote:
>
> I always worry about what I don't know with this kind of discussion that
> seems to dive into entrenched positions of pedantic certainty. Since I love
> my KX3 and other Elecraft products, as well as various microcontrollers, I
> was concerned that I'd missed something about RS232 which I've used for
> decades. So I did a little research. And let me tell you there is so much
> information out there that a pedant can basically shut down any discussion
> as being inaccurate! Don't dare talk about DB9 connectors on equipment
> because you probably mean DE-9P!
>
> Reading the RS232 standard(s), it is clear that any multi-point
> implementations are not technically RS232 compliant and require
> non-standard wiring and/or software and hardware support that is not in the
> specification. Directly connecting standard's compliant equipment will be
> hit and miss and could damage some devices - strict compliance to RS232 is
> short-circuit protected between pin pairs, but many devices are "sort-of"
> compliant. But if you control all sides, then proprietary implementations
> could be easily done. Again, that would not technically comply with the
> standard. On the other hand, RS232 and RS423 support a multi-drop (multiple
> listeners, one sender) format in some cases, which only allows 1 bus driver
> and up to 10 receivers.
>
> BUT. There have been many variations over the years, along with
> similar-seeming RS485 which is multi-drop. RS485 is wired in a similar way
> but is a current loop interface instead of voltage based. I also found
> RS422 which is a long distance "drop-in-replacement" for RS232 and that has
> a multi-drop version, but there seem to be so many different flavors of
> wiring, it may as well be proprietary at that point.
>
> I've found and reviewed a few dozen of the many, many specifications for
> serial communications that are similar to RS232 and can find none that fit
> the impression some of the earlier posts gave of having multiple devices
> communicating back-and-forth on the same physical RS232 connection. The
> talk of sharing connections with boxes that multiplex over an RS232
> connection led me to find the products that speak SDLC to a device that
> then communicates with a set of RS232 devices. I hardly think that is the
> same thing, since although a single RS232 is required on the computer, it
> is not speaking directly to the devices on the other end.
>
> I looked up the Bisync protocol as well as the Uniscope equipment. It looks
> like although they did use what is called RS232 connectors and wiring, they
> did not follow the specification, so standards complient RS232 devices
> wouldn't work in a multi-drop setting.
>
> In summary, it seems that a degree of liberty in the use of the terms and
> standards results in confusion and folks arguing across each other. There
> is a large difference between what might be possible over wiring that
> otherwise conforms to RS232 but is unrelated to the standard which is a
> point-to-point standard for linking two devices. Then if you overlay
> proprietary protocols as used by Uniscope, IBM, et.al along with the many
> almost RS232 standards and we get the situation where some insist that
> RS232 supports multi-point networking while others claim it doesn't. I
> think the bottom line is that any fancy connections (beyond what Elecraft
> specifies) between Elecraft devices will need additional software and/or
> hardware to support.
>
> Some of the references I used:
>
> - RS232 connectors and wiring
> <http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm>
> - IIT course on Serial Communications
> <https://nptel.ac.in/courses/Webcourse-contents/IIT%20Kharagpur/Embedded%20systems/Pdf/Lesson-25.pdf>
> - Blackbox RS232 connection sharing devices
> <https://az849230.vo.msecnd.net/resources/10920_20100.pdf>
> - IBM SDLC protocol concepts
> <http://www.textfiles.com/bitsavers/pdf/ibm/datacomm/GA27-3093-3_SDLC_Concepts_Jun86.pdf>
> - IBM SDLC communications adapter manual
> <http://minuszerodegrees.net/oa/OA%20-%20IBM%20SDLC%20Adapter.pdf>
> - List of some Network Bus standards
> <https://en.wikipedia.org/wiki/List_of_network_buses>
> - EIA RS232 V24 standard
> <https://www.electronics-notes.com/articles/connectivity/serial-data-communications/rs232-eia-v24-standard.php>
>
> With a hurting brain,
> 73 - Brendon
> KK6AYI
>
> On Mon, Feb 11, 2019 at 2:51 PM Michael Blake via Elecraft <
> [hidden email]> wrote:
>
>> Andy, in support of your comments I was an active Bell System DATEC
>> representative back in the 70s and 80s and multipoint polled RS-232 was
>> very common here in the colonies :)
>>
>> Michael Blake
>> [hidden email] <mailto:[hidden email]>
>>
>>
>>
>>
>>
>>
>>> On Feb 11, 2019, at 4:54 PM, Andy McMullin <[hidden email]> wrote:
>>>
>>> Not wishing to get into an argument but consider Binary-Synch, Uniscope
>> or UTS400 protocols. They are poll and response, RS232c communications
>> systems. Used from mainframe to (dumb) terminal. They are synchronous RS232
>> of course rather than asynch and so use the clock and other signals ignored
>> by the [IBM PC] cut down implementation of the RS232 connector. RS232 of
>> course only defining the names and voltages on the connector.
>>>
>>> From memory a Uniscope (U100) “poll” from the mainframe would be the
>> characters: sync, sync, sync, sync, SOH, RID, SID, DID, STX, text, ETX,
>> BCC.
>>>
>>> Now that was dug out of the 1970’s if nothing was!
>>>
>>> Andy, G8TQH
>>>
>>>> On 11 Feb 2019, at 21:35, Don Wilhelm <[hidden email] <mailto:
>> [hidden email]>> wrote:
>>>>
>>>> Andy,
>>>>
>>>> "Polling" normally refers to a situation like Ethernet and others where
>> a response from a particular *addressed* device is requested.
>>>> For RS-232, it is "handshaking" (if implemented) telling the DTE when
>> it is OK to send data - since there is only one transmitter on an RS-232
>> signalling line, there is no need for addressing. The transmitting device
>> expects to communicate to only one receiving device on the other end
>> (although other receivers can 'listen in'.
>>>>
>>>> I have worked with RS-232 for over 35 years both professionally (both
>> modems and DCEs for 20 years) and with ham radio gear and PCs after
>> retirement from that life.
>>>>
>>>> If we wish for clear communication, the terms used are important. Ham
>> Radio "speak" often confuses the proper engineering terms. You hear of ham
>> radio software that "polls" the radio - in reality, it is simply issuing a
>> command to the radio and expects a response to that command. That is a
>> command/response scenerio, and is not really polling.
>>>>
>>>> Don W3FPR
>>>>
>>>>> On 2/11/2019 3:55 PM, Andy Durbin wrote:
>>>>> "I have no idea how your "polling" device works, but with RS-232,
>> thereis no polling, "
>>>>>
>>>>> Point 1 is true. Point 2 is, in my opinion, not true.
>>>>>
>>>>> A poll is a request for information. The device issuing the
>> poll/request is the polling device. For example, sending IF; to a TS-590
>> is a data request, or poll, for the current IF status. The TS-590 responds
>> with the full IF word.
>>>>>
>>>>> Andy, k3wyc
>>>>
>>>> ______________________________________________________________
>>>> Elecraft mailing list
>>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>>>> Help: http://mailman.qth.net/mmfaq.htm
>>>> Post: mailto:[hidden email]
>>>>
>>>> This list hosted by: http://www.qsl.net
>>>> Please help support this email list: http://www.qsl.net/donate.html
>>>> Message delivered to [hidden email] <mailto:[hidden email]>
>>>
>>>
>>> ______________________________________________________________
>>> Elecraft mailing list
>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft <
>> http://mailman.qth.net/mailman/listinfo/elecraft>
>>> Help: http://mailman.qth.net/mmfaq.htm <http://mailman.qth.net/mmfaq.htm
>>>
>>> Post: mailto:[hidden email] <mailto:[hidden email]>
>>>
>>> This list hosted by: http://www.qsl.net <http://www.qsl.net/>
>>> Please help support this email list: http://www.qsl.net/donate.html <
>> http://www.qsl.net/donate.html>
>>> Message delivered to [hidden email] <mailto:[hidden email]>
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:[hidden email]
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to [hidden email]
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]