Test results for 2.7.61 to 2.7.63

[WM0I]

Transceiver is RS-918ssb, a McHF clone Info says, Display HY28B SPI Disp. Controller ILI9325 CPU 413H Flash Size 512KB RAM Size 192 Audio Codec Presence YES

Results no change in NR on all 3 version. The settings in the debug menu have no effect on the noise floor or the notch filter. When I turn on the transceiver on with any of the versions 2.7.61, 2.7.62 or 2.7.63 the DSP setting is NR+Notch is on. The red led pulses and the audio volume goes up and down in sync with the red led. I turn the DSP completely off and the red led goes out and the audio becomes stable but with a high noise floor. Adjusting the values in the Debug menu have no effect on the noise floor.

Version 2.7.31 is the best so far. What I like to do is send you an audio files showing how the Noise floor is so far reduced. I am also thinking of sending you a complete list of menu settings and display settings. It may take a few days to collect everything. Here is the recorded audio which sounds so much like FM radio. rs-918ssb audio.zip

Best regards WM0I

[df8oe]

Hi Rich,

many thanks for your reports - but I absolutely cannot confirm - under no circumstances. I think you are only using one setting ("Release") - and that is missing the most power.

The best one is 2.7.63. The difference to 2.7.31 is gigantic.

Please try setting "NR Mode Devel2" and take allok.

Sadly you own a device which will be at the limits the next days or weeks. A MCU with 512KB is absolutely outdated and will not get further updates when firmware will grow about that limit. We are already scraping at this border.

One reason I never would tell someone to buy one of these clones...

Very easy solution: swap the MCU to STM32F427, 429 or 439 VIT6 with 2MB flash and 256KB RAM ;)

Best regards DF8OE

[df8oe]

Additionally I do not recomend to use LCD in SPI mode. This mode frees up some GPIOs for other purposes (like RTC). Bt at the other hand SPI mode is more noisy as parallel mode. McHF and all of the clones are "at their edge" there. It will not be possible for mcHF to follow with all the goodies we will implement because of a lack of free GPIOs and a lack of RAM.

So it would be a good idea to switch LCD to parallel mode for first reducing "homemade noise". Possibly it will be neccessary to remove RTC mod - you cannot get low noise floor AND RTC at mcHF simultaneously. Hardware design suffers to get that. Running LCD in parallel mode you can much better compare the different NR approaches. If your radio does have very high noise floor (like running LCD in SPI mode) probably you cannot get best results.

vy 73 Andreas

[WM0I]

How do I change the LCD to parallel mode?

[WM0I]

Here are my settings for the audio file I sent you.

[Tibet4690]

I greatly value all the work you have put into this project... but with all due respect, I do not understand some of these claims you are making.

"Sadly you own a device which will be at the limits the next days or weeks. A MCU with 512KB is absolutely outdated and will not get further updates when firmware will grow about that limit. We are already scraping at this border."

"One reason I never would tell someone to buy one of these clones..."

Seems to contradict what you said here, "McHF and all of the clones are "at their edge" there. It will not be possible for mcHF to follow with all the goodies we will implement because of a lack of free GPIOs and a lack of RAM."

This is an issue that is faced by anyone using an older "genuine" revision of mcHF is it not? I haven't followed the latest revisions of the mcHF project, but I'm sure there are users... with genuine hardware, facing the very same issues as WM0I.

It's exciting seeing this project progress and require more substantial hardware. I totally understand why you don't want to hold it back by catering to the minimum hardware out there, its a dilemma just about all developers face. GL and I look forward to seeing what you guys come up with next.

[df8oe]

As I came to mcHF in 2015 I already stated "it is a very good idea to implement MCU with 1MB of flash". This was mostly ignored - also the wish of getting touchscreen functions. Chris M0NKA followed the tipp to switch to 1MB device some month later. But clonders never followed this hint because it would cost some important Cent of their profit.

Of course firmware will grow in size if new feaures are added, better algorithms are used and so on. So this is not astonishing that my hint of 2015 now will get reality:

It WAS a good idea to use MCUs with 1MB or greater. 512KB is a "dead end".

As the decision was made to cut firmware from "BY-NC-SA" and put it to "GNU GPLv3" it was clear, that there will be steps forward. And steps forward in firmware will at some places be based on "steps forward in hardware". Everything what is new and implementes in UHSDR is free an d open. Everyone can take a look at it and use it.

Hardware of mcHF is not changed (except cosmetical changes) from the begining. Firmware is already capable to run on F7 MCUs (soon H7 MCUs), driving two audio codecs simultaneously, driving LCDs with double resolution (480x320) and is capable to do "stereophonic output". Hardware of mcHF and its clones cannot follow. Even newest mcHF 0.7 has identical schematics as before. No Voyx possible, RAM at the limit, no free GPIOs, no stepping forward in RF schematics.

Open Source means "growing". That does not implement "throwing away". So we will support mcHF with unlimited time. But we cannot support mcHF when new features are based on hardware that is not present in mcHF. It is related to the "owner of the project" UHSDR does support. If the owner of the hardware decides not to step forward: this is similar to set up frontiers.

If you are interested how UHSR will grow please take a look at OVI40 project which will step forward. The first (big) step is new design of UI board. RF will follow soon. There will be features and possibilities which cannot work on mcHF because of this hardware does not step forward.

vy 73 DF8OE

[df8oe]

@WM0I

I am missing the setting of "NR Mode" at your photos. You are using an outdated version of firmware. We do want to get reports with newest firmware and using Modes "Devel1" and "Devel2".

[WM0I]

Those photos are from the 2.7.31 version firmware. I sent those someone can see why I like this firmware over the rest. But you told I was configuring the DEBUG settings wrong so I am going back and testing again with NR Mode Devel2 set this time.

Best regards WM0I

[df8oe]

Hi Rich,

yes - it is important to test the "newest features". Problem is we communicate using different platforms like github and discussion group at amateurfunk-sulingen.de and so sometimes it is not quite easy to find the "recent places" testing is needed.

Sorry for that - hopefully information will reach all ;)

73 Andreas, DF8OE

[UR7FM]

It WAS a good idea to use MCUs with 1MB or greater. 512KB is a "dead end". May be possible make extention MCU capacity via memory stick connected to big USB, like on PC?

[WM0I]

If this is a viable solution to the small 512KB and 192KB ram, what would have to done to make it work?

Am I reading this right, expand using a USB memory stick?

[db4ple]

Re USB Stick: see my comment on #1400