Re: [Elecraft] KPA500 serial interfaces

[W2xj]

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  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
>   
>   - IIT course on Serial Communications
>   
> 
>   - Blackbox RS232 connection sharing devices
>   
>   - IBM SDLC protocol concepts
>   
> 
>   - IBM SDLC communications adapter manual
>   
>   - List of some Network Bus standards
>   
>   - EIA RS232 V24 standard
>   
> 
> 
> With a hurting brain,
> 73 - Brendon
> KK6AYI
> 
> On Mon, Feb 11, 2019 at 2:51 PM Michael Blake via Elecraft <
> elecraft@mailman.qth.net> wrote:
> 
>> Andy, in support of your comments I was an 

[Elecraft] KPA500 serial interfaces

[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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Brendon Whateley]

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
   
   - IIT course on Serial Communications
   

   - Blackbox RS232 connection sharing devices
   
   - IBM SDLC protocol concepts
   

   - IBM SDLC communications adapter manual
   
   - List of some Network Bus standards
   
   - EIA RS232 V24 standard
   


With a hurting brain,
73 - Brendon
KK6AYI

On Mon, Feb 11, 2019 at 2:51 PM Michael Blake via Elecraft <
elecraft@mailman.qth.net> 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
> k9...@mac.com 
>
>
>
>
>
>
> > On Feb 11, 2019, at 4:54 PM, Andy McMullin  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] 

Re: [Elecraft] KPA500 serial interfaces

[Michael Blake via Elecraft]

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
k9...@mac.com 






> On Feb 11, 2019, at 4:54 PM, Andy McMullin  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 > > 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:Elecraft@mailman.qth.net
>> 
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to a...@rickham.net 
> 
> 
> __
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft 
> 
> Help: http://mailman.qth.net/mmfaq.htm 
> Post: mailto:Elecraft@mailman.qth.net 
> 
> This list hosted by: http://www.qsl.net 
> Please help support this email list: http://www.qsl.net/donate.html 
> 
> Message delivered to k9...@mac.com 
__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Andy McMullin]

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  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:Elecraft@mailman.qth.net
> 
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to a...@rickham.net


__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Don Wilhelm]

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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Doug Person]

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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to d...@kj0f.com


--
73 de Doug -- KJ0F

__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Andy Durbin]

"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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Don Wilhelm]

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 (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.


__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Andy Durbin]

 "The Serial 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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Bob Wilson, N6TV]

On Sat, Feb 9, 2019 at 10:51 AM Andy Durbin  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  (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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Andy Durbin]

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 
Sent: Saturday, February 9, 2019 10:39 AM
To: Andy Durbin
Cc: elecraft@mailman.qth.net
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


> On Feb 9, 2019, at 8:56 AM, Andy Durbin  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:Elecraft@mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to jackbrin...@me.com

__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

Re: [Elecraft] KPA500 serial interfaces

[Jack Brindle via Elecraft]

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  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:Elecraft@mailman.qth.net
> 
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to jackbrin...@me.com

__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com

[Elecraft] KPA500 serial interfaces

[Andy Durbin]

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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com