I do miscellaneous switching chores at my remote station with two devices:
a remotely-controlled AC power strip and a remotely-controlled DC relay
board. Either could be adapted to your requirements IF your switch has
digital inputs such as four independent control lines. I don't know if
either of
Hi Dennis.
Have you checked what is available here:
http://www.remoterig.com/wp/
73, Yngvi TF3Y
On Wed, Mar 7, 2018 at 1:30 AM, Dennis Ashworth
wrote:
> My original post (below) morphed into a thread on standards, etc ... the
> discussion was insightful and useful in defining my solution to qu
It's great to say what should have been done, particularly when the
original design is 35+ years old (Yaesu transceiver/FL-7000). It
is not practical to make a change to all the legacy hardware so any
equipment supporting Yaesu format "Band Data" needs to be designed
to be +12V tolerant and any
Right on Don.
73,
Fred KE7X
From: elecraft-boun...@mailman.qth.net on
behalf of Don Wilhelm
Sent: Friday, March 2, 2018 5:19 PM
To: elecraft@mailman.qth.net
Subject: Re: [Elecraft] Advice needed: Remote Station Enhancement
I believe that logic can quickly
I believe that logic can quickly merge into the idea that "the first to
introduce BCD Band Data" will "set the standard". I for one do not
believe that is the best approach, and certainly not sufficient to 'set
a standard', which may have serious flaws when extended beyond that
manufacturer's
As far as older Yaesu transceivers are concerned, their design is
proprietary and cannot be brought into the mold without serious
converters (which should frankly be easily constructed by the serious
amateur).
Yaesu's transceivers were the *first* to use BCD "band data". As such,
it should be
Actually, we're talking about exactly the same thing.
I should have included tags. Sorry for the omission.
On 3/2/2018 2:03 PM, Jim Brown wrote:
On 3/2/2018 1:48 PM, Lynn W. Taylor, WB6UUT wrote:
The nice thing about standards is that there are so many to choose from.
Actually, what we're
On 3/2/2018 1:48 PM, Lynn W. Taylor, WB6UUT wrote:
The nice thing about standards is that there are so many to choose from.
Actually, what we're describing here is the LACK of a Standard -- each
company decided in isolation how to implement things like this. I serve
on the Standards Committee
The nice thing about standards is that there are so many to choose from.
73 -- Lynn
On 3/2/2018 1:43 PM, ab2tc wrote:
My main point is that the amateur community should move towards following
the "standard". If all devices followed that "standard" they would all work
together and there would be
Hi all,
Of course this assumes that the sole transmitter on the bus obeys the rules
as well, which is to be an open collector or open drain (or relay contact to
ground). I am sorry if I omitted that point.
As far as older Yaesu transceivers are concerned, their design is
proprietary and cannot be
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.
Of course, they would fail to work with older Yaesu transceivers that
source voltage for a logic high and ar
Knut,
This has been a "corruption" of the RS-232 environment.
RS-232 is a point to point protocol, and too many ham applications have
tried to turn it into a multi-point communication. It just does not work.
Multiple receivers will work, but multiple drivers will not. It all
boils down to t
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
pr
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 th
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 .
Either they get frustrated because the connection doesn’t work and no
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
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 (BC
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
> 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
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
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 providi
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 dri
> 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
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.
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 dam
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
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
Date: Sat, Dec 26, 2015 at 7:06 PM
Subject: Re: [Elecraft] K3 and Band Data
To: John Noga
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
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 l
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 gr
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, althoug
31 matches
Mail list logo