Title: OVI40 RF - wie ist der Stand?
Post by: DF8OE on 14. May 2019, 05:47:46
Ursprünglich hatte ich meinen Beitrag unter "fertiggestellten mcHF" geschrieben - mich aber dann doch dazu entschlossen einen eigenen Beitrag daraus zu machen.
Sicher gibt es immer irgendwas, was man nachbauen kann. Oder etwas, wo man an "ein paar Kleinigkeiten" feilen kann, um etwas ein wenig besser zu machen.
An der Stelle stand ich vor zwei Jahren - als ich vor hatte, das Konzept "Tayloe Mischer" TX- und RX-seitig zu verbessern und als "neue OVI40-RF-Platinen" herauszubringen. Man konnte doch tatsächlich an fast allen Nicklichkeiten herumschrauben. Als ein Beispiel greife ich mal die mangelhafte LO-Unterdrückung im TX-Betrieb auf. Die kann man durch einen DC-Pegel am Mischereingang kompensieren. Das ist schnell herausgefunden: und so hat Artur zwei Trimmer an die Mischereingänge gelegt. Logisch - schlüssig - aber leider keine Lösung des Problems. Denn der benötigte DC-Pegel ist frequenzabhängig. Also habe ich experimentiert, ob man aus dem Audio-Codec einen DC-Offset herausbekommt: ja - geht, bekommt man. Sah an der Stelle nicht schlecht aus. Allerdings habe ich dann herausgefunden, dass der DC-Pegel auch von der Aussteuerung des Mischers (also dem "NF-Eingangssignal") abhängt. Grmblgrrr..... Noch etwas wo man eine dynamische Abhängigkeit hat. Also wären alleine für die Nicklichkeit "durchgereichter LO im TX-Betrieb" ZWEI dynamische Fixes nötig, die sowohl im Hardware- als auch im Softwarebereich abgefangen werden müssen. Und man müsste das tatsächlich bei jedem Gerät individuell einrichten. Wenn ich dann resümmiere wie viele der mir zur Reparatur eingeschickten mcHFs keinen IQ-Abgleich hatten - dann frage ich mich wie wie viele denn solche zusätzlichen Abgleiche vornehmen würden. Aktuell liegt ein Pull Request von jemandem vor, der als Hardwareänderung eine kleine Platine mit zwei DACs an den Mischer anschließen möchte und über diese den DC-Offset generiert. Ich weiß nicht ich weiß nicht ob das wirklich Sinn macht... Es geht nicht um den technischen Sinn - es geht um den praktischen Sinn. Denn diese Kompensation ist nur EINE. Es gibt sowohl im TX als auch im RX Zweig noch etliche Stellen mehr an denen meine Platinen solche "Korrekturmaßnahmen" hatten und wer diese "Optimierungen" am mcHF schon mal experimentell gemacht hat weiß wovon ich rede.... Klar kann man sagen: "A brauchen wir und B nicht" - dumm nur dass der nächste aus seiner Sicht sagen wird "B brauchen wir und A nicht".
Ich bin für mich zu der Entscheidung gekommen, dass das Tayloe-Konzept die gesetzten Ansprüche nicht erfüllen kann. Die Bauteile sind leider nicht "ideal" - und die dadurch entstehenden Probleme bei diesem Konzept führen dazu, dass man zwar sehr leicht ein "passables Ergebnis" erreichen kann - aber jeder Schritt darüber hinaus führt zu neuen (dynamischen) Abgleichpunkten und/oder hardwareseitig schwierigeren Aufbauten. Da es sehr viele kleine Punkte zum Verbessern gibt pilzt eine Lösung für alles gewaltig auf. Auch schließen sich einige Kompensationen gegenseitig aus bzw. behindern sich.
Ich bastle zwar gerne - noch lieber "entwickle" ich: aber RICHTIG.
Also habe ich mich weiter umgeschaut und bin auf den "Adalm Pluto" gestoßen. Sofort gekauft - und experimentiert. Dort werkelt ein Tranceiverchip von Analog Devices, der den Bereich 70MHz...6GHz abdeckt. Technisch interessierte können im Web jede Menge Infos bekommen. Den sollte/müsste man mit dem OVI40 verheiraten - dann hätte man für den VHF/UHF/SHF-Bereich eine sehr gute Lösung. Also sofort herangemacht. Einen Zync brauchen wir dafür nicht unbedingt - ein "einfacher FPGA" sollte reichen. Meine Wahl fiel auf den Spartan6. Also eine Platine entworfen. Beim Entwurf Magenschmerzen und Gedanken "was machen wir für den SW-Bereich bis 4m"? Mischen in den Arbeitsbereich des AD9363? Direktwandeln? Besser wäre sicher direktwandeln. Aber AD-Wandler mit 160MHz Samplefrequenz sind sündhaft teuer und verbrauchen jede Menge Strom... Also so wie alle anderen machen: bis 50MHz "direkt" (mit ADC 125MHz), darüber "Sub-Sampling"? Zündende Idee: Warum nicht zwei billige Wandler mit 80MHz Samplefrequenz nehmen und diese mit phasenverschobenem Takt betreiben? Die Idee kam mir als ich dachte "die doppelte Samplingfrequenz würden wir bekommen wenn wir einmal auf der ansteigenden Flanke und einmal auf der fallenden Flanke des Taktes wandeln (Voraussetzung: Taktverhältnis exakt 50:50). Dann wäre es so als hätten wir einen Wandler mit der doppelten Taktfrequenz. Und gleich darauf die nächste Idee: Könnte man nicht gleich mit 90° Phasendifferenz an die Wandler "clocken" - dann hätten wir gleich ein IQ-Signal und der FPGA bräuchte dieses nicht mehr herzustellen. Gab es zum ersten Ansatz noch spärliche Infos (keine Bastelprojekte, aber Doktorarbeiten oder theoretische Entwicklerpapiere), so hörten die Infos zu meiner Idee, gleich einen 90° Clock an die beiden ADCs zu legen, komplett auf. Die Idee hatte wohl so noch keiner - oder er hat sie nicht veröffentlicht. Also: frei nach dem Motto "ich lerne gerne und betrete gerne Neuland" habe ich auch dafür eine Platine entworfen. Große Teile habe ich von meiner ersten Platine benutzen können - nur das "Frontend" mit dem AD9363 wurde durch zwei preiswerte ADCs ersetzt mit "Experimentierfeld" für die Clock-Erzeugung. Ein "fliegender Aufbau" ist bei solchen Bauteilen nicht mehr möglich. Die ADCs arbeiten mit 80MHz - dieses Konzept wird also ohne Subsampling von DC bis 4m gehen. Eine "Phasenkorrektur" wird nur an einer Stelle rechnerisch nötig sein und die ist statisch: eventuelle Phasenfehler der ADC-Clocks. Also EINE Einstellung für den gesamten Bereich. DACs sind deutlich preiswerter: hier arbeite ich mit einem DAC der direkt bis 80MHz arbeitet.
Vor mir liegen jetzt also seit 5 Tagen zwei 4-fach-Multilayerplatinen (eine für den Bereich DC...80MHz) und eine von 75MHz...6GHz). Einige Bauteile habe ich auch schon "gesourced". Noch nicht alle - aber das wird nur noch Tage dauern, dann kann ich die beiden PCBs bestücken. Die Materialkosten werden übrigens deutlich niedriger liegen als bei meiner ursprünglich angedachten Variante - auch die Menge der Bauteile ist drastisch kleiner.
Die Hardware ist so ausgelegt, dass ich zu Forschungszwecken mit einem USB-PHY auf die Daten zugreifen kann. Das ist für mich bequemer als es mit dem STM32 zu tun - dann hätte ich eine potentielle Fehlerquelle mehr. Also in der "Forschung" mit Linux, GnuRadioCompanion und Co. direkt drauf zugreifen und wenn da alles geht eine "Datenschnittstelle" I2S und eine "Steuerschnittstelle" (SPI oder I2C) integrieren.
Und damit kommen wir zum zweiten Teil: Die Arbeit des Dezimierens und Filterns wird per Software vorgenommen. Aber nicht von einer MCU (und in der Sprache "C"), sondern von einem FPGA und in "seiner" Sprache ("VHDL"). In einem FPGA verschaltet man simplifiziert "einfach nur ein paar tausend Gatter und Register" so dass sie das tun was man will - mit hoher Geschwindigkeit. Die Sprache VHDL konnte ich aber noch nicht - und hier habe ich keinen Mitstreiter gefunden. Also: selbst ist der Mann. Entwicklungsumgebung aufgesetzt, FPGA-Experimentierboard für 35,-- Euronen bei ebay geordert ("Mojo V3") und losgelegt. Schau an: auch FPGA-Programmierung ist kein Hexenwerk - aber es wird für mich ein "very long way to Tipperary". Denn ich muss jetzt nicht nur den Umgang mit VHDL (drastisch!!!) verbessern - ich muss auch (endlich) die kompletten mathematischen Zusammenhänge eines SDR völlig verstehen. Auch die Theorie hinter der Filterei (FIR, CIC etc.) Meine einzige Hilfe sind die zahlreich im Netz vorhandenen VHDL Codeschnipsel zu einzelnen Aufgaben. So habe ich schon etwa 150MB an Quellcode gesammelt aus anderen GPL-Projekten zu den Aufgaben "USB-Anbindung", "I2C und SPI Anbindung", "I2S-Anbindung".
Ein "Positron" das diesen Weg mit mir zusammen geht habe ich bislang nicht gefunden - aber das ist der Weg den ich gehen möchte und gehen werde.
Das Konzept "Direktmischer" mit zwei PCBs - die dann auch ausgekoppelt verwendet werden können (per USB mit anderer Firmware) ist deutlich attraktiver als ein Tayloemischer mit jede Menge Korrekturen. Ich erkannte das Tayloe-Konzept meiner ersten Platinen mit Schrecken in einem "Stern" im Wartezimmer beim Arzt: Dort war ein Körper gezeichnet an dem es keine Stelle ohne Pflaster gab, alle Beine und Arme waren irgendwie bandagiert und hochgebunden (das war unser Sozialsystem). Ich erkannte aber auf Anhieb das Tayloe-Konzept mit dem Versuch alle Nicklichkeiten zu eliminieren darin wieder ::)...
Es bleibt also dabei:
Der OVI40 wird von DC starten und mit der "SW-PCB" bis 4m einschließlich gehen - ohne Tricks wie "Sub-Sampling". Mit der zweiten Platine erweitert man den Bereich dann von 75MHz...6GHz (und kann dann "aus der Hand und standalone" über Amsat Oscar 100 arbeiten). Beide Platinen werden Full-Duplex können, und beide Platinen werden sich aus dem OVI40-Projekt auskoppeln lassen, da sie über eine optionale USB-Schnittstelle verfügen.
Die Technik anstatt eines ADCs zwei zu nehmen ist im HAM-Bereich absolutes Neuland (oder verbessert mich z.B. mit Links zu bestehenden Konzepten - ich brauche noch sehr viel Input!!!), und die ADCs schon mit 90° phasenversetztem Takt zu betreiben ist ein interessanter Gedankenansatz (Frank, wie weit kannst Du mir mit deinem mir noch weit überlegenen Wissen über die SDR-Theorie hier weiterhelfen? Geht das?)
Wenn die Platinen bestückt sind werde ich im OVI40-Bereich entsprechendes (auch Fotos) posten. Da es sich um 4-fach-Layer handelt bei dem alle vier Lagen Signalleitungen führen ist ein "einfaches Klonen" nun nicht mehr möglich ;D. Wenn die Sachen final sind wird die Schaltung und die gesamte Firmware dazu Open Source gestellt. Sollte jemand mit VHDL-Kenntnissen und einer vorhandenen Entwicklungsumgebung mithelfen wollen: meldet euch bitte bei mir. In genau dem Bereich könnte ich Hilfe gebrauchen, dann kommt man schneller zum Ziel. Mein Ziel besteht aber nicht nur darin "einfach irgendwas zusammenzudengeln" - sondern selbst besser zu werden. Mein technisches Verständnis soll weiter wachsen - denn je größer dieses Wissen ist desto mehr wirklich Neues kann man auch entwickeln... Das macht für mich den Reiz am Hobby aus!
vy 73
Andreas |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DD4WH on 14. May 2019, 11:53:50
Hi Andreas,
hochinteressant! Vielen Dank für Deinen Beitrag und die vielen Infos!
Du hast Dir ja extrem viel vorgenommen :-):
1.) einen HF-Direktsampler neu designen [und dazu noch ein neues Prinzip mit anderer ADC-Konfiguration] mit FPGA [mit neuer Programmiersprache ;-)]
2.) ein zweites frontend zur Anbindung an den Pluto für den Bereich ab VHF, also auch ein neues Prinzip
Wie Du schreibst, musst Du dazu ganz viele neue Dinge lernen. Das ist sehr schön und war für mich auch bei allen Basteleien die erste Motivation!
Ich versuche mal, meine ersten Gedanken zu den beiden Ansätzen zusammen zu fassen:
1.) Direktsampler:
* Ich würde an Deiner Stelle zuallererst mit der bestehenden mcHF/OVI40RF-hardware versuchen, Direktsampling im Bereich DC bis 192kHz/96kHz zu machen. Dann bekommst Du schon mal ein Gefühl dafür, was Du für Direktsampling alles brauchst
* Direktsampling mit 90 Grad versetzten ADCs: ich kann mir das noch nicht richtig vorstellen. Du hast dann im besten Fall I & Q - streams mit jeweils 80MHz Bandbreite (und brauchst dafür extrem gute analoge 80MHz anti-alias-Filter, die z.B. den UKW-Bereich mit >80dB unterdrücken, ich weiß wovon ich spreche, denn ich habe hier 5x100kW-UKW-Sender in 3km Entfernung ;-)). Das heißt, der FPGA hat die doppelte Arbeit zu tun (I UND Q). Und Du kannst im FPGA keine ausgefeilte IQ Phasen-/Amplitudenkorrektur machen (wie wir es jetzt schon im UHSDR machen), denn dafür ist der nicht schnell genug (auf jeden Fall nicht ein kleiner FPGA). Ich habe keine große Ahnung von Direktsamplern, aber ich dachte, die Hauptaufgabe des FPGA ist es, ganz schnell aus der riesigen Bandbreite ein Stück herauszuschneiden und extrem zu dezimieren. Also z.B. aus 80MHz dann durch decimation-by-256 baseband 312.5 kHz zu machen (oder noch weiter runter). Das geht am sparsamsten in fixed point mit CIC-Filtern und nachgeschalteten FIR-Filtern. Das müsstest Du dann bei Deinem Konzept 2x machen, für I & Q. Dann geht der stream in die MCU und wird dort gefiltert/demoduliert etc. Da ist es doch eigentlich sparsamer, den FPGA nur für die decimation zu verwenden, und in der MCU im baseband mit geringer Bandbreite I & Q zu erzeugen, oder? Aber letztendlich ist es nur eine Abwägung, wo Du das Geld und den Strom hineinsteckst ;-), entweder in die ADCs oder in den (größeren schnelleren teureren) FPGA.
* "Die Technik anstatt eines ADCs zwei zu nehmen ist im HAM-Bereich absolutes Neuland": bei der Aussage bin ich mir nicht sicher: auch das Tayloe-frontend hat doch zwei ADCs und sampelt daher mit 96kHz eine Bandbreite von 96kHz, oder ? ;-)
* Slawek und andere haben mit dem mini-HIQSDR aus meiner Sicht genau das gebaut, woran Du gerade sitzt: ein HF-Direktsampler-frontend mit allem Schnick und Schnack. Das ist genau genommen also schon fertig entwickelt inclusive Verilog/VHDL. Auch der Red Pitaya hat da schon eine sehr weit entwickelte FPGA-Software, soweit ich das beurteilen kann, da könntest Du den Hauptentwickler Pavel mal kontaktieren, der scheint mir sehr nett und hilfsbereit zu sein, das ist ja auch alles open source
* "Ich bin für mich zu der Entscheidung gekommen, dass das Tayloe-Konzept die gesetzten Ansprüche nicht erfüllen kann": vermutlich liegt das auch daran, dass für mich die Ansprüche nie genau definiert waren ;-). Für mich war das Ziel immer, das Tayloe-Konzept zu optimieren, ohne den Konzept-Bereich eines stromsparsamen Rx-Teils und eines portablen TRX zu verlassen (aber es war mir schon klar, dass Du noch etwas Anderes/Besseres wolltest). Wenn das Ziel jedoch die Entwicklung eines high-end-Trx für HF ist, dann wäre sicherlich der Tayloe, aber auch der Direktsampler nicht gut genug, sondern dann sollte man über double conversion, roofing filter, H-mode-Mixer und nachgeschalteten SDR-Teil nachdenken :-). Dein Ziel scheint jetzt so etwas wie eine eierlegende Wollmilchsau zu sein: HF besser als der Tayloe, aber nicht highend, und dann ab VHF bis in den GHZ-Bereich Mittelklasse. Mittelklasse deshalb, weil der chip AD9363 für die Kostenoptimierung entwickelt wurde und nicht für Spitzenklasse-Transceiver. Wobei wir hier auf sehr hohem Niveau meckern :-). Das ist alles viel besser als 10x so teure Technik noch vor 25 Jahren.
Also: neues Ziel - neues Glück!
Das ist ja das Schöne im Amateurfunk (oder in jedem Hobby): man ist nur durch die eigenen Ansprüche und Fähigkeiten (und ein paar finanzielle und zeitliche Restriktionen ;-)) limitiert !
Ich bin sehr gespannt auf Deine ersten Testergebnisse mit den neuen Platinen!
Herzliche Grüße,
Frank |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DF8OE on 14. May 2019, 12:45:07
Hallo Frank,
danke für deine Gedanken. Mir ist schon klar dass es "fertige Konzepte" für Selbstbau-Direktwandler gibt. Stichwort "N2ADR". Könnte man nachbauen - will ich aber nicht. Man könnte auch einen Red Pitaya nehmen. Ist aber kein Selbstbau und eben ein "Fertigmodul". Habe ich ja auch - und verwende ihn als Messgerät oder auch für WSPR.
Eine "eierlegende Wollmilchsau" soll es nicht werden - aber ein universell einsetzbares und verwendbares Konzept soll es sein. Also keine Konkurrenz zum Hilberling oder anderen kommerziellen Geräten. Es sollte ein Gerät werden was einen möglichst großen Frequenzbereich abdeckt, möglichst preiswert im Material ist, modular aufgebaut (die Module ggf. auch für andere Aufgaben einsetzbar) und keinen großen Abgleichaufwand erfordern. Es war für mich niemals ein Ziel einen QRP-portabel-SDR zu bauen (sonst hätte ich ja auch nicht die 75W angepeilt). Er soll von den Abmessungen und vom Gewicht her schon "portabel" sein - aber er darf schon 500...800mA im RX aufnehmen. Klar: je weniger desto besser. Aber das Zeil einen stromsparenden TRX zu bauen hatte ich nie (sonst hätten wir besser beim 2.8" LCD bleiben sollen). "Standalone" sollte er schon sein - also "mit OVI40-UI".
Im FPGA sitzen unter anderem die Decimation und einige Filter.
Und der AD9363 kostet wenn man ihn bei Digikey kauft (was ich NICHT mache) um die 100,-- Euro: also kein "Low Cost Modell". Man kann ihn aber für unter 20,-- Euro (als Originalteil!!) in China sourcen. Das liegt daran dass viele hochwertige Drohnen den als TRX Chip nutzen und von den chinesischen Herstellern weit größere Mengen geordert wurden (und werden) als sie eigentlich brauchen. Der übrigbleibende Teil wird in CN verkauft. Das ist auch keine temporäre Sache: die werden für ca. 20,-- Euro immer zur Verfügung stehen (denke ich). Der AD9363 gibt einen digitalen I und einen digitalen Q Stream aus. Der wird vom FPGA "nur" dezimiert und gefiltert - "hinten" soll dann ein vom STM verarbeitbarer Datenstream rauskommen. Idealerweise 16Bit I und 16Bit Q alternierend. Um die Module so kompatibel wie möglich zu machen soll aus beiden Modulen der GLEICHE Datenstream kommen. Die Steuerung der Frequenz unterscheidet sich natürlich - aber die Datenstreams sollen es nicht tun. Und die einzige Gemeinsamkeit mit dem Pluto ist eben dieser AD9363 - es wird KEIN Pluto verbaut oder der Zync dazu. Dementsprechend wird auch der Pluto nicht angebunden - der Datenstream aus dem AD9363 wird vom FPGA so umgebaut dass er identisch zu dem aus dem anderen (SW-Direktwandler) Modul ist.
Klar kann ich mir den Quellcode zum "STM32-Radio" (Direktsampler bis ca. 1MHz) ansehen. Das kann mir das Prinzip erklären. Ich möchte das aber auf Basis "C" nicht bis in die unterste Ebene tun - da wesentliche Teile eben im FPGA passieren sollen und werden.
Klar arbeitet das Tayloe-Verfahren mit zwei ADCs. Der große Unterschied liegt aber darin, dass beide phasengleich arbeiten. I und Q werden schon davor im Tayloe erzeugt. Bei meinem Direktwandler geht das Eingangssignal aber direkt in die ADCs (phasengleich). Das habe ich so noch nirgendwo gesehen...
vy 73
Andreas |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: SP9BSL on 14. May 2019, 18:57:03
Hello all,
as everyone with positron badge here knows what I'm currently working on, I would like to bring some of this under direct sunlight because my name was called.
As Frank said, this is DDC/DUC concept checked first on HiQSDR mini board, connected to OVI40 UI. There were some tests on 2m and on HF bands with success.
Current state is: 4 layers board works but is under development and new elements are soldered and tested. It is built with Altera/Intel EP4CE15, ADS6145, AD9744 and some other amplifier/programmable attenuators and PGA103+ LNA for 2m/4m usage. There are two sets of filters: 52MHz LPF, 4m BPF and 2m BPF for RX and TX with two pair of switched inputs/outputs. Board is intented to work up to 52MHz with additional board with band pass filters if needed and in 4m/2m VHF range using aliases in apropriate Nyquist zones. Also there is plan to have two receivers working on the same filter range. For first receiver UHSDR code is mostly ready.
Because my time is strongly limited, so far only few elements have been tested: internal power supplies (works in range 8V..18V), FPGA, ADC and low phase noise clock source. FPGA code is written in Verilog HDL using main project as block schematic entry file. As mentioned using few modules from N2ADR, and all the rest (mainly SAI, SPI I/O) written by me. See below for current picture of partialy working board and small preview of the code inside FPGA.
|
Title: Re:OVI40 RF - wie ist der Stand?
Post by: SP9BSL on 14. May 2019, 18:57:34
Title: Re:OVI40 RF - wie ist der Stand?
Post by: SP9BSL on 14. May 2019, 19:04:00
| Forgot to mention: board is intented to be fitted verticaly into a kind of base board between UI and the rest (as planned earlier). It uses DIN 41612 Harting connector. Of course I will provide case for all modules when all will be ready to be shown. |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DL6KL on 15. May 2019, 06:57:00
Da muss ich mich doch mal melden.
Ich gebe Thomas vollkommen recht.
Die meisten OM,s haben doch die UI Platine gekauft um auf diesem Weg , wenn die neue RF Platine kommt, einen verbesserten mcHF zu bekommen.
Dieses Projekt wo Slawek eine Einsicht gegeben hat werden sehr viele OMs überfordert werden
Ob das von Anfang an der Sinn der Sache war?
Ich selber war auch schon auf andere Projekteumgestiegen
(Eagle,SParrow und Tulipan)
Gruß aus dem hohen Norden |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: dl2eea on 15. May 2019, 07:07:23
Hallo an alle Gläubigen.
Thomas, glaubst du immer noch wirklich, dass ein neuer Teil der RF entsteht? Das ist nur Bla..Bla..Bla und sonst nichts! Es scheint, dass die Polen etwas tun werden, um diejenigen zu retten, die in den UI-Teil investiert haben.
Gruß
Josef |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: SP9BSL on 15. May 2019, 07:34:28
Hi,
I agree - my approach is not for everyone, it's only additional module to replace the planned analogue RX/TX module concept, using the other modules as was planned earlier. My idea was to solve/replace all the balancing issues we have, adding some new functionality with second receiver. As mentioned - an option. |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DF8OE on 15. May 2019, 09:31:11
Wie ich schon in meinem langen Startpost schrieb:
Ich hatte ursprünglich geglaubt man könne einen "verbesserten mcHF" machen, der die vielen Nicklichkeiten ausmerzt. Anfangs ging es auch ganz gut voran - aber je weiter es voranging desto mehr offenbarte sich dass man mit nicht unerheblichem Aufwand nur vergleichsweise wenig Wirkung hatte. Die Dinge beeinflussten sich gegenseitig und/oder benötigten einen Abgleich. Meistens bandabhängig, und oft war die zu erzielende Wirkung gemessen am Aufwand unbefriedigend. Meine Testaufbauten der neuen RF wurden immer umfangreicher und doch zwickte und zwackte es an vielen Enden. Und wenn die OMs die Abgleichprozedur nicht akribisch befolgen würden wäre das Produkt kaum besser als ein mcHF. Wie schon geschrieben: bei den meisten mcHFs, die ich zur Reparatur bekomme, steht der TX-IQ-Abgleich auf "OFF".
Es gibt so viele Projekte, die den Ansatz eines verbesserten mcHF gehen. Zum Beispiel der Sparrow. Er ist ein solches Produkt, und es steht dem nichts im Weg ihn nachzubauen.
Ich möchte auf jeden Fall keine "leichte Abwandlung" des mcHF oder des Sparrow bauen: das gibt es alles schon.
Ich möchte auch keinen N2ADR DUC/DDC bauen: gibt es auch schon. Und einen Red Pitaya mit Raspberry PI: gibt es auch schon.
Ich möchte ein modulares Konzept entwickeln, das ein Standalone-Gerät mit deutlich besseren Features als der mcHF, Sparrow und Co. bietet, aber in der gleichen Preisklasse liegt. Es sollte auch die Möglichkeit geben, Module "auszukoppeln" und anderweitig zu verwenden.
Die jetzige UI-Platine wird auf jeden Fall mit meinen Platinen zu verwenden sein. Einige Bauteile müssen dann nicht mehr bestückt werden, weil deren Aufgabe bereits auf der RF-Platine erledigt wird. Es kann auch sein, dass diese Bauteile in einer folgenden Version der UI gar nicht mehr bestückbar sind. Aber auch hier bin ich eher zurückhaltend. Durch diese Bauteile erhält die UI ihre Kompatibilität zu mcHF-RF-Platinen. Warum sollte man diese Bauteile komplett aus dem Layout nehmen?
Im Laufe der Entwicklung der RF-Platinen mit Tayloe-Mischer habe ich den Punkt überschritten, an dem der Aufwand, wenn man ihn in ein anderes Konzept steckt, deutlich mehr Features und in vielen Punkten zusätzlich deutlich deutlich bessere Signalqualität bei gleichem Preis bietet. Zusätzlich ist keine Abgleichorgie nötig, und viele Punkte des aktuellen Abgleichs sind sogar überflüssig.
Die Bauteile für die SW Platine werden nicht schwieriger einzulöten sein als die der OVI40-UI und der mcHF-RF.
Ich möchte nicht "kommerziell" denken in der Art: "was kann ich jetzt in großen Mengen anbieten oder verkaufen" (ohne Rücksicht auf den tatsächlichen Mehrwert).
Ich möchte denken in der Art: "was kann man aus dem großen vorhandenen Fundus an Wissen und neuen Möglichkeiten für ein Konzept schaffen, dass es in dieser Form noch nicht gibt" (und sowohl das Konzept als auch die Möglichkeiten der Verwendung bieten einen wirklichen Mehrwert).
Man kann übrigens sowieso machen was man will: alle zufriedenzustellen ist ein Ding der Unmöglichkeit. Es wird immer und an jedem Projekt etwas geben was stört. Jeden etwas anderes.Und jeder weiß sofort an welcher Ecke er schrauben würde um das noch besser zu machen...
Thema "Zeitschiene":
Die PCBs sind, denke ich, nahezu final. Auf jeden Fall ist die Menge der eventuell nötigen Änderungen überschaubar. Die Bärenarbeit steckt in der Firmware. Da das mein Hobby ist gibt es einige Dinge im Leben die eine höhere Priorität haben. Wer bei der Erstellung der Firmware mithilft, würde auf jeden Fall die Zeitschiene verkürzen - das steht fest.
Ich habe auch auf den PCBs Bauteile vorgesehen, die aktuell noch nicht benötigt werden. Z.B. einen SRAM 8Mx8. Das ist der "kleine BGA". Wie beim mcHF als ich anfangs Kleinigkeiten bei Chris nachgefragt habe möchte ich auch hier "nach oben Luft lassen". Wer weiß wofür man den mal brauchen könnte?! Stören tun die Leiterbahnen und der Footprint nicht. Und die Platine ist ca. 50x50mm groß. Platz braucht man da nicht zu sparen.
EDIT:
@Thomas:
Die Vorstellung, was denn der "Entwicklerkreis" ist und macht, möchte ich nochmal ganz transparent machen.
Es gibt (mich eingeschlossen) 7 "Positronen". Die Arbeit von Ralf DG8YGW war die UI-Platine, und die ist abgeschlossen. Frank DD4WH, Danilo DB4PLE und Michael DL2FW sind nur Beobachter in Sachen Hardware - die kümmerten sich um UHSDR. Slawek SP9BSL hat die LCD-Platine für das 3.5" mit mir zusammen gemacht - und in der Zwischenzeit ein DDC/DUC Board auf Basis des Cyclone IV entwickelt. Gerd DF9TS hat sich um das WIKI gekümmert - weder um die Hardware noch um die Firmware (ich habe von ihm seit ca. 1 Jahr nichts mehr gehört). Das WIKI ist ja soweit auch fertig! Und ich habe mich um die RF gekümmert. Ab und zu habe ich im Entwicklerbereich Fragen gestellt (meistens "ob xyz in der FW bzw. dem Codec möglich ist). Mit Danilo habe ich den HMC1023 zum Laufen gebracht (Danilo die Firmware, ich die Hardware). Da wir alle hunderte Kilometer auseinander wohnen haben wir keinen Treffpunkt. Erst wenn es mir gelungen ist die erste FPGA-Firmware zum Laufen zu bringen werden Platinen an Danilo weitergegeben, damit wir dann an die Integration in UHSDR arbeiten können.
Im Entwicklerforum finden nicht - wie der Name suggeriert - Entwicklerdiskussionen statt. Das würde voraussetzen, dass alle gleichzeiitig am Hardwareprojekt arbeiten (was nicht der Fall ist. Vielmehr dient dieser Bereich aktuell dazu dass jeder, der etwas entwickelt hat, es dort präsentieren kann (und dadurch ggf. Synergieeffekte entstehen).
vy 73
Andreas |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DL1HT on 15. May 2019, 11:18:02
Hallo zusammen,
ich bin durch das Internet über den mchf auf den OVI40 gestoßen.
Ganz frisch seit gestern hier registriert.
Ich bin hier in dem Thread vielleicht auch komplett falsch, möchte Euch aber versuchen zu erklären wie es auf mich wirkt der nur erstmal Infos sucht.
Es gibt viele Beiträge aus dem letzten Jahr, in diesem Jahr habe ich noch nicht so viel gefunden.
Ich versuche seit Stunden herauszufinden was denn nun ein aktueller STand ist.
Erschlagt mich wenn ich tatsächlich etwas übersehen habe, aber für jemanden wie mich der aktuell Infos sucht ist es schwer irgendeine verlässliche Aussage zu finden.
Was man liest sind tolle Ideen, es gibt Muster, es gibt viele verschiedene Versionen.
Einige OMs die sich wahrhaftig richtig ins Zeug legen.
Andere OMs die vieles schlecht reden, man liest sogar von ziemlich heftige Diskussionen die der Sache eigentlich gar nicht dienlich sind.
Gibt es den jetzt Stand der Dinge irgendetwas was ich mir bestellen kann?
Aus dem ich einen funktinierenden TRX bauen kann, den ich evtl. später erweitern kann?
Ich lese hier eine Option von bis zu 6GHz in anderen Threads geht es um den Bereich bis über 200 MHz.
Ich bin sehr verwirrt und würde mir für alle die sich informieren wollen eine
leich Verständliche Übersicht zu finden.
Was man jetzt schon bauen kann oder welche Ideen die hier noch geplant sind wann ungefähr als Zeitraum geplant sind.
Ich möchte hier keine Kritik üben sondern Euch einfach nur mal mitteilen wie schwer ich es habe hier eine gute einfache Übersicht zu finden.
Sollte ich hier genau das nicht gefunden haben entschuldigt das bitte und löscht meinen Beitrag.
Ich finde Euer Projekt so Mega Klasse das ich sehr gerne ein Teil davon sein möchte.
73 & 55 de Thomas DL1HT
|
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DF8OE on 15. May 2019, 11:24:55
Hallo Thomas,
das Projekt ist noch nicht fertig und befindet sich in der Entwicklung. Es gibt zwar schon UI-Platinen zum Selberlöten - aber noch keine RF Baugruppen. Wenn Du also ein fertiges Projekt suchst bist Du hier aktuell noch nicht richtig. Wenn Du mit entwickeln / programmieren möchtest: je mehr aktiv am Projekt arbeiten desto schneller wird es ein "fertiges Projekt"!
Die UI-Platine kann aktuell mit der RF-Platine des mcHF verwendet werden.
Da das Projekt noch nicht fertig ist, gibt es keine "Vermarktungsbeschreibung" - nur ein Lastenheft, was es mal werden soll. Und selbst das Lastenheft ist in ständiger Bewegung (die sich aber mit schwächer werdender Amplitude allmählich "einschwingt")...
vy 73
Andreas |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DL1HT on 15. May 2019, 11:37:37
Ich bedanke mich für diese Info.
Dann bin auf jeden Fall durcheinander geraten da man mit der UI und der RF Platine des mcHF ein Gerät verwirklichen kann.
Vielleicht hilft das ja auch dem einen oder anderen der sich interessiert.
Ich werde hier ganz spannend mitlesen.
Ich bin zwar Fachinformatiker aber hierfür reicht es dann leider nicht aus.
Ich bin sehr sehr gespannt was Ihr erschafft,
bitte lasst Euch nicht von Eurem Pfad abbringen.
73 de Thomas (DL1HT) |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DL4HAO_Dietmar on 15. May 2019, 12:38:31
Danke für das Update zum Stand des OVI40 :)
Ich vermisse aber noch die Angabe, wann denn die Leute, die damals eine bestückte UI-Platine bestellt und bezahlt hatten, ihre Platine bekommen?
vy73,
Dietmar, DL4HAO
|
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DF8OE on 15. May 2019, 14:15:41
Auch da bin ich dran. In jeder freien Sekunde löte ich welche zusammen. Wenn ich jetzt nicht völlig in der RF-Platinen-Erstellung "verschwinde" sind rechnerisch die letzten Ende Juli ausgeliefert.
"Bestückte" wird es dann erst wieder geben, wenn das Projekt fertig ist. Dann natürlich auch zeitnah.
vy 73
Andreas |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DD4WH on 15. May 2019, 17:06:29
Hi Andreas,
habe gerade etwas Interessantes gefunden zum Thema "mehrere ADCs, um Bandbreite zu erhöhen", welches Du ja mit Deinem design aufgegriffen hast, das nennt man in der Literatur bei zwei verwendeten ADCs "ping pong interleaving", sehr schöner Begriff :-)
[allgemein auch "Time-Interleaved Data Converters" oder "Interleaving ADCs"]:
https://www.analog.com/en/analog-dialogue/articles/interleaving-adcs.html
http://www.ti.com/lit/an/snaa286/snaa286.pdf
https://www.maximintegrated.com/en/app-notes/index.mvp/id/989
Es scheint also wirklich möglich zu sein, aber insgesamt relativ bis sehr schwierig, die Phasen und Amplituden wirklich gut abzugleichen. In den Quellen sind auch Angaben zu den erreichten Kennwerten zu finden sowie Hinweise auf analoge und digitale Möglichkeiten, die Phasen und Amplituden anzugleichen.
Beste 73
Frank DD4WH |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DF8OE on 15. May 2019, 17:19:34
Hallo Frank,
danke für die Links. Die von mir verwendeten ADCs besitzen die Möglichkeit einer Hardwarekorrektur - an Amplituden- und Phasenfehler hatte ich bereits gedacht... Wie gut das geht - werden wir sehen. Ich werde übrigens mit 180° clocken (der Clock wird aus einem Flip-Flop gewonnen und hat somit exakt 50% Tastverhältnis).
Habe heute zum ersten Mal mit der ISE richtig rumgespielt. Ist schon cool: "wir bauen einen Sinusoszillator in einem FPGA" ::) Morgen wird das restliche nicht vorhandene Hühnerfutter geordert, und dann geht es weiter.
vy 73
Andreas |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DF8OE on 16. May 2019, 04:50:30
In einem gebe ich Dir Recht:
Das Entwicklerforum hat nicht das gebracht was ihm an Aufgabe zugedacht war. Die Idee, Fragen nach Mithilfe in bestimmten Bereichen (denn ich brauche noch nicht alle: z.B. den "Messen"-Bereich brauche ich aktuell nicht und da gibt es auch schon viele stehende Angebote von OMs) öffentlich zu stellen ist bestimmt besser. Wobei mir aber auch von Anfang an klar war, dass eine "verteilte Entwicklung" im Bereich Software/Firmware naturgemäß wesentlich effektiver funktioniert als im Hardwarebereich. Das Subjekt der Arbeit (der Quellcode) ist in Sekundenbruchteilen bei allen verfügbar und jeder kann technisch Ideen sofort einbauen und die Wirkung ausprobieren. Im Hardwarebereich müssen meistens erst Dinge beschafft, dann eingebaut und dann vermessen werden. Und da wir von HF reden, kann es sogar sein, dass ein und die gleiche Änderung (verschieden ausgeführt) unterschiedliche Ergebnisse hat. Das ist bei Software anders ::)
Seit etwa 8 Monaten habe ich an der Idee mit den zwei Direktwandlern gearbeitet - von "Stillstand" kann aus technischer Sicht hier keine Rede sein.
Das mit dem "viermal abmelden und wieder anmelden" wäre für mich (egal in welchem Bereich egal wobei/wofür) keine Option. Entweder ich will etwas oder ich will es nicht. Wenn ich es nicht will bin ich weg und komme nicht wieder, wenn ich es will (aber aus irgendwelchen Gründen aktuell nicht kann) dann bleibe ich am Ball. Und wenn ich unentschlossen bin dann "lasse ich ruhen". Dieser Absatz hat aber mit der "Technik" nichts zu tun.
Dass das erste Konzept was ich erarbeitet hatte nicht mehr zur Vollendung geführt hat finde ich selbst auch nicht gerade schön. Aber so ist es in der Entwicklung eben: nicht jeder Weg, den man beschreitet, wird zu Ende beschritten. Manchmal korrigiert man nur leicht (um irgendwelche Widrigkeiten drum herum) und ab und zu erkennt man, dass die vielen Schlangenlinien hinter einem nicht etwa nach vorne einen geraden Weg folgen lassen sondern immer neune Schlangenlinien (Korrekturen an Nicklichkeiten). Irgendwann ist dann bei vielen "das Maß der Toleranz" voll und der Weg wird abgebrochen. Die Schaltung mit dem Tayloe hatte so viele Korrekturen in Firmware nötig, dass UHSDR gewaltig hätte erweitert werden müssen um viele Einstellpunkte, die auch abgespeichert hätten werden müssen. Sicher: hier hätte ich einen Teil der Arbeit von mir auf andere abschieben können. Es bleibt aber trotzdem ein Flickenteppich, und dann auch noch einer der seine optimale Wirkung erst dann entfaltet wenn alle die Abgleichprozeduren auch tatsächlich ausführen. Trotzdem weine ich der Zeit keine Träne nach, denn sie hat mich weitergebracht. Sie hat mich weitergebracht als viele andere die nach wie vor versuchen, mit dem Tayloe etwas drastisch besseres zu erreichen als es der mcHF tut. Hier eine kleine Aufzählung der Punkte aus dem Gedächtnis (dabei gehte es NUR um den eigentlichen Mischerteil):
- RX: wie beseitigt man das dynamische Amplitude und Phase Verhalten?
- RX: wie beseitigt man die mangelhafte Unterdrückung des LO am Antenneneingang?
- RX: wie minimiere ich die Entstehung von Mischprodukten ("Nebenempfangsstellen") durch Nichtlinearitäten im verwendeten Schaltermischer?
- wie kann ich eine Vergrößerung der empfang- und nutzbaren Bandbreite erzielen?
- TX: wie beseitigt man die mangelhafte Unterdrückung des LO am Mischerausgang?
- TX: wie verhindert man die Entstehung von Intermodulationen, die das TX-Signal im Nutzbereich (+/- sechsfacher Abstand der Nutzbandbreite) und im Fernbereich (Signale teilweise einige hundert Khz neben der Nutzfrequenz) beeinträchtigen?
Die Liste ist sicher nicht vollständig. Ich hatte jeden dieser Punkte bereits bearbeitet und für jeden mindestens eine wirklich praktikable Lösung in meinen ersten Schaltungen drin (nicht praktikabel sind z.B. Trimmpotis für Dinge, die sich dynamisch ändern - über sowas denke ich gar nicht erst nach - spätestens wenn ich erkenne dass sich die Dinge dynamisch ändern fliegt so eine Idee wieder raus - lange bevor die Sache auch nur den "Prototyp-Status" erreicht hat). Allerdings beeinflussten sich die Dinge, je besser man es machen wollte, immer mehr gegenseitig, was dynamische Anpassungen der Korrekturwerte zur Laufzeit durch UHSDR erfordert hätte. Also "Korrekturen der vom User ermittelten Korrekturen". Zwar automatisch durch die FW - aber es bleiben Korrekturen. Ich erinnere an das Bild des mit Pflastern übersähten Patienten. Als ich an einigen Stellen bereits als eine Option ansah, bestimmte gesetzte Ziele aufzuweichen - da habe ich dieses Konzept schweren Herzens verlasen und begonnen mich messtechnisch und praktisch mit Direktwandlern zu befassen und habe mit Freude festgestellt, dass die oben genannten Punkte dort allesamt nicht auftreten. Die Probleme die bei Direktwandlern auftreten können sind entweder individuell und einfach lösbar oder "zu akzeptieren".
Und jetzt werde ich mich wieder an das Projekt machen. Alles, was ich aus technischer Sicht sagen wollte ist gesagt, jetzt wartet die (Entwickler)-Arbeit ;) Heute oder morgen werden die restlichen Teile gesourct, dann werden die Platinen bestückt und ich muss dieser Hardware durch die geeignete (FPGA)-Firmware Leben einhauchen. Wenn es Neuigkeiten gibt die allgemein interessant sind werde ich sie hier schreiben (nicht mehr im Entwicklerforum) und wenn es irgendwo hakt auch. Wenn es denn hakt wird das Problem klar benannt und es wird transparent sein warum es hakt. Eine grobe Roadmap wie ich vorgehe habe ich natürlich - auch Ideen wie man bestimmte Dinge "tricky" machen könnte (in der Theorie) die sonst wieder Abgleichorgien nach sich ziehen würden. Aber die wahren Probleme erkennt man erst wenn man direkt vor ihnen steht.
vy 73
Andreas
|
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DF8OE on 16. May 2019, 09:59:21
Hallo Thomas,
##UI-Leiterplatten##
Ich hatte ausgesourced - zu einem chinesisichen Anbieter der auch Kleinstserien < 50 Stück zu akzeptablem Preis bestückt. Diesen Preis hatte ich dann nahezu 1:1 an alle Interessenten weitergereicht. Der chinesische Anbieter ist aber leider 5 Tage bevor der Auftrag angefangen werden sollte abgesprungen. Der Versuch, einen anderen zu finden, der bei diesen Stückzahlen den Preis halten konnte, ist fehlgeschlagen. Also muss ich diesen Stapel abarbeiten. Weitere "bestückte" habe ich nicht angenommen bzw. das Material vorab berechnet.
##abmelden und anmelden##
Eine mit Bedacht zu verwendende "Waffe", die nicht Nebenwirkungsfrei ist. Weder für andere noch für einen selbst...
##Facebook##
Nach wie vor stehe ich zu meiner damals gemachten Aussage, dass alles, was es von mir an Wissen und Erkenntnissen irgendwo frei zu finden gibt auch von jedem ungefragt und überall weiterverbreitet werden kann und soll. Ich mache sehr wohl eine Einschränkung, wo ich selbst schreibe oder nicht, (weil das meine eigene Sache ist), nicht aber bei den zu verbreitenden Dingen selbst. Insofern gibt es für mich an der Facebook/Instagram/WhatsApp etc. Front keine Neuigkeiten oder Veränderungen. Ich habe hier aber gelernt, dass nicht jeder so denkt und jeder hier andere Prioritäten setzt - und das in den Nutzungsbedingungen des Forums berücksichtigt.
##Positron-Mail##
Hier kann ich nur staunend danebenstehen. Das Ganze kann ich unter Einsatz aller meiner Phantasie und aus jedem mir möglichen Standpunkt nicht nachvollziehen. Ich suche auf jeden Fall bei Fragen zu einem Thema immer zuerst mit dem dafür "zuständigen" zu kommunizieren - und habe dabei je nach Sachlage auch sehr viel Geduld. Ich habe aber keine Nachricht oder Frage von irgendeinem Positron bekommen. Komisch.
vy 73
Andreas |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: IZ6MAF on 17. May 2019, 10:16:19
To overcome all the difficulties you talked about, maybe you could change approach and switch from an analog signal demodulator to a digital demodulator, as described in the attached abstract; thus you are not forced to switch to a direct sampling transceiver with consequent complications and increased costs.
'73 de
IZ6MAF Paolo |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DF8OE on 17. May 2019, 10:56:34
Hi Paolo,
I do see much more increasing costs using the concept mentioned in your attached paper. We do need bandpass filtering at RF stages which are very steep. If this would only be neccessary for one specific frequency there would be no problem. But we do need that filtering for every frequency we want to work on.
I know the document you attached - I saw it ~ 1 year ago ::). And I played in theory with it. After weighting all the advantages and disadvantages I concluded to the direct sampling method. Dimensions, costs and technical (signal) quality are in a comfortable compromise. I have played much with direct sampling Red Pitaya and I tested on frequencies > 70 MHz "Adalm Pluto". The two modules (one direct sampling and one carrying AD936x) won the race at my testings...
But that is only MY way. If someone wants to check this way: welcome!
The actual stage is "prototyping" (on PCBs). When this is finished I will publish header pin layouts for RF motherboard so that as much as possible different methods can be used for testing and comparing. We can (and should) discuss at that stage which signals are mandatory, which are possibly needed and how much "spare" connections must be added.
vy 73
Andreas |
Title: Re:OVI40 RF - wie ist der Stand?
Post by: DD4WH on 17. May 2019, 11:07:55
Hi Paolo, hi Andreas,
in fact, we are already doing this in the digital domain :-).
Have a look at the frequency translation method we use in UHSDR: it shifts our baseband signal by sample rate / 4 (or minus sample rate / 4), thats the very same principle ("frequency translation without multiplication") as described in the paper.
And, yes, we could easily go without the QSD and heterodyne the incoming RF in the analog domain and then sample the baseband signal with one ADC. Then in the digital domain we can build I & Q easily.
But we would need a very good antialias filter for our ADC, as far as I can see. [or go with a relaxed filter and oversampling and decimate in software afterwards]
All the best 73s,
Frank DD4WH |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|