Pages: [1]
|
|
|
|
Author
|
Topic: NR causes glitch (Read 1633 times)
|
|
|
SP9BSL
positron alter Hase
Offline
Posts: 443
|
|
Re:NR causes glitch
« Reply #1 on: 04. November 2020, 19:56:51 »
|
|
Hi Chuck, you have different filter width, try the same 2.7k on both.
|
|
Logged
|
73 Slawek
|
|
|
WD8BXS
alter Hase
Offline
Posts: 286
|
|
Re:NR causes glitch
« Reply #2 on: 04. November 2020, 20:39:55 »
|
|
Yes, the narrower bandwidth helps.
I wonder why??
|
|
Logged
|
Thanks, De WD8BXS vy 73
|
|
|
|
WD8BXS
alter Hase
Offline
Posts: 286
|
|
Re:NR causes glitch
« Reply #4 on: 05. November 2020, 13:00:52 »
|
|
Hello Andreas, Good day to you!
I have 3 radios here , all original M0NKA 6.3 versions, all using SPI, all act the same way, when bandwidth is above 2.7 tuning slows down.
I tried complete reset (F1 + F3 + F5) to defaults, and the radio still acts the same way. Do you think it may be because of the SPI??
TNX, Vy 73, de Chuck
|
|
Logged
|
Thanks, De WD8BXS vy 73
|
|
|
|
SP9BSL
positron alter Hase
Offline
Posts: 443
|
|
Re:NR causes glitch
« Reply #6 on: 05. November 2020, 16:28:18 »
|
|
Hi, I have the mcHF with parallel 480x320 display and see slow down when switching to 2.9kHz wit NR enabled. I think there was an discussion about this, but I can't find it.
|
|
Logged
|
73 Slawek
|
|
|
|
DD4WH
positron alter Hase
Offline
Posts: 462
Ich liebe dieses Forum!
|
|
Re:NR causes glitch
« Reply #8 on: 06. November 2020, 14:41:08 »
|
|
The spectral noise reduction represents quite a heavy load for the MCU (see here for the specific algorithm we use: https://github.com/df8oe/UHSDR/wiki/Noise-reduction).
Nyquist dictates that we can only process frequencies in DSP, that are lower than half the sample rate, otherwise we hear aliasing.
For the spectral noise reduction, as far as I remember (its a long time since we programmed it), the internally used sample rate of 48ksps is decimated down to 6ksps, making the processing a lot easier for the MCU (factor of 8 !).
If filter BW is above 2.7kHz, we need a higher internal sample rate in order to avoid aliasing, thus we use a decimation to 12ksps (factor of 4). This means that the effort for the MCU to perform the calculations for the NR is exactly twice as high as for lower bandwidths.
I suspect it is this which causes the observed phenomena and the differences in "sluggishness" for 2.7 and 2.9kHz filter bandwidth.
All you can do about this is use the narrower bandwidth of 2.7kHz (or use a faster processor :-)
73 Frank DD4WH
|
|
Logged
|
----------------------------------------- Teensy Convolution SDR https://github.com/DD4WH/Teensy-ConvolutionSDR
|
|
|
WD8BXS
alter Hase
Offline
Posts: 286
|
|
Re:NR causes glitch
« Reply #9 on: 06. November 2020, 18:31:27 »
|
|
So, help me understand... When I got involved with this radio, I remember everyone saying that SPI was better.
So what changed?? And why?? And will the firmware still work with the parallel?
Has anyone changed a 6.3 over to parallel with any success??
TNX de Chuck
|
|
Logged
|
Thanks, De WD8BXS vy 73
|
|
|
|
WD8BXS
alter Hase
Offline
Posts: 286
|
|
Re:NR causes glitch
« Reply #11 on: 06. November 2020, 19:23:10 »
|
|
I think the confusion was with this statement from the recommended modifications doc. UI 0.5 HY28B/HY28A
"This will be used in future to get some more GPIO pins for further enhancements. There are big advancements in the speed of SPI mode in the last months. This change is (not yet) necessary."
Sounded like you were going to use the extra GPIO later.
I do know that the display manufacturer did stop production on the HY28B and they said they improved it. I wonder if is any better in Parallel mode now?
I thought I saw a post earlier about someone who was trying to convert a 6.3 over. But I can't seem to see it now.
de Chuck
|
« Last Edit: 06. November 2020, 21:16:48 by WD8BXS » |
Logged
|
Thanks, De WD8BXS vy 73
|
|
|
Pages: [1]
|
|
|
|
|
|
|