Topics

Spurious RF at beginning of CW transmission in the uBitx

n1kw@...
 

When keying my new uBitx transceiver on CW into an antenna, I noticed that just as it transitions to TX mode, the reflected power meter would jump up momentarily and then return to normal. This would happen each time the rig was keyed and went from RX to TX. I suspected spurious output removed from the operating frequency. Looking at the output on a spectrum analyzer there is a nice broadband "mess" produced that I can of course hear in any receiver. Has anyone encountered this problem or know of a fix?

73,
Bob N1KW

 

Warren Allgyer <allgyer@...>
 

I have seen the same thing Bob on the spectrum analyzer. A big burst of wideband energy on the initial character. Mine does it from time to time upon PTT initiation. 

I only got got mine running a couple of days before vacation and am planning to dig into it further this week when I get back to the lab. 

It has has all the symptoms of the PAs going briefly into oscillation. 

WA8TOD

n1kw@...
 

Hi Warren,

Thanks for the reply. I noticed that it occurs on all bands and that the spurious output is always in the same relationship to the operating frequency so I suspect that it is not because of the PA itself going into oscillation as that would certainly be band specific. It seems that if it is a problem common to all bands and frequencies, it could be due to something with one of the local oscillators. I wonder if it is something to do with the firmware or timing issues? I'm sure someone will come up with a solution!
73,
Bob N1KW

Gordon Gibby
 

The digital synthesizer doing something as it settles on frequency?


On Jul 29, 2018, at 19:28, "n1kw@..." <n1kw@...> wrote:

Hi Warren,

Thanks for the reply. I noticed that it occurs on all bands and that the spurious output is always in the same relationship to the operating frequency so I suspect that it is not because of the PA itself going into oscillation as that would certainly be band specific. It seems that if it is a problem common to all bands and frequencies, it could be due to something with one of the local oscillators. I wonder if it is something to do with the firmware or timing issues? I'm sure someone will come up with a solution!
73,
Bob N1KW

 

This is the first I have heard of this issue on the uBITX.  

There was a similar issue with the BITX40 and Allard, PE1NWL implemented a code workaround to suppress it by temporarily shutting down the Si5351 CL2 for about 50ms after PTT closure, to let things settle down before allowing the rig into TX. 

Michael VE3WMB 

Warren Allgyer <allgyer@...>
 

Good info Tom. I still have the Pacific and most of the US between me and my lab but looking forward to getting into it in 24-36 hours. 

WA8TOD

n1kw@...
 

That seems unlikely as the Si5351 itself is very fast. As the data sheet indicates, it has "glitchless frequency changes" in the microsecond range. That is why I suspect an issue with the firmware.

73, Bob N1KW

Jerry Gaffke
 

The "glitchless frequency changes" thing means that when clocking digital logic you don't get a runt clock pulse.
As it turns out, for small frequency changes it's a smooth transition, and a vfo sweep using an si5351 
sounds about as good as an analog vfo.  Large frequency changes will be very abrupt. 
When transitioning to CW transmit,  clk2 is jumping  from 45mhz + operating_frequency to operating_frequency.
The si5351's internal vco remains at a constant 875mhz when using the si5351bx routines
since si5351bx_setfreq() is only messing with the output dividers.
I'd expect the output divider ratio change to be instantaneous. 

However, it does take a couple milliseconds to load all those i2c registers at 100khz for each clock.
So if the transmitter is getting turned on and then the call to si5351bx_setfreq(clk2, operating_freq) is made,
you will have an initial burst of energy for a few milliseconds at 45mhz + operating_frequency.

Here's the original firmware for the uBitx as it was shipped from hfsignals.
Note that the transmitter gets turned on with  digitalWrite(TX_RX, 1);
before any calls to si5351bx_setfreq() get made.  That's clearly wrong.
 

void startTx(byte txMode){
  unsigned long tx_freq = 0;
  digitalWrite(TX_RX, 1);
  inTx = 1;
 
  if (ritOn){
    //save the current as the rx frequency
    ritRxFrequency = frequency;
    setFrequency(ritTxFrequency);
  }
 
  if (txMode == TX_CW){
    //turn off the second local oscillator and the bfo
    si5351bx_setfreq(0, 0);
    si5351bx_setfreq(1, 0);
 
    //shif the first oscillator to the tx frequency directly
    //the key up and key down will toggle the carrier unbalancing
    //the exact cw frequency is the tuned frequency + sidetone
    if (isUSB)
      si5351bx_setfreq(2, frequency + sideTone);
    else
      si5351bx_setfreq(2, frequency - sideTone);
  }
  updateDisplay();
}
 

The calls to turn off clk0 and clk1 should happen pretty quick because with a frequency of 0
the only i2c register write that happens is this:  
    i2cWrite(3, si5351bx_clken); // Enable/disable clock
On returning to receive mode we could restore clk0 and clk1 by again only writing to the clken register,
but the extra few ms of delay incurred by writing to all those i2c registers doesn't really matter then.

Clearly, we should turn the transmitter off with
      digitalWrite(TX_RX, 0);
before restoring the clocks for receive mode.

So I think the extra delay incurred by turning on the transmitter after clk2 has moved 
will be on the order of 2ms.   At 40 WPM, a dot takes 33ms.

I have no idea what the other firmware releases are doing,
but a good chance they are doing the same thing.
 
Jerry, KE7ER



On Mon, Jul 30, 2018 at 01:59 AM, <n1kw@...> wrote:
That seems unlikely as the Si5351 itself is very fast. As the data sheet indicates, it has "glitchless frequency changes" in the microsecond range. That is why I suspect an issue with the firmware.

Tom Cooper
 

I noticed this jump in reflected power on CW also.  There appears to be no corresponding increase on forward power, so I am guessing it is due to the LPF relays.  When the first CW character starts the relays are just closing, so there is some unfiltered RF that is out of band and that is not matched by the tuner. 

73,

Tom  W1EAT

Jerry Gaffke
 

Hmm, the LPF's should knock out my    45mhz + operating_frequency  burp
at the start of a CW transmission, regardless of which filter is selected.
Though the filters aren't perfect.

Also, in an addendum to my previous post, we aren't actually transmitting
until CW_KEY is asserted to unbalance that mixer.
The code is a bit convoluted (as is pretty much all unfamiliar code),
still trying to figure out what happens when here.

Jerry, KE7ER


On Mon, Jul 30, 2018 at 07:37 AM, Tom Cooper wrote:
I noticed this jump in reflected power on CW also.  There appears to be no corresponding increase on forward power, so I am guessing it is due to the LPF relays.  When the first CW character starts the relays are just closing, so there is some unfiltered RF that is out of band and that is not matched by the tuner. 

Jerry Gaffke
 

Not quite as simple as post  55338  suggested, but I do think the fix is to 
mess with the clocks first, and only then assert TX_RX.


Here's the sequence of events at the start of a CW transmission:

main loop continuously calls cwKeyer(), if the paddle was press then
    cwKeyer calls startTX()
        which turns on the TX_RX bit to supply power to the transmit circuits
        calls setFrequency(), which calls setTXFilters(),  and then sets the VFO up for SSB transmit
        shuts down clk0 and clk1, then sets the VFO (which is clk2) at the operating_frequency for CW transmit
    cwKeyer then asserts CW_KEY to actually start transmitting.

So the mixer should not get unbalanced by CW_KEY till the very last thing, good.
And the filters get set up several milliseconds before CW_KEY is asserted since it takes awhile
to do all the i2c writes out to the si5351 when setting clk2 to the operating_frequency.
However, note that the first thing done is to assert TX_RX, so any audio at the mike will
go out over the air as if it were a normal SSB transmission.
This happens before setting up the filters.
And before we start messing with all those clocks.



Here's the pertinent code for the stock uBitx v3 firmware as installed by hfsignals:


:In file ubitx_20.ino:
 
void setFrequency(unsigned long f){
  uint64_t osc_f;
 
  setTXFilters(f);
 
  if (isUSB){
    si5351bx_setfreq(2, SECOND_OSC_USB - usbCarrier + f);
    si5351bx_setfreq(1, SECOND_OSC_USB);
  }
  else{
    si5351bx_setfreq(2, SECOND_OSC_LSB + usbCarrier + f);
    si5351bx_setfreq(1, SECOND_OSC_LSB);
  }
 
  frequency = f;
}
 
 
.....
 
void startTx(byte txMode){
  unsigned long tx_freq = 0;
  digitalWrite(TX_RX, 1);
  inTx = 1;
 
  if (ritOn){
    //save the current as the rx frequency
    ritRxFrequency = frequency;
    setFrequency(ritTxFrequency);
  }
 
  if (txMode == TX_CW){
    //turn off the second local oscillator and the bfo
    si5351bx_setfreq(0, 0);
    si5351bx_setfreq(1, 0);
 
    //shif the first oscillator to the tx frequency directly
    //the key up and key down will toggle the carrier unbalancing
    //the exact cw frequency is the tuned frequency + sidetone
    if (isUSB)
      si5351bx_setfreq(2, frequency + sideTone);
    else
      si5351bx_setfreq(2, frequency - sideTone);
  }
  updateDisplay();
}
 
...
 
// The transmit filter relays are powered up only during the tx so they dont
// draw any current during rx.
void setFrequency(unsigned long f){
  uint64_t osc_f;
 
  setTXFilters(f);
 
  if (isUSB){
    si5351bx_setfreq(2, SECOND_OSC_USB - usbCarrier + f);
    si5351bx_setfreq(1, SECOND_OSC_USB);
  }
  else{
    si5351bx_setfreq(2, SECOND_OSC_LSB + usbCarrier + f);
    si5351bx_setfreq(1, SECOND_OSC_LSB);
  }
 
  frequency = f;
}
 
....
 
 
 
 
In file ubitx_20.keyer:
 
void cwKeyer(){
....
    // if we are here, it is only because the key or the paddle is pressed
    if (!inTx){
      keyDown = 0;
      cwTimeout = millis() + CW_TIMEOUT;
      startTx(TX_CW);
      updateDisplay();
    }
    
    // star the transmission)
    // we store the transmitted character in the lastPaddle
    cwKeydown();
....
 
 
void cwKeydown(){
  keyDown = 1;                  //tracks the CW_KEY
  tone(CW_TONE, (int)sideTone); 
  digitalWrite(CW_KEY, 1);     
  cwTimeout = millis() + CW_TIMEOUT;
}
 

Jerry, KE7ER


On Mon, Jul 30, 2018 at 08:36 AM, Jerry Gaffke wrote:
The code is a bit convoluted (as is pretty much all unfamiliar code),
still trying to figure out what happens when here.

Jerry Gaffke
 

The LPF relays only get powered when TX_RX is asserted, which puts 12 on the TX rail.
So there should be a delay in there between when TX_RX is asserted 
and the first time that CW_KEY is asserted.  This addresses Tom's concern of post   55339

Jerry, KE7ER



On Mon, Jul 30, 2018 at 09:12 AM, Jerry Gaffke wrote:
Not quite as simple as post  55338  suggested, but I do think the fix is to 
mess with the clocks first, and only then assert TX_RX.

ajparent1/KB1GMX
 

Jerry,

There is a simple mod for that.  Rather than a delay in the code that might mess with the first CW character
just apply DC to the relays.

It requires an etch cut between kt3 and K3 and a wire jumper from 12V(power in) and kt1 +Vpin.
Sorry I have no pictures of that just my notes.

What this does is keep power for KT1 though 3 on and separates it from the TX/RX function.
There is no TX RX delays for band pass and in some cases it prevents hot switching of RF
before the contacts are made (more likely with SSB).

Allison

Jerry Gaffke
 

I'd be fine with constantly powering the LPF relays on my rig.
And may be the best solution.

Though does raise power requirements a bit during receive,
an issue for those running from a battery. 
Those few that care could go to latching relays.

Also, we apparently have several thousand uBitx's out in the field now.
We need a firmware fix to not be messing with the clocks while transmitting.
If that fix can also deal with these other issues, then it's a win
for those hesitant to take a knife to their precious uBitx.
Especially since most users won't be sending CW at 20 wpm.

At 20 wpm, a dot is around 60 ms.
Would be interesting to measure how long it takes the LPF relays to turn on
after TX_RX is driven true.  There are two levels of relays involved there,
first the T/R relay has to supply power to the TX rail.  Maybe 20ms total?
And need additional delay to add a margin of safety.
So getting iffy.

Jerry, KE7ER



On Mon, Jul 30, 2018 at 10:29 AM, ajparent1/KB1GMX wrote:
Jerry,

There is a simple mod for that.  Rather than a delay in the code that might mess with the first CW character
just apply DC to the relays.

It requires an etch cut between kt3 and K3 and a wire jumper from 12V(power in) and kt1 +Vpin.
Sorry I have no pictures of that just my notes.

What this does is keep power for KT1 though 3 on and separates it from the TX/RX function.
There is no TX RX delays for band pass and in some cases it prevents hot switching of RF
before the contacts are made (more likely with SSB).

Allison

Jerry Gaffke
 

A possible firmware fix for the LPF relay delay would be to add a pipeline delay
to all CW code elements, not just the starting edge of the transmission.
The sidetone could happen immediately, so the operator would not notice a difference.

Jerry


On Mon, Jul 30, 2018 at 11:17 AM, Jerry Gaffke wrote:
At 20 wpm, a dot is around 60 ms.
Would be interesting to measure how long it takes the LPF relays to turn on
after TX_RX is driven true.  There are two levels of relays involved there,
first the T/R relay has to supply power to the TX rail.  Maybe 20ms total?
And need additional delay to add a margin of safety.
So getting iffy.

ajparent1/KB1GMX
 

Generally 10-20MS is fast for a relay.

Keep in mind for 80M, 5 relays have to switch so you always plan for the slowest
which in the case of this is a cascade of two.

To go to transmit The Raduino activates K1, TX+ is its output and that activates the remaining 
3 band pas filter relays as needed and K3 always.

So RX to TX switching is the sum of K1 and K3 switching time.  20mS would be optimistic.

Allison

n1kw@...
 

It appears that I have solved the problem! While analyzing the circuit further, I realized that the large capacitor C52, which is charged during receive, would feed back through R52 and R18 keeping the receive path (Q10, 11, and 12) after the balanced modulator "hot" for a brief period. When the transmit path is activated, the receive side of the circuit is going to remain on for some period of time due to the time constants of C52 and its loads. It is understandable that if both directions of the circuit are on, it could oscillate during that time!

To resolve the issue I simply added a diode in series with R52 (cathode toward C52) so that C52 can no longer back feed power to Q10, 11, and 12 upon initiation of transmit state. Now the transmitter output looks perfectly clean on the spectrum analyzer at beginning if TX. Shorting the diode causes the problem to show as before.

The same issue could apply to C64 when transitioning from TX to RX but at least there will not be spurious emissions going out over the air. I will add a diode in series with R66 in the same manner just for fun!

My apologies for suspecting that it could possibly a firmware issue!!!

Next I will address the CW keying shape which seems to have about 0.5 ms rise and fall times, far too short!

73,
Bob N1KW

Gordon Gibby
 

​good detective work, n1kw!!



From: BITX20@groups.io <BITX20@groups.io> on behalf of n1kw@... <n1kw@...>
Sent: Monday, July 30, 2018 4:39 PM
To: BITX20@groups.io
Subject: Re: [BITX20] Spurious RF at beginning of CW transmission in the uBitx
 

It appears that I have solved the problem! While analyzing the circuit further, I realized that the large capacitor C52, which is charged during receive, would feed back through R52 and R18 keeping the receive path (Q10, 11, and 12) after the balanced modulator "hot" for a brief period. When the transmit path is activated, the receive side of the circuit is going to remain on for some period of time due to the time constants of C52 and its loads. It is understandable that if both directions of the circuit are on, it could oscillate during that time!

To resolve the issue I simply added a diode in series with R52 (cathode toward C52) so that C52 can no longer back feed power to Q10, 11, and 12 upon initiation of transmit state. Now the transmitter output looks perfectly clean on the spectrum analyzer at beginning if TX. Shorting the diode causes the problem to show as before.

The same issue could apply to C64 when transitioning from TX to RX but at least there will not be spurious emissions going out over the air. I will add a diode in series with R66 in the same manner just for fun!

My apologies for suspecting that it could possibly a firmware issue!!!

Next I will address the CW keying shape which seems to have about 0.5 ms rise and fall times, far too short!

73,
Bob N1KW

n1kw@...
 

Thanks Gordon! I have a simple solution in mind for the keying shape issue. I'll try it and, if it works, I will post it under a new thread.

73, Bob N1KW

Arv Evans
 

On Mon, Jul 30, 2018 at 01:39 PM, <n1kw@...> wrote:
Bob N1KW

Every since the first BITX we have griped and complained about the 20 ms infamous "BITX Click"
that occurs in changing over from receive to transmit and from transmit to receive.  Earlier tests
indicated that it was somehow associated with hold-over voltage on capacitors between audio circuits
and the balanced modulator.  Is it possible that you have now found, and fixed, that long-standing
problem?

It appears that I have solved the problem! While analyzing the circuit further, I realized that the
large capacitor C52, which is charged during receive, would feed back through R52 and R18
keeping the receive path (Q10, 11, and 12) after the balanced modulator "hot" for a brief period.
When the transmit path is activated, the receive side of the circuit is going to remain on for some
period of time due to the time constants of C52 and its loads. It is understandable that if both
directions of the circuit are on, it could oscillate during that time!


To resolve the issue I simply added a diode in series with R52 (cathode toward C52) so that C52
can no longer back feed power to Q10, 11, and 12 upon initiation of transmit state. Now the transmitter
output looks perfectly clean on the spectrum analyzer at beginning if TX. Shorting the diode causes
the problem to show as before.


If this fixes that long-standing problem, then we all owe you a big THANK YOU

Arv K7HKL
_._