Title: performance problem daily Snapshot vom 2.12.16
Post by: DL8EBD on 03. December 2016, 19:20:34
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DB4PLE on 03. December 2016, 20:03:02
Hallo Thomas,
das ist sehr mysteriös. wenn deine vorhergehende Daily-Fassung vom 29.11. ist (ist das so?), dann kamen danach keine SSB/CW spezifischen Sachen in den Commits vor. Ich habe leider keinen mcHF im Zugriff bis morgen abend.
Kannst Du mal einen Screenshot von deinen Bildschirm posten oder mir per PN schicken, dann sehe ich ja noch eine Reihe weiterer Einstellungen.
Ansonsten: Kann das Verhalten mit dem aktuellen Daily von jemand anderes bestätigt werden (@Thomas: Ich bin mir sicher, dass das Problem bei Dir echt ist und in der Firmware begründet ist, trotzdem spannend ob das Problem bei allen auftritt)?
Andreas wird uns heute ja nicht helfen, der muss ja dem Weihnachtsmann im OV helfen.
73
Danilo |
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DB4PLE on 03. December 2016, 21:04:36
Hallo Thomas,
danke! Ich habe einen Verdacht, wobei ich immer noch nicht den Bezug zu CW/SSB verstehe, aber ich werde, wie gesagt, erst morgen schauen können. Insbesondere wenn andere das Problem auch haben, würde sich mein Verdacht erhärten.
EDIT: Pull ist erfolgt, Daily kann ausprobiert werden.
73
Danilo
|
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DF8OE on 03. December 2016, 21:07:23
Ich kann so schnell drehen wie ich will - bei mir passiert nichts besonderes. Keine Aussetzer, kein Haken, kein Knacken.
vy 73
Andreas |
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DL1EGQ on 03. December 2016, 21:23:18
Hallo
Bei mir ist alles ok, soweit ich den NB auf 2 einstelle, sonst bleibt die Frequenz von Zeit zu Zeit stehen.
Gruß
|
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DB4PLE on 04. December 2016, 08:05:36
Hallo Thomas,
immernoch mysteriös. Wie auch immer, ich habe mal meinen Verdacht umgesetzt und eine Kleinigkeit meiner Änderungen vom 2.12. zurückgenommen. Wenn Andreas den Pull-Request in den neuen Daily Build verwandelt hat, kannst Du ja mal probieren und berichten. Das Merkwürdige ist, das die Magnify Funktion so garnichts mit SSB/CW vs. AM/FM zu tun hat. Der Funktion ist die Demodulation sowas von egal.
Ich gehe auch davon aus, das Du beim S-Meter die Old-School Einstellung hast (Menü Display Configuration).
Berichte dann mal, wenn Du den Build ausprobiert hast.
Grüße
Danilo
|
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DF8OE on 04. December 2016, 08:32:00
Es hat definitiv etwas mit dem Magnify zu tun - wenn es beim Start auf etwas anderem als "1" steht. Bei mir steht es immer auf "1" - deswegen bei mir kein Fehler... Stelle ich es aber auf "2", schalte den mcHF aus und wieder ein - dann kann ich es auch reproduzieren.
Da ich aber default einen möglichst großen Überblick über das Band haben will startet mein mcHF immer mit "1". Will ich dann im Laufe des Betriebes mehr sehen, tauche ich mit dem Magnify tiefer rein. In dem Fall kommt kein Fehler. Wobei ich mit aktiviertem Magnify auch keine schnellen / großen Frequenzänderungen durchführe. Die finden stets bei Magnify "1" statt... Dank Touchscreen ist das Handling ein Kinderspiel...
vy 73
Andreas |
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DF8OE on 04. December 2016, 08:44:03
Ich habe mal die neu gebaute Daily von heute probiert - damit kann ich auch mit "2" starten ohne dass es hakt.
Dieser Fehler wäre mir aber wegen anderen Handlings mit dem Gerät NIEMALS aufgefallen...
vy 73
Andreas |
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DB4PLE on 04. December 2016, 09:17:51
Hallo,
OK. Dann hat mich mein Gefühl nicht betrogen. Allerdings müssen wir dann wirklich mal dem Magnify Code tief in die Augen schauen.
Was ich implizit gemacht hatte, war dem Compiler etwas mehr Freiheiten beim Optimieren zu geben, was auf Grund der Teilung des Magnify Codes in Interrupt Code (audio_driver.c) und Anzeige Code (ui_spectrum.c) offensichtlich zu Problemen beim Zusammenspiel führt. In diesem Fall deutet das auf Probleme im Code hin (für die Informatik-affinenen: kritischer Abschnitt) , die wir lösen können und dann können wir den Compiler auch wieder von der Leine lassen.
Prima, das wir das gefunden haben. Danke Thomas!
73
Danilo
|
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DB4PLE on 04. December 2016, 09:34:07
Hallo Thomas,
nicht im Geringsten. Wie gesagt, der Code, der von meiner Änderung betroffen ist, hat direkt nichts mit SSB/CW zu tun. Das Problem liegt im Bereich ungünstiges Timing. Ich werde dann später versuchen das Problem nachzustellen, kann aber schwierig werden, wegen Timing als wesentlichem Element.
73
Danilo
|
Title: Re:performance problem daily Snapshot vom 2.12.16
Post by: DF8OE on 04. December 2016, 13:31:10
Hallo Thomas,
ich denke, wenn wir wüssten, an wie vielen Stellen wir nur noch ein paar Mikrosekunden von heftigen Fehlfunktionen entfernt sind, würde es uns kalt den Rücken runterlaufen ::). Es ist eben nicht die gleiche Philosophie wie im PC-Bereich, wo man dermaßen viel Reserven hat, dass "es nicht drauf ankommt". Im Bereich embedded systems ist idealerweise immer etwas mehr Rechenleistung/RAM/FLASH zur Verfügung als man braucht. Da redet man nicht von "...wir könnten locker die Geschwindigkeit der MCU halbieren"...
Dementsprechend können Änderungen an Stellen, die nichts direkt mit dem beobachteten Fehlverhalten zusammenhängen, Phänomene wie das beobachtete hervorrufen. Stell es Dir am Besten wie ein Zahnrad vor, bei dem die Zähnung etwas breiter gemacht wurde. Erst der zweite oder dritte Zahn beißt jetzt irgendwo rein, wo er nicht reinbeißen soll 8) Und wenn Du dann noch in das Gedankengebäude einbaust, dass die Zähnung nicht gleichmäßig ist (wobei das "Gegenrad" im Lauf-Falle die gleiche Unregelmäßigkeit besitzt) - sind unsere Daily Snapshots schon qualitativ extrem hochwertig :)
Die meisten Probleme, die wir seit ein paar Monaten in der FW haben, sind exakt solche Timing-Probleme / Race Conditions. Deswegen ist es auch verdammt schwierig (wenn nicht gar unmöglich) diese mit einer Emulation herauszufinden. Messungen bzw. Beobachtungen "am realen Objekt" in Verbindung mit geschärften Sinnen, was denn von "...geht..." zu "...geht nicht mehr..." verändert wurde, sind oft die einzigen anwendbaren Mittel!
vy 73
Andreas |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|