Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Spurious RF at beginning of CW transmission in the uBitx
|
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
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 |
|
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
toggle quoted message
Show quoted text
|
|
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? |
|
The "glitchless frequency changes" thing means that when clocking digital logic you don't get a runt clock pulse.
toggle quoted message
Show quoted text
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. |
|
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 |
|
Hmm, the LPF's should knock out my? ? 45mhz + operating_frequency? burp
toggle quoted message
Show quoted text
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.? |
|
Not quite as simple as post? 55338? suggested, but I do think the fix is to?
toggle quoted message
Show quoted text
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), |
|
The LPF relays only get powered when TX_RX is asserted, which puts 12 on the TX rail.
toggle quoted message
Show quoted text
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? |
|
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 |
|
I'd be fine with constantly powering the LPF relays on my rig.
toggle quoted message
Show quoted text
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, |
|
A possible firmware fix for the LPF relay delay would be to add a pipeline delay
toggle quoted message
Show quoted text
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. |
|
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 |
|
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! |
|
Gordon Gibby
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> on behalf of n1kw@... <n1kw@...>
Sent: Monday, July 30, 2018 4:39 PM To: [email protected] 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! |
|
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 _._ |
to navigate to use esc to dismiss