Re: [Elecraft] Advice needed: Remote Station Enhancement
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 these techniques is what you really want, but maybe they'll give you some ideas. My AC power strip is from Digital Loggers Inc. I found it at a surplus store for a lot less than new boxes. It supports eight controllable AC outlets from a Web page that's hosted inside the outlet strip itself. Connect it to your remote LAN with a little well-documented, one-time network magic and you're good to go. You can assign mnemonic names to each outlet, subdivide them into "user" and "administrator" sets, monitor access via a "heartbeat" on the Internet for restart sequencing, etc. Quite nice but not exactly what you want as you would have to plug in wall warts or external relays and you would have to activate the four lines manually, one at a time. To change antennas you would probably have to turn one off and another on which is kind of messy. My DC relay board is from Velleman Projects. It has a local interface program (Windows) that I access via a remote desktop app. It has eight SPDT relays but only exposes the common and normally open contacts via a terminal strip. I've considered tacking wires onto the normally closed contacts and adding a second terminal strip to expose them, but so far haven't had to do that. They probably have other models with different I/O capabilities. Although this device, like the power strip, provides eight independent, binary lines, its local interface program is written in Basic and source code is available. I wanted to re-program it with mnemonic names instead of just numbers 1-8 but when I saw the Gothic environment into which Basic has devolved, I gave up. If you're handier with Basic, you could use the supplied source code as education and write your own program that turns on one and no more than one line at a time. There are other vendors of similar devices. I believe there are also some solutions involving remote serial ports but I have no experience with them. Good luck & 73, /Rick N6XI -- Rick Tavan Truckee, CA On Tue, Mar 6, 2018 at 5:30 PM, Dennis Ashworth wrote: > > Question #2 remains. How do I remotely switch between 4 positions on an RX > antenna switch (e.g. K9AY switch box) via some kind of Windows based UI. > Ideas? > __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 question #1 > below. Thanks. > > Question #2 remains. How do I remotely switch between 4 positions on an RX > antenna switch (e.g. K9AY switch box) via some kind of Windows based UI. > Ideas? > > Thanks > Dennis, K7FL > > > Sent from my iPad > > Begin forwarded message: > > > From: Dennis Ashworth > > Date: February 24, 2018 at 2:23:20 PM EST > > To: "elecraft@mailman.qth.net" > > Subject: 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: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 t...@tf3y.net -- http://www.tf3y.net __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
[Elecraft] Advice needed: Remote Station Enhancement
My original post (below) morphed into a thread on standards, etc ... the discussion was insightful and useful in defining my solution to question #1 below. Thanks. Question #2 remains. How do I remotely switch between 4 positions on an RX antenna switch (e.g. K9AY switch box) via some kind of Windows based UI. Ideas? Thanks Dennis, K7FL Sent from my iPad Begin forwarded message: > From: Dennis Ashworth > Date: February 24, 2018 at 2:23:20 PM EST > To: "elecraft@mailman.qth.net" > Subject: 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:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 transceiver generating "band Data" needs to source +12V for logic high and provide open circuit (or a weak pull down) for logic low. If a given piece of hardware doesn't meet those specifications, the manufacturer clearly needs to label it as *not compatible* with the Yaesu products. This is not a matter of "standards" as there were none when Yaesu designed its transceivers and amplifier. For many years, those who built their own hardware to interface with the Yaesu rigs built to the Yaesu specification ... and if the current crop of third party hardware was designed to meet Yaesu's specification there would not be an issue of incompatibility with multiple receivers connected to the "Band Data bus". While you may not like the approach of "first to use" setting the "standard", that "standard" has been there for 35+ years. It's a little late to "wish it away" particularly since Yaesu still make transceivers and amplifiers that continue to use "voltage source = logic high/high impedance = logic low". 73, ... Joe, W4TV On 3/2/2018 7:19 PM, Don Wilhelm wrote: 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 realm. The Yaesu method (I cannot call it a standard) will inter-operate with other Yaesu gear and 3rd party gear designed to inter-operate with it, but that does not constitute a "standard" The "standard" for data communication has been established in the digital world for many, many years, and pre-dates the Yaesu system. Drivers do not source voltage (they use open collector and open drain devices), and there is one pullup resistor at the end of the signal line - there may be multiple receivers monitoring the signal line, but there can be only one driver active at a time - which for a multiple driver situation means an external source of control is necessary for gating the drivers. I was working with those "rules" when designing computer console circuits for a IBM large system back in 1969, and the same principals had been devised since the advent of IBM SLT logic modules in the late 1950s. So if anyone wants to apply "the first guy sets the standard", I think Yaesu was not the first, but they made the mistake of having the drivers source voltage. That is only practical for very short signal lines and a very limited number of receivers listening on the signal line(s). Efforts to continue the "Yaesu method" will result in further confusion as amateur box to box communications develops further and more and more incorporates design principles previously applied to computer systems and communications lines. Even the IBM terminal communications plugged the "pullup" resistors at only one terminal (they were called line terminators) - at the end of the communications line. That is a long established principle that works even today if done right. What I am saying is that Yaesu did not "do it right" and creates limitations to expansion and the advancement of technology within the amateur community today. So get out the cutters and remove the collector and drain resistors from the Yaesu drivers, and put pullup resistors only at the far end of the lines, and you can have the Yaesu "system" without any of the problems. There are other systems that do allow multiple drivers on the same signalling line(s) - I2C is one example - whichever driver grabs the signalling first gets priority is a simplified version of the operation. Ethernet is another example, but in any of these systems, the protocol must define which driver gets priority. That requires a bit more sophistication than a simple driver on the communication line. I believe the original K3 "did it right" to use open drain drivers on the band data lines - but succumbed to the hue and cry that it did not work with the various versions of the Yaesu system and Elecraft then added pullup resistors to the drivers. The result has been a bastardized "system" that in many cases requires the addition of steering diodes and/or the removal of pullup resistors from external devices to make it work right. 73, Don W3FPR On 3/2/2018 6:17 PM, Joe Subich, W4TV wrote: 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 incumbent
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 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 realm. The Yaesu method (I cannot call it a standard) will inter-operate with other Yaesu gear and 3rd party gear designed to inter-operate with it, but that does not constitute a "standard" The "standard" for data communication has been established in the digital world for many, many years, and pre-dates the Yaesu system. Drivers do not source voltage (they use open collector and open drain devices), and there is one pullup resistor at the end of the signal line - there may be multiple receivers monitoring the signal line, but there can be only one driver active at a time - which for a multiple driver situation means an external source of control is necessary for gating the drivers. I was working with those "rules" when designing computer console circuits for a IBM large system back in 1969, and the same principals had been devised since the advent of IBM SLT logic modules in the late 1950s. So if anyone wants to apply "the first guy sets the standard", I think Yaesu was not the first, but they made the mistake of having the drivers source voltage. That is only practical for very short signal lines and a very limited number of receivers listening on the signal line(s). Efforts to continue the "Yaesu method" will result in further confusion as amateur box to box communications develops further and more and more incorporates design principles previously applied to computer systems and communications lines. Even the IBM terminal communications plugged the "pullup" resistors at only one terminal (they were called line terminators) - at the end of the communications line. That is a long established principle that works even today if done right. What I am saying is that Yaesu did not "do it right" and creates limitations to expansion and the advancement of technology within the amateur community today. So get out the cutters and remove the collector and drain resistors from the Yaesu drivers, and put pullup resistors only at the far end of the lines, and you can have the Yaesu "system" without any of the problems. There are other systems that do allow multiple drivers on the same signalling line(s) - I2C is one example - whichever driver grabs the signalling first gets priority is a simplified version of the operation. Ethernet is another example, but in any of these systems, the protocol must define which driver gets priority. That requires a bit more sophistication than a simple driver on the communication line. I believe the original K3 "did it right" to use open drain drivers on the band data lines - but succumbed to the hue and cry that it did not work with the various versions of the Yaesu system and Elecraft then added pullup resistors to the drivers. The result has been a bastardized "system" that in many cases requires the addition of steering diodes and/or the removal of pullup resistors from external devices to make it work right. 73, Don W3FPR On 3/2/2018 6:17 PM, Joe Subich, W4TV wrote: > >> 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 incumbent on anyone using that interface to be electrically > compatible with Yaesu's interface (source +5/+12V for logic high, open > circuit for logic low). Even the amateur DOS based logging software > that provided "band data" on a computer LPT port duplicated that > interface. > __ 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 fc...@montana.edu __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 realm. The Yaesu method (I cannot call it a standard) will inter-operate with other Yaesu gear and 3rd party gear designed to inter-operate with it, but that does not constitute a "standard" The "standard" for data communication has been established in the digital world for many, many years, and pre-dates the Yaesu system. Drivers do not source voltage (they use open collector and open drain devices), and there is one pullup resistor at the end of the signal line - there may be multiple receivers monitoring the signal line, but there can be only one driver active at a time - which for a multiple driver situation means an external source of control is necessary for gating the drivers. I was working with those "rules" when designing computer console circuits for a IBM large system back in 1969, and the same principals had been devised since the advent of IBM SLT logic modules in the late 1950s. So if anyone wants to apply "the first guy sets the standard", I think Yaesu was not the first, but they made the mistake of having the drivers source voltage. That is only practical for very short signal lines and a very limited number of receivers listening on the signal line(s). Efforts to continue the "Yaesu method" will result in further confusion as amateur box to box communications develops further and more and more incorporates design principles previously applied to computer systems and communications lines. Even the IBM terminal communications plugged the "pullup" resistors at only one terminal (they were called line terminators) - at the end of the communications line. That is a long established principle that works even today if done right. What I am saying is that Yaesu did not "do it right" and creates limitations to expansion and the advancement of technology within the amateur community today. So get out the cutters and remove the collector and drain resistors from the Yaesu drivers, and put pullup resistors only at the far end of the lines, and you can have the Yaesu "system" without any of the problems. There are other systems that do allow multiple drivers on the same signalling line(s) - I2C is one example - whichever driver grabs the signalling first gets priority is a simplified version of the operation. Ethernet is another example, but in any of these systems, the protocol must define which driver gets priority. That requires a bit more sophistication than a simple driver on the communication line. I believe the original K3 "did it right" to use open drain drivers on the band data lines - but succumbed to the hue and cry that it did not work with the various versions of the Yaesu system and Elecraft then added pullup resistors to the drivers. The result has been a bastardized "system" that in many cases requires the addition of steering diodes and/or the removal of pullup resistors from external devices to make it work right. 73, Don W3FPR On 3/2/2018 6:17 PM, Joe Subich, W4TV wrote: 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 incumbent on anyone using that interface to be electrically compatible with Yaesu's interface (source +5/+12V for logic high, open circuit for logic low). Even the amateur DOS based logging software that provided "band data" on a computer LPT port duplicated that interface. __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 incumbent on anyone using that interface to be electrically compatible with Yaesu's interface (source +5/+12V for logic high, open circuit for logic low). Even the amateur DOS based logging software that provided "band data" on a computer LPT port duplicated that interface. Absent any documented standard for the interface, any product developer who claims to support "BCD band data" should be expected to properly emulate the Yaesu "ports" so that their receiver works with any Yaesu transceiver and/or their transceiver properly drives any Yaesu amp (FL-7000/Quadra). The issue is accessory makers who are not +12V tolerant and those who apply voltage to the BCD lines ... and transceiver makers who provide "band data" ports that do not source +5/12V for logic high. 73, ... Joe, W4TV On 3/2/2018 4:43 PM, ab2tc wrote: 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 brought into the mold without serious converters (which should frankly be easily constructed by the serious amateur). 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 no problem with one device powering another. AB2TC - Knut ab2tc wrote 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: Elecraft@.qth This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to lists+1215531472858-365791@.nabble -- 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: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 li...@subich.com __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 describing here is the LACK of a Standard -- each company decided in isolation how to implement things like this. __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 of Audio Engineering Society, and we develop Standards by consensus, through a process that accepts engineering (and sometimes applications) input from anyone who wishes to participate. Many of our Standards took years to formulate. The situation with ham gear is that, most likely for competitive reasons, each company developed their way of doing things on their own. This happens fairly often in the world of consumer products. Over a period of nearly 20 years, I rarely saw representatives of Japanese companies in Standards meetings, while US and EU companies and users are represented. Indeed, I mostly remember the Japanese companies presenting papers on their new developments. 73, Jim K9YC __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 no problem with one device powering another. __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 brought into the mold without serious converters (which should frankly be easily constructed by the serious amateur). 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 no problem with one device powering another. AB2TC - Knut ab2tc wrote > 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: > Elecraft@.qth > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to > lists+1215531472858-365791@.nabble -- 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:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 are open circuit on logic low. 73, ... Joe, W4TV On 3/1/2018 7:58 PM, ab2tc wrote: 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: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 li...@subich.com __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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 that point. In addition, all but the far end receivers should provide the pullup resistors. If that is followed, no harm will occur. Unfortunately, many devices want to be that far end receiver with the pullup resistors, and chaos is the result. Until a systems approach is implemented (don't hold your breath), the RS-232 and interoperatability between manufacturers will be a thing only to be wished for. Each manufacturer has there own version of interoperability which works fine until someone offers some gear which does not conform. Maybe we need a ham radio "standards" organization to resolve the problems and make all things ham radio to work together. That is not likely in the near future IMHO. 73, Don W3FPR 73, Don W3FPR On 3/1/2018 7:58 PM, ab2tc wrote: 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. __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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 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 . > >> 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 >> wo
Re: [Elecraft] 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 . 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 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
Re: [Elecraft] 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 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
Re: [Elecraft] 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:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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: > Bu
Re: [Elecraft] 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 em
Re: [Elecraft] 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 approp
Re: [Elecraft] 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: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 li...@subich.com __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qt
Re: [Elecraft] 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: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 li...@subich.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 donw...@embarqmail.com __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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: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 li...@subich.com __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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 Date: Sat, Dec 26, 2015 at 7:06 PM Subject: Re: [Elecraft] K3 and Band Data To: John Nogatch 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. __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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 Date: Sat, Dec 26, 2015 at 7:06 PM Subject: Re: [Elecraft] K3 and Band Data To: John Nogatch 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:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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 > On Feb 25, 2018, at 2:09 PM, Dave Hachadorian 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: elecraft@mailman.qth.net > 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: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 k6ll.d...@gmail.com > __ > Elecraft mailing list > Home: http:/
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 > On Feb 25, 2018, at 2:09 PM, Dave Hachadorian 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: elecraft@mailman.qth.net > 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: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 k6ll.d...@gmail.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 jackbrin...@me.com __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] Advice needed: Remote Station Enhancement
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: elecraft@mailman.qth.net 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: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 k6ll.d...@gmail.com __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
Re: [Elecraft] 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 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: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 marklgoldb...@gmail.com __ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
[Elecraft] 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: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
