Gam­ma-Mess­ge­rät, Teil 1 – Hardwarebeschreibung

Ein­lei­tung

Schon seit Jah­res­an­fang 2026 ist die erste Ver­si­on des Refle­xi­ons­fak­tor-Mess­ge­rä­tes ver­füg­bar, die über den Pro­to­ty­pen­sta­tus hin­aus­geht. Inzwi­schen funk­tio­niert die­se Ver­si­on zuver­läs­sig und sehr zufrie­den­stel­lend. Auch der Anten­nen­kopp­ler mit der Ver­si­ons­num­mer 1.7 funk­tio­niert im gesam­ten Kurz­wel­len­be­reich, mit klei­nen Abstri­chen sogar im 2‑m-Band. Eine erste Kurz­be­schrei­bung hat­te ich schon im Febru­ar ver­öf­fent­licht und den Kopp­ler noch­mal etwas detail­lier­ter im März. Bei der Inbe­trieb­nah­me zeig­ten sich Unge­reimt­hei­ten des Kopp­lers, die ich in einem Nach­trag beschrie­ben habe. Sie sind glück­li­cher­wei­se gelöst.

Sta­tus

Die Hard­ware funk­tio­niert nun ohne erkenn­ba­re Pro­ble­me. Der RTL-Code für das FPGA und die Soft­ware für den syn­the­ti­sier­ten RISC-V-Pro­zes­sor wür­de ich als Beta-Release bezeich­nen. Es sind alle gewünsch­ten Funk­tio­nen imple­men­tiert und kei­ne Feh­ler bekannt. Sowohl der Ver­i­log-RTL-Code wie auch der C‑Quellcode könn­ten sicher­lich noch etwas glatt­ge­zo­gen und bes­ser doku­men­tiert wer­den. Hier und da ist noch Test­code vor­han­den, der nicht mehr benö­tigt wird.

Inzwi­schen ist auch die Host-Soft­ware gut benutz­bar, wenn­gleich auch noch im Beta-Sta­tus. Sie ist für Qt geschrie­ben und damit prin­zi­pi­ell auch für ande­re Betriebs­sy­ste­me als Win­dows ver­wend­bar. Eine even­tu­el­le Por­tie­rung über­las­se ich dem geneig­ten Anwen­der. Ich selbst habe mal eine frü­he­re Ver­si­on in einer vir­tu­el­len Ubun­tu-Maschi­ne erfolg­reich über­setzt, es ist mir aber nicht gelun­gen ein Deployment zu erzeu­gen, das auch außer­halb die­ser Maschi­ne lief. Damit möch­te ich erst mal kei­ne wei­te­re Zeit vertun.

Bei­spiel­mes­sun­gen

Hier ein Ein­druck des aktu­el­len Soft­ware-Stan­des, exem­pla­risch mit einer reel­len Last von 10 Ω und mit einer induk­ti­ven Last von 0,93 µH (Wert mit VNWA bei 21 MHz gemessen):

Oben ist jeweils der Refle­xi­ons­fak­tor gezeigt (Schie­be­reg­ler links), dar­un­ter das Smit­h­dia­gramm (Schie­be­reg­ler rechts) und unten das Fen­ster mit den jewei­li­gen Mess­wer­ten und den dar­aus errech­ne­ten Ergeb­nis­sen. Als Signal­quel­le dient ein Signal­ge­nera­tor mit 20 dBm Aus­gangs­lei­stung. Wenn das gemes­se­ne Steh­wel­len­ver­hält­nis klei­ner als SWR3 ist (hier auf 20 ein­ge­stellt), wird eine Anpas­sung mit einem LC- oder CL-Netz­werk berech­net und ein­ge­zeich­net. Eine detail­lier­te Erklä­rung folgt bei der Beschrei­bung der Host-Software.

Pro­jekt­be­schrei­bung

Das gesam­te Pro­jekt ist recht umfang­reich und umfasst die Lei­ter­plat­ten­ent­wick­lung mit KiCad, die FPGA-Ent­wick­lung in Ver­i­log, die Firm­ware des dar­auf syn­the­ti­sier­ten Risc-V-Pro­zes­sors in C und natür­lich die Host-Bedie­ner­ober­flä­che in C++. Ich wer­de alle Quell­codes ver­öf­fent­li­chen und in gro­ben Zügen beschrei­ben. Dabei will ich mich nicht in Details ver­lie­ren. Wer das Pro­jekt nach­bau­en will, muß sich sowie­so ein­ar­bei­ten, falls er nicht ohne­hin alles anders und bes­ser machen will. Even­tu­el­le Fra­gen beant­wor­te ich natür­lich gerne.

Die­ser erste Teil soll sich um die Hard­ware, die FPGA-Ent­wick­lung und die Firm­ware dre­hen. Die Host-Soft­ware inklu­si­ve eini­ger Bei­spiel­mes­sun­gen wird einen eige­nen Bei­trag erfordern.

Hard­ware­be­schrei­bung

Die Hard­ware ist bereits hier kurz beschrie­ben und soll hier noch­mal kopiert wer­den, um nicht zwi­schen den Bild­schir­men hin- und her­schal­ten zu müssen.

Ansich­ten und Design-Dateien

Die 3D-Ansich­ten…

3D-Ansich­ten des ersten Releases

und hier der Schalt­plan und das KiCad-Projekt:

Kurz­be­schrei­bung

Die Dämp­fungs­glie­der am Ein­gang sind jetzt für eine maxi­ma­le Ein­gangs­lei­stung von 27 dBm (500 mW) aus­ge­legt. Bei einer Kop­pel­dämp­fung von 26 dB darf die maxi­ma­le Ein­gangs­lei­stung damit bei 53 dBm, also 200 Watt liegen.

Dem nega­ti­ven Ein­gang der Kom­pa­ra­to­ren ist nun jeweils ein rausch­ar­mer Prä­zi­si­ons-OpAmp vom Typ OPA376 als Span­nungs­fol­ger vor­ge­schal­tet. Der kom­pen­siert die Span­nungs­ver­schie­bung durch den Ein­gangs­leck­strom der Kom­pa­ra­to­ren. Für OpAmp und Kom­pa­ra­to­ren wären auch jeweils Vari­an­ten mit zwei Ein­hei­ten in einem Gehäu­se ver­füg­bar. Um eine best­mög­li­che Ent­kopp­lung der bei­den Kanä­le zu errei­chen, wur­de auf deren Ein­satz aber verzichtet.

J7 dient der Span­nungs­ver­sor­gung und der seri­el­len Kom­mu­ni­ka­ti­on mit der Außen­welt. Hier kann zu Test­zwecken ein USB-Seri­ell-Kon­ver­ter direkt ange­steckt wer­den. Um einen gewis­sen Schutz gegen Ver­po­lung zu errei­chen, sind in die Daten­lei­tun­gen seri­el­le Wider­stän­de von 330 Ω ein­ge­fügt. Die Span­nungs­ver­sor­gung ist mit einer Ther­mo­si­che­rung und einer TVS-Diode gesi­chert. J3 und J6 stel­len ein paar Signa­le des FPGAs zur Ver­fü­gung. Wenn alles auf Anhieb funk­tio­niert, sind sie unnötig.

Die Kanä­le wur­den jetzt mit Port1 und Port2 bezeich­net. Sie sind ja gleich­ar­tig auf­ge­baut und die Soft­ware ent­schei­det, wel­cher Port die vor­lau­fen­de und wel­cher die rück­lau­fen­de Span­nung aufnimmt.

Ergän­zung zur Kurzbeschreibung

Die Span­nungs­ver­sor­gung erfolgt über einen an J7 ange­steck­ten USB-RS232-Kon­ver­ter mit einem 5‑V-Aus­gang. Sie wird über F1 und D2 gegen Über­span­nung und Ver­po­lung abge­si­chert und mit C28, C29 und C30 gefil­tert. Die­se Span­nung ver­sorgt die OpAmps, die Kom­pa­ra­to­ren, die log­arith­mi­schen Ver­stär­ker und das Tang-Pri­mer-Board. Das Tang-Board erzeugt die von ihm benö­tig­ten Span­nun­gen selbst und gibt sie auch über sei­nen Steck­ver­bin­der nach außen.

Die Außen­be­schal­tung ent­schei­det, wel­che FPGA-Bän­ke mit wel­cher Betriebs­span­nung ver­sorgt wer­den. In die­sem Fall wer­den alle Bän­ke mit 3,3 V ver­sorgt. Mit die­sen 3,3 V wird außer­dem auch der AD-Wand­ler U1 (ADS1118) betrie­ben. Er braucht typi­scher­wei­se nur 0,3 mA. Es ist ein ADC mit vier Ein­gän­gen und zusätz­lich einem Ther­mo­me­ter. Sei­ne Kon­fi­gu­ra­ti­on erhält er über eine SPI-Schnitt­stel­le, die gleich­zei­tig auch die Mess­wer­te überträgt.

Der ADC misst die bei­den Aus­gangs­span­nun­gen der log­arith­mi­schen Ver­stär­ker sowie die 5‑V-Ein­g­ans­span­nung von der USB-Schnitt­stel­le und die 3,3 V vom Tang-Board. Er hat eine Auf­lö­sung von 16 Bit und kann je nach Kon­fi­gu­ra­ti­on bis zu 860 Mess­wer­te pro Sekun­de liefern.

Das Tang-Board ist völ­lig eigen­stän­dig und hat alle benö­tig­ten Kom­po­nen­ten an Bord. Es benö­tigt nur die 5‑V-Betriebs­span­nung. Sei­ne Kon­fi­gu­ra­ti­on inklu­si­ve der Firm­ware eines optio­nal syn­the­ti­sier­ten Pro­zes­sors wird beim Ein­schal­ten aus einem seri­el­le Flash-Spei­cher gela­den. Um die­sen Flash-Spei­cher zu pro­gram­mie­ren, muss das Tang-Board abge­zo­gen und auf ein Tang-Base­board auf­ge­steckt wer­den. Das habe ich hier beschrie­ben, dar­über­hin­aus sei auf wei­te­re Quel­len im Inter­net verwiesen.

Das erste Board hat lei­der noch zwei Feh­ler, die zum Glück nicht gra­vie­rend sind, aber bei einem neu­en Design beho­ben wer­den sol­len. Es sind SMA-Buch­sen mit fal­schem Pin­ab­stand ein­ge­baut und die NFM18P­S105R-Fil­ter unter dem Tang-Board sind zu dick. Da muß ent­we­der ein höhe­rer Sockel ver­wen­det wer­den oder die Fil­ter müs­sen woan­ders hin ver­scho­ben wer­den. Beim jet­zi­gen Board muß ein Strei­fen Iso­lier­band unter dem Tang-Board auf­ge­klebt wer­den und es darf nicht zu fest ein­ge­drückt wer­den, sonst gibt es Kurz­schlüs­se. Außer­dem ist D1 zu hell und blen­det, wenn das Board vor einem auf dem Tisch liegt.

FPGA-Design

Das Funk­ti­ons­prin­zip des FPGAs habe ich bereits in einem Bei­trag Anfang 2026 für den ersten Pro­to­ty­pen beschrie­ben. Die Beschrei­bung ist nach wie vor gül­tig, außer daß ich den asyn­chro­nen Sen­der ATX wei­ter­ent­wickelt und ihn in ART (asyn­chro­no­us receiver/transmitter) umbe­nannt habe, auch wenn der Emp­fangs­teil noch nicht imple­men­tiert ist.

Hier das leicht über­ar­bei­te­te Blockdiagramm:

Der asyn­chro­ne Sen­der ART

Der Sen­de­teil ist nun bes­ser kon­fi­gu­rier­bar als vor­her. Man kann zwi­schen einem und zwei Stop­bits wäh­len und kei­ne, gera­de oder unge­ra­de Pari­tät aus­wäh­len. Die Bit­ra­te ist nun nicht mehr ein ganz­zah­li­ger Bruch­teil der Takt­fre­quenz son­dern ein ganz­zah­li­ger Bruch­teil von 1⁄8 der Takt­fre­quenz. Der Grund ist der noch nicht imple­men­tier­te Emp­fän­ger, der jedes Bit mehr­fach abta­sten muss, beab­sich­tigt ist acht­mal. Wegen die­ser Ände­rung wur­de die CPU- und ART-Takt­fre­quenz nun auf 25 MHz erhöht, weil mit den bis­he­ri­gen 20 MHz die erwünsch­te Baud­ra­te von 115.200 Bd nicht hin­rei­chend genau erzeugt wer­den konnte.

Da die Inter­rupt-Aus­füh­rungs­zeit des PicoRV32 recht hoch ist und die Res­sour­cen im FPGA vor­han­den sind, wur­de ein 256-Byte Sen­de-FIFO imple­men­tiert. Es wird CPU-sei­tig in einem Rutsch mit den Sen­de­da­ten gefüllt und vom ART nach Bedarf geleert. Inter­rupts sind nicht mehr not­wen­dig, solan­ge nicht mehr Daten gesen­det wer­den sol­len, als in das FIFO passen.

Wahl der Messrate

Zunächst zur Abschät­zung der Gren­zen: Eine Mes­sung pro Sekun­de wäre das abso­lu­te Mini­mum. Lang­sa­mer darf es nicht sein, wenn man den Wert nur optisch anzei­gen will. Zehn Mes­sun­gen pro Sekun­de wäre das Mini­mum, um einen Anten­nen­tu­ner anzu­steu­ern. Hun­dert Mes­sun­gen pro Sekun­de wären in den mei­sten Fäl­len wohl schon ein Overkill.

Was kann denn die Hard­ware? Der AD-Wand­ler kann pro Sekun­de 860 Mes­sun­gen durch­füh­ren, die auf sei­ne bis zu fünf Kanä­le ver­teilt wer­den. Abso­lut not­wen­dig sind die bei­den Kanä­le zur Mes­sung der Vor- und Rück­lauf­span­nung. Damit liegt also die maxi­ma­le Mess­ra­te bei 430 Mes­sun­gen pro Sekun­de. Beschränkt man sich also auf die genann­ten 100 Mes­sun­gen pro Sekun­de, dann kön­nen in jedem Mess­zy­klus pro­blem­los alle vier AD-Kanä­le und die Tem­pe­ra­tur gemes­sen wer­den. Das ver­ein­facht die Soft­ware, Klimm­zü­ge sind unnötig.

Der Pha­sen­ver­glei­cher akku­mu­liert im Mess­in­ter­vall die Eigen­schaf­ten der vor- und rück­lau­fen­den Signa­le: die Anzahl und Sequenz ihrer Flan­ken und die Dau­er der Über­lap­pung. Das Mess­in­ter­vall muss hin­rei­chend lang sein, damit genü­gend Flan­ken aus­ge­wer­tet wer­den kön­nen. Blei­ben wir bei dem Bei­spiel mit 100 Mes­sun­gen pro Sekun­de, dann dau­ert ein Mess­in­ter­vall 10 ms, was bei den 1,8 MHz des 160-m-Ban­des also für 18.000 Flan­ken reicht. Das reicht für eine Sta­ti­stik und bei den höhe­ren Bän­dern wird es zuneh­mend mehr.

Ein wei­te­rer Punkt ist zu beach­ten: die Mess­da­ten müs­sen ja irgend­wie über­tra­gen wer­den. Dazu ist die seri­el­le Schnitt­stel­le imple­men­tiert, deren Daten­ra­te begrenzt ist. Um bei den Stan­dard­ra­ten zu blei­ben, habe ich hier 115 kBd mit zwei Stop­bits und gerad­zah­li­ger Pari­tät gewählt. Damit kann man also pro Sekun­de maxi­mal 115200⁄11 ≅ 10kByte über­tra­gen, was in 10 ms 100 Byte sind. In der Ent­wick­lungs­pha­se war das etwas zu knapp, denn hin und wie­der wur­den aus­führ­li­che Test­da­ten mit Zusatz­in­for­ma­ti­on benö­tigt, die die­sen Rah­men über­schrit­ten haben. Daher fiel die Wahl auf 25-ms-Inter­val­le, also 40 Mes­sun­gen pro Sekun­de. Das ist der jet­zi­ge Stand, der aber in den genann­ten Gren­zen änder­bar ist.

VCO und PLL

Als Takt für den Pha­sen­ver­glei­cher clk_s soll­ten die ursprüng­lich gewähl­ten 200 MHz bei­be­hal­ten wer­den. Damit las­sen sich 26-Bit-Zäh­ler zuver­läs­sig syn­the­ti­sie­ren, ohne die Fre­quenz­gren­zen zu ver­let­zen. Das reicht für Mess­in­ter­val­le bis län­ger als 300 ms. Mit den nun gewähl­ten Inter­vall von 25 ms wären daher auch 23-bit-Zäh­ler aus­rei­chend, die even­tu­ell etwas schnel­ler getak­tet wer­den kön­nen. Der Nut­zen wäre gering, daher bleibt es momen­tan bei 26-bit-Zählern.

Der inter­ne VCO wird mit 800 MHz betrie­ben und dar­aus wer­den durch Tei­lung die Abtast­fre­quenz von 200 MHz und die CPU-Takt­fre­quenz von 25 MHz gene­riert. Aus einem Ach­tel der CPU-Fre­quenz wird durch ganz­zah­li­ge Tei­lung die Baud­ra­te der asyn­chro­nen Schnitt­stel­le erzeugt. Daher ist man nicht ganz frei in der Wahl der Taktfrequenzen.

Vor­schau auf Teil 2

Im näch­sten Teil soll die Firm­ware, der FPGA-Ver­i­log-Code und die Host-Soft­ware beschrie­ben wer­den. Wie oben ange­deu­tet, ist momen­tan alles min­de­stens als funk­tio­nie­ren­de Beta-Ver­si­on ver­füg­bar. Hier ist der aktu­el­le Stand zusammengepackt:

Vor einem ech­ten „Release“ und einer detail­lier­ten Beschrei­bung will ich aber alles noch etwas glatt­zie­hen. Es fehlt auch noch eine Mod­bus-Vari­an­te, die dann zusam­men mit ande­ren Modu­len an einer RS-485-Schnitt­stel­le betrie­ben wer­den kann. Blue­tooth wäre auch nicht schlecht, denn beim Test­be­trieb habe ich fest­ge­stellt, daß über die USB-Schnitt­stel­le vie­le Stö­run­gen vom PC auf einen ange­schlos­se­nen Trans­cei­ver ein­ge­kop­pelt wer­den. Das ist dar­an erkenn­bar, daß der Rausch­pe­gel im Trans­cei­ver deut­lich steigt, wenn man den USB-Stecker nur an die USB-Buch­se am PC hält, so daß noch kei­ne Span­nungs­ver­sor­gung erfolgt. Das hängt aber ver­mut­lich auch von der Ent­stö­rung des jeweils ver­wen­de­ten PCs ab.

Wie auch immer, ich wer­de mir die nöti­ge Zeit las­sen. Soll­te trotz­dem jemand vor­ab mit den Quell­codes her­um­spie­len wol­len, möge er das mit dem oben ange­bo­te­nen Code machen. Wer nicht klar­kommt, kann mich per Email kontaktieren.