Hallo Glen,
no, I only refer to SSB exploding in bandwidth when nonlinear distortion
occurs. Standard compression is no good choice to improve PAPR.
What do you mean with 'hard' processed SSB ? The only reasonable way I
know is David's, W9GR, methode CESSB (controlled envelope single
sideband). But this fine SSB signal can't prevent IM in the typical
hamradio PA with 30 dB (PEP)/24 dB 2-tone IMD. This insufficient
linearity causes the 'explosion of bandwidth'. No operator can prevent
this. 30 dB (PEP) IMD is too less!
Helmut, DC6NY
Am 23.09.2026 um 00:06 schrieb glen english LIST:
Hi Helmut,
with reference to "The nominal 3 kHz bandwidth explodes up to 10 and
more kHz. Only HPSDR based radios are able to linearize internal*+
*external poweramps by means of adaptive digital predistortion."
are you referring to RADE exploding in bandwidth ?
If the transmitter is behaviin well, and dynamic behaviour is
suitable, then the bandwidth will not expand from that injected into
the audio input..
bandwidth only expands on SSB transmissions if the user adjusts their
radio incorrectly. bandwidth will expand if there is amplitude
distortion post the transmitting IF sideband filter (overdriving the
PA, poor ALC loop behaviour/ excessive reliance on ALC function)
That's why RF speech processing prior to the SSB filter is so
effective as modulation and bandwidth control
-glen
On 22/09/2026 17:53, Helmut Oeller via Freetel-codec2 wrote:
wow, what a discussion I triggered, hi. Why it's so difficult to
accept RADE's superiority compared with SSB. Hard compressed SSB is
no benchmark, it's a wonderful intermodulation generator at least for
legacy radios. The nominal 3 kHz bandwidth explodes up to 10 and more
kHz. Only HPSDR based radios are able to linearize internal*+
*external poweramps by means of adaptive digital predistortion.
Helmut, DC6NY
Am 22.09.2026 um 06:41 schrieb Mooneer Salem:
The RADE paper has estimates of how much CPU is needed:
https://arxiv.org/abs/2505.06671. Hope this helps!
-Mooneer K6AQ
On Mon, Sep 21, 2026, 6:58 PM glen english LIST
<[email protected]> wrote:
a while back, years now, I floated a "SM3000" project using
FPGA +SoC (integrated) hardware.
Then at about same time, LPCnet etc was the new kid on the block.
Suddenly, the horsepower required took a big hike. So, project
went on hold
I have a bit more time up my sleeve, and substantial resources
to make this happen. I'm doing another priject right now that
has a hard-burned in CNN into the fpga fabric (no moving weights
out of memory to the transformers) (fpga reconfigures itself
every few 100uS to adopt a different function )
Target would be at least RADE.
But I am not in the loop enough to understand computational
requirements.
If someone has time, they might converse with me here, or
privately about computational requirements.
It is also important to consider, that when there is an FPGA
involved, computational requirements of a software written
task can be quite different if parallel fpga resources can be
thrown at something. IE mixed implementation, which can save
alot of power. And saving power means a much simpler mechanical
design, because designs that make lots of heat need more
advanced metalwork ideas to get rid of the heat . But that's a
bit beyond this discussoon.
Such a design also needs plenty of capability in hand at Rev 1,
because fearyures and scope and capability requirementts always
increase.
-glen
On 22/09/2026 11:36, Ashhar Farhan wrote:
We are assuming that with compression, the pa linearity holds.
Which is usually not the case. Advantage RADE
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
