¿ªÔÆÌåÓý

Re: #sbitx a software update to fix the spikes #sBitx


 

Btw, just a side note, using a non-atomic control variable and a sleep for thread synchronization is not correct and can create undesired behaviors (apart of the inherent delay). As in some other parts of the code, better use proper thread synchronization primitives. There is a fork that went through the list which fixes some of the thread synchronization issues, for example, in the threads creation. Can anyone remind me that repo address?

Cheers,
Rafael

On 6/7/23 04:09, Ashhar Farhan wrote:

Peeps,
We have seen reports from many users about the blowing up of the PA transistors. There were?hardware reasons for this to happen (like improper?heatsink mounting) these have been fixed through changes in clamping etc.
However, there was a particularly nagging problem of large spikes at the start and end of the transmissions.? See the attached images from the oscilloscope traces. The blue trace is the TX_LINE that goes high on transmit and comes down on receive.
You will note that there is a large burst of RF of 160 v peak to peak at the beginning?and end of transmissions. Sometimes these bursts extend?to 180 v.? The input to the gates of the PA that leads to such high transients exceeds 20v, the breakdown voltage of the PA transistors, leading to catastrophic results.
These needed to be cured and I have been investigating this for sometime now. I finally have arrived at the cause and, thankfully, also an entirely software based fix for it.
The?transient at the beginning?of the transmission is from the function tx_process() in sbitx.c, the main function that generates transmission signal at 24 KHz. The? tx_process handles a bunch of audio samples from the mic at a time, converts it to frequency domain, etc. To prevent abrupt start and end of the? signals, we use prefix samples from a previous block to the current block of samples to make the signal look continuous. This works well, except that the first time you want to transmit, there are no previous samples and that buffer is full of random numbers that mess up the tx output. I added a code to reset the overlap buffers.
The transient at the end of the transmission was discovered to be for those few microseconds where the PA capacitors still have voltage on them while we also open up the T/R switch to bypass the PA, thereby shorting the PA input and output together, creating a nice oscillator that runs until the PA capacitors discharge. The way to stop oscillations is to break the loop. We do this by turning off the LPF switches before switching off the TX_LINE to bypass the PA.
The pictures of the RF output after the patch are given here as well.
I pushed these changes a few minutes ago. I recommend this update to protect your PA.

Join [email protected] to automatically receive all group messages.