VFO-A & VFO-B is it possible to store more than just the frequency? Can we store DSP, AGC, AFC, CMP, TRB, BAS, FAS, NR, Notch & PEAK too?

[Lars-mcHF]

Just like you, I like to get the settings really good for RX and it would be very help-full to be able to do a "A" & "B" compare, is this setting better than that setting?. If these settings were stored in VFO-A along with the frequency and VFO-B then we could switch back and forth to see which is better. I hope this is more than just an idea to drive programmers nuts, it might help to make a better Radio if looking at one setting then another is just a switch away. Things that could go along with the frequency are the: DSP, BW, AGC, AFC, treb and bass setting, as the radio grows so does this list of options. And if your wondering: DF8OE asked me to come over here from FaceBook where all the mcHF programmers are getting immensely popular with the code they write.

[df8oe]

Hi Lars,

of course this is technically possible - but:
reading of the settings is done under the basement that each "storage place" has a well-known size. After xx bytes there MUST be the next storage place. If change the structure of storing all settings will be lost. So we have not touched this part of code because of we do not want to touch it many times. Users should only loose ONE time all their settings. So we are collecting ideas what is neccessary to store and what not, how many "spare space" we add to each storing place, and we are thinking about if small MCU with 192KB RAM is able to buffer a new-loaded memory or not. We are running at the edge of RAM of these small MCU. For exporting to USB much more difficult scenario: Newer versions of firmware do have more EEPROM space used than older ones. Building a table with all known versions so that every version can import any same or older settings via USB is possible - but very, very large project. We are thinking about this for a long time, too. Settings must be text-based / like config files under Linux). Advantage would be you can read and edit them using simple text editor. But here we are 100% running out of RAM and Flash if small MCU is used. Sadly all 1MB MCUs Chris has put to his kits only do have 192KB RAM like the very small from the beginning. So nearly noone would be able to use this firmware. Changing storage structure and possibility of exporting / importing without problems is a big project. It is on our todo list - but because of it is not a simple one maybe it will need more time...

[Lars-mcHF]

Hi Andreas,
Thank you for the reply
How did you add the "Label" I could not find it any where?
Will the next generation of THIS radio design have more memory ?
Or will that break the model of the software foot print too much?
Will other SDR radios have more memory? For instance the MiniTRX?
Is it possible to have different versions of this firmware doing different personalities?
Or will that make the project too complicated? Or will it load itself into a small space if that space is detected or chosen when uploaded
Is there a place in the user manual where user/software settings are recommended for use?
"That is a loaded question". By the Way,,,,
Thank you for the excellent software and how it makes a nice radio.
Sincerely ,
NE7LS

[df8oe]

Hi Lars,
I have a try for answering:

1. The "labels" are only virtual at the moment. Each band has its own correspondent memory place and is x bytes long. We access it via array band[i] where i is the corresponding band. This structure was already present as we started work on firmware.
2. I do not know the future of mcHF because it is not my/our project. it is Chris' (M0NKA) project - he is the only one who knows an answer.
3. The OVI40SDR we are starting the next weeks will have much more RAM and much more FLASH - and much more ports and GPIOs. It is running with a STM32F7 (144pin).
4. There are actually two different versions of UHSDR: The one for mcHF (fully compatible with miniTRX) and the one for OVI40 (compiled for F7 and different hardware).
5. We will follow two different paths: a) detecting hardware during lifetime AND precompiled for usage with hardware xyz. Both do have advantages and disadvantages - we will choose the best way for users.
6. Recommended software settings are the "default values". You can set each configuration point to default using "F4". I do not guarantee everything is correct ;)

73
Andreas