search

df8oe / UHSDR

SDR firmware and bootloader with configuration files for use with Eclipse, EmBitz and Makefile
Other
356 stars 185 forks source link

Issues with new Firmware 2.9.14. Audio/PA settings changed/CODEC Gain changed #1472

Closed WM0I closed 6 years ago

WM0I commented 6 years ago

Your firmware version: 2.9.14 Your bootloader version: 4.0.0

Hardware

Describe the issue:

Installed new Firmware and as soon as I turned the unit on I got a loud burst of audio that would not go away until I rebooted the unit. Happened several times. After getting to be normal audio I had to go into menu mode to turn down the Codec gain from 5 to 3. This got the red hash marks back to white.

After getting the most of the menu items back to what I had before I loaded the new firmware. I was unable to transmit with the correct power. It seems the new firmware had set the PA settings off to something unusable. I reinstalled the 2.9.13 firmware and set all the PA setting back to where I had them set.

Also audio seemed to be a bit choppy.

Best regards WM0I

Your relevant settings

Hint: most of the information can be seen on a screenshot of the main display.

You have audio related problems:

You have display (also fill if audio problem) related problems:

Other settings you consider as relevant:

df8oe commented 6 years ago

I cannot confirm. At my mcHF and OVI40 everything works as before without changing any setting. No audio distrortion, no changed PA output.

It seems you have cut the power supply during poweroff sequence so that your configuration settings are damaged. Never cut power supply until power off cycle has ended completely otherwise the configuration is not written completely (and so garbaged).

mcHF: STM32F439, parallel LCD 3.2"

OVI40 STM32F7, LCD 3.5"

db4ple commented 6 years ago

Hi, I can second that. The code change between 2.9.13 and .14 has nothing whatsoever to do with anything related to signal processing AND is small enough to be sure after a manual review this has with 99.9% no impact. There is always a possibility that something goes wrong during the build etc. but it is unlikely. The "changed" PA settings indeed indicate another issue which could be related to the change since it was about saving/restoring some extra data. @WM0I: Do you use your own build or a official firmware? @phaethon: Be so kind to consider if your change could impact any saving / restoring of other configuration data (BTW, I don't see any of this).

df8oe commented 6 years ago

I cannot see any possible impact - except this one:

Maybe they have save some Cent at the clones and have fitted a very small EEPROM and storage wraps around at the end of the storage area. I am not completely sure if we detect such an issue and disable EEPROM usage - and I do not know what happens if CW memory meets a mcHF with only virtual EEPROM enabled...

db4ple commented 6 years ago

I think we correctly determine the size of the EEPROM. And since we don't let smaller EEPROM < 32k to be used, there should not be a risk unless the save code is completely wrong (which I doubt).

phaethon commented 6 years ago

It is not writing to virtual EEPROM. Saving only if real EEPROM is present. The code is only writing to the eeprom starting from 0x1000. @WM0I What EEPROM chip do you have?