Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regarding SSB demodulation #100

Open
bahari opened this issue Sep 30, 2024 · 12 comments
Open

Regarding SSB demodulation #100

bahari opened this issue Sep 30, 2024 · 12 comments

Comments

@bahari
Copy link

bahari commented Sep 30, 2024

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
Copy link
Owner

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
Copy link
Author

bahari commented Oct 1, 2024

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
Copy link
Owner

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
Copy link
Author

bahari commented Oct 2, 2024

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
Copy link
Contributor

penfold42 commented Oct 2, 2024

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
Copy link
Contributor

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
Copy link
Author

bahari commented Oct 2, 2024

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
Copy link
Author

bahari commented Oct 2, 2024

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
Copy link
Owner

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
Copy link
Author

bahari commented Oct 4, 2024

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
Copy link
Contributor

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants