Firmware FAQ

Development Process

Q: Is there a place that will tell us what is changed in each new firmware update?

A: Yes, there is a more or less short comment for each commit. You can find them here: (https://github.com/df8oe/UHSDR/commits/active-devel) Just click on a commit and you can see the comment which usually tells you what was changed by this commit.

User Interface

Q: Why is the Band shown twice in the UI?

A: The upper right "Bndxx" is the name of the vfo band memory (switched using Band-/+), the lower right is the band according to the currently used frequency. You may store any frequency in any vfo band memory but generally it is recommended to keep used band and vfo band memory aligned to avoid confusion.

Q: After doing a band change through WSJTX (or any other CAT program), BAND +/- does not go to the correct band. Instead it acts as though the CAT band change had never occurred. Only power cycle brings the "normal" order back.

A: This is the expected behavior with default settings. You can achieve the same by dialing a different frequency by hand. The UHSDR has named band memory, which are switch through in the order of band wave length. Each band memory can be dialed to any frequency. The label BndXXm (right , below meters) will show you the active Band Memory Name. For CAT you can set in the configuration menu the "CAT in a sandbox" item to "On". This will prevent the band memory from being overwritten by CAT commands. You'll see "CAT" in the label field if the frequency has been change by a CAT command. Switching bands manually makes the transceiver "forget" the CAT frequency change if this option is active.

There is also an option which controls if out-of-band-memory-range frequency storage is permitted (default off). This is independent from the CAT setting and will not permit permanent (i.e. when you turn the transceiver off) storage of changed frequencies.

Q: Can I switch off scope or waterfall in the spectrum display?

A: Yes, you can. Setting the waterfall or scope speed to 0 will stop the permanent redraw of the spectrum display.

Q: Why do I get the blue screen at power on?

A: You get it, because at the end of the boot splash screen the firmware tests if any key is pressed. If so, it enters key test mode. The key which was pressed is encoded in the initial key value shown at the top of the screen. It is hexadecimal, each bit represents the key with respective number in the software. If you see 20000: This is the touchscreen. Often a defective or wrongly connected touchscreen causes virtual keypresses, which lead to the blue screen. The 10000 is the power key, typically when you keep pressing it during power on. Other key numbers can be seen the source code, but typically this are not relevant. If you are sure you did not press a key and you have your TRX newly build, and the same number always comes up, it is often a solder bridge at the MCU.

Bootloader and Firmware

Q: Can I use the UHSDR firmware with the M0NKA bootloader?

A: Yes, no issues known. However, you miss a lot of cool features such as update of bootloader (!) and firmware using the Mini-USB with standard software, no need to set P6 for bootloader updates. And the display-guided operation of the bootloader makes updating firmware a pleasure.

Q: Can I use UHSDR firmware on mcHF board revision xy?

A: Yes. There is no mcHF version where you cannot use UHSDR firmware. Because of there are some changes in hardware configurations (0R jumpers...) regarding LCD mode (SPI/parallel) or touchscreen handling maybe you first have to check correct jumper settings otherwise you will get malfunctions. You can find additional information in our modification page.

Q: What is the difference between the full and "small" mcHF Firmware?

A: Some mcHF are equipped with STM32F4xx processor which have only 512kb of flash memory. The UHSDR firmware with all available functionality will not fit into this small flash memory. The "small" firmware removes some functions (right now only FreeDV) and will fit into the small flash machines. The small firmware will fit and work in all machines (also the ones with larger flash). For machines with the STM32F7xx and STM32H7xx (such as OVI40) only a single firmware exists.

Q: What is the meaning of LEDs when booting?

A: Boot LED coding is as follows:

1. LEDs OFF -> bootloader active and starting firmware
2. LED RED (aka firmware just started)
3. LED RED + LED GREEN (running through main initialization)
4. LED GREEN (all init passed, starting radio application)

Firmware Functions

Q: Is there a VOX function?

A: No, and with the mcHF hardware alone you will never get one purely based on software extensions. The mcHF uses the analog input to sample the IQ signals during receive, so it has not way to sample the microphone signal. For the OVI40 hardware this is different, audio input and IQ input can be handled in parallel. And so it may eventually get a VOX function with the OVI40. For the mcHF the only solution is to use some "external"/"additional" circuit to detect voice on the microphone input.

Q: It seems my EEPROM is not being used, what can I do?

A: If the system info menu shows that your EEPROM has a wrong signature, and at power off the firmware tells you it is saving to flash, you can try erasing the EEPROM (configuration menu). This will tell the firmware to copy the current configuration from the flash memory to EEPROM and from then on will use EEPROM to save current values.

Q: It seems my EEPROM is being used but I get error messages when powering off, what can I do?

A: If the system info menu shows that your EEPROM is being used, and at power off the firmware tells you it has problems saving to EEPROM, you can try reduce I2C speeds (configuration menu, only STM32F4 machines such as mcHF). If this does not fix the problem, you have an hardware issue (I2C line trouble, power supply issues, defective chip or bad soldering). Try resoldering, checking the lines and finally replace the EEPROM.

Q: The load display shows a load percentage, what does it mean?

A: The load percentage (enabled in the debug menu) shows how much time the audio interrupt uses. If you see something like 30% it means, everything else (like screen updates, user input processing, additional signal processing not done in the audio interrupt, ... ) get 70%. The higher the number, the lower the amount of time spent on user interface updates etc. This also means, the load percentage is NOT an indicator for overall load of the processor. Its purpose is to identify during development whether the audio interrupt takes too much time or something else.