Alles Mögliche rund um die Technik vom DB0QI

Neues am und um DB0QI: (sonstiges Neues auf der DL1MFK-Homepage ist hier zu finden)

(Die Links sind in umgekehrter zeitlicher Reigenfolge)

Der ATV-Umsetzer DB0QI soll jetzt mal SCHÖN dokumentiert werden ...

Der ist ein ATV-Umsetzer in München der auf dem Siemens-Hochhaus einen Platz gefunden hat. Mittlerweile ist er doch in die Jahre gekommen und man hat beschlossen die ganzen änderungen und Verbesserungen die in den Jahren entstanden sind nun sauber zu dokumentieren ... Naja es kennt doch jeder es wird hier mal eben schnell eine Neuerung aufgebaut, getestet und dann eingebaut. Wie immer funktioniert sowas NIE auf Anhieb. Nun wird ein Provisorium entstehen um die neue Funktion doch einzubinden. Nur spätestens hier wird kein Papier bemüht ... naja und über längere Sicht geraten einfach Dinge in Vergessenheit. Die Aufgabe ist es nun sich ein aktuelles Bild zu verschaffen und dabei auch das ein oder andere Problem in den Griff zu bekommen, das doch noch existiert. Es gilt nicht verwendete Komponenten rauszuwerfen und oben genannte Provisorien "ordentlich" einzubaun ... bis dahin wirds wohl noch ein weiter Weg sein, aber ein Anfang ist gemacht. Steuerleitungen und Signalwegen werden jetzt verfolgt und versucht deren Bedeutung zu entschlüsseln :-)

Irgendwann soll hier mal eine nette Info-Seite zum DB0QI entstehen, aber da bin ich nun Mal gaaaanz am Anfang. Es fehlt wie gesagt noch die Dokumentation in einem Blockschaltbild und eine Beschreibung dieser Funktionen. Auch Bilder der Antennen und sonstiger Komponenten, sowie ein wenig zur Geschichte vom QI will ich hier noch feilbieten aber das kann noch dauern ...

rauf Home

Erste Eindrücke von der "Dokumentations-Stoffsammlung" am DB0QI (02.10.2004):

Mit dabei waren:

- DH1MMT Herwig
- DB3CD Dietmar
- DL6MAQ Fritz
- eine Tüte voll mit Leberkäs-Semmeln (Leider keine Bilder davon)

 

 

Die größte Nuß die es zu Knacken gilt ist die gigantische Steuer-Software, die der Deti DG9MHZ geschrieben hat. Leider findet sich nur sehr wenig Dokumentation darüber, aber Stück für Stück finden sich dazu verschiedene Bausteinchen, die sich zusammenfügen lassen. Damit können vielleicht änderungen und Erweiterungen auch zusätzlich eingebaut werden. Ideen dafür sind ja immer zu Hauf vorhanden.

rauf Home

Das erste Papier zum veröffentlichen ist fertig

Inzwischen hab ich auch zusammen mit dem Herwig DH1MMT eine übersicht erstellt, die sicherlich noch nicht ganz alles erfasst.

rauf Home

Erste Grundgedanken zur Neugestaltung von DB0QI

Der DB0QI ist ja mittlerweile in die Jahre gekommen, was nicht bedeuten soll, daß er nicht mehr funktioniert oder technisch veraltet ist. über die Jahre sind viele Elemente dazu gekommen und es ist viel verbessert und erweitert worden. Nun soll aus diesen Erfahrungen heraus und aus neuen Ideen Stück für Stück ein Komponenten-Umbau erfolgen. Die ersten Baugruppen werden die Steuersender und Empfänger sein.

Als neue Idee soll hierbei mit einfließen, daß sowohl jede Einzelkomponente, z.B. RX, TX, etc ... autark für sich arbeiten können muß, sowie auch als 8er-Verbund eigenständig, mit einer extra Bedieneinheit, als auch von Außen über eine Gesamtsteuereinheit und ebenso von einem PC, DTMF oder sonstwie fernsteuerbar sein soll. Um dies zu realisieren soll jede Einzel-, wie Verbundkomponente einen kleinen Steuerungsprozessor besitzen. Als gemeinsamer Steuerbus soll der I2C-Bus eingesetzt werden.

Probleme die es hierbei zu beseitigen gilt:
Durch die Vielfalt der Komponenten die auch intern nicht immer mit einem I2C-Bus arbeiten, ist es schwierig eine gemeinsame Steuerung zu bauen. Ebenso verfügt der I2C-Bus über einen begrenzten Adressraum, speziell die wenn die Einzelkomponenten jeweils eine andere Adresse besitzen müssen, um alle getrennt zu steuern. Als Beispiel sei erwähnt, daß auch PLL-I2C-ICs nur 3 gültige Adressen haben können, es aber gewünscht ist 4 Empfänger zu nutzen. Damit wäre es auch unmöglich diese Einzelkomponenten flexibel als Ersatz bereit zu halten, da dann für jeden Einschub eine Vielzahl von Adressen eingestellt werden müssen. Ein Ausweg wäre mehrere I2C-Busse zu verwenden.

Hieraus entstand folgende Idee:
- Jede Komponente (Einschub RX) in einer Kategorie (max. 8 x RX-Einschübe in einem 19" Gehäuse) hat die gleichen Adressen und Parameter. Damit kann jede Komponente einer Kategorie beliebig gegeneinander ausgetauscht werden.
- Jede Komponente hat eine Möglichkeit über ein ansteckbares Tasten- und Anzeigemodul bedient und eingestellt zu werden. Die Werte sind im Prozessor-Eeprom gespeichert. Die Adressen der ICs (Prozessor, PLL, I2C-Bausteine aller Art) auf diesem Modul sind auf allen Komponenten die gleichen. Jede Komponente hat für die Kommunikation genau einen I2C-Bus. Sonstige Signal Ein- und Ausgänge müssen identisch sein.
- Jede Kategorie hat ein fest eingebautes Tasten- und Anzeigemodul das die jeweiligen Komponenten bedient. Wie gültigen Parameter der Kategorie wenden in einem I2C-EEProm gespeichert
- Jede Kategorie hat genau einen I2C-Bus zur Steuerung wiederum von Außen über verschiedene Baugruppen wie autarke Steuerungsplatine als Schnittstelle zu DTMF, über PC als Schnittstelle zu Packet-Radio.

Diese Forderungen bedeuten, daß jede Steuerungsebene gleichberechtigt ist. Um das zu realisieren ist es notwendig die Werte jeder Komponente allgemein zugänglich zu hinterlegen. Damit soll es möglich sein Komponenten einfach im "heißen" Zustand einfach auszutauschen. Wird nun eine beliebig konfigurierte Komponente an einen Platz gesteckt, welche zuvor eine gültige Konfiguration besaß (also z.B. ein Austausch eines Steuersendereinschubs weil dieser defekt ist) dann soll die "frische" Komponente automatisch nach dem Einstecken die Parameter übernehmen, die für diesem Steckplatz gelten. Die Werte werden aus den I2C-EEProms der Kategorie ausgelesen. Der Kniff ist einen I2C-Baustein zu verwenden der einen I2C-Bus als Eingang verwendet und diesen auf einen von 8 Ausgangs-I2C-Bussen zu schalten. Auf jedem dieser Ausgangs-I2C-Busse liegt jeweils ein EEProm. Damit haben auch alle EEProms die gleiche Adresse. Im gesamten System ist somit über einen I2C-Bus, über die Kategorie-Adresse und die Komponenten-Adresse ein Einschub explizit ansprechbar. Das Ganze erfolgt allerdings indirekt. Soll nun ein Parameter einer Komponente verändert werden wird nur der Parameter im I2C-EEProm geändert. Die Komponente selbst frägt den Inhalt dieses I2C-EEProms ab und aktualisiert dann den geänderten Parameter. Sind die Werte des EEProms ungültig werden diese Werte mit denen der Komponente überschrieben. Ist das EEProm nicht vorhanden werden die eingestellten Parameter der Komponente nicht verändert. Der Lese- und Schreibzyklus beträgt ca. 5s. Somit ist gewährleistet, daß der Datenverkehr auf den verschiedenen I2C-Bussen nicht überhand nimmt.

Als Bild soll das dann so aussehen:

Die Kategorie "maximal 8 TX" soll intern so aussehen:

Alles Klar ???

rauf Home

Erste Versuche mit dem I2C-Multimaster-Bus

Einige interessante Dinge sind mittlerweile passiert. Nach dem sich die PIC-Prozessoren die ich bis dato im Einsatz hatte, haben sich für diesen Schnittstellen-Betrieb disqualifiziert (Die wollten einfach ab und zu wenn man das Richtungsregister beschreibt, an den Ein und Ausgangspins nicht die Klappe halten ... nur bis ich da draufgekommen bin ....), habe ich mich auf die Suche nach einem Pic gemacht der die I2C-Schnittstelle schon fest eingebaut hat und außerdem über mehr Speicherplatz verfügt. Das ist also jetzt der PIC16F88. Er hat so manchen Vorteil, nur um das I2C-Modul nutzen zu können mußte ich nun komplett das CPU-Layout ändern ... (die CPU-Schaltung und das Layout ist hier beschrieben) ... hier mal ein paar Bildchen des Versuchsaufbaus:

mal ein überblick über den ganzen Saustall .... hihi

Ein Test-19"-Einschub um die vom Herwig entflochtene Platine bequem verwenden zu können:

Hier schon mal ein Blick auf die neue CPU-Platten :-)

Aber der ärger sollte noch weiter gehen ... immer wieder nach unzähligen Versuchen gab das I2C-EEprom auf. Zuerst dachte ich daß meine Soft einen Fehler hatte, aber es scheint so als ob die Häufigkeit des Datenaustausches daran schuld sei. Klar daß ich natürlich für richtig Streß auf den Datenleitungen sorge um zu überprüfen ob die Multimaster-Soft auch tut -)

Nächster Schritt ist jetzt ein FRAM anstatt der EEProms zu betreiben, diese erlauben eine weit höhere Anzahl an Lese- und vorallem Schreib-Zugriffe.

rauf Home

Frams werden eingebaut

Das Dumme war nur daß die FRAMs nur in SMD gebaut werden. Somit war Adapterbasteln angesagt:

Gut daß diese RAMs sind den Beanspruchungen dieses Systems im Gegensatz zu herkömmlichen I2C-EEProms gewachsen. Nach einigen Versuchen stellte sich heraus, daß der Bus nicht mehr hängen bleibt, und sich die Bausteine auch nicht mehr ins Nirwana verabschieden. Prima, nur ist meine Software leider noch nicht ganz sattelfest was Kollisionen angeht. Den größten Teil der Zeit haut das schon ganz gut hin:

Nur ab und zu gibt es noch ungültige Daten ... das ist noch zu lösen in diesem Aufbau:

rauf Home

Endlich ein zuverlässiger multimasterfähiger I2C-Bus ...

der sich auch so richtig stressen lässt, bis keine Pakete mehr in die Zeitachse passen. Nur die Bedienung wird dann recht zäh, aber so massiv sollte der reguläre Betrieb auf diesem Bus dann auch wieder nicht sein :-) Nach vielen Fehlschlägen ist es endlich geschafft. Drei Frams, zwei I2C-Switch-ICs und vier PICs haben in dieser Zeit aufgegeben. Die Frams und die I2C-Switch-ICs sind statischen Aufladungen zum Opfer gefallen, und die PICs sind wohl zu oft neu programmiert worden. Es stehen noch ein paar Kleinigkeiten an, aber die Basis-Routinen sind fertig. Die Software in den Einschüben und den Modulträgern ist identisch. Es werden lediglich verschiedene Softwareteile hinzu oder weg geschaltet. Diese Konfiguration ist für jeden Steckplatz im FRAM abgelegt, zusammen mit den spezifischen Arbeitsdaten. Die Software die alle Einschübe steuert ist in ihren verwendeten Teilen so eingestellt, daß diese nur Daten ins FRAM schreibt oder ausliest. Es fehlen noch die Softwareteile für die Europakarten-Empfänger, aber dazu muß ich erst noch in einer ruhigen Minute wieder ein wenig Platz in den PICs schaffen :-). Im Grunde ist somit dieses Projekt fertig.

rauf Home

Ein RS232 nach multimasterfähigem I2C-Bus Konverter gibt sich die Ehre

Im Augenblick ist ein weiterer Baustein kurz vor der Fertigstellung: Der PC soll ja alle Modulträger und Einschübe steuern können. Dazu muß dieser erst einmal I2C tauglich gemacht werden. Da ich es für unsinnig halte jetzt Klimmzüge zu machen, die serielle oder parallele Schnittstelle so zu verbiegen, daß diese multimasterfähig ist, bin ich einen anderen Weg gegangen:

Die serielle Schnittstelle wird auch als solche verwendet. Die übersetzung der RS232-Daten in Multimaster-I2C soll ein PIC übernehmen. Ein extra übertragungsprotokoll habe ich mir gespart, da sowas doch einigermaßen aufwendig ist dies auch in einen PIC zu packen. Das soll aber nicht bedeuten daß ich keinen Wert auf übertragungssicherheit lege. Ich habe den einfachsten Weg gewählt und einfach aus den zu übertragenden Daten eine Prüfsumme zu berechnen und entsprechend auszuwerten. Somit ist eine übertragungssicherheit von 99,9% erreicht, wenn man der einschlägigen Literatur trauen darf :-)

Die Software des Konverters ist fertig, mit einer Einschränkung. Der Datenverkehr ist bis jetzt nur so ausgelegt, daß ausschließlich der PC als Master somit agieren kann (wie ja auch die ganzen anderen PICs auf den I2C-Leitungen. Sollte es irgendwann auch einmal notwendig sein auch einen SLAVE-Betrieb zu ermöglichen, wird das auch noch eingebaut.

Hier ist noch Schaltplan, Layout und Bestückungsplan und da mehr zu finden.

Was mir im Moment noch Kopfzerbrechen bereitet ist die visuelle Aufbereitung der ganzen Modulträger und Einschübe. Eine Oberfläche zur Steuerung der einzelnen Einschübe ist bereits fertig und die Steuerungssoftware ist auch nahezu komplett. Es fehlen nur noch die Darstellungen und Steuerungen der laufenden Software-Komponenten der einzelnen Einschübe. (Man ist das kompliziert .... hihihi) Sieht bis jetzt mal so aus:

Um damit arbeiten zu können hab ich ein uraltes Platinchen zur Pegelwandlung von RS232 auf TTL mittels MAX232 verwendet, und die Datenleitungen gehen auf die entsprechenden Eingänge des PIC16F88 (AUSART Pins). Im Moment ist an die 16F88er Platine auch das Display noch angeschlossen, damit ich auch (noch) Fehler suchen und anzeigen lassen könnte.

Bei der vielen Programmiererei ist mir auch der Sinn nach einem kleineren Programmiergerät gestanden. Die Dateien dazu, Schaltplan, Layouts diskret und SMD findet man hier.

rauf Home

Die Softentwicklung geht voran ... (23.12.2005)

In der Zwischenzeit ist mit der Soft einiges passiert. Meine Wunsch-Soft war, daß ich nur eine Version für alle RX und TX-Module bastle, aber leider sind auch 4k dann ein recht begrenzender Faktor. Auch mit vielen Klimmzügen und doppelter Verwendung von Variablen und RAM war das Problem nicht zu erschlagen, zumal dann auch noch ein paar Module in der Soft fehlten. Also nochmal alles zerpflückt und 2 Module geschrieben, einmal für RX und 8-fach-RX-Steuerung und ein weiteres für TX und 8fach-TX-Steuerung.

Nun ist auch der Komfort einer bequemen Darstellung der Frequenz bei der Verwendung von ZF/LO und Vervielfachern brauchbar eingearbeitet und läßt sich schön mittels 2x8 Zeichen darstellen. Auch die Konfigurationen der einzelnen PICs auf den unterschiedlichen Platinen läßt sich großteils jetzt automatisch konfigurieren. Das bequemste Element zu Bedienung ist der PC über den RS232/I2C-Konverter. Die PC-Soft ist mit den zusätzlichen Modulen nun auch ausstaffiert, und somit läßt sich eine Grundkonfiguration der RX bzw. TX-Karten bequem einstellen. Nur die Gesamtübersicht eines 8fach RX/TX ist noch nicht in Code für den PC verwandelt, weil mir einfach noch keine schöne Oberfläche dazu einfallen will :-)

Nachdem nun der erste Prototyp eines RX-19 Zoll Trägers fertig mit den Leiterkarten bestückt ist, ist der nächste Schritt die noch fehlenden Bauteile einzulöten und dann die Software einzuspielen und ausgiebigst zu testen.

rauf Home

Abspecken spart Zeit... (26.02.2006)

Hier die Idee um die doch aufwendige Steuerung optisch einigermaßen aufzubereiten ... naja der Code dazu ist noch lückenhaft aber ein Anfang ist getan, und so siehts bis jetzt aus:

ich denk damit läßt sichs arbeiten. Das Configurations-Menue bereitet mir noch etwas Kopfzerbrechen, aber das ist jetzt noch nicht so aktuell.

Nachdem nun manche OMs schon in den Startlöchern scharren, gibt es nun für den RX-Einschub einfach nur ein kleines "Soft-Paket" um die ersten Langzeit-Versuche zu starten. Mein Wunsch die Software so komplex zu gestalten, daß wirklich jede Ebene autark arbeitet und vor allem auch von allen Ebenen zu bedienen ist, ist im Moment einfach mal hinten angestellt. Die Software die jetzt in die Controller eingespielt wird, kann also im Moment nur eine Bedienung der RXe über die Controllerkarte für alle RX-Platinen und ist im Moment nicht über den I2C-RS232-Konverter zu bedienen. Die Funktion ist also lediglich das der RX-Zusatzplatinen-Controller seine Werte aus dem FRam abholt und an die PLL weitergibt (Tasten und eine Anzeige können jedoch angeschlossen werden). Die 8-fach-Controller-Platine kann die FRams bedienen und zeigt die eingestellten Frequenzen an. Die Software auf beiden Seiten des FRam ist mittlerweile so gestaltet, das sie nach einer Zeit einfach wieder bei "0" anfängt, sich also immer so benimmt, als wenn der Controller neu gestartet wird.

Der Prototyp ist nun fertig aufgebaut, mit allen Bauteilen bestückt, 2 RX-Platinen mit Zusatz-Platinen (hier ist der Controller drauf zum Steuern der PLL, mit Möglichkeit auch völlig autark mit und ohne FRam zu arbeiten), die Steuerungs- und Anzeigeplatine die alle 6(8) RXe bedient, mit einer einfacheren Soft mittlerweile am Laufen.

rauf Home

Auslieferungszeit ... (28.02.2006)

Heut war es soweit, der Herwig (DH1MMT) hat div Updates aus dem Internet für seinen Lappy bekommen, außerdem hält er für den nächsten QI-Besuch den Begrenzer-Verstärker in seinen Händen, und was viel wichtiger ist, er hat nun den ersten fertigen Einschub für max. 6 Empfänger mit samt multimasterfähiger I^2C-Bus-Steuerung ... mal sehen wie gewöhnungsbedürfig die Software für andere außer mir ist.

Endlich auch mal Bildchen davon:

Die Anzeigen an den beiden Steuerplatinen neben den Empfängern waren nur zum überprüfen da ob die Soft auch wirklich das tut was man von ihr erwatet.

Noch ists ziemlich leer in dem Gehäuse, aber es sollen da insgesamt 4 Empfänger rein und ebenso 4 Steuerungen. (mittlerweile sind es jeweils 7 ... Nov. 2009)

rauf Home

Michaels 13cm ANTENNE (24.11.2006)

Endlich gibts Bilder der Antenne für die 13cm Eingabe, gebaut von Michael DH0GMI:

Hier die Einspeisung mal etwas genauer:

Der Fuß mit dem vielleicht zukünftigen Konverter:

Respekt !!!!

Hier die Bilder von den ersten Versuchen auf dem QI-Dach:

Mal sehen wann die Antenne fest instaliert wird !!!

rauf Home

Ein Schritt weiter in Richtung Neubau (10.03.2007)

Inzwischen ist einiges an neuer Software entstanden. Es existieren nun I2C-Slaves für die OSD-Module die an jedem Empfänger angeschlossen sind, und zum Steuern der neuen Videokreuzschiene. Die Software stammt von Ernst DJ7DA. Der DTMF-I2C-Konverter kann nun die OSDs ansprechen und entsprechend Schalten. Die Software zum Videoschalten ist zwar fast fertig, aber noch nicht implementiert. Es gibt eine neue Software im RS232-> I"C-Konverter. Sie bedient RX und TX-FRAMs, die OSDs sowie die Videokreuzschiene. Um dieses Modul ansteuern zu können gibt es jetzt zum Einstellen der TX/RX-FRAMs, der OSDs (mit Laufschrift) und der Videokreuzschiene, ZWEI Programme. Einmal zur bequemen übersicht Vorort mittels Laptop oder vorhandenem Rechner, graphisch einigermaßen selbsterklärend, wenn auch noch ein wenig im "DEBUG-Desgin" :-), zum Anderen ein DOS-Programm das Befehlszeilen auswertet und damit die Geräte bedient und abfragen kann. Dieses Tool ist die Voraussetzung, damit die Geräte auch bequem über PR angesprochen werden können.

Es war ein Berg von Emails, ein Container voll Flüchen und viel Geduld von Ernst notwendig bis die verschiedenen Programmbausteine endlich brav miteinander komuniziert haben :-)

Hier die Softwareschmiede samt portabler Hardware-Entwicklungsumgebung:

So sieht das Windows Werkzeug nun aus:

Im Moment bin ich noch nicht ganz zufrieden, weil ich zu jeder zusätzlichen Hardware auch den RS232-I2C-Konverter neu programmieren muß. Vielleicht finde ich noch die Zeit und Muße das gute Stück so umzustricken daß "nur" die Lese und Schreibbefehle sowie die zu übertragenden Bytes angegeben werden müssen .... leider läßt sich dies mit dem DTMF-Modul nicht realisieren ... da muß ich dann wohl jedes mal ran :-)

Vielen Dank an den Ernst für die Geduld und das unermütliche Testen der Software !

Inzwischen ist die Software so flexibel, daß damit alle I2C-Funktionen allgemein ausgeführt werden können. Infos sind hier.

rauf Home

Die Empfänger sind im Rack (24.07.2007)

Nachdem die Schachtel mit 6 Empfängern und Steuerplatinen fertig war, die Software für DTMF, PC-Fernsteuerung mittels RS232 ausgiebig getestet war, stand nun an, eine weitere Fernsteuerung über PacketRadio zu realisieren. Die Steuerung über das TROVA (Hier die VB_6 Sourcen der aktuell verwendeten Version.), also die Windows-Oberfläche hatte ja bereits die RS232 Schnittstelle zum I2C-Bus verwendet. Jetzt war es an der Zeit diese Schnittstelle von Packet aus bedienbar zu machen. Gerhard DH8MO hatte mir einen fix und fertig konfigurierten PC mit USCC-Karte, 70cmTRX, Flexnet-Digisoftware in die Werkstatt getragen. Das Service-Programm von Deti DG9MHZ war das Ziel meiner Versuche. Es mußte nun ein DOS-Programm entstehen das eine ASCII-Zeile aus Packet umsetzt und auf der COM-Schnittstelle ausgibt. Mittels QBasic ist nun ein Werkzeug entstanden mit dem sich die Frequenzen der RXe einstellen lassen, die Einblendungsbausteine entsprechend geschaltet werden und auch der Lauftext übergeben werden kann, die zukünftige Videokreuzschiene läßt sich schalten, sowie der neue Audio-Mischer. Es war zwar noch der ein oder andere Klimmzug und längst verschüttetes Dos-Wissen wieder ans Tageslicht zu bringen, notwendig, aber nun läufts. Hier ist der Sourcecode für das QBasic 4.5

Die ersten Tage verliefen ganz brav, bis auf einen Absturz des zusätzlichen PR-Rechners ... ein Watchdog tut not ....

Hier einige Bilder des neuen 6-fach-RX-Einschubs:

Der eigentliche Empfänger:

Auf dieser Zusatzplatte zum Empfänger ist der Steuerrechner, der die RX-PLL bedient, sich die aktuellen Einstellungen aus dem FRAM holt. Optional können hier noch Tasten und ein LC-Display angeschlossen werden um den RX auch alleine bedienen zu können. Außerdem befindet sich hier noch ein weiterer Controller der das OSD-Modul steuert, und selbst seine Daten über den I2C-Bus bekommt. Auch ein zusätzlicher Audio und Videoausgang wird hier bereit gestellt, so wie die Aufbereitung der AGC (Feldstärke) und Audio-Spannung für die Darstellung im OSD.

Hier stecken jetzt die Empfänger drin. Die Bedienung des ganzen Einschubs erfolgt über die 3 Tasten und das LCD. Was nicht zu sehen ist, ist der RS232 und DTMF -I2C-Konverter.

Hier noch ein Überblick der Verdrahtungsarbeiten von Herwig (Mannomann der macht dees sauber, wann ich mich da mal so zamreißn könnt ...)

Jetzt wird getestet .....

rauf Home

Und endlich kommt der 13cm Zugang (30.07.2007)

Die Empfänger laufen nun schon einige Tage brav bei der 10 GHz-Eingabe und den Links von OE2XUM, DB0TVM und DB0ITV. Nun war es an der Zeit auch die Eingabe auf 13cm auf den´neuen RX umzustecken.

Zuerst wurden aber noch Messungen gemacht was denn so alles in der Luft ist. Leider war's an diesem Tag wirklich seeehr ruhig, keine Auto/Gaaraaaschendorghamera, und keine Wohnzimmabisinsschlafzimmaübertragung, auch WLAN war in der Nähe der 2392.5MHz Eingabe zu sehen.

Die Messungen waren also ok, nun die noch fehlenden Kabel umstecken und Einschalten

Mancher betrachtet das seeeehr skeptisch ......

Klar bei dem Materialaufwand der in den 24.Stock getragen wurde:

Aber Herwigs Test hat auf Anhieb fongsionierd.


rauf Home

Noch Fragen ???

73 de Tomtom

Home