Title: NR causes glitch
Post by: WD8BXS on 04. November 2020, 19:48:28
Check out this video from a friend!
When NR is on the radio tuning slows way down.
When NR is off all is OK.
https://photos.google.com/share/AF1QipN_XFgH3YOg4awZuTjJ7D2n71xOoRIaVxhny5VEgGoyn7ZhPJ-1VqPXVrlZPhd2iA?key=dzlzc09RZnJNaWRHSU5VX2R4SWktN2E5OVVTOWRn
All settings are the same in another radio I have and it works fine.
Any ideas??
TNX, de Chuck WD8BXS |
Title: Re:NR causes glitch
Post by: SP9BSL on 04. November 2020, 19:56:51
Hi Chuck,
you have different filter width, try the same 2.7k on both. |
Title: Re:NR causes glitch
Post by: WD8BXS on 04. November 2020, 20:39:55
Yes, the narrower bandwidth helps.
I wonder why?? |
Title: Re:NR causes glitch
Post by: DF8OE on 05. November 2020, 05:02:11
Hi Chuck,
are LCD connections the same (SPI / parallel)? If so:
Reset all settings to default and start from all values default. There are some settings which cannot live together. Some settings cannot be accessed by hand and there are many settings in complete. It is nearly impossible to fix that without a complete reset (F1+F3+F5)
vy 73
Andreas |
Title: Re:NR causes glitch
Post by: WD8BXS 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 |
Title: Re:NR causes glitch
Post by: DF8OE on 05. November 2020, 13:21:30
Yes, definitely.
vy 73 - take care
Andreas |
Title: Re:NR causes glitch
Post by: SP9BSL 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. |
Title: Re:NR causes glitch
Post by: DF8OE on 05. November 2020, 17:03:30
Horse power is missing at 2.9KHz band width.... The cycle length has left only a handfull milliseconds. If LCD is in SPI mode we leave cycle length of loop when NR is activated at higher rates.
vy 73
Andreas |
Title: Re:NR causes glitch
Post by: DD4WH 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 |
Title: Re:NR causes glitch
Post by: WD8BXS 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 |
Title: Re:NR causes glitch
Post by: DF8OE on 06. November 2020, 18:58:33
Hardware development by Chris and software development by UHSDR team was not always in sync - sorry. LCD in parallel mode is the preferred mode - it causes less rf impacts and uses less MCU ressources. Parallel mode of the newest HY28B was not stable. That is a quality problem of LCD manufacturer.
I by myself have left mcHF hardware design long time ago. I am using OVI40 UI since nearly 3 years. But mcHF design still is supported! Parallel mode of LCD is much preferred.
vy 73
Andreas |
Title: Re:NR causes glitch
Post by: WD8BXS 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 |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|