logo
Welcome, Guest. Please Login or Register.
04. October 2024, 12:29:44


Home Help Search Login RegisterWIKIUHSDR Download

Amateurfunk Sulingen
Diskussions- und Newsboard des DARC-Ortsverbandes I40  |  allgemeine Kategorie  |  UHSDR Firmware (Moderators: DF8OE, DL1PQ)  |  Topic: "12KHz firmware issue" <- zurück vorwärts ->
Pages: [1] Go Down Print
   Author  Topic: "12KHz firmware issue"  (Read 1965 times)
DF8OE
Administrator
*****

Offline

Posts: 6270



Stellvertr. OVV I40, Jugend / Nachwuchsreferent

View Profile WWW
"12KHz firmware issue"
« on: 18. August 2018, 06:45:23 »

This is a frequently upcoming theme in Yahoo NG. Here in our group I never have had heard about it. I am reading in Yahoo, but I do not write there since nearly a year. But I want to help people who can see this issue at their rigs.

Sympthoms:
If you tune with VFO over the bands you can hear strong signals appearing every 12KHz. You can definitely hear them, you very rarely see them on scope / WF. This is independent of band, Xlate setting, working mode and any other setting you can change. Yes: you can cycle through ALL user changeable settings and reset them to DEFLT and the issue will persist!

How to get rid of it
Power down rig, press simultaneously F1-F3-F5. Hold this three buttons pressed while rig is powering up until you see the standard screen. This forces ALL values to be reset to working defaults. There are many values that are stored which are not directly accessible by users. Doing this you will get rid off the "12KHz issue" - but of course you will loose all your settings and have to rework them manually! Important is that you do not cut power supply - this would rewoke your old config! Power down rig via power button (or store active setting using long-press-F1).

The following two "solutions" do not work:

  • backup your config in flash, do a "full reset" as described above and then restore your old settings from flash
  • backup your config to PC, do a "full reset" as described above and then restore your old settings using the file saved on PC

In both cases you will reeimplement the issue! I have tested some hours about the issue with no big success - but I can tell something about it:

  • the issue is 100% a "settings issue" - I call it "infected" from now on. The infection itself can be very old - maybe years - but all firmwares before new AGC was implemented will eat the spurs due to their "deafness" and so nobody recognizes the existence of the spurs. You can carry an infected configuration to any other mcHF and this rig will have the issue, too from now on. (The possibility of carrying configs to other machines is only available for newer firmwares where you can read/write settings via USB and small python script using PC). This is regardless of the firmware and bootloader version. I have checked all versions where we do hold binaries in our archive (this is back to 2.5.57) All of these versions can become the "12KHz issue" when I start them with an infected config. How to check if you cannot fit config via PC to rig because the firmware does not support "python method"? Very simple. Apply the infected config with a newer firmware and "backup it to flash" after you have powered down and up mcHF. Very important is powering down and up after you apply the config because this is the point it walks into your EEPROM. Now you have a mcHF where you can use any firmware back down to Clints firmware because of the config is not changed during firmware udates/downgrades (except version string in it) and now resides in both flash and EEPROM.
  • starting with implementation of very good new AGC the issue was much clearer to hear than before. That means it is present at older firmwares, too but you may think it is gone when you use firmware where new AGC is not present. Old AGC decreases sensitivity of mcHF if you have a strong signal in visable spectrum/scope ! That means: If you do have a signal which will be heard every 12KHz it would be so strong that old AGC will remove these spurs because of your sensitivity gets much lower !!
  • So definitely this issue resides very long. For testing how long you must rebuild old firmware versions and flash them to a mcHF which has already infected config. You have to play with AGC settings (or switch it off) to identify clearly if the issue is present or not. This is very time intensive. And maybe the issue is already present in Clints last firmware - I do not have tested - but that is a good idea I got now and will do it next time.


In summary:
Is it a firmware issue?
Yes and no.
"Yes" because it is 100% code related
"No" because it only pops up if you do have a screwed configuration.
Sorry we have not yet investigated which setting (or mostly it will be a combination of valid setting which together becomes screwed) is the bad one. I have alredy bisect the infected config but could not 100% identify the problem. It is 100% in the second half of setting values - but that are more than 170...

Perfect solution would be if we can identify the problem and if such a configuration is detected when mcHF is powered on by the testing routines it will be corrected automatically to valid ones. So you would not loose all your settings. But again: my first idea of a "fast success" was shattered because of the issue is very, very old but was not identified because of bad working old AGC.

There are only a handful of rigs which do have the issue. So actually there is no other possibility to get rid of it using the method I mentioned above.

If someone can reproduce the way he awakes the issue this would very appreciated! This would give us strong hints where to search.


EDIT:
I am 100% sure that settings of IQ (RX / TX) are **NOT** the cause of this issue and individual settings which are written down before cleaning can be reentered after full reset. Settings for PA (ALL settings) are not critical, too.
I would stop at filter settings, display settings, NR settings and so on. All these might be involved in the issue.
And the boundary of "first half" is at <amount of all settings> / 2

EDITEDIT:
No firmware version (of course include the recent ones) shows 12KHz receive issue when you start it with a not infected configuration. If you do have 12KHz receive issue at recent firmware there are two possible causes:
1) you do not follow exactly the procedure which is described above
2) your issue is related to your personal device and not to UHSDR or mcHF in general

vy 73
Andreas
« Last Edit: 19. August 2018, 15:16:51 by DF8OE » Logged

Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
Pages: [1] Go Up Print 
Diskussions- und Newsboard des DARC-Ortsverbandes I40  |  allgemeine Kategorie  |  UHSDR Firmware (Moderators: DF8OE, DL1PQ)  |  Topic: "12KHz firmware issue" <- zurück vorwärts ->
Jump to: 


Login with username, password and session length

 Es wird die Verwendung von Browsern die auf der "Blink"-Engine basieren und mindestens
1024x768 Pixel Bildschirmauflösung für die beste Darstellung empfohlen
 
Amateurfunk Die Beiträge sind, sofern nicht anders vermerkt, unter der folgenden Lizenz veröffentlicht:
GNU Free Documentation License 1.3 GNU Free Documentation License 1.3
verbindet!
Powered by MySQL Powered by PHP Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2004, YaBB SE Dev Team. All Rights Reserved.
- modified by Andreas Richter (DF8OE)
Impressum & Disclaimer
Valid XHTML 1.0! Valid CSS!