Er sagte: „Er wird von vielen QO-100-Benutzern und Microwavern in Europa verwendet“. Er sagte auch, dass es auf der BATC-Webseite mehr Informationen über die Verwendung dieses LNBs gibt. Also haben ein paar von uns Boulder-ATV-Funkamateuren bereits ein BullsEye zum Testen gekauft. Wahnsinn! Niedrige Kosten - nur $ 30 bei E-Bay und großartige Leistung! Der Hersteller behauptet: „Der Bullseye LNB ist der präziseste und stabilste Ku-Band-Abwärtskonverter der Welt“. Glauben Sie es. Unsere Messungen haben gezeigt, dass er genau auf der Frequenz ist.
Die wichtigsten Daten sind: Modellnummer BE01; LO Frequenzen = 9.750 & 12.750 GHz, Frequenz-Abdeckung = 10,489 - 12,750 GHz (tatsächlich für das gesamte 10-GHz-Band der Amateure nutzbar), ZF-Frequenz = 739 - 2150 MHz (funktioniert wirklich gut unter 739), Rauschzahl = 0,5 dB, Umwandlungsverstärkung = 50 bis 60 dB. Die LO-Frequenz ist laut Herstellerangaben auf 1 kHz genau kalibriert. Ein zweiter F-Anschluss bietet Zugriff auf den 25-MHz-Referenzoszillator.
Erste Tests auf dem Prüfstand haben gezeigt, dass der LNB in einem breiten Bereich von Gleichspannungen funktioniert. Bei +12 Vdc zog er 90 mA Strom, er funktionierte bis +7,5 Vdc (150 mA). Wenn die Gleichspannung +14,5 Vdc übersteigt, schaltet der LNB automatisch die Polarisation von vertikal auf horizontal um. Bei 16 Vdc zog er 60 mA. Die normale LO-Frequenz beträgt 9,75 GHz, was ideal für den Einsatz im 3-cm/10-GHz-Band ist. Wenn ein 22-kHz-Ton in die ZF+DC-Leitung eingespeist wird, soll der LNB den LO auf die höhere Frequenz umschalten. Wir hoffen, in zukünftigen Ausgaben dieses Newsletters über unsere Betriebserfahrungen mit diesen BullsEyes im Feld bei 10-GHz-DVB-T DX-Peditionen berichten zu können.
Jim Andrews, KH6HTV, editor - kh6htv@arrl.net
10-m-DATV-TRX update
Ich habe den Videokomprimierungsprozess weiter verbessert mit den Schlüsselbildern und den Bewegungsbildern. Ich schaue jetzt, dass ich die Audiokompression in Hardware durchführe, da es viel einfacher ist, auf dieser Ebene zu arbeiten für das, was ich tun möchte. Ich plane einen R+L, R-L Prozess, bei dem 3/4 der Informationen die Summe der beiden sind und 1/4 die Differenzinformation. Ich schaue mir auch einige der Möglichkeiten an, wie NiCAM mit digitalen Audio-Bitströmen arbeitet. Da die Video- und Audioinformationen keine Fehlerkorrektur haben, wird nur die Rauschunterdrückung verwendet, was eine große Einengung für die mischbare Nutzbandbreite darstellt.
Da ich mit den SDR-Schritten viel weiter fortgeschritten bin, arbeite ich nun mit GNU Radio unter Linux und verwende eine UDP-IP-Schnittstelle zwischen der Videokompressionssoftware und dem SDR-Block. Ich habe eine einfache UDP-Rückschleife in GNU Radio und baue nun die Mehrfachträger-OFDM mit 256FSK oder 256PSK auf, was einige Monate Arbeit in Anspruch nehmen könnte. Um DSP mit FPGAs zu lernen, fange ich wieder von vorne an, um herauszufinden, wie man GNU Radio mit seinen SDR-Blöcken nutzt. Hat jemand Entwicklungsarbeit mit GNU Radio gemacht? Ich wäre interessiert daran, Feedback zu bekommen, wie man die Modulator- und Demodulatorstufen zum Laufen bringt. Ich plane, die Linux-Software irgendwann im nächsten Jahr öffentlich verfügbar zu machen, basierend auf den Tests, die ich im Moment durchführe.
Die Software besteht aus zwei Teilen, dem Video-Kompressor und -Dekompressor, die in Gambas3 geschrieben wurden, und dem SDR in GNU Radio geschrieben. Ich hoffe, bald eine 192-kHz-PCIe-Soundkarte bestellen zu können, um einen Basisbandausgang zu bieten, da 48 kHz zu niedrig ist, um alle digitalen Video- und Audio-Informationen in eine modulierte Wellenform unterzubringen. Es gibt also Fortschritte, aber nur sehr langsam, und ich hoffe, den Modulator und den Demodulator bis Ende des Jahres in Betrieb zu nehmen und im Kurzschlussbetrieb zu testen.
Der Signalprozessor arbeitet in Hardware mit PWM, aber ich suche nach Möglichkeiten, ihn in SDR-Blöcke umzuwandeln, da dies ein wichtiger Teil ist, um den Ionosphären-Phasenjitter herauszufiltern. Ich werde sehen müssen, etwas in Python zu kodieren, um den Signalprozessor in SDR-Blöcke umzuwandeln, da dieser Ansatz bisher noch nicht gemacht wurde. Ich kann in BASIC und VHDL programmieren, und ich hoffe, dass Python eher wie BASIC zu arbeiten ist und nicht wie C-Code, den ich nicht gut beherrsche.
Ein einfaches Hardware-ATV-Projekt wird jetzt mehr zu einem Softwareentwicklungsprojekt, um die Kosten auf ein Minimum zu reduzieren. Die gute Nachricht ist, dass ich im nächsten Jahr ein Ende in sehe, wenn ich nicht durch andere Dinge abgelenkt werde. Ich habe mir die SDR-Hardware noch nicht angesehen, aber ich denke immer noch daran, den HackRF zu verwenden, da er heutzutage sehr verbreitet ist und GNU Radio ihn unterstützen wird.
Grant Taylor, VE3XTV, North York, Ontario, Kanada
Quelle: www.kh6htv.com