Moin.

Also ... *tief lufthol* ... vielleicht erwähne ich nun Dinge, die du schon kennst, aber
ich möchte sie im Zusammenhang erwähnt wissen bzw. haben. Vielleicht wird dadurch
das Problem erleichtert - nicht nur für dich, sondern auch für andere, die auf der Suche
nach Programmierstations-Schaltplänen sind (stelle nur ich eine Häufung genau dieser
Anfrage in den letzten 4 Wochen fest?) ..

Dein Melder hat ja, wie du sicher weist, einen nicht-flüchtigen Speicher. In diesem, mal
unabhängig davon, ob wir einen "analogen" oder "digitalen" Meldeempfänger haben,
werden seine Parameter gespeichert. Wird die Spannungsquelle entfernt, bleibt dieser
Speicher logischerweise bestehen. Wird die Spannungsquelle wieder angelegt, startet
die Betriebssoftware des Melders (im folgenden Text kurz "Firmware" genannt). Diese
liest in einem frühen Stadium den oben genannten nicht-flüchtigen Speicher (im folgenden
Text "EEPROM" genannt) aus. Damit "weiss" der Melder dann, auf welche Alarmadresse
(ob nun 5-Ton-Folge, 2-Ton-Folge, POCSAG-RIC oder meinetwegen FMS oder gar DTMF)
er reagieren soll, und was er genau bei dieser Alarmadresse tun soll (Beispiel: Text darstellen,
laut piepsen, Melodie abspielen, Funk auf Lautsprecher durchschalten, ...). Bei PLL-Meldern
(also solchen, wo nicht ein Quarz die Frequenz bestimmt, sondern ein programmierbarer
Oszillator) liest er sich hier natürlich auch die entsprechenden Parameter aus dem EEPROM
aus. Er beginnt in einer Endlosschleife (oder meinetwegen auch unterbrechungsgesteuert,
SO technisch will ich nun nicht werden) mit dem "Empfang" und "Auswerten" der empfangen
Daten. In dieser Endlosschleife ist auch eine Routine enthalten, die prüft, ob eine evtl.
angeschlossene Programmierstation (=Pegelwandler) Daten erfragt oder liefert.

Stellt diese Routine mit "Erfolg" fest, das eine Programmiersoftware über die angeschlossene
Programmierstation dem Melder mitteilt "Hallo, ich bin da, ich bin auch die richtige Software, sende
mir doch bitte deinen EEPROM-Inhalt", wird sie über die Schnittstelle ihre Daten versenden. Hierbei
wird es sicherlich eine generische Protokollsicherung geben, diese ist aber für uns nur zweit-
rangig.
Stellt diese Routine nun fest, das eben diese Programmiersoftware sagt "Hallo, ich bin deine
Programmiersoftware, du bist auch der geeignete Melder, den ich programmieren will, ich sende
dir nun meine Daten +binary data+" .. nun, dann wird sie, wenn sie gut programmiert wurde,
die Daten zunächst in einen temporären Speicher (sagen wir RAM dazu) speichern, prüfen, ob
sie richtig empfangen wurde, und anschliessend diese "RAM-Daten" in den EEPROM sichern.
Dabei gehen die vorherigen Daten verloren. Anschliessend wird der Melder per Software (oder
per Hardware) neu gestartet.

Die Programmierstation ist ja nur die Schnittstelle zwischen dem Kommunikationsanschluss des
PC und dem des Melders. Die Leitung des PCs, die Daten sendet, geht über diesen "Pegelwandler"
auf die Leitung des Melders, die für den Empfang zuständig ist. Umgekehrt geht natürlich die
"Sendeleitung" des Melders (er antwortet auf die Anfragen der Programmiersoftware, sonst wüsste
diese ja nicht, wer da an dem Anschluss hängt) über den Pegelwandler an den PC. Evtl. gehen
noch zwei weitere Leitungen vom PC zum Pegelwandler, diese werden aber meistens nur mit-
einander verbunden. Diese zwei Leitungen "RTS" und "CTS" sagen aus, das der PC Daten zu
senden hat bzw. das er bereit ist, Daten zu empfangen. Verbindet man beide per Drahtbrücke,
würde der PC immer dann, wenn er "klar zum senden" (CTS, clear to send) ist, möglicherweise
vorhandene Daten anfordern (RTS, request to send). Ich kenne nur wenige Melder, die jene
Leitungen zu Verfügung stellen - wäre ein Melder gerade nicht in der Lage, Daten zu verarbeiten,
würde er "CTS" abschalten und dem PC damit sagen "ich mag nicht!" .. dieser dürfte dann die
Daten nicht senden (und je nach Architektur zwischenspeichern oder verwerfen).

Am Standard-Schaltplan eines Pegelwandlers hat man also die PC-Seite und die Melder-Seite.
Die PC-Seite nennt sich bekanntlich "RS232, die andere könnten wir mal "TTL" nennen..
Wie man nun diesen oder jenen speziellen Melder an die TTL-Seite anhängt, entscheiden
Faktoren wie Gehäuse, Anschlussleiste, Kreativität des Melder-Herstellers. Man mag sich
also denken "nehme ich auf Pegelwandlerseite einen Anschluss, und welcher Melder dran-
kommt, entscheide ich mit dem Kabel, das auf einer Seite den immer gleichen Anschluss hat
und auf der anderen Seite die Kontaktierung für den Melder". Also werde ich "nur zur Sicherheit"
mal nicht nur die beiden Datenleitungen auf den "Standard"-Stecker legen, sondern auch mal
noch ne Versorgungsspannung, sei es zum Laden des Melders, sei es, weil ein Melder andere
Pull-Down oder Pull-Up-Widerstände braucht, die zwischen Signalleitung und Masse bzw.
Versorgungsspannung liegen usw usw .. und sei es nur, weil man ne LED leuchten lassen will,
das gerade die Programmierstation Strom bekommt.

Doch kommen wir zu dem wichtigsten Punkt, den jeder immer gerne verdrängt:

Situation von oben: Programmiersoftware sagt "Hier sind meine Daten für dich, speicher sie!" ..

Folgendes kann passieren:
* Die Übertragung geht gut, die Prüfung geht gut, der Melder speichert seine neuen Daten,
startet neu, alle sind zufrieden.

* Die Übertragung geht schief, die Prüfung geht schief, der Melder meckert und startet evtl.
neu, um die "bösen" Daten schnell zu vergessen.

* Die Übertragung geht gut, die Prüfung geht gut, der Melder will seine Daten speichern und
mitten in der Speicherung ist die Spannung weg. (Das Speichern von Daten in ein EEPROM
geht verhältnissmässig LANGSAM vonstatten, im Vergleich zur Übertragung der Daten oder
Datenspeichern in RAM-Regionen)..

* Die Übertragung geht nicht gut, die Prüfung geht aber gut und der Melder speichert falsche
Daten, ohne es zu merken, und startet neu.

Im Fall 1 + 2 ist alles OK .. im Fall 3 + 4 ist der Melder erstmal KAPUTT! Und so ein Melder
kostet Geld. Mir persönlich ist es egal, ob ich sagen wir 150 EUR für einen privaten Melder
ausgegeben habe, oder ob die Hilfsorganisation, die mir einen Melder gegeben hat, diese
150 EUR bezahlt hat. Der Melder ist kaputt.
Beim privaten Melder sag ich: dumm gelaufen, schade ums Geld.
Beim HiOrg-Melder: oh f**k ... das harmloseste wäre wohl, den Melder fallen zu lassen,
evtl. mit dem Auto drüber zu fahren oder irgendwas anderes, das vmtl. ebenso Versicherungs-
betrug ist wie das Fallen-lassen und Auto-drüber-fahren, und eben diesen "Unfall" in die
Sachschadensmeldung zu schreiben... wenn keiner den EEPROM-Inhalt prüft, hat man Glück
gehabt. Falls er geprüft wird, ist eindeutig feststellbar, das er einen Programmierfehler hat.
Kein Autoreifen kann den EEPROM umprogrammieren! (Na vielleicht schafft es nen Wasserbad..)

Klar, der Melder ist nicht zwingend "UNREPARIERBAR" kaputt .. meinen privaten Melder würde
ich dann einfach der Werkstatt oder dem Elektronik-Freak des Vertrauens geben (der Autor würde
den Melder übrigens gleich selbst reparieren können) ... was aber mit dem HiOrg-Melder ..
Klar, den kann man auch einschicken und kriegt ihn zurück, zahlt die Reparatur und gut ist ..
.. und in der Zeit fragt einer, der nicht wissen darf, das der Melder zur Reparatur ist "Wo ist denn
dein Melder?" oder will den zufällig genau in den 3 Tagen bis 2 Wochen, die das Ding weg ist,
unter die Augen oder in die Hände nehmen können ..

Zählt nun das Umprogrammieren eines HiOrg-Melders zu einem Dienstvergehen? Ganz gleich,
wie es einzustufen ist - spätestens ein "primär kaputter" Melder wird irgendwo in die Richtung
"Sachbeschädigung" gehen, lassen wir das mal juristisch in dieser "Schwebeposition" .. wir wollen
gar nicht erst in die oft diskutierte "Mithören reinprogrammieren" oder "unberechtigt(e) Schleifen
hinzufügen" eingehen - das wurde anderorts zur Genüge getan, das TKG wurde oft genug zitiert
(und dennoch hat fast jeder Feuerwehrmann, den ich kenne, einen "offenen Melder" *duck*) ...

Du weisst, was Kondensatoren sind - ich frage nun nicht, wie es sonst so aussieht mit Fachwissen
Elektronik, die Antwort kannst du dir ja schliesslich selbst besser eingestehen als hier im Forum
darauf einzugehen. Nur spätestens, wenn du sagst, das du nicht weisst, wie du den Melder nun
anschliessen sollst, und das bei signaltechnisch einfach zu offensichtlichen Parametern ..

BITTE informier dich, bevor du dir den Melder zerschiesst ! Oben drin steht, wie PC über Pegel-
wandler an Melder kommen.. wie bei welchem speziellen Melder die Anschlüsse belegt sind,
findest du hier und anderorts.. die Informationen sind auf einem nicht zu hohen Niveau und sollten
verständlich genug sein... aber bitte sei dir sicher, das der Melder genug Spannung hat, und
du dir den nicht genau im falschen Moment aus der improvisierten Klebeband-Programmierstecker-
Halterung reisst...
Lacht nicht, es gibt sogar IT-Techniker, die in der Werkstatt ein BIOS neu flashen, aus irgendeiner
Eingebung ein Päckchen PC-Schrauben, gemischt, in die Hand nehmen, lachend "wetten, ich treffe
den Not-Aus-Schalter" sagen, über die Schulter ohne hinzuschauen hinter sich werfen ... und das
Licht (und der PC, der geflasht wird) ausgehen ... Treffer ..

Gruss,
Tim

PS: Ich sehe es schon kommen, diese Message-ID wird man nun jedem an den Kopf werfen,
der eine Programmierstation bauen will ... oh, ich hab noch vergessen, zu Fragen, wie du an
die Programmiersoftware kamst, vorsicht, es gibt da eine Rau...erm, dezentrale Sicherungskopie
mit einem fiesen Virus, hab ich mal Gerüchte gehört ... denn meistens ist bei der Original-
Software eine Programmiereinrichtung dabei oder umgekehrt .. gut gut, die neueren Digitalmelder
haben ja zum Teil "Freeware" oder "ca 25 EUR" Programmiersoftware ohne Hardware im
Angebot .. aber das ist ein anderes (und auch schon oft diskutiertest) Thema ..