Diskussions- und Newsboard des DARC-Ortsverbandes I40
allgemeine Kategorie => OVI40 SDR Projekt (English AND German discussions around OVI40 SDR project) => Message started by: DF8OE on 10. September 2021, 16:20:41

Title: Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: DF8OE on 10. September 2021, 16:20:41

Sep 10, 2021:
This week I got the prototype PCBs (final layout) for OVI40 RF (RX/TX) from manufacturer. It is a six layer PCB and I am very exited if everything is working. Today I started with FPGA (and checked if all balls are connected: they are - and no short circuits). This weekend I will populate more and more parts, every step checking if everything works as expected.

I have already tested all blocks on former intermediate prototype PCBs (shortwave RX/TX block works for nearly a year). AD9363 has worked using Spartan FPGA, also USB interface. It is "new" to marry all blocks together on one PCB :D. I hope they will iove each other and will result in a "perfect working team"...

I will report from time to time about the progress.

vy 73
Andreas

Title: Re:Final RF (RX/TX) PCB Prototype populating has started
Post by: DF9EH on 10. September 2021, 17:15:13

Super,
viel Erfolg bei der weiteren Arbeit.

Title: testing FPGA (1)
Post by: DF8OE on 11. September 2021, 11:29:09

Sep 11, 2021:

Everything mounted to program FPGA (top side)

Title: testing FPGA (2)
Post by: DF8OE on 11. September 2021, 11:29:48

Sep 11, 2021:

Everything mounted to program FPGA (bottom side)

Title: testing FPGA (3)
Post by: DF8OE on 11. September 2021, 11:31:15

Sep 11, 2021:


;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D
;D programming successfully finished ;D
;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D

Title: Re:Final RF (RX/TX) PCB Prototype populating progress (Sep 11. 2021)
Post by: DC4YN on 11. September 2021, 12:15:20

Hallo Andreas....

TOP!!!

Title: Re:Final RF (RX/TX) PCB Prototype populating finished on Sep 17. 2021
Post by: DF8OE on 17. September 2021, 15:08:14

Sep 17, 2021:

Hi to all,

today I finished populating of OVI40-RF2. I have checked everything twice and more during populating, measured voltages and currents on several places / tracks.

Of course such a complex schematics (and because of netlist the resulting PCB, too) has some errors which I did not discover before PCBs are manufactured. But until now these are minor errors which can be corrected on the prototype PCBs - not necessary to manufacture new, corrected ones.

I already have transmitted on the shortwave block (10KHz...76.8MHz) and received using both ADCs. So this block can be declared as "not containing issues". Testing of VHF/UHF/SHF block will take some time because of I first must port the Spartan code to Altera. But all voltages and signals on AD9363 are looking fine, data lines are all checked so that I hopeully will confirm working of this stage in the next time.

vy 73
Andreas

Title: Re:Final RF (RX/TX) PCB Prototype populating progress (Sep 17. 2021)
Post by: DF8OE on 17. September 2021, 15:08:34

Sep 17, 2021:

vy 73 Andreas

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: DF8OE on 18. September 2021, 16:15:39

Today I build a simple adaptor PCB to marry RF2-Board and OVI40-UI_1.8...

vy 73 Andreas

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: DF8OE on 18. September 2021, 16:16:02

...

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: DF8OE on 18. September 2021, 16:16:16

...

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: DF8OE on 18. September 2021, 16:17:04

Now FPGA firmware development can start ;D

vy 73
Andreas

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: Michael_K on 23. September 2021, 17:49:00

Sieht und hört sich ja gut an; unter andrem auch die weitere Nutzung des OVi40-ui-Boards (auch ich habe noch eins "rumliegen")
2, wenn auch nebensächlcihe Fragen:
1. wie sieht es mit der Kühlung der ICs aus? von anderen, ähnlichen Projekten sind mir "nicht unerhebliche Kühlkörper" im Gedächtnis.
2. eigentlich zum ui: wie sieht es da mit 4"-Display aus?

vy 73 aus Erfurt
Michael_K

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: DF8OE on 24. September 2021, 04:45:47

Weder auf der RF-Platine noch auf der UI-Platine muss irgendwas gekühlt werden. Das Gespann aus OVI40-UI mit 4" LCD und RF2 nimmt im RX man gerade 240mA auf. Mit 2 ADCs in vollem Betrieb und AD9363 aktiviert.

vy 73
Andreas

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: Michael_K on 24. September 2021, 10:57:22

Danke an Andreas und Thomas für die Infos.
Die "thermische Frage" ist damit geklärt.
Ich möchte das eigentliche Thema hier nicht "mißbrauchen".
Könntet Ihr mir ein paar Infos zu 4" rüberschieben (Adapterplatine welches LCD). evtl. per PN
Danke
vy 73 aus Erfurt
Michael_K

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: Michael_K on 24. September 2021, 14:20:32

Thomas, estut sich leider nichts !

73 Michael_K

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: db9rb on 24. September 2021, 14:51:26

Michael bei mir klappt der Link am Handy mit Firefox.

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: Michael_K on 24. September 2021, 16:20:01

Danke Reiner,
aber auch das klappt weder am PV (WIN10 H 64Bit) noch am Smartphone.
vy 73
Michael_K

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: DF8OE on 24. September 2021, 16:46:39

Ich tippe mal auf "Windows"...

Geht auch bei mir einwandfrei.

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: DF8OE on 25. October 2021, 06:26:03

@Olli:
Ich habe den Bedarf vorher ermittelt - und auf Grund dieser Ergebnisse habe ich geplant, entwickelt und gebaut. Allerdings ist meine Bedarfsermittlung nicht auf das I40-Forum beschränkt gewesen, sondern hat die Stimmen vieler OMs und SWLs aus der ganzen Welt beriücksichtigt.

Wer QO100 möchte (und das sind sehr viele) benötigt einen Frequenzbereich von 13cm TX. Wo man landet wenn man mit einem LNB den RX runtermischt kann man auch leicht via Internet herausbekommen.

Olli: ich denke das Projekt ist nichts für Dich! Einerseits forderst Du, andererseits stellst Du "brauche ich nicht" Statements auf und einen halben Satz später hebst Du diese wieder auf indem Du sagst "vielleicht noch QO100". Wenn ich QO100 einplanen will und mir steht ein Transceiverchip zur Verfügung der von 70MHz...6GHz geht - dann plane ich keinen Upconverter. Aber da gehen die Philosophien eben weit auseinander. Ich würde auch niemals einen Transverter an den mcHF anschließen. Beides wird aber munter gemacht. Ist ja auch alles gut so: wer einen Upconverter nehmen möchte kann und soll das tun. Und wer mit dem mcHF mit einem Transverter arbeiten möchte: bitte: Feuer frei! Das OVI40-Projekt hat aber eine andere Zielgruppe.

EDIT:
Es ist nicht einfach sich sachlich und fachlich orientiert zu äußern und zu diskutieren ::). Daher fehlt auch diesem Beitrag für neu lesende Menschen jeglicher Bezug (weil Beiträge gelöscht wurden). Damit sind die Vorteile dieses Forums (nämlich die Nachverfolgbarkeit der logischen Zusammenhänge) da angekommen wo sie auch im Kneipengespräch sind: wenn man den ersten Teil verpasst hat kann man eigentlich nicht mehr mitreden... Trotzdem schreibe ich noch eine Antwort auf die Frage die nun nicht mehr zu lesen ist...
Der verwendete Transceiverchip ist der AD936x. Alle Chips dieser Reihe sind in Sachen 1.RX / 1.TX komplett pin- und befehlskompatibel. Es gibt den AD9361, den 9362, den 9363 und den 9364. Sie unterscheiden sich zum einen durch entweder 1RX/1TX oder jeweils 2, und auch die Frequenz-Arbeitsbereiche sind von AD jeweils anders angegeben. Aber jeder der sich mit dem Adalm-Pluto beschäftigt hat (und das habe ich auch getan) kann bestätigen, dass auch die Chips, die angeblich erst bei 325MHz beginnen, alle problemlos (!!) bei 70MHz starten. Man muss sie nur entsprechend konfigurieren. Es bleibt letztendlich dem User überlassen, welchen Chip er einsetzt. Ich habe auf meinem 1. Prototypen (der noch mit dem Spartan FPGA gearbeitet hat) den AD9363ABCZ verwendet (angeblich der "schlechteste" aus der Reihe) und auch der spielt prima ab 70MHz. Es sind auch beide RX und TX auf der PCB geroutet und verwendbar. Macht natürlich nur bei Chips mit 2 RX/TX einen Sinn. Die Preisunterschiede bei den Chips sind erheblich - ich habe für meine drei die ich damals gekauft habe bei einem chinesischen Halbleiterbroker 20 Euro pro Stück bezahlt. Bei Digikey bezahlt man für den "besten" aktuell über 200 Euro. Den bekommt man aber auch für ~50 Euro bei Halbleiterbrokern. Um der Frage gleich zuvorzukommen: Es gibt viele zuverlässige Halbleiterbroker. Ich kaufe oft dort. Man muss nur aufpassen wem man vertraut - wie im normalen Leben auch. Pauschale Aussagen sind auch hier unangebracht und falsch. Grundsätzlich gilt: um etws beurteilen zu können sollte man sich damit beschäftigt und es in groben Zügen verstanden haben.

vy 73
Andreas

Title: Re:Final RF (RX/TX) PCB Prototype populating history (Sep 10.-18. 2021)
Post by: DF8OE on 25. October 2021, 06:55:08

Hallo Thomas,
diese Antwort ist eine die ich in meinen Umfragen vorher hunderte von Malen gehört habe. Es war die überwältigende Mehrheit die so gedacht hat. Für diese Mehrheit habe ich mir die Zeit genommen, das zu starten, Dinge zu lernen, die erste 6-Layer-Platine meines Lebens zu entwickeln (incl. diverser laufzeitkompensierter Bussysteme, da die Busse teilweise mit 150MHz Takt laufen). Und habe VHDL und Verilog angefangen. BGAs löte ich seit 15 Jahren täglich. Nur bei Verilog / VHDL / Grundwissen zur FPGA-Planung mittels Quartus - da bin ich noch nicht so weit dass ich mit meinen Fortschritten zufrieden wäre. Das Thema ist auch so komplex dass es nicht damit getan ist eine einzige Frage zu stellen (in einem Forum z.B.) und dann ist "alles klar"... Es werden immer wieder (Anfangs häufiger, mit der Zeit weniger) Fragen aufkommen und da wäre es eben schön wenn jemand im Team wäre der das nicht erst alles lernen muss sondern es schon kann. Er muss keine DSP-Bearbeitung in FPGAs können - aber eben die Grundzüge im Schlaf beherrschen.

Aktuelles Beispiel:
Der Code des FPGA für 15KHz...75MHz läuft bereits (TX und RX). Es sind noch einige Dinge drin die geändert werden müssen - die aus den Open Source Projekten stammen aus denen ich Blöcke als Basis genommen habe.

Also habe ich angefangen diese Teile zu verändern. Jetzt stehe ich an dem Punkt dass mein neuer Code standalone läuft. Baue ich ihn aber in den RF2-FPGA Teil ein dann geht auf einmal ein DSP-Teil nicht mehr so wie er soll - obwohl der NICHTS mit dem geänderten Teil zu tun hat. Ich kann das Phänomen so weit runterbrechen dass ich nur eine einzige Zeile einfügen muss die nichts anderes tut als einem ansonsten unbenutzten Register einen Wert zuzuweisen - und schon geht der DSP-Code nicht mehr so wie er soll. Ursache dürfte sein dass der Compiler den laufenden Teil anders routet wenn mein zusätzlicher Code dazu kommt, und dann dort Timingprobleme auftreten. Ich müsste also dem Compiler irgendwie sagen können, dass bestimmte Routings nicht mehr angefasst werden dürfen, wenn neue Teile dazukommen. Ich weiß aber nicht wie man das macht. Nichts was ich dazu bereits probiert habe war die Lösung. Bisher in dieses Problem investierte Zeit: ca. 48 Stunden. Es ist für mich auch keine Lösung zu schreiben "das geht nur wenn Du die Software von Intel kaufst und nicht die freie Variante nimmst". Die Soft von Intel kostet ein paar Kiloeuro.

EDIT:
Und die Antwort "geht nicht" akzeptiere ich ebensowenig. Diese Antwort ist häufig ein KO-Argument warum man sich nicht (zeitintensiv) mit der Lösung eines Problems beschäftigen will. Sie passt aber prima in unsere heutige schnellebige Welt und daher findet man sie sehr oft ::)
Die 48 Stunden von weiter oben waren im Prinzip teures Lehrgeld. Ich habe den Fehler in meinem Code gesucht - aber keinen gefunden. 48 Stunden lang, Bis ich dann festgestellt habe dass schon eine einzige (fehlerfreie aber definitiv einflusslose) Zeile den DSP-Code ebenfalls aus dem Takt wirft.

vy 73
Andreas


Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.