A feature request: it is possible to connect a keyboard to P3/PX3, for instance to enter text for CW/PSK/RTTY. Unfortunately, the P3/PX3 require use of the SCROLL LOCK key. The problem is that compact keyboards do not have a SCROLL LOCK key.

A compact keyboard makes a lot of sense when operating. It is much smaller, saving desk real estate, and versions exist that are wireless (using a USB receiver). If the P3/PX3 code can be adapter to accept another key code to do scroll lock, then these keyboards would be fully usable.

Symptoms

CW sidetone sticks on if using the TX inhibit input. Sidetone unsticks if a front panel key is pressed.

Details

Reported to Elecraft mailing list 2020-09-14 by N0UK who emailed a revised problem description on 2020-09-15:

Having solved the need for getting +Ve Tx Inhibit working on my KX3/10GHz Transverter integration using a MOSFET switch to invert the logic level coming from the 10GHz transverter and configured the KX3 for 0v Tx Inhibit, I had the opportunity to test it out yesterday afternoon.

The solution seemed to work fine on SSB but I now have a weird issue when using the rig on CW.

If I manually select transmit with the microphone PTT (didn?t try the XMIT key) and then wait for the transverter sequencing to remove Tx Inhibit and then key CW with the paddles, the system works as desired.

If I key the system using CW VOX, the Tx Inhibit functions correctly, fully disabling the transmitter from producing RF until TxInhibit is removed by the transverter?s sequencing logic BUT then the CW sidetone becomes permanently on from the moment TXInh disappears, regardless of whether I am keying or not. It stays present until I press any of the buttons on the KX3. This happens regardless of which band is enabled, but occurs whenever TxInhibit is initially present.

If I remove the TXInh fro the ACC2 GPIO input (but leave the option enabled in the KX3 config) the rig operates normally under VOX control.

Can anyone else replicate this oddball behavior? It seems to be a firmware bug. I have tried removing power from the KX3 but that does not correct the anomalous behavior.

Again, all works just fine if I don?t try to key the paddles before PTT sequencing has changed over.

N7DA reproduced and provided additional behavior details to the mailing list 2020-10-10:

I was able to reproduce the bug Chris, N0UK, reported with tx inhibit and CW sidetone on the KX3.

To be thorough, the FW as just installed by Elecraft, is uC 02.90 and DSP 01.52 which is the latest.

I have cabling for the ACC2 port, as I use ring contact to PTT a transverter and also to PTT a KXPA100.

Menus have had minimal configuration post service from elecraft, just enough to setup for transverter operation in the 10 GHz contest. Mode is CW and VOX is on of course.

ACC2 Inhibit = Low. I used a paddle on the KXPD paddle port (key 2). Was able to get the stuck sidetone as you describe while sending dits or sending dahs by. (Key 2 left = dot.) For kicks, changed to Key 2 = hand. Found that if the key is released before inhibit is released, the sidetone does not stick. The value of inhibit when the key is initially asserted is not buggy. Saw the same behavior with menu setting inhibit high.

inhibit low
key - inhibit - inhibit release - key release --> sidetone stuck
key - inhibit - key release - inhibit release --> sidetone OK
inhibit - key - inhibit release - key release --> sidetone stuck
inhibit - key - key release - inhibit release --> sidetone OK

inhibit high
key - inhibit - inhibit release - key release --> sidetone stuck
key - inhibit - key release - inhibit release --> sidetone OK
inhibit - key - inhibit release - key release --> sidetone stuck
inhibit - key - key release - inhibit release --> sidetone OK

The behavior is a problem is in the firmware at the inhibit released event.

A thorough bug report would also include observations of the PTT output and actual RF output.

Symptoms

• alarm works normally whether or not battery charging has been turned on while the rig remains on
• with no battery charging, alarm wakes up the rig
• alarm fails to wake up the rig during a charging interval

TODO: determine if the alarm will wake up the rig if the alarm time is after the charging time has elapsed.

Workaround

None

Details

Observed in:

• MCU/DSP 2.90/1.52 (KX3 S/N 7846)
• TODO: confirm MCU/DSP 2.95/1.52

Original problem report

There is a problem that when the charger is charging the internal batteries and an alarm has been set then the alarm will never work. Only when charger is not charging then the alarm will work. Has been reported to Elecraft few years ago but nothing has been done.
Gerard VK2JNG

The K3 S-meter has an "absolute" mode where the indication is compensated if you have pre-amplifiers or attenuators enabled.

The KX3/KX2 MENU setting suggests the feature exists (so does the manual) but the feature is not implemented: the only setting is "tbd".

Symptoms

KX3 configured for a 10 GHz transverter. If power up on the transverter band, very loud buzz on audio output. If power up on any other band, no buzz, and the band can be changed to the transverter band.

Workaround

Always change to another band before turning off and change to transverter band before turning on. If forgot, change to non-transverter band, turn off, turn on, and change back to the transverter band.

Details

KX3 SN 7846 fresh from factory where a 50 MHz TX Pout problem was fixed and firmware was updated to MCU/DSP 2.90/1.52. Configured for use with a 10 GHz transverter in 2020 ARRL 10 GHz and Up contest. Settings changed:

• AFX mode off (was delay)
• ATU bypass (can't remember if it came back this way or not. XVTR is good 50 ohm load.)
• BAT CHG off (was not inst)
• BKLIGHT off (was on)
• MIC BIAS off (I think came back on; used dynamic mic during contest)
• MIC BTN Ptt (was up/down)
• TX DLY 10 (was 5. abundance of caution as 5 is more than enough for the 10 GHz rig I'm running)
• XV1 on
• XV1 RF 10368
• XV1 IF 50
• XV1 PWR 0.1
• XV1 OFS (set in field) 1.20
• XV1 ADR trn1
• set the clock. :-)

Problem observed on 2020-08-15. Ruled out power supply and removed all other equipment. Found the workaround, so continued with the contest.

Smelled like FW issue, but needed to rule out HW.

Reported to Elecraft after the August weekend. As part of trouble shooting, used the KX3 utility to save a configuration file after powering up on the transverter band. Changed to 50 MHz, powered down, powered up, and saved another configuration file.

• SN07846.20200918T022035.KX3Config - powered up on transverter band (buzzing)
• SN07846.20200918T022241.KX3Config - powered up on 50 MHz (no buzzing)

On 2020-10-30, Elecraft emailed that they were able to reproduce the problem on another KX3 with the configuration files. Elecraft said it is a firmware/configuration issue.

Setting the power to three specific power levels (50W, 5W, 1mW) triggers a TXGN calibration procedure and may leave the radio with the TXGN parameters way off.

Because of this, it is ill advised not to select these power levels: set to 51W, or 49W, not 50W.
This behavior is (obscurely) documented in the CONFIG:TXGN parameter in the manual.

It is unsure if KX3 / KX2 are also affected but it is possible given that their code has the same code base.

Lots of discussion on this on the [email protected] mailing list

When setting repeater shift to a value higher than 1000 (for instance, 1600, the shift used on 70cm here), then pressing ALT to switch repeatershift will show "TX -600" or "TX +600" while the shift really is -1600 or +1600 respectively.

This problem happens on KX3 and on K3.

Using a KX3 to drive transverters, it is possible to configure one or more transverters (CONFIG:XV* options). When only a transverter is used, it makes sense to disable the classic HF bands (CONFIG:BND MAP).

HOWEVER, when all HF bands are disabled, only one or more transverterbands are configured, the BAND+/BAND- buttons misbehave: they switch to 28 MHz (which is disabled!) or 3.5 MHz (also disabled!)

This is with the latest firmware known today (2.95/1.52)

The interesting bit is that exactly the same problem also exists in the K3 (latest firmware). May I request this to be fixed on both platforms?

The microphone input is connected to the control panel, U1 via C42 for the audio signal. If MIC BIAS is enabled, 3.3V is sourced from U1 pin 15 via 2k2 resistor R24.

If mic bias is disabled, then pin15 is reprogrammed to be three-state and the input impedance raises. So much, that if one presses XMIT with higher MIC settings, say from 50 onwards, a background buzz is transmitted.

I appreciate the ability to switch off the bias, but with today's low-impendance dynamic microphones, I believe there should a 3rd setting where the same R24 should drive the voltage to ground, avoiding the noise.

While this formally is a hardware problem, this would be an easy to implement software mitigation: mike the MIC BIAS setting a three-state setting: on, off, high-z.

Setting the KX3 to charge its internal batteries with the KXBC3 charger missing causes the firmware to freak out.
I'd expect an error message, but if you try this - make a backup of your settings first!

When trying to change a parameter that is locked under "tech mode", the text "to unlock, hold freq for 3 seconds" show. But the name of the unlock button isn't FREQ, it is RATE, or KHZ.
This is the case on my radio as well as the latest KX3 manual.

For some operations, like sat operations, using dedicated transmitters and receivers are desirable.
The "receiver radio" then is connected to a receive-only converter that doesn't take well if it receives RF power on its output.

The KX3 can be set "TX PWR = 0" but unless TUN POWER is also set to 0 (or set to NORM), pressing the TUN button still generates unhealthy RF power (don't ask how I know!)

Many configurations on KX3 are locked, requiring a deliberate action (long push of RATE button) to unlock.

Feature request is to add a "TX INH" setting that is locked, that will, if set, prevent the KX3 from transmitting and just print a "TX INH" error on the display. Only way to make the radio transmit is to un-set this setting.

It is possible to inhibit the transmitter using ACC2, however that pin is often used for other creative uses.

Doing FM mode on a KX3 (or K3) works, but has limitations.

I am asking:

1. Because FM distorts pretty quick when an FM signal isn't in mid of filter, add a center meter, just like CW mode has
2. Add CTCSS decode (in addition to CTCSS encode) to avoid interference from distance repeaters