Memo-Stromverbrauch und Erwärmung reduzierenAntwort: "FAQ" steht für "Frequently Asked Questions" (= häufig gestellte Fragen) und ist im Internet ein gängiges Kürzel für Seiten wie diese, also Seiten mit Antworten auf "häufig gestellte Fragen".
Betrifft: Firmware-Version 2.0x (Mai 1996)
Frage: Wir betreiben den Papagei auf unserer Ortsfrequenz, auf der natürlich auch normale Simplex-QSOs laufen. Leider wird der Papagei ab und zu durch normale Sprache aufgetastet.
Antwort: Diese Probleme beschränken sich auf die erste Firmware-Version (2.0x, Mai 1996) und sind inzwischen behoben.
Eine kleine Unachtsamkeit in der Software führte dazu, daß zufällige sporadische 1750-Hz-Anteile im Sprachspektrum - die eigentlich ganz normal sind - sich in seltenen Fällen unbeabsichtigt zu einer erkennungsrelevanten Gesamtdauer summieren konnten, so daß, besonders bei längeren Durchgängen, fälschlich ein Rufton erkannt werden konnte. Das führte dann zum Auftasten. Bei bereits aufgetastetem Papagei konnte der gleiche Effekt das Ansprechen der Ruftonsperre und damit die "Unterschlagung" des eigentlich zu wiederholenden Durchganges bewirken.
Abhilfe: Firmware updaten (sowieso empfehlenswert).
Betrifft: Alle Versionen
Frage: Warum wiederholt der Papagei manchmal einen Durchgang nicht bzw. erst nach einer undefinierten, unerklärlich langen Pause? (Im Unterschied zum vorgenannten Problem tritt hier aber kein unbeabsichtigtes Auftasten durch Sprache auf).
Antwort: Dies Verhalten kann sehr verwirrend sein, weil es aus der Sicht der Beteiligten (Nutzer) absolut konfus anmutet und der Grund sich nicht unbedingt sofort offenbart. Dabei ist die Erklärung ganz einfach: Wenn die Frequenz sporadisch "unsauber" ist oder der Papagei noch andere, entferntere Stationen auffängt, die man selbst "am Boden" vielleicht gar nicht hört, dann schließt seine Rauschsperre nicht mit dem Ende des eigentlichen Sprachdurchganges (oder jedenfalls nicht lang genug, um die QSB-Schutzzeit zu überdauern), sondern erst, wenn auch das "Fremdsignal" gerade mal lange genug verstummt.
Folge: Der Papagei hält den Sprachdurchgang für noch nicht beendet und wartet deshalb mit der Wiederholung - unter Umständen auch sehr lange. Da man von den "fremden" Signalen wenig mitbekommt, und diese ja meist auch sporadischer Natur sind, kann das völlig unreproduzierbare Verhalten des Papageis höchst skurril und rätselhaft wirken. Trotzdem handelt es sich nicht um einen Fehler, sondern liegt in der Natur der Sache.
Abhilfe: QSY auf eine saubere Frequenz (hi).
Betrifft: Alle Versionen
Frage: Die Wiedergabe des Papageis ist von einem Geräusch (Rattern, Knarren, Brummen) begleitet. Woher kommt das und was kann man dagegen tun?
Antwort: Obwohl bei korrektem Aufbau eigentlich kein nennenswertes Taktgeber-Geräusch zu hören sein sollte, ist mir ein solches Geräusch nicht unbekannt. Ich kenne es aus der Entwicklungsphase, als ich das Innenleben der Sprach-Memos untersucht und die nötige externe Beschaltung erforscht habe. Das Geräusch erwies sich als Folge der bei uns notgedrungen unsymmetrischen (masse-bezogenen) Ansteuerung der eigentlich symmetrischen Mikrofoneingänge. Es läßt sich aber, wie ich durch einen glücklichen Zufall herausfand, durch einen niederohmigen Abschluß des Einganges unterbinden. Dies geschieht in der Schaltung durch R10. Das Ergebnis ist eine praktisch vollständige Unterdrückung des Taktgeräusches.
Ist ein derartiges Geräusch dennoch mehr als allenfalls ganz zart im Hintergrund zu hören, sollte zunächst der komplette Aufbau einschließlich der Sprachmodul-Verdrahtung nochmals gewissenhaft geprüft werden, um Schaltungsfehler und fehlerhafte oder falsch dimensionierte Bauteile auszuschließen. Wer zwei oder mehr Memo-Module hat, sollte auch mal im Modus 3 mit nur einem Modul arbeiten und dann testweilse mal das eine, mal das andere einsetzen, um zu sehen, ob nur ein spezielles Modul betroffen ist.
Abhilfe: Falls sich soweit keine Anhaltspunkte für die Fehlerursache ergeben, kann man R10 versuchsweise verkleinern (z.B. einen weiteren 15-Ohm-Widerstand parallelschalten), was natürlich einen Neubagleich von R7 erforderlich macht. Eine praktische Untergrenze für R10 ist dadurch gegeben, daß bei zu starker Verkleinerung keine ausreichende Aussteuerung (NF-Lautstärke bei Aufzeichnung) mehr an R7 einstellbar wäre.
Betrifft: Alle Versionen
Frage: Mein Papagei reagiert nicht mehr auf Sysop-Kommandos. Offenbar habe ich meine PIN vergessen bzw. ungewollt verändert. Was kann ich tun?
Antwort: Tja, in weiser Voraussicht habe ich - als bisher undokumentiertes Feature - einen "Rettungsanker" für solche Situationen vorgesehen, den ich nunmehr hier verrate. Es ist also in den meisten Fällen nicht nötig, den Prozessor zur Neuprogrammierung an mich einzusenden! Um Mißbrauch dieses Features durch Unbefugte zu verhindern, habe ich es so konzipiert, daß dazu ein "physischer" Zugang zur Relaisstelle unumgänglich ist. Per Funk gibt es (außer dem Notabschaltcode) keine Möglichkeit, den Papagei bei unbekannter PIN zu beeinflussen!
Und so sieht die "Rettungsaktion" aus: Benötigt wird eine Testkonfiguration wie unter "Inbetriebnahme und Abgleich" beschrieben, d.h. die funktionsfähig aufgebaute und angeschlossene Papageien-Platine, so wie sie bis zum "Abschuß" funktioniert hat. Ferner ist ein zweites Funkgerät erforderlich, mit dem die Papageien-Frequenz abzuhören ist. Sowohl der Papagei als auch das zweite Funkgerät sollten im Nahbereich an Dummies betrieben werden - aber das kennt Ihr ja schon... Auf jeden Fall sollte sichergestellt sein, daß während der Rettungsaktion keine "fremden" Signale den Vorgang stören können.
Und nun bitte genau aufpassen und exakt die nachfolgend beschriebene Prozedur befolgen:
Der Papagei befindet sich jetzt im gleichen Zustand wie nach dem ersten Einschalten nach Lieferung oder wie nach Ausführung von <PIN>D (=Default-Grundeinstellung wiederherstellen). Sämtliche Einstellungen einschließlich (ggf.) Call-Eingabe und Vergabe einer PIN müssen neu vorgenommen werden, bevor der Papagei wieder in der Öffentlichkeit "auftreten" darf (siehe Handbuch 2. Teil; "Pflichtteil" der Konfiguration).
Sollte keine CW-Sequenz ertönen, liegt ein ernstes Problem vor. Ich lasse mich dann ggf. gern zu Rate ziehen.
Betrifft: Erste Version von Hard- und Firmware gemäß Erstveröffentlichung
Frage: Öfter mal (unregelmäßig) sinkt bei meinem Papagei die Frequenz der Sprachwiedergabe gegen Ende der 20 Sek. stark ab, bei ansonsten unbeeinträchtigter Funktion.
Antwort: Mir ist bei allen Tests und Versuchen über mehrere Jahre mit diversen Memo-Modulen nie ein solches Verhalten aufgefallen. Ich denke aber, daß es mit der Modul-internen Erwärmung zusammenhängt, und daß mit dem nachfolgenden Tip Abhilfe geschaffen werden kann.
Memo-Stromverbrauch und Erwärmung reduzierenBetrifft: Erste Version von Hard- und Firmware gemäß Erstveröffentlichung
Dieser Tip gilt ausschließlich für die in der Erstveröffentlichung beschriebenen (nicht mehr erhältlichen) Sprachmemos und deren Umarbeitung zu Sprachspeicher-Modulen. Es gibt jetzt andere Typen. Die alten können aber trotzdem - auch in Kombination mit neueren - weiterverwendet werden, jedoch sollte dort, falls noch nicht geschehen, unbedingt folgende Korrektur vorgenommen werden:
Bitte hierzu nebenstehende korrigierte Form von Bild 4 aus FUNKAMATEUR Heft 3/96, Seite 312 beachten.
Von Modul-Anschlußpin 1 (GND) führt eine selbst hinzuzufügende Leitung zu einem Lötpad - und ursprünglich von dort weiter zu einem weiteren.
(Im FA-Foto Bild 3 ist dies etwas anders, aber elektrisch und funktional identisch, durch eine zum Platinenrand führende Brücke bewerkstelligt worden.)
Die Weiterführung der GND-Verbindung zum oberen der beiden Lötpads, (hier gestrichelt angedeutet) ist zu entfernen. Die von Pin 1 kommende Leitung soll also nur noch zum unteren der beiden Lötpads führen; das obere (links vom Anschlußpunkt des 4k7-Widerstandes) bleibt künftig unbeschaltet.
Die Masseverbindung des oberen Pads ist, wie ich inzwischen herausgefunden habe, nicht nur für die Funktion unnötig, sondern sogar schädlich, denn sie erhöht nur die Verlustleistung. Das Modul wird also "geschont", und mögliche Problemquellen werden eliminiert, wenn diese Verbindung entfällt.
Betrifft: Alle Versionen
Im unbeaufsichtigten Betrieb, womöglich noch an einem entfernten oder schwer zugänglichen Standort, gelten erhöhte Zuverlässigkeits-Anforderungen. Die nachfolgenden Überlegungen sollen auf einige Punkte hinweisen, denen man Aufmerksamkeit schenken sollte, um mögliche Probleme von vornherein zu vermeiden.
a) Stromsensor-Schaltung zur SQ-Signal-Gewinnung
Im allgemeinen arbeitet die Schaltung rund um den 741 (IC 4) zur Gewinnung eines Signals über den Zustand der Empfänger-Rauschsperre präzise und zuverlässig - und das bei einfachem und unkritischem Abgleich, wie alle meine Erfahrungen mit verschiedenen modernen Funkgeräten bestätigen. Man sollte sich jedoch vor Aufnahme des unbeaufsichtigten Betriebes am endgültigen Standort davon überzeugen, daß der einmal vorgenommene Abgleich (R11) hinreichend temperaturstabil ist, zumal an typischen Relais-Standorten direkt unter dem Dach oder im Freien oftmals extreme Temperaturverhältnisse herrschen.
Ich habe in einem Fall erlebt, daß die Stromaufnahme auch von der Umgebungstemperatur abhing - und zwar immerhin so stark, daß dies die eigentlich auszuwertenden Stromänderungen in unzulässiger Weise überlagert hat. Mit anderen Worten: Jeder Abgleich "driftete" abhängig von Betriebsdauer und Umgebungstemperatur, so daß an R11 keine Einstellung zu finden war, die unter allen möglichen Bedingungen einen zuverlässigen Betrieb gewährleisten konnte, wenngleich im Moment alles in Ordnung zu sein schien. In solchen Fällen kommt man dann doch an einem Eingriff in das Funkgerät nicht vorbei, um dort ein "direktes" SQ-Signal zu finden und herauszuführen.
Das ist praktisch immer problemlos möglich - ein Schaltbild ist dazu nicht erforderlich (wenngleich es hilfreich sein kann). Im vorliegenden Fall habe ich auch ohne Schaltbild und ohne jede Kenntnis der Innenschaltung keine 5 Minuten gebraucht, um durch reines Probieren (Abtasten beliebiger Schaltungspunkte am offen betriebenen Gerät mit dem Multimeter bei gleichzeitigem Auf- und Zudrehen der Rauschsperre) einen Punkt zu finden, dessen Gleichspannung sich zwischen offener und geschlossener Rauschsperre von ca. 0,2 auf 4,7 Volt änderte - also freundlicherweise gleich TTL-Pegel, was eine direkte Ansteuerung des PIC (Pin 1 von K1) möglich machte. Würde der obere Wert über 5 Volt liegen, hätte ein simpler Serienwiderstand (z.B. 33 k) zur Pegelanpassung ausgereicht.
b) Stromversorgungs-Anforderungen für Power-on-Reset
Die interne Power-on-Reset-Schaltung des Microcontrollers sorgt normalerweise ohne weiteres Zutun für einen definierten und sauberen Start beim Einschalten der Betriebsspannung. Dies funktioniert aber nur, wenn die Betriebsspannung einigermaßen schnell "da" ist. Der Hersteller spricht von etwa 0,05V/ms oder besser, d.h. von 0 auf 5 Volt in max. 1/10 Sekunde. Steigt die Spannung beim Einschalten zu langsam an, z.B. weil vielleicht erst "dicke Elkos" aufgeladen werden müssen bzw. weitere "elko-haltige" Geräte zugleich versorgt und eingeschaltet werden, kann es zu Fehlfunktionen des Programmablaufs kommen.
Ich habe diesem Thema übrigens in allen Test-Konfigurationen keinerlei besondere Aufmerksamkeit geschenkt und bin dennoch nie auf ein solches Problem gestoßen. Aber ich wollte trotzdem auf diese Thematik hingewiesen haben.
Falls solche Fehlfunktionen festgestellt werden, sollte zuerst überprüft werden, ob es sich wirklich um ein Reset-Problem handelt - z.B. die Stromversorgung direkt an der Papageien-Platine (meist Pin 4 von K1) unterbrechen und wieder einschalten. Wenn danach ein sauberer Start erfolgt, handelte es sich tatsächlich um ein Reset-Problem.
Als Abhilfe kann man den Papagei über eigenes kleines Mini-Netzteil separat versorgen oder aber die Papageien-Stromversorgung über ein Relais mit Verzögerung erst dann zuschalten, wenn sich die Ausgangsspannung des Netzteils voll aufgebaut hat.
Betrifft: Alle Versionen (sowie speziell alte Fassung der Bauanleitung in der Erstveröffentlichung)
Frage: Mein Papagei meldet sich nach dem Einschalten der Stromversorgung zwar mit seiner Kennung, läßt sich dann aber nicht auftasten und reagiert auch nicht auf Sysop-Befehle.
Antwort: Falls sich der Papagei bei keiner Lautstärkeeinstellung am Funkgerät auftasten läßt, obwohl an Pin 3 des PIC das empfangene Ruftonsignal (begrenzt, mit angeflachten Spitzen) anliegt, ist der wahrscheinlichste Grund, daß der PIC durch unglückliche Zufälle auf eine falsche SQ-Polarität programmiert wurde. (Bekanntlich wird beim Erst-Einschalten wie auch bei jeder manuell ausgelösten Grund-Initialisierung die Ruhepolarität des SQ-Signals automatisch neu ermittelt und für die Zukunft festgehalten).
Abhilfe: Entweder gemäß Sysop-Handbuch wie unter "SQ-Polarität ändern (invertieren)" beschrieben. Oder aber wie weiter oben unter "PIN vergessen..." verfahren und damit implizit auch eine neue (hoffentlich richtige) SQ-Polaritätserkennung auslösen. Anschließend ggf. nochmals die richtige Lautstärkeeinstellung am Funkgerät gemäß Abgleichanweisung herstellen.
Frage: Gut, aber wie konnte es zu der falschen SQ-Erkennung kommen? Ich habe mich genau an die Anleitung zur Erst-Inbetriebnahme gehalten.
Antwort: Wahrscheinlich hast Du die alte Fassung der Anleitung benutzt; sie ist inzwischen dahingehend präzisiert worden, daß beim Erst-Einschalten zuerst das Funkgerät und erst dann der Papagei mit Strom versorgt werden sollte. (Bei allen künftigen Einschaltvorgängen, also solchen, die nicht mit einer Grundinitialisierung einhergehen, muß natürlich keine Reihenfolge eingehalten werden).
Aber mal der Reihe nach: Schließen wir zunächst den Fall aus, daß im Moment der Polaritätsermittlung beim Erst-Einschalten zufällig gerade ein Signal empfangen wurde, so daß der PIC eine offene Rauschsperre als vermeintliche Ruhepolarität vorfand. Da ich für das Erst-Einschalten und vergleichbare Vorgänge immer die Verwendung von Dummy-Loads "gepredigt" habe, kann das ja eigentlich nicht vorkommen...
Aber: Je nach Herkunft des SQ-Signals kann es im Einzelfall evtl. vorkommen, daß dies Signal im Einschaltmoment kurzzeitig "aktiv" wird, obwohl gar kein reales Signal empfangen wird (bedingt durch funkgeräte-interne Einschwing- oder Aufladevorgänge). Der PIC wartet nach dem Einschalten der Stromversorgung zwar wohlweislich eine Sekunde, damit sich die SQ-Leitung stabilisieren kann, bevor ihr Zustand zwecks automatischer Polaritätserkennung abgefragt wird, aber diese Zeit mag in einigen Konstellationen - obwohl ich das nie erlebt habe - zu kurz sein.
Sollte das der Grund sein, gibt es jene besagte Abhilfe: Beim Erst-Einschalten bzw. bei der "Pin vergessen"-Prozedur solle das Funkgerät schon an (und somit die SQ-Leitung bereits stabil) sein, bevor der Papagei erstmals mit Strom versorgt wird. Das gilt aber, wie gesagt, nur für solche "einmaligen" Spezialsitutionen; normalerweise kann die Stromversorgung von Papagei und Funkgerät selbstverständlich gleichzeitig eingeschaltet werden.
Betrifft: Alle Versionen
Frage: Bei aktiviertem "Prompt" (Sprechaufforderung, Roger-Piep) wird die PTT-Leitung zwischen der Papageien - Wiederholung eines Durchganges und dem darauffolgenden Roger-Zeichen kurzzeitig inaktiv. Das ist ja funktional eigentlich unnötig und führt in dem von mir verwendeten Transceiver zu einem unschönen Extra-Relaisklicken. Läßt sich das verhindern?
Antwort: Im Prinzip natürlich schon, faktisch leider nein, jedenfalls nicht von der Firmware her. Eine spezielle Berücksichtigung dieses Falles würde nämlich ein bißchen Extra-Programmcode erfordern, für den leider kein Platz mehr vorhanden ist.
Da stets mehr Ideen für Erweiterungen und Verbesserungen vorhanden sind als es Speicherplatz gibt, gilt es jeweils Prioritäten abzuwägen. Hier handelt es sich um ein bloßes Schönheitsproblem ohne echte funktionale Mängel oder sonstige Nachteile, deshalb steht dieser Punkt auf meiner "Wunschliste" nicht sonderlich weit oben...
Betrifft: "Neue" Sprachspeichermodule und Firmware-Version 2.4
Frage: Überall ist die Rede von elektrischen Unterschieden zwischen "alten" und "neuen" Sprachspeichermodulen, die per Firmware erkannt und "kaschiert" bzw. berücksichtigt werden müssen, um funktionale Kompatibilität herzustellen. Worin bestehen denn nun diese Unterschiede?
Antwort: Bei den als Ausgangsmaterial verwendeten Sprach-Memos ist das Verhalten der LED - im Papagei bekanntlich als Ende-Kriterium ausgewertet - unterschiedlich. Willst Du's noch genauer wissen? Dann muß ich mal wieder aus dem Nähkästchen plaudern. Leider wird's kompliziert, und Du brauchst einiges an Geduld.
Zunächst zur Erinnerung: Die aus dem Chip unter dem schwarzen Klecks herauskommende LED-Leitung wird bekanntlich in den Modulen als "End"-Signal benutzt, mit dem das Ende des modulinternen Speicherzyklus an den PIC signalisiert wird. Der PIC weiß dadurch, wann ein Aufnahme- bzw. Wiedergabevorgang zuende ist. Bei Aufnahme ist zwar nicht dies Signal, sondern der Trägerwegfall das eigentlich relevante Ende, trotzdem wird hier das "End"-Signal auch benötigt, damit im Modus 1 (d.h. 2 Module für 40 s Sprechzeit kaskadiert) die Aufnahme genau in dem Moment auf das zweite Modul umgeschaltet wird, wenn das erste "voll" ist.
Nun zu den - müham herausgefundenen - Unterschieden (mit "0" und "1" sind die logischen Zustände "low" und "high" gemeint):
| Verhalten der "End"-Leitung bei Aufnahme | Verhalten der "End"-Leitung bei Wiedergabe | |
|---|---|---|
"Alte" Module | Während der Aufnahme1; | Während der Wiedergabe 1; bei Ende Wechsel auf 0 |
"Neue" Module | Während der Aufnahme 0, bei Ende (=Modul voll) Wechsel auf 1 | Während der Wiedergabe 1, bei Ende kurzer 0-Puls (ca. 16 ms) |
Das Verhalten der LED-/End-Leitung war also bei den alten Modulen geradlinig und "pflegeleicht", das "neue" Verhalten aber könnte unterschiedlicher kaum ausfallen. Es dürfte auf der Hand liegen, daß eine auf das alte Schema ausgerichtete Firmware mit den neuen Modulen nicht klarkommen kann.
Doch damit nicht genug: was die Tabelle verschweigt, ist nämlich, daß auch das Verhalten der End-Leitung bei deselektierten Modulen noch unterschiedlich ist und berücksichtigt werden muß, was angesichts der selbstaufgestellten Forderung, daß bis zu 4 Module unterschiedlichen Typs kombinierbar (quasi parallelgeschaltet) sein dürfen, besonders delikat ist. Nur mit Schaltungstricks in der neuen Modul-Verdrahtung in Verbindung mit neuer Firmware konnte trotz des neuen, uneinheitlichen Verhaltens dennoch das bisherige Konzept einer "wired-or"-Verknüpfung der End-Signale aller Module beibehalten und damit eine Schaltungsänderung auf der Hauptplatine vermieden werden.
Ich hab' übrigens irre lange daran getüftelt und wundere mich immer noch selbst, daß es überhaupt relativ unspektakulär gelungen ist, alle denkbaren Eventualitäten unter einen Hut zu bringen - und das auch noch bei dem ohnehin schon vollem PIC-Speicher..
Und so kommt nun neuere Firmware (ab 2.4) "selbstadaptierend" damit klar, selbst bei gemischter Modul-Bestückung (stark vereinfacht):
Während ich die Firmware-Version 2.4 entwickelte und testete, war ich mir hinsichtlich der vorgenannten Dinge noch keineswegs 100%ig sicher. Denn da ich keinen Logik-Analysator besitze, war ich darauf angewiesen, Hypothesen zu entwickeln und diese experimentell bzw. durch oszilloskopische Einzelmessungen zu überprüfen und schrittweise zu verfeinern. Nur so sind die vorgenannten Erkenntnisse - die inzwischen aber ausreichend erhärtet sind - entstanden.
Wegen der anfänglichen Unsicherheit habe ich den Wert der "Schutzzeit" mittels einer undokumentierten Sysop-Funktion einstellbar gemacht, um mit verschiedenen Werten experimentieren und im Falle von etwaigen Problemen hier "drehen" bzw. Tips geben zu können. Dies also verbirgt sich hinter der geheimnisvollen Speicherstelle, die im neuen Sysop-Handbuch (3. Auflage, S. 25) als "inoffiziell für Test & Diagnostik" gekennzeichnet ist!
Inzwischen hat sich aber herausgestellt, daß mit dem Default-Wert von 20 ms eine problemlose und zuverlässige Funktion sichergestellt ist und dieser Wert keiner Anpassung bedarf. Trotzdem ist die Einstellmöglichkeit auch in der endgültigen Version der Firmware 2.4 sozusagen als "Relikt" immer noch vorhanden; sie bleibt aber inoffiziell und wird in etwaigen künftigen Versionen eliminiert, sobald der Platz für etwas anderes gebraucht wird. Der Rat aus dem Sysop-Handbuch, diesen Wert nicht zu ändern, sollte unbedingt beherzigt werden, will man nicht jenen beschriebenen fatalen "Dauer-Hänger mit Dauer-Senden" riskieren...
Betrifft: Ausschließlich Sysop-Handbuch 3. Auflage und ausschließlich Firmware-Version 2.4x
Frage: Auf Seite 4 des Handbuchs steht: "Die Sysop-Funktionen stehen nur bei unaufgetastem Papagei zur Verfügung." Auf Seite 14 aber wird die Sonderfunktion "dauer-aktiver Papagei" (d.h. rein trägergesteuerte Betriebsart) angeboten. Wie ist das vereinbar? Wenn die Sysop-Funktionen nur bei inaktivem Papagei funktionieren, wie kann ich dann bei einem dauer-aktiven Papagei überhaupt noch Sysop-Kommandos ausführen, und sei es auch nur, um den dauer-aktiven Zustand wieder zu beenden???
Antwort: Das ist in der Tat eine Inkonsistenz, die aber bis jetzt noch niemandem aufgefallen ist (mir auch nicht). Da es fatalerweise per Funk keine Möglickeit zur Aufhebung eines einmal initiierten dauer-aktiven Zustandes gibt, sollte der dauer-aktive Modus bei Firmware-Version 2.4, wenn überhaupt, nur mit Bedacht und äußerster Vorsicht verwendet werden.
Abhilfe: Update auf Firmware-Version 2.5 - dort ist das Problem ursächlich behoben. Für die Version 2.4 gibt es folgende Behelfslösung; wir verdanken sie Filip, ON4PC, der auch den obigen Widerspruch entdeckt hat:
Hintergründe: Die eigentlich nicht sonderlich nützliche Möglichkeit, Sysop-Funktionen optional auch im aufgetasteten Zustand verwenden zu können, ist in der Firmware-Version 2.4 wegen Speicherplatz-Knappheit entfallen. Um genauer zu sein, bei diesem Wegfall handelte es sich um einen zwar nicht intendierten, aber hingenommenen Nebeneffekt meiner "Code-Knautschereien" im ewig zu knappen PIC-Programmspeicher... Nicht bedachte Folge: Besagte Sonderfunktion bekam dadurch ihren Rückweg abgeschnitten und wurde zur fatalen Sackgasse!
Dieser Nebeneffekt hängt übrigens mit der automatischen Modulerkennung zusammen und tritt nur bei Verwendung von Modulen "neuen" Typs auf, was heute wohl die Regel ist. Werden "alte" Module eingesetzt, ist die Verwendung von Sysop-Funktionen auch in Firmware-Version 2.4 im aufgetasteten Zustand möglich.
Zwei Jahre lang gibt es nun schon die Firmware-Version 2.4, und zwei Jahre lang ist dieser Widerspruch niemandem aufgefallen - selbst mir war er nicht bewußt! Erst Filip, ON4PC, hat mich darauf aufmerksam gemacht - er hat nach dem Aufbau seines Papageis keine Woche gebraucht, um zu entdecken, was allen bisher verborgen blieb...
Daß diese Entdeckung außerhalb von DL erfolgte, obwohl meine Papageien hierzulande natürlich viel verbreiteter sind , ist sicherlich kein Zufall: Die "Auftastung" eines Repeaters mittels 1750-Hz-Ton ist eher eine nationale Eigenheit in DL. Während die rein trägergesteuerte Betriebsweise von Relais hierzulande nicht zulässig ist, ist sie anderswo gang und gäbe. Folglich führt auch die "dauer-aktive" (sprich: trägergesteuerte) Betriebsart des Funkpapageis hierzulande ein Schattendasein und ist - wie auch das Handbuch betont - allenfalls für kurzzeitige Experimente unter Aufsicht geeignet. Ganz anders im Ausland: Dort wird es gewiß sehr begrüßt und keineswegs als "exotische Nebenfunktion" angesehen, daß der Papagei auch die rein trägergesteuerte Betriebsart beherrscht. Es ist nur logisch, daß auch deren Tücken dort zuerst entdeckt wurden.
Aber Filip fand nicht nur das Problem, sondern dankenswerterweise auch gleich die erwähnte vorläufige Lösung : Während ich noch die obige "PIN-vergessen"-Methode als probaten, aber einzigen Ausweg ansah (was jedesmal den Verlust sämtlicher Konfigurationsdaten und Einstellungen zur Folge hätte), hat er durch fleißiges Probieren und viele zeitraubende Versuche schließlich herausgefunden, daß zufälligerweise (warum auch immer...) das vorübergehende Entfernen der Sprachspeichermodule - maßgebend ist hier wohl Modul 1 - ausreicht, um den Papagei trotz aktiven Zustands doch für Sysop-Kommandos empfänglich zu machen. Ich wäre wahrscheinlich nie auf die Idee gekommen, das überhaupt zu probieren! Bald wird er den Papagei wohl besser kennen als ich...
Der Witz bei dieser Lösung ist, daß es auch für sie keine "geradlinige" Erklärung gibt: genau wie das Problem selbst beruht sie auf einem unbeabsichtigten Nebeneffekt, der hier sozusagen "zufällig" den eigentlichen Nebeneffekt vorübergehend außer Kraft setzt... (tnx an ON4PC)
Inzwischen habe ich die ganzen Wirkmechanismen der erwähnten Nebeneffekte in der Firmware durchschaut und sie ursächlich behoben. Ausnahmsweise war das mal ohne Erhöhung des Speicherplatzbedarfs im völlig ausgereizten PIC-Programmspeicher möglich. Das Ergebnis ist die Version 2.5, die sich ansonsten praktisch nicht von 2.4 unterscheidet. (Details).