Topics

burst of harmonics during CW key-down?

Adrian Chadd
 

hi!

I've noticed on my ubitx4 that when you key down for the first CW tone (when it transitions RX->TX and transmits a tone) I get some pretty hefty harmonics out before it settles down. Subsequent CW tones whilst TX is asserted is fine.

It shows up on an LED SWR meter as a quick, bright flicker before it settles in OK.

I'm running the stock firmware with a couple of other bugfixes (like changing LSB<->USB doesn't immediately reprogram in the correct VFO until you change frequency..)

Has anyone else seen this? Is this fixed in Ian's firmware? (I checked out the source code and I can't see anything obviously fixing TX<->RX timing or the order which oscillators are gated/programmed.) Or should I go and dig into it a bit myself?

Thanks!


-adrian

Joe Puma
 

Yes search for carrier burst in the threads and you’ll find your answer. I just did the mod on mine. I also noticed that if you have RF issues in the rig it will show a power surge in meter and you might hear some RF noise in speaker during the delay time of a CW unkey. I was getting RF in the pan adapter wire I installed. 

Joe
KD2NFC 



On Apr 17, 2019, at 5:27 PM, Adrian Chadd <adrian@...> wrote:

hi!

I've noticed on my ubitx4 that when you key down for the first CW tone (when it transitions RX->TX and transmits a tone) I get some pretty hefty harmonics out before it settles down. Subsequent CW tones whilst TX is asserted is fine.

It shows up on an LED SWR meter as a quick, bright flicker before it settles in OK.

I'm running the stock firmware with a couple of other bugfixes (like changing LSB<->USB doesn't immediately reprogram in the correct VFO until you change frequency..)

Has anyone else seen this? Is this fixed in Ian's firmware? (I checked out the source code and I can't see anything obviously fixing TX<->RX timing or the order which oscillators are gated/programmed.) Or should I go and dig into it a bit myself?

Thanks!


-adrian

Adrian Chadd
 

hi!

Ok, I see the fix for the bitx40 firmware fork. I'll go test it out on afarhan's bitx40 firmware and if it works i'll send him a pull request. Hopefully I can get it into the normal v4 and v5 firmware trees.

Thanks!


-adrian


On Wed, 17 Apr 2019 at 16:39, Joe Puma <kd2nfc@...> wrote:
Yes search for carrier burst in the threads and you’ll find your answer. I just did the mod on mine. I also noticed that if you have RF issues in the rig it will show a power surge in meter and you might hear some RF noise in speaker during the delay time of a CW unkey. I was getting RF in the pan adapter wire I installed. 

Joe
KD2NFC 



On Apr 17, 2019, at 5:27 PM, Adrian Chadd <adrian@...> wrote:

hi!

I've noticed on my ubitx4 that when you key down for the first CW tone (when it transitions RX->TX and transmits a tone) I get some pretty hefty harmonics out before it settles down. Subsequent CW tones whilst TX is asserted is fine.

It shows up on an LED SWR meter as a quick, bright flicker before it settles in OK.

I'm running the stock firmware with a couple of other bugfixes (like changing LSB<->USB doesn't immediately reprogram in the correct VFO until you change frequency..)

Has anyone else seen this? Is this fixed in Ian's firmware? (I checked out the source code and I can't see anything obviously fixing TX<->RX timing or the order which oscillators are gated/programmed.) Or should I go and dig into it a bit myself?

Thanks!


-adrian

Jerry Gaffke
 

Far as I know, stock Bitx40 code remains exactly as it was when it first shipped in Dec of 2016.
Warts and all.
Good luck with that pull request.

These rigs are great as a vehicle for learning about radios.
They work as shipped, but could use a number of enhancements.
As you can see, lots of forum members are enjoying that process.
Many enhancements to the Bitx40 and uBitx have been posted to the forum,
but for the most part the kits continue to come with a minimum of changes.

I suggest you try Allard's code for the Bitx40, it is a major clean up of the stock Bitx40 code.
He has a fix for the PTT carrier burst.
    https://github.com/amunters
The Bitx40 code there works without any hardware mods, though some minor mods will add quite a few features.
The Bitx40-raduino-v2 code is similar but requires hardware mods, and gives many additional features.
If you find bugs, Allard may update his code to incorporate your fix.

Jerry, KE7ER


On Wed, Apr 17, 2019 at 06:14 PM, Adrian Chadd wrote:
Ok, I see the fix for the bitx40 firmware fork. I'll go test it out on afarhan's bitx40 firmware and if it works i'll send him a pull request. Hopefully I can get it into the normal v4 and v5 firmware trees.
 

Adrian Chadd
 

Oh sorry I messed up my last response. my ubitx v4 has this behaviour. I see the fix in the bitx40 firmware fork, sure; I'm going to try porting it to my ubitx v4 firmware fork and see if it works OK.


-adrian

Adrian Chadd
 

Hi!

ok, so i fixed it in my fork:


This /seems/ applicable to all versions of the ubitx (3, 4, 5.) It's a mostly straight port from the bitx40 fork that fixed it.

Ian and other firmware hackers - would you mind taking a look and see if it makes sense?

Thanks!


-adrian
(kk6vqk)

John (vk2eta)
 

Thank you Adrian.

I also noted this affects my V3 uBitx and I will apply the mods to my customized version.

I am just surprised that a delay of 15ms is necessary after sending the clock shutdown command, presumably for the si5351 chip to stop its clock.

That's a 67Hz on/off max frequency and seems out of proportion with the clock frequencies generated (lowest is 3.5MHz in CW mode for the stock version) or even when compared with the transmission of the 8 registers needed to program the si5351 clock frequencies over the i2c bus which should take less than 1ms per clock.

I must be missing something.

The 30ms for the relays/TX power stabilization make sense to me on the other hand,

Best 73, John (VK2ETA)

Adrian Chadd
 

oh I based it on a 65ms delay on the bitx40 fork. I haven't actually measured it yet! midnight hackery and all that.



-adrian

On Thu, 18 Apr 2019 at 03:25, John (vk2eta) <vk2eta@...> wrote:
Thank you Adrian.

I also noted this affects my V3 uBitx and I will apply the mods to my customized version.

I am just surprised that a delay of 15ms is necessary after sending the clock shutdown command, presumably for the si5351 chip to stop its clock.

That's a 67Hz on/off max frequency and seems out of proportion with the clock frequencies generated (lowest is 3.5MHz in CW mode for the stock version) or even when compared with the transmission of the 8 registers needed to program the si5351 clock frequencies over the i2c bus which should take less than 1ms per clock.

I must be missing something.

The 30ms for the relays/TX power stabilization make sense to me on the other hand,

Best 73, John (VK2ETA)

Adrian Chadd
 

.. (and morning hackery - i hit send too quickly.)

I measured the RF output but I didn't measure the time it takes to gate the si5351. I have a bunch of breakout boards so I can go do that measurement separate from the ubitx and tweak that constant later. The bitx40 just sleeps for 65ms when turning on. I elected to split it up into two #defines so we can tweak each phase later on based on actual measurements.

Ok, now I'll get coffee. ;-P


-a


On Thu, 18 Apr 2019 at 03:25, John (vk2eta) <vk2eta@...> wrote:
Thank you Adrian.

I also noted this affects my V3 uBitx and I will apply the mods to my customized version.

I am just surprised that a delay of 15ms is necessary after sending the clock shutdown command, presumably for the si5351 chip to stop its clock.

That's a 67Hz on/off max frequency and seems out of proportion with the clock frequencies generated (lowest is 3.5MHz in CW mode for the stock version) or even when compared with the transmission of the 8 registers needed to program the si5351 clock frequencies over the i2c bus which should take less than 1ms per clock.

I must be missing something.

The 30ms for the relays/TX power stabilization make sense to me on the other hand,

Best 73, John (VK2ETA)

Jerry Gaffke
 

Adrian,

Thanks for posting your code!
Curious that it hadn't been addressed on the uBitx yet by anyone,
given that it was a known problem on the Bitx40.

Jerry, KE7ER


On Thu, Apr 18, 2019 at 12:39 AM, Adrian Chadd wrote:
ok, so i fixed it in my fork:
 
 
This /seems/ applicable to all versions of the ubitx (3, 4, 5.) It's a mostly straight port from the bitx40 fork that fixed it.
 
Ian and other firmware hackers - would you mind taking a look and see if it makes sense?
 
Thanks!

John (vk2eta)
 

Thanks Adrian.

I understand the logic.

If you make actual measurements please let us know.

All the best,

73, John