Elecraft

Advice needed: Remote Station Enhancement

Classic

List

Threaded

30 messages Options

Dennis Ashworth-2

Advice needed: Remote Station Enhancement

I’ve been remoting my K3, KPA500, KAT500 station via the RemoteRig boxes and K3/0 mini for two years with solid results. Later this year, I want to make several enhancements, including the replacement of the KPA500 and KAT500 with a KPA1500. The amp/tuner should be a fairly straightforward hardware replacement, but it does necessitate a few station changes which I’m not certain how to implement. Let me explain and hopefully the masses have ideas/approaches for consideration.

1. I feed a HyTower vertical (optimized for 40M & 80M) on all bands. Where the driving impedance is close to 50 ohms on 40M & 80 (my bands of interest) there has been no attempt to match the HyTower on other bands. With the KAT500, matching was not a problem and I reduced mismatch losses on the feed line by using hardline from the in-shack tuner to the antenna.

When I switch to the KPA1500, operation on the unmatched bands might prove problematic. To address this, I plan to provide switchable matching networks to transform the HyTower drive impedance on each band to something the KPA1500 can match. I can design the required impedance transformation networks, but not sure how to automatically select the various (relay based) impedance networks required for each band. Clearly, I need to grab band data from the K3, but what’s the best hardware to use for this task?

BTW, I want to power the KPA1500 ON with the K3, which requires a Y-cable modification, or perhaps one of the N6TV boxes?

2. I want to interface a K9AY RX antenna 4 position switch to some sort of UI that I can access remotely. I can design an electrical interface to the K9AY switch, but controlling and monitoring remotely is the issue. Ideas?

3. I have a Windows computer available at each end of the radio circuit. The only other hardware is a SignalLink used for digital mods.

4. Configuring the station for future antenna enhancements (e.g. SteppIR if we live long enough to see sunspots return!) are great if they come without significant reliability impacts.

Any ideas how to accomplish the required switching/monitoring?

Thanks
Dennis, K7FL
Currently in Panama City, Florida
Station in Battle Ground, WA

Sent from my iPad
______________________________________________________________
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]

Mark Goldberg

Re: Advice needed: Remote Station Enhancement

Are you sure the KPA1500 will not be able to tune your antennas? It
includes a tuner, and I would expect it to be capable.

I have been using Arduinos to control things, as they have lots of I/O and
appear to the computer as a USB serial port. Those serial ports can be
remoted via software, although I have not done it. I write simple software
that takes commands over the USB serial port and replies with a response.
See an example at

https://sites.google.com/site/spectrumlabtesting/home/usb-controlled-rf-switch

Maybe you can modify it to control something else. There are Arduinos with
multiple serial ports and lots more I/O that may be useful too. If you have
not tried it, programming an Arduino is not that hard and there are plenty
of examples out there to do almost anything you can think of.

I can't help much with the other stuff, as I have a KPA500 but none of the
other stuff you listed.

73,

Mark
W7MLG

On Sun, Feb 25, 2018 at 2:50 PM, Dennis Ashworth <[hidden email]
> wrote:

> I’ve been remoting my K3, KPA500, KAT500 station via the RemoteRig boxes
> and K3/0 mini for two years with solid results. Later this year, I want to
> make several enhancements, including the replacement of the KPA500 and
> KAT500 with a KPA1500. The amp/tuner should be a fairly straightforward
> hardware replacement, but it does necessitate a few station changes which
> I’m not certain how to implement. Let me explain and hopefully the masses
> have ideas/approaches for consideration.
>
> 1. I feed a HyTower vertical (optimized for 40M & 80M) on all bands. Where
> the driving impedance is close to 50 ohms on 40M & 80 (my bands of
> interest) there has been no attempt to match the HyTower on other bands.
> With the KAT500, matching was not a problem and I reduced mismatch losses
> on the feed line by using hardline from the in-shack tuner to the antenna.
>
> When I switch to the KPA1500, operation on the unmatched bands might prove
> problematic. To address this, I plan to provide switchable matching
> networks to transform the HyTower drive impedance on each band to something
> the KPA1500 can match. I can design the required impedance transformation
> networks, but not sure how to automatically select the various (relay
> based) impedance networks required for each band. Clearly, I need to grab
> band data from the K3, but what’s the best hardware to use for this task?
>
> BTW, I want to power the KPA1500 ON with the K3, which requires a Y-cable
> modification, or perhaps one of the N6TV boxes?
>
> 2. I want to interface a K9AY RX antenna 4 position switch to some sort of
> UI that I can access remotely. I can design an electrical interface to the
> K9AY switch, but controlling and monitoring remotely is the issue. Ideas?
>
> 3. I have a Windows computer available at each end of the radio circuit.
> The only other hardware is a SignalLink used for digital mods.
>
> 4. Configuring the station for future antenna enhancements (e.g. SteppIR
> if we live long enough to see sunspots return!) are great if they come
> without significant reliability impacts.
>
> Any ideas how to accomplish the required switching/monitoring?
>
> Thanks
> Dennis, K7FL
> Currently in Panama City, Florida
> Station in Battle Ground, WA
>
>
>
>
>
> Sent from my iPad
> ______________________________________________________________
> 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]

Dave Hachadorian-2

Re: Advice needed: Remote Station Enhancement

In reply to this post by Dennis Ashworth-2

For a band decoder, I like the Unified Microsystems device:
http://www.unifiedmicro.com/decoder.html

To use this device, you would put +12 VDC on all the relay coils, and the decoder would ground the appropriate relay to pull it in. I would use cat 6 cable for the run out to the relays, with ground/signal on each twisted pair.

Dave Hachadorian, K6LL
Yuma, AZ

-----Original Message-----
From: Dennis Ashworth
Sent: Sunday, February 25, 2018 2:50 PM
To: [hidden email]
Subject: [Elecraft] Advice needed: Remote Station Enhancement

I’ve been remoting my K3, KPA500, KAT500 station via the RemoteRig boxes and K3/0 mini for two years with solid results. Later this year, I want to make several enhancements, including the replacement of the KPA500 and KAT500 with a KPA1500. The amp/tuner should be a fairly straightforward hardware replacement, but it does necessitate a few station changes which I’m not certain how to implement. Let me explain and hopefully the masses have ideas/approaches for consideration.

1. I feed a HyTower vertical (optimized for 40M & 80M) on all bands. Where the driving impedance is close to 50 ohms on 40M & 80 (my bands of interest) there has been no attempt to match the HyTower on other bands. With the KAT500, matching was not a problem and I reduced mismatch losses on the feed line by using hardline from the in-shack tuner to the antenna.

When I switch to the KPA1500, operation on the unmatched bands might prove problematic. To address this, I plan to provide switchable matching networks to transform the HyTower drive impedance on each band to something the KPA1500 can match. I can design the required impedance transformation networks, but not sure how to automatically select the various (relay based) impedance networks required for each band. Clearly, I need to grab band data from the K3, but what’s the best hardware to use for this task?

BTW, I want to power the KPA1500 ON with the K3, which requires a Y-cable modification, or perhaps one of the N6TV boxes?

2. I want to interface a K9AY RX antenna 4 position switch to some sort of UI that I can access remotely. I can design an electrical interface to the K9AY switch, but controlling and monitoring remotely is the issue. Ideas?

3. I have a Windows computer available at each end of the radio circuit. The only other hardware is a SignalLink used for digital mods.

4. Configuring the station for future antenna enhancements (e.g. SteppIR if we live long enough to see sunspots return!) are great if they come without significant reliability impacts.

Any ideas how to accomplish the required switching/monitoring?

Thanks
Dennis, K7FL
Currently in Panama City, Florida
Station in Battle Ground, WA

Sent from my iPad
______________________________________________________________
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]

Jack Brindle-2

Re: Advice needed: Remote Station Enhancement

Interesting idea, but I would talk to N6TV before going too far down this path. The reason is the introduction of +12V on the Band lines will cause issues in the KPA500 and KAT500. There is a series-connected 220 ohm protection resistor in the K3’s Band signals. When +12V is placed on the band lines, the band voltage no longer is allowed to go below the TTL threshold needed by the KPA and KAT. N6TV has taken a good look at this, and may have a good solution for driving the UM decoder in this setup.

There are other decoders that use standard TTL voltage levels that work very well. These include the Elecraft KRC2, the Top-Ten Devices Band Aide decoder, The YCCC MOAS (which may be overkill for this use) and several others that are also very good.

73!

Jack, W6FB

> On Feb 25, 2018, at 2:09 PM, Dave Hachadorian <[hidden email]> wrote:
>
> For a band decoder, I like the Unified Microsystems device:
> http://www.unifiedmicro.com/decoder.html
>
> To use this device, you would put +12 VDC on all the relay coils, and the decoder would ground the appropriate relay to pull it in. I would use cat 6 cable for the run out to the relays, with ground/signal on each twisted pair.
>
>
> Dave Hachadorian, K6LL
> Yuma, AZ
>
>
> -----Original Message-----
> From: Dennis Ashworth
> Sent: Sunday, February 25, 2018 2:50 PM
> To: [hidden email]
> Subject: [Elecraft] Advice needed: Remote Station Enhancement
>
> I’ve been remoting my K3, KPA500, KAT500 station via the RemoteRig boxes and K3/0 mini for two years with solid results. Later this year, I want to make several enhancements, including the replacement of the KPA500 and KAT500 with a KPA1500. The amp/tuner should be a fairly straightforward hardware replacement, but it does necessitate a few station changes which I’m not certain how to implement. Let me explain and hopefully the masses have ideas/approaches for consideration.
>
> 1. I feed a HyTower vertical (optimized for 40M & 80M) on all bands. Where the driving impedance is close to 50 ohms on 40M & 80 (my bands of interest) there has been no attempt to match the HyTower on other bands. With the KAT500, matching was not a problem and I reduced mismatch losses on the feed line by using hardline from the in-shack tuner to the antenna.
>
> When I switch to the KPA1500, operation on the unmatched bands might prove problematic. To address this, I plan to provide switchable matching networks to transform the HyTower drive impedance on each band to something the KPA1500 can match. I can design the required impedance transformation networks, but not sure how to automatically select the various (relay based) impedance networks required for each band. Clearly, I need to grab band data from the K3, but what’s the best hardware to use for this task?
>
> BTW, I want to power the KPA1500 ON with the K3, which requires a Y-cable modification, or perhaps one of the N6TV boxes?
>
> 2. I want to interface a K9AY RX antenna 4 position switch to some sort of UI that I can access remotely. I can design an electrical interface to the K9AY switch, but controlling and monitoring remotely is the issue. Ideas?
>
> 3. I have a Windows computer available at each end of the radio circuit. The only other hardware is a SignalLink used for digital mods.
>
> 4. Configuring the station for future antenna enhancements (e.g. SteppIR if we live long enough to see sunspots return!) are great if they come without significant reliability impacts.
>
> Any ideas how to accomplish the required switching/monitoring?
>
> Thanks
> Dennis, K7FL
> Currently in Panama City, Florida
> Station in Battle Ground, WA
>
>
>
>
>
> Sent from my iPad
> ______________________________________________________________
> 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]

Ken K6MR-3

Re: Advice needed: Remote Station Enhancement

The UM decoders don’t put 12V on the input side. They have optoisolators on the input side that can be driven directly from the K3 without interfering with the KPA/KAT setups. I’ve got several in my setup and they work great. The outputs are active low, so if you have high side driven relays you need their high side driver board also.

Ken K6MR

From: Jack Brindle
Sent: Sunday, February 25, 2018 14:42
To: Reflector Elecraft
Subject: Re: [Elecraft] Advice needed: Remote Station Enhancement

Interesting idea, but I would talk to N6TV before going too far down this path. The reason is the introduction of +12V on the Band lines will cause issues in the KPA500 and KAT500. There is a series-connected 220 ohm protection resistor in the K3’s Band signals. When +12V is placed on the band lines, the band voltage no longer is allowed to go below the TTL threshold needed by the KPA and KAT. N6TV has taken a good look at this, and may have a good solution for driving the UM decoder in this setup.

There are other decoders that use standard TTL voltage levels that work very well. These include the Elecraft KRC2, the Top-Ten Devices Band Aide decoder, The YCCC MOAS (which may be overkill for this use) and several others that are also very good.

73!

Jack, W6FB

______________________________________________________________
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]

AC6SL

Re: Advice needed: Remote Station Enhancement

I had difficulty with the Unified Microsystems BCD-14, i.e. the CMOS
inverter IC was overheating.

I eventually received the following advice from AB3CV, which I found to work.

-John AC6SL

From: Jim Miller <[hidden email]>
Date: Sat, Dec 26, 2015 at 7:06 PM
Subject: Re: [Elecraft] K3 and Band Data
To: John Nogatch <[hidden email]>

My BCD14 purchased this summer was unreliable as well. If you look at
the K3 (or K3s...the same) the Band Data outputs are open collector
pulled up by 2.2K in series with 200ohms. I knew this could be a
problem with anything which wasn't properly buffered so I looked at
the BCD14 schematic. I found the BCD-14 online schematic differed from
the unit I had after inspection with a ohm meter and magnifying glass.

I probed my unit and found the optoisolators on my board had a current
transfer ratio insufficient to drive the decode chip input to a proper
logic low level when used with its supplied collector resistor and
driven by the K3s' modest pull up. After some discussion with the
supplier I changed the collector resistors to 33K and it works
perfectly now. The dark current on the optoisolator and the input bias
current on the decoder are insignificant making this resistor change
possible.

The improper logic levels on the board could easily result in
operating in the linear zone and oscillate as a result.

Good luck

jim ab3cv
______________________________________________________________
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: Advice needed: Remote Station Enhancement

John and all,

This is a problem caused by the "way things work".
The original K3 did not have pullup resistors on the band data lines
(correct by engineering practices, the pullup resistors should be in the
receiving device).
BUT as a concession to those band decoders did not implement pullup
resistors in their decoders, Elecraft got a lot of "flack" because the
K3 did not work with those decoders.

As a result Elecraft added pullup resistors in the K3. However those
pullup resistors only work with devices which will respond to the +5
volt high level.

There are some band decoders that DO provide pullup resistors, and some
of them tie the pullup resistors to +12 volts. Those band decoders will
not work with the K3/K3S unless the pullup resistors in the band
decoders are removed AND that the band decoder will respond to a +5 volt
level for the logic high. The result is that the K3 and band decoder
"fight" for the logic high level.

IMHO, the original K3 design "did it right", and the problem lies with
the band decoders. The K3 addition of the internal pullup resistors
caused problems with all except those band decoders that did not have
internal pullup resistors.

73,
Don W3FPR

On 2/25/2018 9:08 PM, John Nogatch wrote:

> I had difficulty with the Unified Microsystems BCD-14, i.e. the CMOS
> inverter IC was overheating.
>
> I eventually received the following advice from AB3CV, which I found to work.
>
> -John AC6SL
>
>
> From: Jim Miller <[hidden email]>
> Date: Sat, Dec 26, 2015 at 7:06 PM
> Subject: Re: [Elecraft] K3 and Band Data
> To: John Nogatch <[hidden email]>
>
>
> My BCD14 purchased this summer was unreliable as well. If you look at
> the K3 (or K3s...the same) the Band Data outputs are open collector
> pulled up by 2.2K in series with 200ohms. I knew this could be a
> problem with anything which wasn't properly buffered so I looked at
> the BCD14 schematic. I found the BCD-14 online schematic differed from
> the unit I had after inspection with a ohm meter and magnifying glass.
>

ab2tc

Re: Advice needed: Remote Station Enhancement

Hi Don and all,

Hear,hear, Don. The receivers should have the pullup resistor to whatever
the appropriate voltage needed (within reason) *and* a steering diode in
series with the input. This will prevent another device with a higher
voltage from feeding current back into the device which could damage
semiconductors. Without the steering diode all receivers must use the same
pullup voltage. Of course a single receiver is not a problem either.

AB2TC - Knut

--
Sent from: http://elecraft.365791.n2.nabble.com/
______________________________________________________________
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: Advice needed: Remote Station Enhancement

Knut,

That is the way it *should* be, and was that way in the K3 originally.
But many (most) ham devices do not do it that way, they expect the
pullup resistors will be provided by the driver gear.
So, because of that, Elecraft added pullup resistors to the band data
outputs of the K3 long ago.
So yes, we are left with a situation that often requires steering diodes.

73,
Don W3FPR

On 2/27/2018 3:48 PM, ab2tc wrote:
> Hi Don and all,
>
> Hear,hear, Don. The receivers should have the pullup resistor to whatever
> the appropriate voltage needed (within reason) *and* a steering diode in
> series with the input. This will prevent another device with a higher
> voltage from feeding current back into the device which could damage
> semiconductors. Without the steering diode all receivers must use the same
> pullup voltage. Of course a single receiver is not a problem either.
______________________________________________________________
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]

Joe Subich, W4TV-4

Re: Advice needed: Remote Station Enhancement

> But many (most) ham devices do not do it that way, they expect the
> pullup resistors will be provided by the driver gear.

Actually, most devices that use BCD "band data" expect an open
emitter driver not an open collector driver. Open emitter will
*source* voltage for logic high and be open circuit for logic
low. This is the convention from the early Yaesu rigs which
were the first devices to support "band data" (it is the way
the FL-7000 and Quadra amplifiers operate).

You will find the W9XT BCD10/BCD14 decoders with their opto-isolator
inputs work just fine with the "open emitter" drivers. Other devices
designed with Yaesu transceivers in mind have appropriate current
limiting (series) on the input lines and "pull down" (parallel)
resistors on the logic gates. Some "standard" devices (Top Ten
BD-Y and the original microHAM Band Decoder) will provide both
current limiting resistors and internal pull-ups but I have not
seen any amateur product with series diodes in the band data lines.

73,

... Joe, W4TV

On 2/27/2018 4:17 PM, Don Wilhelm wrote:

> Knut,
>
> That is the way it *should* be, and was that way in the K3 originally.
> But many (most) ham devices do not do it that way, they expect the
> pullup resistors will be provided by the driver gear.
> So, because of that, Elecraft added pullup resistors to the band data
> outputs of the K3 long ago.
> So yes, we are left with a situation that often requires steering diodes.
>
>
> 73,
> Don W3FPR
>
> On 2/27/2018 3:48 PM, ab2tc wrote:
>> Hi Don and all,
>>
>> Hear,hear, Don. The receivers should have the pullup resistor to whatever
>> the appropriate voltage needed (within reason) *and* a steering diode in
>> series with the input. This will prevent another device with a higher
>> voltage from feeding current back into the device which could damage
>> semiconductors. Without the steering diode all receivers must use the
>> same
>> pullup voltage. Of course a single receiver is not a problem either.
> ______________________________________________________________
> 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: Advice needed: Remote Station Enhancement

The problem is that most devices (in the ham world) expect the driver
device to provide voltage.
In the communications (non-ham) world, the expectation is that the
driver device produces either a logic low (short to common) or a logic
high ( open circuit).

Look at the data sheets for "line drivers" and "line receivers" to check
out what I am saying.

Open collector or open emitter does not make a difference in function,
it is only a circuit design decision. Yes, open Collector (or open
drain) is commonly use in logic where the active state is zero volts
(transistor or FET conducting to ground).
The open emitter design is the opposite. A conducting device will
provide a voltage on the line (or signal) being driven.

The point is that in a properly designed communications system, the
drivers provide either conduction to ground or an essentially open
circuit to the communications line (think of a relay being either open
or closed). The receiver provides the voltage to detect whether the
driver is in an open circuit or closed circuit state.
If there are multiple receivers in the system, only one can be "boss",
and that one determines the open circuit voltage and contains the pullup
resistors for the system. Other receivers work in listen mode and will
contain no pullup resistors or active drivers.

This whole situation goes back to the "one driver, one receiver"
condition.
Only one driver can exist on a communications system without conflict.
Multiple receivers are possible, but only one (at the far end of the
line) should provide the pullup resistors. All other receivers must be
only in the listen mode.

73,
Don W3FPR

On 2/27/2018 8:06 PM, Joe Subich, W4TV wrote:

>
> > But many (most) ham devices do not do it that way, they expect the
> > pullup resistors will be provided by the driver gear.
>
> Actually, most devices that use BCD "band data" expect an open
> emitter driver not an open collector driver. Open emitter will
> *source* voltage for logic high and be open circuit for logic
> low. This is the convention from the early Yaesu rigs which
> were the first devices to support "band data" (it is the way
> the FL-7000 and Quadra amplifiers operate).
>
> You will find the W9XT BCD10/BCD14 decoders with their opto-isolator
> inputs work just fine with the "open emitter" drivers. Other devices
> designed with Yaesu transceivers in mind have appropriate current
> limiting (series) on the input lines and "pull down" (parallel)
> resistors on the logic gates. Some "standard" devices (Top Ten
> BD-Y and the original microHAM Band Decoder) will provide both
> current limiting resistors and internal pull-ups but I have not
> seen any amateur product with series diodes in the band data lines.
>
> 73,
>
> ... Joe, W4TV
>
>
> On 2/27/2018 4:17 PM, Don Wilhelm wrote:
>> Knut,
>>
>> That is the way it *should* be, and was that way in the K3 originally.
>> But many (most) ham devices do not do it that way, they expect the
>> pullup resistors will be provided by the driver gear.
>> So, because of that, Elecraft added pullup resistors to the band data
>> outputs of the K3 long ago.
>> So yes, we are left with a situation that often requires steering diodes.
>>
>>
>> 73,
>> Don W3FPR
>>
>> On 2/27/2018 3:48 PM, ab2tc wrote:
>>> Hi Don and all,
>>>
>>> Hear,hear, Don. The receivers should have the pullup resistor to
>>> whatever
>>> the appropriate voltage needed (within reason) *and* a steering diode in
>>> series with the input. This will prevent another device with a higher
>>> voltage from feeding current back into the device which could damage
>>> semiconductors. Without the steering diode all receivers must use the
>>> same
>>> pullup voltage. Of course a single receiver is not a problem either.
>> ______________________________________________________________
>> 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]
>

Joe Subich, W4TV-4

Re: Advice needed: Remote Station Enhancement

You're dealing with a "standard" that was originally developed for use
only within one company's products - much like Elecraft's Aux Bus.

As such, any "industry standard" is moot. The design is for active
high/voltage source (to +12V originally) and was not intended for any
purpose than providing band switching for the FL-700 then the Quadra.
It would seem to me that any product that claims to inter-operate with
the Yaesu "Band Data" would emulate or at least be compatible with
that behavior - including the ability to *source* sufficient current
at +12V.

These devices are not operating in the "communications (non-ham) world",
they are strictly amateur products.

73,

... Joe, W4TV

On 2/27/2018 9:28 PM, Don Wilhelm wrote:

> The problem is that most devices (in the ham world) expect the driver
> device to provide voltage.
> In the communications (non-ham) world, the expectation is that the
> driver device produces either a logic low (short to common) or a logic
> high ( open circuit).
>
> Look at the data sheets for "line drivers" and "line receivers" to check
> out what I am saying.
>
> Open collector or open emitter does not make a difference in function,
> it is only a circuit design decision. Yes, open Collector (or open
> drain) is commonly use in logic where the active state is zero volts
> (transistor or FET conducting to ground).
> The open emitter design is the opposite. A conducting device will
> provide a voltage on the line (or signal) being driven.
>
> The point is that in a properly designed communications system, the
> drivers provide either conduction to ground or an essentially open
> circuit to the communications line (think of a relay being either open
> or closed). The receiver provides the voltage to detect whether the
> driver is in an open circuit or closed circuit state.
> If there are multiple receivers in the system, only one can be "boss",
> and that one determines the open circuit voltage and contains the pullup
> resistors for the system. Other receivers work in listen mode and will
> contain no pullup resistors or active drivers.
>
> This whole situation goes back to the "one driver, one receiver" condition.
> Only one driver can exist on a communications system without conflict.
> Multiple receivers are possible, but only one (at the far end of the
> line) should provide the pullup resistors. All other receivers must be
> only in the listen mode.
>
> 73,
> Don W3FPR
>
> On 2/27/2018 8:06 PM, Joe Subich, W4TV wrote:
>>
>> > But many (most) ham devices do not do it that way, they expect the
>> > pullup resistors will be provided by the driver gear.
>>
>> Actually, most devices that use BCD "band data" expect an open
>> emitter driver not an open collector driver. Open emitter will
>> *source* voltage for logic high and be open circuit for logic
>> low. This is the convention from the early Yaesu rigs which
>> were the first devices to support "band data" (it is the way
>> the FL-7000 and Quadra amplifiers operate).
>>
>> You will find the W9XT BCD10/BCD14 decoders with their opto-isolator
>> inputs work just fine with the "open emitter" drivers. Other devices
>> designed with Yaesu transceivers in mind have appropriate current
>> limiting (series) on the input lines and "pull down" (parallel)
>> resistors on the logic gates. Some "standard" devices (Top Ten
>> BD-Y and the original microHAM Band Decoder) will provide both
>> current limiting resistors and internal pull-ups but I have not
>> seen any amateur product with series diodes in the band data lines.
>>
>> 73,
>>
>> ... Joe, W4TV
>>
>>
>> On 2/27/2018 4:17 PM, Don Wilhelm wrote:
>>> Knut,
>>>
>>> That is the way it *should* be, and was that way in the K3 originally.
>>> But many (most) ham devices do not do it that way, they expect the
>>> pullup resistors will be provided by the driver gear.
>>> So, because of that, Elecraft added pullup resistors to the band data
>>> outputs of the K3 long ago.
>>> So yes, we are left with a situation that often requires steering
>>> diodes.
>>>
>>>
>>> 73,
>>> Don W3FPR
>>>
>>> On 2/27/2018 3:48 PM, ab2tc wrote:
>>>> Hi Don and all,
>>>>
>>>> Hear,hear, Don. The receivers should have the pullup resistor to
>>>> whatever
>>>> the appropriate voltage needed (within reason) *and* a steering
>>>> diode in
>>>> series with the input. This will prevent another device with a higher
>>>> voltage from feeding current back into the device which could damage
>>>> semiconductors. Without the steering diode all receivers must use
>>>> the same
>>>> pullup voltage. Of course a single receiver is not a problem either.
>>> ______________________________________________________________
>>> 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]
>>
>

Don Wilhelm

Re: Advice needed: Remote Station Enhancement

Joe,

You do admit that many amateur products do not conform to typical
communications standards in the digital world. My experience does go
back to my design and evaluation of IBM terminal communication between a
DCE and a DTE device. Although this was not necessarily RS-232 levels,
the same thing is true. The drivers provide the low and high levels to
the line (an open circuit or a ground) while the receiver at the far end
of the line provides the logic high level. All other receivers will not
provide voltage, but can listen in on the communication. This is not
consistent with amateur products with one providing pullup resistors ath
the driver location and some receive locations requiring the opposite
I.E, those providing pullup resistors to +12 volts.
THe point is that the two do not work together. It is not a systems
approach.

73,
Don W3FPR.

On 2/27/2018 10:09 PM, Joe Subich, W4TV wrote:

>
> You're dealing with a "standard" that was originally developed for use
> only within one company's products - much like Elecraft's Aux Bus.
>
> As such, any "industry standard" is moot. The design is for active
> high/voltage source (to +12V originally) and was not intended for any
> purpose than providing band switching for the FL-700 then the Quadra.
> It would seem to me that any product that claims to inter-operate with
> the Yaesu "Band Data" would emulate or at least be compatible with
> that behavior - including the ability to *source* sufficient current
> at +12V.
>
> These devices are not operating in the "communications (non-ham) world",
> they are strictly amateur products.
>
> 73,
>
> ... Joe, W4TV
>
>
> On 2/27/2018 9:28 PM, Don Wilhelm wrote:
>> The problem is that most devices (in the ham world) expect the driver
>> device to provide voltage.
>> In the communications (non-ham) world, the expectation is that the
>> driver device produces either a logic low (short to common) or a
>> logic high ( open circuit).
>>
>> Look at the data sheets for "line drivers" and "line receivers" to
>> check out what I am saying.
>>
>> Open collector or open emitter does not make a difference in
>> function, it is only a circuit design decision. Yes, open Collector
>> (or open drain) is commonly use in logic where the active state is
>> zero volts (transistor or FET conducting to ground).
>> The open emitter design is the opposite. A conducting device will
>> provide a voltage on the line (or signal) being driven.
>>
>> The point is that in a properly designed communications system, the
>> drivers provide either conduction to ground or an essentially open
>> circuit to the communications line (think of a relay being either
>> open or closed). The receiver provides the voltage to detect whether
>> the driver is in an open circuit or closed circuit state.
>> If there are multiple receivers in the system, only one can be
>> "boss", and that one determines the open circuit voltage and contains
>> the pullup resistors for the system. Other receivers work in listen
>> mode and will contain no pullup resistors or active drivers.
>>
>> This whole situation goes back to the "one driver, one receiver"
>> condition.
>> Only one driver can exist on a communications system without conflict.
>> Multiple receivers are possible, but only one (at the far end of the
>> line) should provide the pullup resistors. All other receivers must
>> be only in the listen mode.
>>
>> 73,
>> Don W3FPR
>>
>> On 2/27/2018 8:06 PM, Joe Subich, W4TV wrote:
>>>
>>> > But many (most) ham devices do not do it that way, they expect the
>>> > pullup resistors will be provided by the driver gear.
>>>
>>> Actually, most devices that use BCD "band data" expect an open
>>> emitter driver not an open collector driver. Open emitter will
>>> *source* voltage for logic high and be open circuit for logic
>>> low. This is the convention from the early Yaesu rigs which
>>> were the first devices to support "band data" (it is the way
>>> the FL-7000 and Quadra amplifiers operate).
>>>
>>> You will find the W9XT BCD10/BCD14 decoders with their opto-isolator
>>> inputs work just fine with the "open emitter" drivers. Other devices
>>> designed with Yaesu transceivers in mind have appropriate current
>>> limiting (series) on the input lines and "pull down" (parallel)
>>> resistors on the logic gates. Some "standard" devices (Top Ten
>>> BD-Y and the original microHAM Band Decoder) will provide both
>>> current limiting resistors and internal pull-ups but I have not
>>> seen any amateur product with series diodes in the band data lines.
>>>
>>> 73,
>>>
>>> ... Joe, W4TV
>>>
>>>
>>> On 2/27/2018 4:17 PM, Don Wilhelm wrote:
>>>> Knut,
>>>>
>>>> That is the way it *should* be, and was that way in the K3 originally.
>>>> But many (most) ham devices do not do it that way, they expect the
>>>> pullup resistors will be provided by the driver gear.
>>>> So, because of that, Elecraft added pullup resistors to the band
>>>> data outputs of the K3 long ago.
>>>> So yes, we are left with a situation that often requires steering
>>>> diodes.
>>>>
>>>>
>>>> 73,
>>>> Don W3FPR
>>>>
>>>> On 2/27/2018 3:48 PM, ab2tc wrote:
>>>>> Hi Don and all,
>>>>>
>>>>> Hear,hear, Don. The receivers should have the pullup resistor to
>>>>> whatever
>>>>> the appropriate voltage needed (within reason) *and* a steering
>>>>> diode in
>>>>> series with the input. This will prevent another device with a higher
>>>>> voltage from feeding current back into the device which could damage
>>>>> semiconductors. Without the steering diode all receivers must use
>>>>> the same
>>>>> pullup voltage. Of course a single receiver is not a problem either.
>>>> ______________________________________________________________
>>>> 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]
>>>
>>
>

Joe Subich, W4TV-4

Re: Advice needed: Remote Station Enhancement

> THe point is that the two do not work together.

The point is that the devices don't work together because the third
party manufacturers did not bother to understand the Yaesu design
and take the necessary steps to be compatible. Yaesu's only purpose
was to provide band switching data from the transceiver to a Yaesu
amplifier. Their was no reason to design their system according to
some inapplicable "standard" from the data processing world.

Third party manufacturers need only provide a low impedance source
of +12V for a logic high and open circuit for a logic low on the
"transmit" side to emulate the Yaesu transceiver.

On the receive side, any device that would connect to a Yaesu compatible
transceiver needs to tolerate +12V on the input and have a moderately
high (1 - 2K) pull down on any logic inputs (if it uses logic inputs);
opto-isolator inputs simply need the appropriate current limiting
resistors for 12V inputs (or +5V inputs given that many transceivers
have failed to provide +12V logic high outputs).

The bottom line is that this is not a "standards based" application.
If one is going to provide (or use) BCD "band data" the device must
closely emulate the Yaesu transceiver or clearly state that its
signaling levels are not [guaranteed] compatible with Yaesu.

73,

... Joe, W4TV

On 2/27/2018 10:53 PM, Don Wilhelm wrote:

> Joe,
>
> You do admit that many amateur products do not conform to typical
> communications standards in the digital world. My experience does go
> back to my design and evaluation of IBM terminal communication between a
> DCE and a DTE device. Although this was not necessarily RS-232 levels,
> the same thing is true. The drivers provide the low and high levels to
> the line (an open circuit or a ground) while the receiver at the far end
> of the line provides the logic high level. All other receivers will not
> provide voltage, but can listen in on the communication. This is not
> consistent with amateur products with one providing pullup resistors ath
> the driver location and some receive locations requiring the opposite
> I.E, those providing pullup resistors to +12 volts.
> THe point is that the two do not work together. It is not a systems
> approach.
>
> 73,
> Don W3FPR.
>
>
> On 2/27/2018 10:09 PM, Joe Subich, W4TV wrote:
>>
>> You're dealing with a "standard" that was originally developed for use
>> only within one company's products - much like Elecraft's Aux Bus.
>>
>> As such, any "industry standard" is moot. The design is for active
>> high/voltage source (to +12V originally) and was not intended for any
>> purpose than providing band switching for the FL-700 then the Quadra.
>> It would seem to me that any product that claims to inter-operate with
>> the Yaesu "Band Data" would emulate or at least be compatible with
>> that behavior - including the ability to *source* sufficient current
>> at +12V.
>>
>> These devices are not operating in the "communications (non-ham) world",
>> they are strictly amateur products.
>>
>> 73,
>>
>> ... Joe, W4TV
>>
>>
>> On 2/27/2018 9:28 PM, Don Wilhelm wrote:
>>> The problem is that most devices (in the ham world) expect the driver
>>> device to provide voltage.
>>> In the communications (non-ham) world, the expectation is that the
>>> driver device produces either a logic low (short to common) or a
>>> logic high ( open circuit).
>>>
>>> Look at the data sheets for "line drivers" and "line receivers" to
>>> check out what I am saying.
>>>
>>> Open collector or open emitter does not make a difference in
>>> function, it is only a circuit design decision. Yes, open Collector
>>> (or open drain) is commonly use in logic where the active state is
>>> zero volts (transistor or FET conducting to ground).
>>> The open emitter design is the opposite. A conducting device will
>>> provide a voltage on the line (or signal) being driven.
>>>
>>> The point is that in a properly designed communications system, the
>>> drivers provide either conduction to ground or an essentially open
>>> circuit to the communications line (think of a relay being either
>>> open or closed). The receiver provides the voltage to detect whether
>>> the driver is in an open circuit or closed circuit state.
>>> If there are multiple receivers in the system, only one can be
>>> "boss", and that one determines the open circuit voltage and contains
>>> the pullup resistors for the system. Other receivers work in listen
>>> mode and will contain no pullup resistors or active drivers.
>>>
>>> This whole situation goes back to the "one driver, one receiver"
>>> condition.
>>> Only one driver can exist on a communications system without conflict.
>>> Multiple receivers are possible, but only one (at the far end of the
>>> line) should provide the pullup resistors. All other receivers must
>>> be only in the listen mode.
>>>
>>> 73,
>>> Don W3FPR
>>>
>>> On 2/27/2018 8:06 PM, Joe Subich, W4TV wrote:
>>>>
>>>> > But many (most) ham devices do not do it that way, they expect the
>>>> > pullup resistors will be provided by the driver gear.
>>>>
>>>> Actually, most devices that use BCD "band data" expect an open
>>>> emitter driver not an open collector driver. Open emitter will
>>>> *source* voltage for logic high and be open circuit for logic
>>>> low. This is the convention from the early Yaesu rigs which
>>>> were the first devices to support "band data" (it is the way
>>>> the FL-7000 and Quadra amplifiers operate).
>>>>
>>>> You will find the W9XT BCD10/BCD14 decoders with their opto-isolator
>>>> inputs work just fine with the "open emitter" drivers. Other devices
>>>> designed with Yaesu transceivers in mind have appropriate current
>>>> limiting (series) on the input lines and "pull down" (parallel)
>>>> resistors on the logic gates. Some "standard" devices (Top Ten
>>>> BD-Y and the original microHAM Band Decoder) will provide both
>>>> current limiting resistors and internal pull-ups but I have not
>>>> seen any amateur product with series diodes in the band data lines.
>>>>
>>>> 73,
>>>>
>>>> ... Joe, W4TV
>>>>
>>>>
>>>> On 2/27/2018 4:17 PM, Don Wilhelm wrote:
>>>>> Knut,
>>>>>
>>>>> That is the way it *should* be, and was that way in the K3 originally.
>>>>> But many (most) ham devices do not do it that way, they expect the
>>>>> pullup resistors will be provided by the driver gear.
>>>>> So, because of that, Elecraft added pullup resistors to the band
>>>>> data outputs of the K3 long ago.
>>>>> So yes, we are left with a situation that often requires steering
>>>>> diodes.
>>>>>
>>>>>
>>>>> 73,
>>>>> Don W3FPR
>>>>>
>>>>> On 2/27/2018 3:48 PM, ab2tc wrote:
>>>>>> Hi Don and all,
>>>>>>
>>>>>> Hear,hear, Don. The receivers should have the pullup resistor to
>>>>>> whatever
>>>>>> the appropriate voltage needed (within reason) *and* a steering
>>>>>> diode in
>>>>>> series with the input. This will prevent another device with a higher
>>>>>> voltage from feeding current back into the device which could damage
>>>>>> semiconductors. Without the steering diode all receivers must use
>>>>>> the same
>>>>>> pullup voltage. Of course a single receiver is not a problem either.
>>>>> ______________________________________________________________
>>>>> 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]
>>>>
>>>
>>
>
>

Don Wilhelm

Re: Advice needed: Remote Station Enhancement

So are you advocating that all manufacturers of ham gear should adopt
the Yaesu implementation as a "standard"? Icom, Kenwood, Flex and
Elecraft may have other thoughts.

73,
Don W3FPR

On 2/28/2018 11:15 AM, Joe Subich, W4TV wrote:

>
> > THe point is that the two do not work together.
>
> The point is that the devices don't work together because the third
> party manufacturers did not bother to understand the Yaesu design
> and take the necessary steps to be compatible. Yaesu's only purpose
> was to provide band switching data from the transceiver to a Yaesu
> amplifier. Their was no reason to design their system according to
> some inapplicable "standard" from the data processing world.
>
> Third party manufacturers need only provide a low impedance source
> of +12V for a logic high and open circuit for a logic low on the
> "transmit" side to emulate the Yaesu transceiver.
>
> On the receive side, any device that would connect to a Yaesu
> compatible transceiver needs to tolerate +12V on the input and have a
> moderately
> high (1 - 2K) pull down on any logic inputs (if it uses logic inputs);
> opto-isolator inputs simply need the appropriate current limiting
> resistors for 12V inputs (or +5V inputs given that many transceivers
> have failed to provide +12V logic high outputs).
>
> The bottom line is that this is not a "standards based" application.
> If one is going to provide (or use) BCD "band data" the device must
> closely emulate the Yaesu transceiver or clearly state that its
> signaling levels are not [guaranteed] compatible with Yaesu.
>
> 73,
>
>    ... Joe, W4TV
>
>
> On 2/27/2018 10:53 PM, Don Wilhelm wrote:
>> Joe,
>>
>> You do admit that many amateur products do not conform to typical
>> communications standards in the digital world. My experience does go
>> back to my design and evaluation of IBM terminal communication
>> between a DCE and a DTE device. Although this was not necessarily
>> RS-232 levels, the same thing is true. The drivers provide the low
>> and high levels to the line (an open circuit or a ground) while the
>> receiver at the far end of the line provides the logic high level.
>> All other receivers will not provide voltage, but can listen in on
>> the communication. This is not consistent with amateur products with
>> one providing pullup resistors ath the driver location and some
>> receive locations requiring the opposite I.E, those providing pullup
>> resistors to +12 volts.
>> THe point is that the two do not work together. It is not a systems
>> approach.
>>
>> 73,
>> Don W3FPR.
>>
>>
>> On 2/27/2018 10:09 PM, Joe Subich, W4TV wrote:
>>>
>>> You're dealing with a "standard" that was originally developed for use
>>> only within one company's products - much like Elecraft's Aux Bus.
>>>
>>> As such, any "industry standard" is moot. The design is for active
>>> high/voltage source (to +12V originally) and was not intended for any
>>> purpose than providing band switching for the FL-700 then the Quadra.
>>> It would seem to me that any product that claims to inter-operate with
>>> the Yaesu "Band Data" would emulate or at least be compatible with
>>> that behavior - including the ability to *source* sufficient current
>>> at +12V.
>>>
>>> These devices are not operating in the "communications (non-ham)
>>> world",
>>> they are strictly amateur products.
>>>
>>> 73,
>>>
>>>    ... Joe, W4TV
>>>
>>>
>>> On 2/27/2018 9:28 PM, Don Wilhelm wrote:
>>>> The problem is that most devices (in the ham world) expect the
>>>> driver device to provide voltage.
>>>> In the communications (non-ham) world, the expectation is that the
>>>> driver device produces either a logic low (short to common) or a
>>>> logic high ( open circuit).
>>>>
>>>> Look at the data sheets for "line drivers" and "line receivers" to
>>>> check out what I am saying.
>>>>
>>>> Open collector or open emitter does not make a difference in
>>>> function, it is only a circuit design decision. Yes, open
>>>> Collector (or open drain) is commonly use in logic where the active
>>>> state is zero volts (transistor or FET conducting to ground).
>>>> The open emitter design is the opposite. A conducting device will
>>>> provide a voltage on the line (or signal) being driven.
>>>>
>>>> The point is that in a properly designed communications system, the
>>>> drivers provide either conduction to ground or an essentially open
>>>> circuit to the communications line (think of a relay being either
>>>> open or closed). The receiver provides the voltage to detect
>>>> whether the driver is in an open circuit or closed circuit state.
>>>> If there are multiple receivers in the system, only one can be
>>>> "boss", and that one determines the open circuit voltage and
>>>> contains the pullup resistors for the system. Other receivers work
>>>> in listen mode and will contain no pullup resistors or active drivers.
>>>>
>>>> This whole situation goes back to the "one driver, one receiver"
>>>> condition.
>>>> Only one driver can exist on a communications system without conflict.
>>>> Multiple receivers are possible, but only one (at the far end of
>>>> the line) should provide the pullup resistors. All other receivers
>>>> must be only in the listen mode.
>>>>
>>>> 73,
>>>> Don W3FPR
>>>>
>>>> On 2/27/2018 8:06 PM, Joe Subich, W4TV wrote:
>>>>>
>>>>> > But many (most) ham devices do not do it that way, they expect the
>>>>> > pullup resistors will be provided by the driver gear.
>>>>>
>>>>> Actually, most devices that use BCD "band data" expect an open
>>>>> emitter driver not an open collector driver. Open emitter will
>>>>> *source* voltage for logic high and be open circuit for logic
>>>>> low. This is the convention from the early Yaesu rigs which
>>>>> were the first devices to support "band data" (it is the way
>>>>> the FL-7000 and Quadra amplifiers operate).
>>>>>
>>>>> You will find the W9XT BCD10/BCD14 decoders with their opto-isolator
>>>>> inputs work just fine with the "open emitter" drivers. Other devices
>>>>> designed with Yaesu transceivers in mind have appropriate current
>>>>> limiting (series) on the input lines and "pull down" (parallel)
>>>>> resistors on the logic gates. Some "standard" devices (Top Ten
>>>>> BD-Y and the original microHAM Band Decoder) will provide both
>>>>> current limiting resistors and internal pull-ups but I have not
>>>>> seen any amateur product with series diodes in the band data lines.
>>>>>
>>>>> 73,
>>>>>
>>>>>     ... Joe, W4TV
>>>>>
>>>>>
>>>>> On 2/27/2018 4:17 PM, Don Wilhelm wrote:
>>>>>> Knut,
>>>>>>
>>>>>> That is the way it *should* be, and was that way in the K3
>>>>>> originally.
>>>>>> But many (most) ham devices do not do it that way, they expect
>>>>>> the pullup resistors will be provided by the driver gear.
>>>>>> So, because of that, Elecraft added pullup resistors to the band
>>>>>> data outputs of the K3 long ago.
>>>>>> So yes, we are left with a situation that often requires steering
>>>>>> diodes.
>>>>>>
>>>>>>
>>>>>> 73,
>>>>>> Don W3FPR
>>>>>>
>>>>>> On 2/27/2018 3:48 PM, ab2tc wrote:
>>>>>>> Hi Don and all,
>>>>>>>
>>>>>>> Hear,hear, Don. The receivers should have the pullup resistor to
>>>>>>> whatever
>>>>>>> the appropriate voltage needed (within reason) *and* a steering
>>>>>>> diode in
>>>>>>> series with the input. This will prevent another device with a
>>>>>>> higher
>>>>>>> voltage from feeding current back into the device which could
>>>>>>> damage
>>>>>>> semiconductors. Without the steering diode all receivers must
>>>>>>> use the same
>>>>>>> pullup voltage. Of course a single receiver is not a problem
>>>>>>> either.
>>>>>> ______________________________________________________________
>>>>>> 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]
>>>>>
>>>>
>>>
>>
>>
>

Joe Subich, W4TV-4

Re: Advice needed: Remote Station Enhancement

On 2/28/2018 12:42 PM, Don Wilhelm wrote:
> So are you advocating that all manufacturers of ham gear should adopt
> the Yaesu implementation as a "standard"? Icom, Kenwood, Flex and
> Elecraft may have other thoughts.

Yes, if another transceiver manufacturer chooses to emulate Yaesu's
protocol (BCD based "band data" with 160M = 1, 80M = 2, 40M = 3,
30M = 4, 20M = 5, 17M = 6, 15M = 7, 12M = 8, 10M = 9 and 6M = 10),
they should also emulate the signal levels.

Icom and Kenwood have spoken, Icom used its own proprietary "Stepped
Voltage" for the IC2KL/IC4KL and certain antenna tuners (which Elecraft
supports in the KPA500 and KPA1500), while Kenwood have never provided
any "band Data" outputs.

I don't know/care what Flex are doing in their current "radios" - their
older products could be made to properly emulate the Yaesu Standard by
running a third party software application that drove an LPT port in
the computer that did the majority of the Flex's "work" - that LPT
sourced sufficient voltage/current (in "full power" ports) to be
compatible with the Yaesu implementation.

73,

... Joe, W4TV

______________________________________________________________
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]

Jack Brindle-2

Re: Advice needed: Remote Station Enhancement

There is a big problem with this, one that was unusual when Yaesu first created this setup, but very common now. The issue is that of false powering of receiving devices. In this day of low power micro controllers and other digital devices, the device can actually be powered through the I/O port when the device is supposed to be off. The I/O current flows into the input pin, through the protective diode and onto the Vcc rail, bypassing the main VCC pin. This means the device may be partially functional, and not under proper control. It can lead quickly to the destruction of the device.

This is the big reason for modern-day communications techniques between devices, and why protective measures must be taken to avoid false powering other devices. Yes, devices connected to BCD band data _can_ be false powered. We do see it. It makes me wonder if perhaps the old Yaesu method should be retired and no longer used. I certainly won’t be buying any of those devices.

There is no reason that BCD data should not be carried at logic levels between devices if these measures have been taken. There appears to be two separate “standards” at this point, the Yaesu 12V system, and the 5 volt TTL logic level system. Devices that play in each should be clearly marked so the buyer can beware. Unfortunately many are not. This does provide an opportunity for the creation of interfaces which translate between the two methods, providing protection to both the transceiver and the device being driven. The problem comes from hams who don’t realize the issue and try to connect the two. Either they get frustrated because the connection doesn’t work and no harm is done otherwise, or they get really frustrated because the 12V driver blows up their device.

Luckily we don’t see the latter happen that much. But arguing that the “old ways” are somehow better, when we know otherwise, doesn’t do very much good.

In the Elecraft case, the drive and receivers are 5-volt TTL logic levels. As long as anything they attach do use those same levels everything works just fine.

- Jack, W6FB

> On Feb 28, 2018, at 11:33 AM, Joe Subich, W4TV <[hidden email]> wrote:
>
>
> On 2/28/2018 12:42 PM, Don Wilhelm wrote:
>> So are you advocating that all manufacturers of ham gear should adopt the Yaesu implementation as a "standard"? Icom, Kenwood, Flex and Elecraft may have other thoughts.
>
> Yes, if another transceiver manufacturer chooses to emulate Yaesu's
> protocol (BCD based "band data" with 160M = 1, 80M = 2, 40M = 3,
> 30M = 4, 20M = 5, 17M = 6, 15M = 7, 12M = 8, 10M = 9 and 6M = 10),
> they should also emulate the signal levels.
>
> Icom and Kenwood have spoken, Icom used its own proprietary "Stepped
> Voltage" for the IC2KL/IC4KL and certain antenna tuners (which Elecraft
> supports in the KPA500 and KPA1500), while Kenwood have never provided
> any "band Data" outputs.
>
> I don't know/care what Flex are doing in their current "radios" - their
> older products could be made to properly emulate the Yaesu Standard by
> running a third party software application that drove an LPT port in
> the computer that did the majority of the Flex's "work" - that LPT
> sourced sufficient voltage/current (in "full power" ports) to be
> compatible with the Yaesu implementation.
>
> 73,
>
> ... Joe, W4TV
>
> ______________________________________________________________
> 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]

Joe Subich, W4TV-4

Re: Advice needed: Remote Station Enhancement

On 2/28/2018 8:19 PM, Jack Brindle wrote:
> It makes me wonder if perhaps the old Yaesu method should be retired
> and no longer used.

If you're willing to purchase/replace all the pre-1990 Yaesu
transceivers still in use <G>.

> Either they get frustrated because the connection doesn’t work and no
> harm is done otherwise, or they get really frustrated because the
> 12V driver blows up their device.

If the device is designed to be +12V tolerant (input current limiting
and properly selected "pull down") there is no damage. The input
current limiting and pull down also keeps any voltage on the inputs
low enough to prevent "false powering." For that matter, the BCD
signals are DC and the third party device could use shunt zener diodes
on the signal lines to limit the input voltage to and prevent false
powering. It's only when the third party device makes assumptions
without understanding the history of the Yaesu "Band Data" (or "Linear")
interface that one has an issue.

73,

... Joe, W4TV

On 2/28/2018 8:19 PM, Jack Brindle wrote:

> There is a big problem with this, one that was unusual when Yaesu first created this setup, but very common now. The issue is that of false powering of receiving devices. In this day of low power micro controllers and other digital devices, the device can actually be powered through the I/O port when the device is supposed to be off. The I/O current flows into the input pin, through the protective diode and onto the Vcc rail, bypassing the main VCC pin. This means the device may be partially functional, and not under proper control. It can lead quickly to the destruction of the device.
>
> This is the big reason for modern-day communications techniques between devices, and why protective measures must be taken to avoid false powering other devices. Yes, devices connected to BCD band data _can_ be false powered. We do see it. It makes me wonder if perhaps the old Yaesu method should be retired and no longer used. I certainly won’t be buying any of those devices.
>
> There is no reason that BCD data should not be carried at logic levels between devices if these measures have been taken. There appears to be two separate “standards” at this point, the Yaesu 12V system, and the 5 volt TTL logic level system. Devices that play in each should be clearly marked so the buyer can beware. Unfortunately many are not. This does provide an opportunity for the creation of interfaces which translate between the two methods, providing protection to both the transceiver and the device being driven. The problem comes from hams who don’t realize the issue and try to connect the two. Either they get frustrated because the connection doesn’t work and no harm is done otherwise, or they get really frustrated because the 12V driver blows up their device.
>
> Luckily we don’t see the latter happen that much. But arguing that the “old ways” are somehow better, when we know otherwise, doesn’t do very much good.
>
> In the Elecraft case, the drive and receivers are 5-volt TTL logic levels. As long as anything they attach do use those same levels everything works just fine.
>
> - Jack, W6FB
>
>
>> On Feb 28, 2018, at 11:33 AM, Joe Subich, W4TV <[hidden email]> wrote:
>>
>>
>> On 2/28/2018 12:42 PM, Don Wilhelm wrote:
>>> So are you advocating that all manufacturers of ham gear should adopt the Yaesu implementation as a "standard"? Icom, Kenwood, Flex and Elecraft may have other thoughts.
>>
>> Yes, if another transceiver manufacturer chooses to emulate Yaesu's
>> protocol (BCD based "band data" with 160M = 1, 80M = 2, 40M = 3,
>> 30M = 4, 20M = 5, 17M = 6, 15M = 7, 12M = 8, 10M = 9 and 6M = 10),
>> they should also emulate the signal levels.
>>
>> Icom and Kenwood have spoken, Icom used its own proprietary "Stepped
>> Voltage" for the IC2KL/IC4KL and certain antenna tuners (which Elecraft
>> supports in the KPA500 and KPA1500), while Kenwood have never provided
>> any "band Data" outputs.
>>
>> I don't know/care what Flex are doing in their current "radios" - their
>> older products could be made to properly emulate the Yaesu Standard by
>> running a third party software application that drove an LPT port in
>> the computer that did the majority of the Flex's "work" - that LPT
>> sourced sufficient voltage/current (in "full power" ports) to be
>> compatible with the Yaesu implementation.
>>
>> 73,
>>
>> ... Joe, W4TV
>>
>> ______________________________________________________________
>> 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]
>
>

Jack Brindle-2

Re: Advice needed: Remote Station Enhancement

With todays microelectronics, false powering can occur with little current, perhaps a milliamp or less, definitely less than that required to drive the LED of an optoisolator. Voltage levels required are quite low, depending on the design. As low as 2 volts can do the trick, and at that level the required current is even lower. The power sourced by the Yaesu design will easily cause the problem. At the voltage levels being discussed, even with protective zener diodes, the result will most likely be destructive. Here in Silicon Valley there are many equipment designers that are very familiar with the issue. A good look at the ATCA backplane specification used in the telco high-availability world will show my take on handling the issue. As a hint, I called for I2C open-drain drive with protective diodes on the receivers and pull-ups behind the diodes, all specified for optimum bus performance. In those systems there is no possibility for current to be driven into devices on communicating blades.

This is really a Ford vs Chevy (Mac vs PC, etc) argument. There are several methods for providing band and frequency information, pretty much as many as there are transceiver manufacturers. Within their ecosystem, each works very well. The problems occur when crossing ecosystems. Just as Icom serial and Icon analog don’t directly connect, neither do others, including logic BCD and Yaesu BCD. All need some sort of proper interface. Forcing one to directly connect to another is risky at best. One is lucky (for a while) if they do work. Providing proper interface circuitry is a requirement of anyone trying to bridge two systems. There are many successful designs, and some that are not successful. The latter tend not to last very long.

If you have a Yaesu radio, by all means use the Yaesu ecosystem. I am sure the devices work very well. The same is true of Icom, Kenwood and other ecosystems. In my case I have Elecraft gear, and use directly compatible electronics, whether it comes from the company, other manufacturers, or my own designs.

Jack, W6FB

> On Feb 28, 2018, at 7:23 PM, Joe Subich, W4TV <[hidden email]> wrote:
>
>
> On 2/28/2018 8:19 PM, Jack Brindle wrote:
>> It makes me wonder if perhaps the old Yaesu method should be retired
> > and no longer used.
>
> If you're willing to purchase/replace all the pre-1990 Yaesu
> transceivers still in use <G>.
>
>> Either they get frustrated because the connection doesn’t work and no
>> harm is done otherwise, or they get really frustrated because the
>> 12V driver blows up their device.
>
> If the device is designed to be +12V tolerant (input current limiting
> and properly selected "pull down") there is no damage. The input
> current limiting and pull down also keeps any voltage on the inputs
> low enough to prevent "false powering." For that matter, the BCD
> signals are DC and the third party device could use shunt zener diodes
> on the signal lines to limit the input voltage to and prevent false
> powering. It's only when the third party device makes assumptions
> without understanding the history of the Yaesu "Band Data" (or "Linear")
> interface that one has an issue.
>
> 73,
>
> ... Joe, W4TV
>
>
> On 2/28/2018 8:19 PM, Jack Brindle wrote:
>> There is a big problem with this, one that was unusual when Yaesu first created this setup, but very common now. The issue is that of false powering of receiving devices. In this day of low power micro controllers and other digital devices, the device can actually be powered through the I/O port when the device is supposed to be off. The I/O current flows into the input pin, through the protective diode and onto the Vcc rail, bypassing the main VCC pin. This means the device may be partially functional, and not under proper control. It can lead quickly to the destruction of the device.
>> This is the big reason for modern-day communications techniques between devices, and why protective measures must be taken to avoid false powering other devices. Yes, devices connected to BCD band data _can_ be false powered. We do see it. It makes me wonder if perhaps the old Yaesu method should be retired and no longer used. I certainly won’t be buying any of those devices.
>> There is no reason that BCD data should not be carried at logic levels between devices if these measures have been taken. There appears to be two separate “standards” at this point, the Yaesu 12V system, and the 5 volt TTL logic level system. Devices that play in each should be clearly marked so the buyer can beware. Unfortunately many are not. This does provide an opportunity for the creation of interfaces which translate between the two methods, providing protection to both the transceiver and the device being driven. The problem comes from hams who don’t realize the issue and try to connect the two. Either they get frustrated because the connection doesn’t work and no harm is done otherwise, or they get really frustrated because the 12V driver blows up their device.
>> Luckily we don’t see the latter happen that much. But arguing that the “old ways” are somehow better, when we know otherwise, doesn’t do very much good.
>> In the Elecraft case, the drive and receivers are 5-volt TTL logic levels. As long as anything they attach do use those same levels everything works just fine.
>> - Jack, W6FB
>>> On Feb 28, 2018, at 11:33 AM, Joe Subich, W4TV <[hidden email]> wrote:
>>>
>>>
>>> On 2/28/2018 12:42 PM, Don Wilhelm wrote:
>>>> So are you advocating that all manufacturers of ham gear should adopt the Yaesu implementation as a "standard"? Icom, Kenwood, Flex and Elecraft may have other thoughts.
>>>
>>> Yes, if another transceiver manufacturer chooses to emulate Yaesu's
>>> protocol (BCD based "band data" with 160M = 1, 80M = 2, 40M = 3,
>>> 30M = 4, 20M = 5, 17M = 6, 15M = 7, 12M = 8, 10M = 9 and 6M = 10),
>>> they should also emulate the signal levels.
>>>
>>> Icom and Kenwood have spoken, Icom used its own proprietary "Stepped
>>> Voltage" for the IC2KL/IC4KL and certain antenna tuners (which Elecraft
>>> supports in the KPA500 and KPA1500), while Kenwood have never provided
>>> any "band Data" outputs.
>>>
>>> I don't know/care what Flex are doing in their current "radios" - their
>>> older products could be made to properly emulate the Yaesu Standard by
>>> running a third party software application that drove an LPT port in
>>> the computer that did the majority of the Flex's "work" - that LPT
>>> sourced sufficient voltage/current (in "full power" ports) to be
>>> compatible with the Yaesu implementation.
>>>
>>> 73,
>>>
>>> ... Joe, W4TV
>>>
>>> ______________________________________________________________
>>> 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]

ab2tc

Re: Advice needed: Remote Station Enhancement

Hi all,

I was reluctant to respond again to this long thread, but I will.

If all receivers on the bus (yes, it is a bus) were to obey the rules to
have a pullup resistor and a steering diode we would not have the problem of
"false power" to devices on the bus. This would be proper engineering
practice which has unfortunately been ignored by the the ham community for
years.

AB2TC- Knut

--
Sent from: http://elecraft.365791.n2.nabble.com/
______________________________________________________________
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]