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 <li...@subich.com> 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 <li...@subich.com> 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: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

Reply via email to