search

dawsonjon / PicoRX

Build a SDR SW/MW/LW Receiver with a Raspberry Pi Pico
Other
252 stars 32 forks source link

Regarding SSB demodulation #100

Open bahari opened 1 month ago

bahari commented 1 month ago

I noticed a major update in the new release code regarding LSB and USB demodulation. At which part on the latest code did you put the SSB modulation process?, there is a major update compared to previous code that I used. I'm in the middle try to understand your code design. I'm really appreciate if you can give me a brief explanation, Thank you

dawsonjon commented 1 month ago

Sure, the most significant change is the move to FFT based filtering in the frequency domain. This method of filtering is inherently more efficient than filtering in the time domain and allows much sharper (brick wall) filters to be implemented without any significant increase in CPU usage.

Other benefits are that it is now possible to modify the filter bandwidth on the fly, and it opens up the possibility of other more dynamic frequency domain filtering such as the adaptive notch filter.

SSB demodulation also becomes much simpler under the new scheme. It is easy to suppress the unwanted sideband simply by removing either the positive or negative frequency bins (in effect making a complex filter with an asymmetric frequency response). Once the unwanted sideband is removed, the demodulation is a trivial matter of selecting either the real or imaginary component.

I will update the documentation, and probably do another video once the next batch of software updates are completed. In the meantime, let me know if you have any questions and I will be happy to help.

bahari commented 1 month ago

Thanks for the information, I'm really appreciate it. Is it possible to improvise the code to include a noise ratio option so that we can reduce the background noise? or is it any way to reduce the background noise,

dawsonjon commented 1 month ago

I don't think there are any magic solutions to this, HF bands are inherently quite noisy due to atmospheric effects. There are things that can be done to help, starting with the choice of antenna, using the best possible antenna setup will probably give the best improvement overall. Some antennas are more sensitive to noise than others, a horizontal dipole is less susceptible to noise than a vertical antenna, and directional antennas can be positioned to minimise noise. It's also a good idea to minimise loss in the antenna feed line, by using good quality cable and keeping the cable length as short as possible. Adding a low noise amplifier to the close to the antenna will also improve the overall noise performance too. It's worth minimising any local sources of RFI, try unplugging things and see if the situation improves. You could also try minimising PSU noise, add plenty of decoupling capacitors, and it's sometimes worth experimenting with their location. In software, you can minimise background noise by using the narrowest possible bandwidth settings. It is also possible to implement noise reduction using spectral subtraction techniques. It's something I would like to implement, and that was part of the motivation for the frequency domain filtering. Its definitely something that I would like to look at!

bahari commented 1 month ago

Basically I compare the receiving noise with my home brew USDX based radio with the same antenna setup. For my existing home brew rig the background noise are not as much as the Pico radio. One more thing, regarding RX gain calibration in the HW config menu, it is only to calibrate the base value for signal strength and spectrum measurements right?

penfold42 commented 1 month ago

One more thing, regarding RX gain calibration in the HW config menu, it is only to calibrate the base value for signal strength and spectrum measurements right?

Yep and squelch

penfold42 commented 1 month ago

Basically I compare the receiving noise with my home brew USDX based radio with the same antenna setup. For my existing home brew rig the background noise are not as much as the Pico radio.

Do they have the same front ends ? same mux, same opamp ? It would be an interesting comparison to use the frontend from the USDX with the pico

bahari commented 1 month ago

Do they have the same front ends ? same mux, same opamp ? It would be an interesting comparison to use the frontend from the USDX with the pico

For PicoRX, I'm using the same components for Tayloe detector used by my (USDX) home brew rig. The difference only on LPF part, for my PicoRX I'm only implements 0-30MHz LPF, but with my USDX there is a pre-LPF for each bands of interest plus final LPF for TX second harmonics suppression. Later I will shared my setup picture.

bahari commented 1 month ago

I'm very interested with PicoRX projects since it's not using external local oscillator for Tayloe detector. I hope I can build a transmitter with the same design without using external local oscillator as describes on @dawsonjon tutorial.

dawsonjon commented 1 month ago

I wonder if the usdx values might give a bandwidth that is too narrow? I think that 82k and 1nF give a bandwidth of about 2kHz, but the Pico Rx uses an IF of 6kHz?

Still very keen to add the transmit capability, watch this space!

bahari commented 1 month ago

I wonder if the usdx values might give a bandwidth that is too narrow? I think that 82k and 1nF give a bandwidth of about 2kHz, but the Pico Rx uses an IF of 6kHz?

Still very keen to add the transmit capability, watch this space!

Yes you're correct USDX Tayloe detector bandwidth are set at approximately 2kHz. If I'm not mistaken PicoRX the first version are set to 12kHz and not 6kHz, correct me if I'm wrong

penfold42 commented 1 month ago

The pdf schematic at https://github.com/dawsonjon/PicoRX/blob/master/PCB/pico_rx/pipicorx.pdf shows 15n caps which should give a QSD cutoff of 45kHz

The breadboard at https://101-things.readthedocs.io/en/latest/_images/breadboard_radio_schematic.svg shows 56n caps at states 12kHz.

dawsonjon commented 1 month ago

I'm currently using about 12kHz bandwidth in the Tayloe detector. The Pico Rx uses a low-IF frequency, the local oscillator is tuned 6kHz either side of the dial frequency (or as close as possible). This means that the wanted signal ends up at + or -6kHz, this is then shifted back to the centre in software. This really helps remove all the noise and interference around DC.

The 2kHz bandwidth detector that's used in the USDX is too narrow to work well with the picorx, the wanted signal at +/-6kHz will be outside the passband of the detector and will be significantly attenuated.

bahari commented 1 month ago

I'm currently using about 12kHz bandwidth in the Tayloe detector. The Pico Rx uses a low-IF frequency, the local oscillator is tuned 6kHz either side of the dial frequency (or as close as possible). This means that the wanted signal ends up at + or -6kHz, this is then shifted back to the centre in software. This really helps remove all the noise and interference around DC.

The 2kHz bandwidth detector that's used in the USDX is too narrow to work well with the picorx, the wanted signal at +/-6kHz will be outside the passband of the detector and will be significantly attenuated.

Understood @dawsonjon, Sorry for misunderstanding regarding 6kHz IF frequency implementations. No wonder when I increasing the Tayloe Detector bandwidth to 12kHz the reception was far more better compared to 2kHz bandwidth. Is it ok to maintain the same feedback resistor and capacitor as a gain control for the preamplifier? same as USDX?

dawsonjon commented 1 month ago

You might see additional benefits by reducing the .47uf sampling capacitors, assuming the source impedance is 50 ohms (which it might not be), the source impedance combined with switch resistance and sampling capacitors give a cutoff of about 1.5kHz.

It's a bit harder to be precise here because it's difficult to say what the source impedance really is. You could adjust the resistors to give you more gain if you like, but you probably won't yet more than a few dB extra gain from a single op-amp stage.