Elecraft

[K3] Band data problem

Classic

List

Threaded

10 messages Options

Jim AB3CV

[K3] Band data problem

I've recently added an MFJ RCS12 controller to my K3/KPA3 setup and
I'm having some problems.

I've built and checked the BANDDATA cable and it only has the four BCD
lines plus ground. I'm using the Elecraft Y-cable and Keyline
interrupter. (The KEYOUT signal is connected to the KPA500 via the
supplied RCA cable directly. This will change of course as the RCS12
becomes operational and again when the KAT500 is added...) The RCS12
reads the BANDDATA <0-3> lines and switches the relay outputs as
expected.

The problem comes when I add the KPA500. The RCS12 continues to read
and follow the band changes from the K3 but the KPA500 switches to 5.3
(60m) and stays there regardless of K3 front panel switches.The KPA500
also operates properly when the cable is connected to the Y connector
but not the RCS12. So the cable is not at fault.

The K3 and RCS12 respond properly to the front panel band selection
switching of the KPA500 but the KPA500 doesn't change from the 60M
indication.

It seems that the KPA500 is reading zeros on the K3 band data outputs
yet capable of sending via AUXBUS band data change requests to the K3
which is then transmitted via the BANDDATA <0-3> lines to the RCS12
yet the KPA500 remains stuck at 60M.

My K3 is serial number 1210 and further reading of the K3 owners manual shows:

"BAND0-3 provide band selection signals. Their behavior is controlled
by the CONFIG:KIO3 menu entry (see below). Band data is based on VFO
A. Earlier K3s may require external pullup resistors to 5 V on these
lines, typically 2.2-10K."

BTW, I have a KIO3A and since it is the interface to the AUXBUS and
BANDDATA I would have guessed that it has sufficient drive and pullup
to do the interface without external pullups. Correct?

So it appears the KPA500 is reading band data rather than AUXBUS and
finding a value of zero. This may be the result of inadequate pullups
on the K3. I thought AUXBUS was bidirectional and the KPA500 would
have been using that for its band info input.

I'm soon adding a KAT500. Since the KAT500 outputs AUXBUS to the
KPA500 I'm wondering if it does any buffering? If so I could pass the
K3 to the KAT500 which presumably would read the BANDDATA <0-3>
properly then pass it along with sufficient strength to drive the
KPA500 as well as the RCS12 correctly. There aren't any schematics yet
for the KAT500 to determine this.

Thanks

jim ab3cv
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

Joe Subich, W4TV-4

Re: [K3] Band data problem

Jim,

> The problem comes when I add the KPA500. The RCS12 continues to read
> and follow the band changes from the K3 but the KPA500 switches to 5.3
> (60m) and stays there regardless of K3 front panel switches.The KPA500
> also operates properly when the cable is connected to the Y connector
> but not the RCS12. So the cable is not at fault.

It is likely that the RCS-12 is loading the band data lines preventing
the KPA-500 from seeing the data from the K3. This has been reported
before ... you may want to look in the archives for a solution:
http://mailman.qth.net/pipermail/elecraft/

I do not remember if the solution is as simple as blocking diodes in
each line or if the RCS-12 requires a high impedance line driver for
isolation.

73,

... Joe, W4TV

On 11/23/2012 9:39 AM, Jim Miller wrote:

> I've recently added an MFJ RCS12 controller to my K3/KPA3 setup and
> I'm having some problems.
>
> I've built and checked the BANDDATA cable and it only has the four BCD
> lines plus ground. I'm using the Elecraft Y-cable and Keyline
> interrupter. (The KEYOUT signal is connected to the KPA500 via the
> supplied RCA cable directly. This will change of course as the RCS12
> becomes operational and again when the KAT500 is added...) The RCS12
> reads the BANDDATA <0-3> lines and switches the relay outputs as
> expected.
>
> The problem comes when I add the KPA500. The RCS12 continues to read
> and follow the band changes from the K3 but the KPA500 switches to 5.3
> (60m) and stays there regardless of K3 front panel switches.The KPA500
> also operates properly when the cable is connected to the Y connector
> but not the RCS12. So the cable is not at fault.
>
> The K3 and RCS12 respond properly to the front panel band selection
> switching of the KPA500 but the KPA500 doesn't change from the 60M
> indication.
>
> It seems that the KPA500 is reading zeros on the K3 band data outputs
> yet capable of sending via AUXBUS band data change requests to the K3
> which is then transmitted via the BANDDATA <0-3> lines to the RCS12
> yet the KPA500 remains stuck at 60M.
>
> My K3 is serial number 1210 and further reading of the K3 owners manual shows:
>
> "BAND0-3 provide band selection signals. Their behavior is controlled
> by the CONFIG:KIO3 menu entry (see below). Band data is based on VFO
> A. Earlier K3s may require external pullup resistors to 5 V on these
> lines, typically 2.2-10K."
>
> BTW, I have a KIO3A and since it is the interface to the AUXBUS and
> BANDDATA I would have guessed that it has sufficient drive and pullup
> to do the interface without external pullups. Correct?
>
> So it appears the KPA500 is reading band data rather than AUXBUS and
> finding a value of zero. This may be the result of inadequate pullups
> on the K3. I thought AUXBUS was bidirectional and the KPA500 would
> have been using that for its band info input.
>
> I'm soon adding a KAT500. Since the KAT500 outputs AUXBUS to the
> KPA500 I'm wondering if it does any buffering? If so I could pass the
> K3 to the KAT500 which presumably would read the BANDDATA <0-3>
> properly then pass it along with sufficient strength to drive the
> KPA500 as well as the RCS12 correctly. There aren't any schematics yet
> for the KAT500 to determine this.
>
> Thanks
>
> jim ab3cv
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
>

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

Jim AB3CV

Re: [K3] Band data problem

In reply to this post by Jim AB3CV

I've gotten feedback on and off list that will help me in figuring
this out. I'll debug it over the weekend and post results and my
solution.

Thanks!

jim ab3cv
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

Jim AB3CV

Re: [K3] Band data problem

In reply to this post by Jim AB3CV

Senior moment: I confused the KIO3 with the KXV3. I have long ago
updated the latter to the "A" version. So my KIO3 and the associated
connector module are almost certainly lacking pullups. I'll open the
K3 tomorrow and confirm and if true try to add the 2.2K pullups found
on the newer model's D-sub module.

jim ab3cv

On Fri, Nov 23, 2012 at 9:39 AM, Jim Miller <[hidden email]> wrote:
>
> BTW, I have a KIO3A and since it is the interface to the AUXBUS and
> BANDDATA I would have guessed that it has sufficient drive and pullup
> to do the interface without external pullups. Correct
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

Jim AB3CV

Re: [K3] Band data problem

In reply to this post by Jim AB3CV

A follow up to the K-Line and RCS12 integration. The problem was that the
RCS12 was excessively loading the band data lines. The fix was additional
drive on the pullups on those lines inside the K3. I used 820 ohms in
parallel with each of the internal 2.2K pullups and all is now working well.

Details:
The RCS12 band inputs drive a 2N3904 common emitter buffer using a 1K base
drive resistor. This puts one Vbe drop plus 1K directly on the K3 Band Data
lines. These lines have a 2.2K pullup and a series 220 protection resistor
for a total of 2.4K to +5v. A quick bit of math shows that when this is
loaded with the RCS12 the resultant voltage on the band data lines falls
below 2V. Although the RCS12 is happy, anything else expecting to read the
band data lines will show zeros. The KPA500 will show 5.3Mhz (60m)
indication as a result.

Paralleling the 2.2K resistors with 820ohms brings the combination to
600ohms which in series with the 220ohms results in 820ohms to +5V which
when driving the RCS12 inputs yields 3V remaining on the band data lines.
This provides a sufficient level for a "1" with reasonable noise margin.

The page 4 of the appnote on the Elecraft site
http://www.elecraft.com/K3/mods/K3ALCMod_Rev_B.pdf shows a convenient way
to implement this mod.

73

jim ab3cv
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

Joe Subich, W4TV-4

Re: [K3] Band data problem

> Paralleling the 2.2K resistors with 820ohms brings the combination
> to 600ohms which in series with the 220ohms results in 820ohms to +5V
> which when driving the RCS12 inputs yields 3V remaining on the band
> data lines. This provides a sufficient level for a "1" with
> reasonable noise margin.

I would be careful when decreasing the value of the pull-up resistors
in the K3. The "Band Data" outputs are open drain - decreasing the
pull-ups increases the current the outputs must sink at logic low on
top of any current sourced by the external devices. It might be better
to buffer the RCS12 using something like the 74ACT244 (at less than
$0.25) to drive the 2N3904s.

73,

... Joe, W4TV

On 12/2/2012 8:53 AM, Jim Miller wrote:

> A follow up to the K-Line and RCS12 integration. The problem was that the
> RCS12 was excessively loading the band data lines. The fix was additional
> drive on the pullups on those lines inside the K3. I used 820 ohms in
> parallel with each of the internal 2.2K pullups and all is now working well.
>
> Details:
> The RCS12 band inputs drive a 2N3904 common emitter buffer using a 1K base
> drive resistor. This puts one Vbe drop plus 1K directly on the K3 Band Data
> lines. These lines have a 2.2K pullup and a series 220 protection resistor
> for a total of 2.4K to +5v. A quick bit of math shows that when this is
> loaded with the RCS12 the resultant voltage on the band data lines falls
> below 2V. Although the RCS12 is happy, anything else expecting to read the
> band data lines will show zeros. The KPA500 will show 5.3Mhz (60m)
> indication as a result.
>
> Paralleling the 2.2K resistors with 820ohms brings the combination to
> 600ohms which in series with the 220ohms results in 820ohms to +5V which
> when driving the RCS12 inputs yields 3V remaining on the band data lines.
> This provides a sufficient level for a "1" with reasonable noise margin.
>
> The page 4 of the appnote on the Elecraft site
> http://www.elecraft.com/K3/mods/K3ALCMod_Rev_B.pdf shows a convenient way
> to implement this mod.
>
> 73
>
> jim ab3cv
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
>

Jim AB3CV

Re: [K3] Band data problem

Hi Joe

There's certainly more than one way to deal with this. External buffer
chips are an inexpensive solution. I didn't want yet another piece of
clutter in my already box and cable littered shack so I chose to mod the K3.

The K3 driver chips are not an issue at all. Any additional external pullup
would add to their load but would also provide the desired additional
pullup drive and make it possible to increase the value from 820ohms to
perhaps 1K. The KAT500/KPA500 add a fraction of a milliamp in total so they
are not an issue. They are the only devices other than the RCS12 on the
band outputs in my case.

The only other consideration is that the increased internal pullup drive
(lowered resistance) puts more load on the 5v regulator sourcing current to
those pullups. Again not an issue.

73

jim ab3cv

On Sun, Dec 2, 2012 at 9:41 AM, Joe Subich, W4TV <[hidden email]> wrote:

> I would be careful when decreasing the value of the pull-up resistors
> in the K3. The "Band Data" outputs are open drain - decreasing the
> pull-ups increases the current the outputs must sink at logic low on
> top of any current sourced by the external devices. It might be better
> to buffer the RCS12 using something like the 74ACT244 (at less than
> $0.25) to drive the 2N3904s.
>
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

Joe Subich, W4TV-4

Re: [K3] Band data problem

> I didn't want yet another piece of clutter in my already box and
> cable littered shack so I chose to mod the K3.

In all probability an inverting buffer or possibly a pair of low drive,
dual optoisolators could replace the 2N3904 transistors directly. I
suspect the transistors are simply buffering and inverting the inputs
to a PIC of some kind and are there to protect against 12V inputs.

Alternatives are to add pull-ups (2K2 Ohm) in the RCS-12 (but that goes
to the same issue of added dissipation on the K3 drivers) or replace
the base resistors with 2K2 (the transistors should have sufficient
gain to work with 1 mA instead of 1.5mA base drive. Even adding 1K-1K5
in each of the band data lines (connector at the RCS-12) might work as
a "no modification/no external box" fix. However, since I don't have
an RCS-12 I have no way of trying it.

73,

... Joe, W4TV

On 12/2/2012 11:28 AM, Jim Miller wrote:

> Hi Joe
>
> There's certainly more than one way to deal with this. External buffer
> chips are an inexpensive solution. I didn't want yet another piece of
> clutter in my already box and cable littered shack so I chose to mod the K3.
>
> The K3 driver chips are not an issue at all. Any additional external pullup
> would add to their load but would also provide the desired additional
> pullup drive and make it possible to increase the value from 820ohms to
> perhaps 1K. The KAT500/KPA500 add a fraction of a milliamp in total so they
> are not an issue. They are the only devices other than the RCS12 on the
> band outputs in my case.
>
> The only other consideration is that the increased internal pullup drive
> (lowered resistance) puts more load on the 5v regulator sourcing current to
> those pullups. Again not an issue.
>
> 73
>
> jim ab3cv
>
> On Sun, Dec 2, 2012 at 9:41 AM, Joe Subich, W4TV <[hidden email]> wrote:
>
>> I would be careful when decreasing the value of the pull-up resistors
>> in the K3. The "Band Data" outputs are open drain - decreasing the
>> pull-ups increases the current the outputs must sink at logic low on
>> top of any current sourced by the external devices. It might be better
>> to buffer the RCS12 using something like the 74ACT244 (at less than
>> $0.25) to drive the 2N3904s.
>>
>

Don Wilhelm-4

Re: [K3] Band data problem

I would suggest if modification to the RCS-12 is in order, the 2N3904s
be changed out for switching FETs such as the 2N7000.

The change Jim made will result in only 8 ma of drain current for the
drivers in their off state. I believe the band data drivers in the K3
are similar to the KEYOUT-LP driver which is rated to sink up to 10 ma.
according to the K3 ACC connector information.

73,
Don W3FPR
On 12/2/2012 12:24 PM, Joe Subich, W4TV wrote:

>
>> I didn't want yet another piece of clutter in my already box and
>> cable littered shack so I chose to mod the K3.
>
> In all probability an inverting buffer or possibly a pair of low drive,
> dual optoisolators could replace the 2N3904 transistors directly. I
> suspect the transistors are simply buffering and inverting the inputs
> to a PIC of some kind and are there to protect against 12V inputs.
>
> Alternatives are to add pull-ups (2K2 Ohm) in the RCS-12 (but that goes
> to the same issue of added dissipation on the K3 drivers) or replace
> the base resistors with 2K2 (the transistors should have sufficient
> gain to work with 1 mA instead of 1.5mA base drive. Even adding 1K-1K5
> in each of the band data lines (connector at the RCS-12) might work as
> a "no modification/no external box" fix. However, since I don't have
> an RCS-12 I have no way of trying it.
>

Jim AB3CV

Re: [K3] Band data problem

In reply to this post by Joe Subich, W4TV-4

Joe/Don

There are lots of ways to skin the cat. If you took apart the RCS12 you'd
see why the the mod to the K3 is by far the easiest approach. Four
resistors, easily applied.

The power dissipation increase on the drivers is a few milliwatts (4 *
(5v/600) * 0.1) and inconsequential in the decision.

73

jim ab3cv
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html