<?xml version="1.0" encoding="UTF-8"?>
<rss  xmlns:atom="http://www.w3.org/2005/Atom" 
      xmlns:media="http://search.yahoo.com/mrss/" 
      xmlns:content="http://purl.org/rss/1.0/modules/content/" 
      xmlns:dc="http://purl.org/dc/elements/1.1/" 
      version="2.0">
<channel>
<title>Radio Science Institute Blog</title>
<link>https://blog.radio-science-institute.eu/</link>
<atom:link href="https://blog.radio-science-institute.eu/index.xml" rel="self" type="application/rss+xml"/>
<description></description>
<generator>quarto-1.10.3</generator>
<lastBuildDate>Sun, 03 May 2026 00:00:00 GMT</lastBuildDate>
<item>
  <title>How to get GNSS from 5 meter to 1 centimetre</title>
  <dc:creator>Ansgar Schmidt</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2026/05/03-rtk-with-ublox-zed-f9p/</link>
  <description><![CDATA[ 





<section id="rtk-gnss-on-linux-with-the-u-blox-zed-f9p-from-5-metres-to-1-centimetre" class="level1">
<h1>RTK GNSS on Linux with the u-blox ZED-F9P — From 5 Metres to 1 Centimetre</h1>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2026/05/03-rtk-with-ublox-zed-f9p/images/img1.png" class="img-fluid figure-img"></p>
<figcaption>u-blox with antenna</figcaption>
</figure>
</div>
<p>Standard GPS gives you roughly 2 to 5 metres of position accuracy on a good day. Real-Time Kinematic positioning — RTK — gives you around 1 centimetre. That is a 200× to 500× improvement, achieved entirely in software and signal processing, with the same satellites overhead. No magic, no proprietary black box. Just a cleverer way of reading the signal that has been reaching your antenna all along.</p>
<p>This post walks through exactly how RTK works, why the math holds together, and how to get a u-blox ZED-F9P receiver on a Linux machine from zero to RTK Fixed — with free correction data from the German SAPOS network. Every concept is explained before any command is typed.</p>
<hr>
<section id="how-standard-gnss-works" class="level2">
<h2 class="anchored" data-anchor-id="how-standard-gnss-works">How Standard GNSS Works</h2>
<p>Each GNSS satellite broadcasts a continuous radio signal containing two things: a precise timestamp from an atomic clock, and the satellite’s orbital position at the time of transmission. Your receiver picks up signals from several satellites simultaneously, measures how long each signal took to arrive, multiplies by the speed of light, and triangulates. Four satellites give you three spatial dimensions plus a clock correction; more satellites improve the geometry and reduce noise.</p>
<p>The timing measurement works through a technique called <strong>code phase ranging</strong>. Each satellite modulates its carrier signal with a pseudorandom noise (PRN) sequence — a pattern of ones and zeros unique to each satellite. Your receiver generates an identical local copy of the code and slides it in time until the two line up. The offset between the local copy and the incoming signal is the travel time. The GPS L1 C/A code runs at 1.023 MHz, so one chip (one bit in the sequence) spans about 293 metres of travel. Receivers can resolve the alignment to perhaps 1% of a chip, giving position resolution in the 1–3 metre range.</p>
<p>Several effects limit accuracy further:</p>
<ul>
<li><strong>Ionosphere</strong>: The ionosphere is a plasma layer 60–1000 km up. Radio signals slow slightly as they pass through it, and the delay varies with solar activity, time of day, and the elevation angle of the satellite. Dual-frequency receivers (L1 + L2) can measure and compensate for most of this delay directly.</li>
<li><strong>Troposphere</strong>: The lower atmosphere adds a smaller, more predictable delay that depends on temperature, pressure, and humidity.</li>
<li><strong>Multipath</strong>: Near buildings or reflective surfaces, signals bounce off walls and arrive via multiple paths, blurring the correlation peak.</li>
<li><strong>Satellite geometry</strong>: If all visible satellites cluster in one part of the sky, your position is poorly constrained in the other direction. The metric is PDOP — position dilution of precision. Lower is better.</li>
</ul>
<p>These effects combine to give standard single-frequency GNSS an accuracy floor of roughly 2–5 metres in open sky, worse in urban environments.</p>
<hr>
</section>
<section id="the-key-insight-carrier-phase-measurement" class="level2">
<h2 class="anchored" data-anchor-id="the-key-insight-carrier-phase-measurement">The Key Insight: Carrier Phase Measurement</h2>
<p>Here is the thing nobody tells you when you first learn about GPS: the satellites are not just broadcasting a code on top of a carrier wave — the carrier wave itself carries information you can measure.</p>
<p>The GPS L1 carrier frequency is <strong>1575.42 MHz</strong>. That corresponds to a wavelength of:</p>
<pre><code>λ = c / f = 299,792,458 m/s ÷ 1,575,420,000 Hz ≈ 0.1903 m ≈ 19 cm</code></pre>
<p>A capable receiver can measure the <strong>phase</strong> of this carrier wave — not just which chip in the PRN code arrived, but where within a single 19 cm oscillation cycle the wave currently sits. Phase measurement precision is typically about 1% of one cycle, which translates to roughly <strong>2 mm</strong> of distance resolution.</p>
<p>That is the leap: from 1–3 metre code resolution to 2 mm carrier-phase resolution. Two orders of magnitude, from the same signal.</p>
<p>So why does standard GPS not use this? Because of a fundamental ambiguity.</p>
<p>When the receiver measures a carrier phase of, say, 127.4°, that tells it where within one cycle the wave is sitting. But it has no idea how many <strong>complete cycles</strong> have elapsed over the total path from satellite to receiver. The satellite is 20,000 km away. At 19 cm per cycle, the signal travels through roughly <strong>105,000,000 cycles</strong> on its way down. The measured phase gives you the fractional part of the last cycle. The integer number of complete cycles — called <strong>N</strong>, or the <strong>integer ambiguity</strong> — is unknown.</p>
<p>More precisely, the carrier phase measurement φ relates to the true range ρ like this:</p>
<pre><code>φ = ρ/λ + N + ε</code></pre>
<p>where N is an integer and ε captures noise and atmospheric delays. You can measure φ to millimetre precision, but N could be anywhere in a range of millions of integers. Until you know N, all that precision is useless.</p>
<p>Resolving N is the entire technical challenge of RTK.</p>
<hr>
</section>
<section id="how-rtk-resolves-the-ambiguity" class="level2">
<h2 class="anchored" data-anchor-id="how-rtk-resolves-the-ambiguity">How RTK Resolves the Ambiguity</h2>
<p>RTK uses a second receiver — the <strong>reference station</strong> — at a precisely known, surveyed location. Both receivers observe the same satellites at the same time. Here is what that buys you.</p>
<p>The reference station knows its exact position. It knows the exact orbital position of each satellite (from the broadcast ephemeris). It can therefore compute exactly what the range ρ to each satellite must be. From that it can compute what the carrier phase measurement <em>should</em> be if there were no atmospheric delay, no clock errors, nothing but geometry.</p>
<p>In reality, the measured phase differs from the predicted phase. That difference is caused by the ionosphere, troposphere, receiver clock drift, and multipath — all the things that also affect the rover (the moving receiver you are trying to position). Crucially, for a baseline of a few tens of kilometres, these errors are nearly identical at both the reference station and the rover. The atmosphere over a 30 km patch of sky looks the same to both receivers.</p>
<p>So the reference station continuously computes: measured phase minus predicted phase = error. It broadcasts these corrections in real time via the <strong>RTCM</strong> protocol (Radio Technical Commission for Maritime Services, version 3 in modern use). The rover receives the RTCM corrections and subtracts them from its own measurements. Most of the atmospheric error disappears. What remains is a much cleaner phase measurement with a known relationship to the true range.</p>
<p>With the errors reduced, the rover’s RTK engine can now solve for N using a technique called <strong>integer least squares</strong> (the most common implementation is LAMBDA — Least-squares AMBiguity Decorrelation Adjustment). The engine generates candidate integer combinations for all tracked satellites simultaneously and tests which set is statistically consistent. When one combination is overwhelmingly more likely than all others, the receiver declares a <strong>fixed</strong> solution. N is now known for every satellite in view. The carrier phase measurements, with their 2 mm resolution, can be used directly for positioning.</p>
<p>The result is a position accurate to <strong>1–2 cm horizontally</strong> and perhaps <strong>2–3 cm vertically</strong>, continuously updated in real time.</p>
<p>A few points are worth emphasising:</p>
<ul>
<li>The correction baseline matters. As the distance between reference station and rover grows, the atmospheric conditions diverge. RTK corrections are typically valid out to 30–50 km from the reference station. Beyond that, accuracy degrades. Networks of reference stations (see Virtual Reference Stations below) extend this range.</li>
<li>The fix is not instantaneous. The RTK engine must collect enough phase observations across enough epochs and satellite geometries to confidently resolve N. In good conditions this takes 10–60 seconds. In poor conditions — heavy tree cover, buildings, multipath — it may never achieve a fixed solution.</li>
<li>L2 (GPS: 1227.60 MHz, wavelength ~24 cm) helps enormously. A dual-frequency receiver can form a <strong>widelane</strong> combination of L1 and L2 phases with an effective wavelength of ~86 cm, which makes the integer ambiguity far easier to resolve. This is why dual-frequency receivers like the ZED-F9P fix so much faster than older single-frequency designs.</li>
</ul>
<hr>
</section>
<section id="fix-states-no-fix-float-fixed" class="level2">
<h2 class="anchored" data-anchor-id="fix-states-no-fix-float-fixed">Fix States: No Fix → Float → Fixed</h2>
<p>RTK receivers report their solution quality through a fix type field. The ZED-F9P’s NAV-PVT message uses a <code>fixType</code> integer:</p>
<table class="caption-top table">
<colgroup>
<col style="width: 20%">
<col style="width: 13%">
<col style="width: 30%">
<col style="width: 34%">
</colgroup>
<thead>
<tr class="header">
<th>fixType</th>
<th>Name</th>
<th>Typical hAcc</th>
<th>What it means</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>0</td>
<td>No Fix</td>
<td>—</td>
<td>Not enough satellites or signals</td>
</tr>
<tr class="even">
<td>1</td>
<td>Dead Reckoning</td>
<td>—</td>
<td>Using IMU only, no GNSS</td>
</tr>
<tr class="odd">
<td>2</td>
<td>2D Fix</td>
<td>&gt;10 m</td>
<td>Altitude assumed, not measured</td>
</tr>
<tr class="even">
<td>3</td>
<td>3D Fix</td>
<td>2–5 m</td>
<td>Standard GNSS, code phase only</td>
</tr>
<tr class="odd">
<td>4</td>
<td>GNSS + Dead Reckoning</td>
<td>varies</td>
<td>Sensor fusion</td>
</tr>
<tr class="even">
<td>5</td>
<td>Time Only</td>
<td>—</td>
<td>Position known, timing mode</td>
</tr>
<tr class="odd">
<td><strong>4 (carrSoln=1)</strong></td>
<td><strong>RTK Float</strong></td>
<td><strong>20–50 cm</strong></td>
<td>Corrections received, ambiguity not yet resolved</td>
</tr>
<tr class="even">
<td><strong>4 (carrSoln=2)</strong></td>
<td><strong>RTK Fixed</strong></td>
<td><strong>~1 cm</strong></td>
<td>Ambiguity resolved, full precision active</td>
</tr>
</tbody>
</table>
<p>In ubxtool output, the relevant fields are <code>fixType</code> and <code>carrSoln</code>:</p>
<pre><code>fixType 3  carrSoln 0   → standard 3D fix
fixType 4  carrSoln 1   → RTK Float (corrections active but N not fixed)
fixType 4  carrSoln 2   → RTK Fixed (goal achieved)</code></pre>
<p>The Float state is not worthless — 20–50 cm is still a significant improvement over a raw 3D fix and can be adequate for some applications. But Fixed, with its sub-centimetre precision, is what makes RTK genuinely extraordinary.</p>
<hr>
</section>
<section id="virtual-reference-stations" class="level2">
<h2 class="anchored" data-anchor-id="virtual-reference-stations">Virtual Reference Stations</h2>
<p>A network of permanent GNSS reference stations — CORS networks — covers most of Europe and North America. Germany operates SAPOS (Satellitenpositionierungsdienst der deutschen Landesvermessung), a network of stations roughly 40–70 km apart. Sweden has SWEPOS, France has RGP, and so on.</p>
<p>Rather than connecting your rover to the single nearest station, modern correction networks use <strong>Virtual Reference Stations (VRS)</strong>. The concept is elegant: the network server knows the precise positions of all its physical stations and continuously models the spatial variation of atmospheric errors across the region. When you send it your approximate position (a single coarse GNSS fix is sufficient), it synthesises a <em>virtual</em> reference station right next to you — typically within a few hundred metres. The correction data the server sends looks like it came from a real station at that virtual position, with no baseline errors to worry about.</p>
<p>This has a practical consequence for the software setup: the NTRIP server needs to know your current position to compute the VRS corrections. Your rover must send NMEA GGA sentences (which contain position) back to the server, not just receive from it. The stream relay tool <code>str2str</code> handles this with its <code>-b</code> flag, described in the setup steps below.</p>
<hr>
</section>
<section id="the-hardware-u-blox-zed-f9p" class="level2">
<h2 class="anchored" data-anchor-id="the-hardware-u-blox-zed-f9p">The Hardware: u-blox ZED-F9P</h2>
<p>The ZED-F9P is u-blox’s flagship professional-grade RTK receiver. The “01B” or “01C” hardware revision suffix you see on commercial modules denotes board revisions with minor component changes; the core receiver is the same.</p>
<p>Key specifications:</p>
<table class="caption-top table">
<thead>
<tr class="header">
<th>Property</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>Frequencies</td>
<td>L1 + L2 (GPS, GLONASS, Galileo, BeiDou)</td>
</tr>
<tr class="even">
<td>Constellations</td>
<td>GPS, GLONASS, Galileo, BeiDou, QZSS, SBAS</td>
</tr>
<tr class="odd">
<td>RTK accuracy</td>
<td>0.01 m + 1 ppm CEP (horizontal)</td>
</tr>
<tr class="even">
<td>PPS accuracy</td>
<td>&lt; 20 ns RMS (with good fix)</td>
</tr>
<tr class="odd">
<td>Update rate</td>
<td>Up to 20 Hz (RTK), 25 Hz (raw)</td>
</tr>
<tr class="even">
<td>Interface</td>
<td>USB (CDC-ACM), UART, SPI, I2C</td>
</tr>
<tr class="odd">
<td>Protocol</td>
<td>UBX (proprietary binary), NMEA, RTCM 3.3</td>
</tr>
</tbody>
</table>
<p>On Linux, the ZED-F9P connects via USB and enumerates as a CDC-ACM device — you will see it as <code>/dev/ttyACM0</code> (or <code>ttyACM1</code> etc. if other ACM devices are already present). No driver installation is required; the kernel’s <code>cdc_acm</code> module handles it automatically.</p>
<p>The built-in RTK engine runs entirely on the receiver’s own processor. Your PC or Raspberry Pi does not compute the RTK solution — it merely feeds the receiver the RTCM correction stream and reads back the result. This matters for embedded applications where the host CPU is busy with other tasks.</p>
<p>The PPS output deserves mention: at under 20 ns RMS, it is competitive with dedicated timing receivers and far more accurate than anything derived from code-phase GNSS. For a GNSS-disciplined oscillator, this output is the primary timing reference.</p>
<hr>
</section>
<section id="the-software-stack" class="level2">
<h2 class="anchored" data-anchor-id="the-software-stack">The Software Stack</h2>
<p>Three tools do all the work. Understand each one before wiring them together.</p>
<section id="ubxtool" class="level3">
<h3 class="anchored" data-anchor-id="ubxtool">ubxtool</h3>
<p><code>ubxtool</code> is part of the <code>gpsd-clients</code> package. It speaks u-blox’s proprietary <strong>UBX binary protocol</strong> — the low-level message format used for configuration, status polling, and raw data. The UBX protocol sits alongside NMEA on the same serial port; the receiver outputs both simultaneously.</p>
<p>Key flags:</p>
<ul>
<li><code>-f /dev/ttyACM0</code> — the device to talk to</li>
<li><code>-p PRESET</code> — send a poll request for a specific message class (e.g., <code>NAV-PVT</code>, <code>RESET</code>)</li>
<li><code>-w 5</code> — wait up to 5 seconds for a response</li>
<li><code>-r</code> — receive-only mode: print all incoming messages without sending anything</li>
</ul>
<p>The <code>-r</code> flag is important when another process already owns the serial port. You cannot send commands through a TCP bridge — only read what the receiver is already outputting autonomously.</p>
</section>
<section id="str2str" class="level3">
<h3 class="anchored" data-anchor-id="str2str">str2str</h3>
<p><code>str2str</code> is part of the <strong>RTKLIB</strong> suite, a well-established open-source library and toolset for GNSS data processing. <code>str2str</code> is a stream relay utility: it reads from one data source and writes to one or more destinations simultaneously, with optional bidirectional forwarding.</p>
<p>It understands several stream types:</p>
<ul>
<li><code>serial://device:baud</code> — serial port (note: no <code>/dev/</code> prefix — RTKLIB prepends it automatically on Linux)</li>
<li><code>ntrip://user:pass@host:port/mountpoint</code> — NTRIP client (downloads RTCM corrections)</li>
<li><code>tcpsvr://:port</code> — TCP server (other tools connect to this port to read the stream)</li>
<li><code>tcpcli://host:port</code> — TCP client</li>
</ul>
<p>The <code>-b N</code> flag enables <strong>back-feeding</strong>: it reads NMEA sentences from output stream N and forwards them back to the input stream. This is how the rover’s position (in NMEA GGA format) reaches the NTRIP server for VRS computation.</p>
</section>
<section id="socat" class="level3">
<h3 class="anchored" data-anchor-id="socat">socat</h3>
<p><code>socat</code> (SOcket CAT) is a general-purpose bidirectional byte relay. It connects two endpoints of almost any type — TCP sockets, serial ports, files, pipes, PTYs — and relays data between them.</p>
<p>In this setup, <code>str2str</code> exposes the receiver’s output on a TCP port. <code>ubxtool</code> only knows how to talk to serial ports. <code>socat</code> bridges the gap by creating a <strong>PTY</strong> (pseudo-terminal, i.e., a virtual serial port) backed by the TCP connection. <code>ubxtool</code> opens the PTY as if it were a real serial device.</p>
<hr>
</section>
</section>
<section id="step-by-step-setup" class="level2">
<h2 class="anchored" data-anchor-id="step-by-step-setup">Step-by-Step Setup</h2>
<section id="step-0-install-dependencies" class="level3">
<h3 class="anchored" data-anchor-id="step-0-install-dependencies">Step 0: Install dependencies</h3>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb4" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb4-1"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">sudo</span> apt install rtklib socat gpsd-clients</span></code></pre></div></div>
<p>Check that your user can access the serial device. The ZED-F9P’s CDC-ACM interface belongs to the <code>dialout</code> group:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb5" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb5-1"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">ls</span> <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-la</span> /dev/ttyACM0</span>
<span id="cb5-2"><span class="co" style="color: #5E5E5E;
background-color: null;
font-style: inherit;"># crw-rw---- 1 root dialout 166, 0 May  3 10:14 /dev/ttyACM0</span></span></code></pre></div></div>
<p>Check your group membership:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb6" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb6-1"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">groups</span> <span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">$USER</span></span></code></pre></div></div>
<p>If <code>dialout</code> is not listed, add yourself and re-login:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb7" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb7-1"><span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">sudo</span> usermod <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-aG</span> dialout <span class="va" style="color: #111111;
background-color: null;
font-style: inherit;">$USER</span></span>
<span id="cb7-2"><span class="co" style="color: #5E5E5E;
background-color: null;
font-style: inherit;"># Log out and back in, or run: newgrp dialout</span></span></code></pre></div></div>
</section>
<section id="step-1-verify-the-receiver-works" class="level3">
<h3 class="anchored" data-anchor-id="step-1-verify-the-receiver-works">Step 1: Verify the receiver works</h3>
<p>Before touching any RTK configuration, confirm the receiver is alive and producing fixes. Start with a factory reset to guarantee a known state:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb8" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb8-1"><span class="ex" style="color: null;
background-color: null;
font-style: inherit;">ubxtool</span> <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-p</span> RESET <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-f</span> /dev/ttyACM0</span></code></pre></div></div>
<p>Give it 10–15 seconds to restart, then poll the navigation fix:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb9" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb9-1"><span class="ex" style="color: null;
background-color: null;
font-style: inherit;">ubxtool</span> <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-p</span> NAV-PVT <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-f</span> /dev/ttyACM0 <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-w</span> 5</span></code></pre></div></div>
<p>The NAV-PVT message is the ZED-F9P’s primary position/velocity/time output. The key fields in the response:</p>
<table class="caption-top table">
<colgroup>
<col style="width: 28%">
<col style="width: 36%">
<col style="width: 36%">
</colgroup>
<thead>
<tr class="header">
<th>Field</th>
<th>Meaning</th>
<th>Example</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><code>fixType</code></td>
<td>Solution type (3 = 3D fix)</td>
<td><code>3</code></td>
</tr>
<tr class="even">
<td><code>carrSoln</code></td>
<td>Carrier solution (0=none, 1=float, 2=fixed)</td>
<td><code>0</code></td>
</tr>
<tr class="odd">
<td><code>numSV</code></td>
<td>Satellites used in solution</td>
<td><code>14</code></td>
</tr>
<tr class="even">
<td><code>lat</code></td>
<td>Latitude × 1e7 (divide by 10,000,000 for degrees)</td>
<td><code>525832100</code> → 52.5832100°</td>
</tr>
<tr class="odd">
<td><code>lon</code></td>
<td>Longitude × 1e7</td>
<td><code>133976400</code> → 13.3976400°</td>
</tr>
<tr class="even">
<td><code>hMSL</code></td>
<td>Height above mean sea level, mm</td>
<td><code>42310</code> → 42.3 m</td>
</tr>
<tr class="odd">
<td><code>hAcc</code></td>
<td>Horizontal accuracy estimate, mm</td>
<td><code>1950</code> → ~2 m</td>
</tr>
<tr class="even">
<td><code>vAcc</code></td>
<td>Vertical accuracy estimate, mm</td>
<td><code>3100</code> → ~3.1 m</td>
</tr>
</tbody>
</table>
<p>If <code>fixType</code> returns 3 and <code>hAcc</code> is in the range 1000–5000 mm, the receiver is working correctly with a standard GNSS fix. Now you can add RTK.</p>
</section>
<section id="step-2-get-ntrip-corrections-sapos-brandenburg" class="level3">
<h3 class="anchored" data-anchor-id="step-2-get-ntrip-corrections-sapos-brandenburg">Step 2: Get NTRIP corrections — SAPOS Brandenburg</h3>
<p>SAPOS (Satellitenpositionierungsdienst der deutschen Landesvermessung) is Germany’s national network of GNSS reference stations, operated by the state survey offices. Brandenburg’s service covers Berlin, Brandenburg, and approximately 100 km beyond the state border — sufficient for much of northeastern Germany and parts of Poland and the Czech Republic.</p>
<p>Registration is free, with no service-level agreement and no usage fees:</p>
<pre><code>https://geobasis-bb.de/lgb/de/geodaten/raumbezug-sapos/sapos-anmeldeformular/</code></pre>
<p>You register with your name and email address. Processing takes 1–2 business days. You receive a username and password by email.</p>
<p>Connection parameters for the VRS service:</p>
<table class="caption-top table">
<thead>
<tr class="header">
<th>Parameter</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>Server</td>
<td><code>www.sapos-bb-ntrip.de</code></td>
</tr>
<tr class="even">
<td>Port</td>
<td><code>2101</code></td>
</tr>
<tr class="odd">
<td>Mountpoint</td>
<td><code>VRS_3_4G_BB</code></td>
</tr>
<tr class="even">
<td>Protocol</td>
<td>NTRIP v1/v2</td>
</tr>
<tr class="odd">
<td>Format</td>
<td>RTCM 3.3, MSM4</td>
</tr>
<tr class="even">
<td>Constellations</td>
<td>GPS + GLONASS + Galileo + BeiDou</td>
</tr>
</tbody>
</table>
<p>MSM4 (Multiple Signal Messages, type 4) provides pseudorange and carrier phase measurements for all tracked signals — exactly what the ZED-F9P needs for dual-frequency RTK.</p>
<p>For other German states: the SAPOS portal for each Bundesland provides its own mountpoints and registration. Some states (Bavaria, Baden-Württemberg) charge annual fees; Brandenburg and Berlin are free. International readers should look for their national CORS network — IGS, EUREF, UNAVCO, and similar organisations maintain lists.</p>
</section>
<section id="step-3-configure-autonomous-nav-pvt-output" class="level3">
<h3 class="anchored" data-anchor-id="step-3-configure-autonomous-nav-pvt-output">Step 3: Configure autonomous NAV-PVT output</h3>
<p>By default, the ZED-F9P responds to polls but does not output anything autonomously. To monitor the RTK progression in real time, configure the receiver to emit NAV-PVT messages once per second without being asked:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb11" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb11-1"><span class="ex" style="color: null;
background-color: null;
font-style: inherit;">ubxtool</span> <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-p</span> CFG-MSG,1,7,1 <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-f</span> /dev/ttyACM0 <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-w</span> 3</span></code></pre></div></div>
<p>Breaking down the parameters:</p>
<ul>
<li><code>CFG-MSG</code> — the UBX message class for output rate configuration</li>
<li><code>1</code> — message class 0x01 (NAV — navigation messages)</li>
<li><code>7</code> — message ID 0x07 (PVT — position, velocity, time)</li>
<li><code>1</code> — output rate: once per navigation epoch (once per second at 1 Hz, the default update rate)</li>
</ul>
<p>After this, the receiver will autonomously push NAV-PVT frames once per second on the serial port. Once <code>str2str</code> starts, these frames will appear on the TCP port too, so <code>ubxtool -r</code> can see them.</p>
</section>
<section id="step-4-start-str2str-with-rtk-corrections" class="level3">
<h3 class="anchored" data-anchor-id="step-4-start-str2str-with-rtk-corrections">Step 4: Start str2str with RTK corrections</h3>
<p>This is the central command. It connects to SAPOS, feeds the corrections to the receiver, and simultaneously makes the receiver’s output available on a local TCP port:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb12" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb12-1"><span class="ex" style="color: null;
background-color: null;
font-style: inherit;">str2str</span> <span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">\</span></span>
<span id="cb12-2">  <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-in</span>  ntrip://USERNAME:PASSWORD@www.sapos-bb-ntrip.de:2101/VRS_3_4G_BB <span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">\</span></span>
<span id="cb12-3">  <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-out</span> serial://ttyACM0:38400 <span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">\</span></span>
<span id="cb12-4">  <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-out</span> tcpsvr://:9000 <span class="dt" style="color: #AD0000;
background-color: null;
font-style: inherit;">\</span></span>
<span id="cb12-5">  <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-b</span> 1</span></code></pre></div></div>
<p>Replace <code>USERNAME</code> and <code>PASSWORD</code> with your SAPOS credentials.</p>
<p>What each flag does:</p>
<p><strong><code>-in ntrip://...</code></strong> Connects to the SAPOS NTRIP caster as a client and streams RTCM 3.3 correction data. The corrections arrive continuously as long as the connection is open.</p>
<p><strong><code>-out serial://ttyACM0:38400</code></strong> Writes the incoming RTCM stream directly into the ZED-F9P’s serial port. Note the absence of <code>/dev/</code> — RTKLIB on Linux prepends <code>/dev/</code> automatically. If you write <code>serial:///dev/ttyACM0</code>, it will try to open <code>/dev//dev/ttyACM0</code> and fail silently or with a confusing error. The baud rate (38400) must match the receiver’s configured UART rate; the default from factory is 38400.</p>
<p><strong><code>-out tcpsvr://:9000</code></strong> Opens a TCP server on port 9000. Any client that connects to <code>localhost:9000</code> receives everything the ZED-F9P outputs — NMEA sentences, UBX frames, the works. This is the observation point for monitoring tools.</p>
<p><strong><code>-b 1</code></strong> The back-feed flag. It reads NMEA sentences from output stream 1 (the serial port, which is the first <code>-out</code>) and relays them back to the input stream (the NTRIP caster). The VRS server needs your rover’s NMEA GGA sentence to know your approximate position and compute the right virtual reference. Without <code>-b 1</code>, the server either refuses the connection or sends corrections for the wrong location.</p>
<p>Leave this command running. It is the active connection; killing it drops the correction stream and the ZED-F9P reverts to a standard 3D fix within seconds.</p>
</section>
<section id="step-5-parallel-monitoring-while-str2str-runs" class="level3">
<h3 class="anchored" data-anchor-id="step-5-parallel-monitoring-while-str2str-runs">Step 5: Parallel monitoring while str2str runs</h3>
<p><code>str2str</code> now exclusively owns <code>/dev/ttyACM0</code>. Any other tool that tries to open that device directly will get a “device or resource busy” error. The TCP port on 9000 is the solution.</p>
<p>Create a virtual serial port (PTY) bridged to the TCP stream:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb13" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb13-1"><span class="ex" style="color: null;
background-color: null;
font-style: inherit;">socat</span> PTY,link=/tmp/gps_pty,raw,echo=0 TCP:localhost:9000 <span class="kw" style="color: #003B4F;
background-color: null;
font-weight: bold;
font-style: inherit;">&amp;</span></span></code></pre></div></div>
<ul>
<li><code>PTY,link=/tmp/gps_pty</code> — creates a PTY and symlinks it at <code>/tmp/gps_pty</code></li>
<li><code>raw,echo=0</code> — disables line processing and echo (essential for binary protocols)</li>
<li><code>TCP:localhost:9000</code> — connects to <code>str2str</code>’s output server</li>
</ul>
<p>Now open the virtual port with <code>ubxtool</code> in receive-only mode:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb14" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb14-1"><span class="ex" style="color: null;
background-color: null;
font-style: inherit;">ubxtool</span> <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-r</span> <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-f</span> /tmp/gps_pty <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-w</span> 30</span></code></pre></div></div>
<p>The <code>-r</code> flag is critical here. You are reading through a TCP bridge; the receiver is not on the other end in the normal sense. Sending UBX commands into this pipe would confuse <code>str2str</code> and accomplish nothing. Use <code>-r</code> to listen only.</p>
<p>You will see a continuous stream of NAV-PVT frames (and other messages) scrolling by. Watch the <code>fixType</code>, <code>carrSoln</code>, and <code>hAcc</code> fields as the RTK engine works.</p>
</section>
<section id="step-6-verify-rtk-fixed" class="level3">
<h3 class="anchored" data-anchor-id="step-6-verify-rtk-fixed">Step 6: Verify RTK Fixed</h3>
<p>Filter for the most relevant fields:</p>
<div class="code-copy-outer-scaffold"><div class="sourceCode" id="cb15" style="background: #f1f3f5;"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb15-1"><span class="ex" style="color: null;
background-color: null;
font-style: inherit;">ubxtool</span> <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-r</span> <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-f</span> /tmp/gps_pty <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-w</span> 60 <span class="dv" style="color: #AD0000;
background-color: null;
font-style: inherit;">2</span><span class="op" style="color: #5E5E5E;
background-color: null;
font-style: inherit;">&gt;&amp;</span><span class="dv" style="color: #AD0000;
background-color: null;
font-style: inherit;">1</span> <span class="kw" style="color: #003B4F;
background-color: null;
font-weight: bold;
font-style: inherit;">|</span> <span class="fu" style="color: #4758AB;
background-color: null;
font-style: inherit;">grep</span> <span class="at" style="color: #657422;
background-color: null;
font-style: inherit;">-E</span> <span class="st" style="color: #20794D;
background-color: null;
font-style: inherit;">"fixType|carrSoln|hAcc"</span></span></code></pre></div></div>
<p>The progression you are looking for:</p>
<pre><code>fixType 3  carrSoln 0  hAcc 1950   ← standard 3D fix, ~2 m, no corrections yet
fixType 3  carrSoln 0  hAcc 1820   ← corrections received but not yet applied
fixType 4  carrSoln 1  hAcc 430    ← RTK Float: corrections active, ~0.5 m
fixType 4  carrSoln 1  hAcc 310    ← Float improving as more epochs accumulate
fixType 4  carrSoln 2  hAcc 12     ← RTK Fixed: integer ambiguity resolved, ~1 cm</code></pre>
<p>In open sky with good satellite geometry (PDOP &lt; 2.5, 12+ satellites on both L1 and L2), the ZED-F9P typically reaches Fixed within 30–90 seconds of receiving the first corrections. The dual-frequency widelane combination dramatically accelerates the integer resolution compared to older L1-only receivers.</p>
<p>Once Fixed, the <code>hAcc</code> value of 10–20 mm is not merely a statistical estimate — it reflects a true centimetre-level position measurement. The receiver’s RTK engine is now tracking carrier phase coherently across all visible satellites, and any small displacement of the antenna is immediately visible in the solution.</p>
<hr>
</section>
</section>
<section id="why-this-matters-for-timing-applications" class="level2">
<h2 class="anchored" data-anchor-id="why-this-matters-for-timing-applications">Why This Matters for Timing Applications</h2>
<p>The ZED-F9P’s PPS (Pulse Per Second) output is accurate to under 20 ns RMS relative to GNSS system time, even with a standard 3D fix. For comparison, the timing jitter of a typical quartz oscillator over one second is orders of magnitude larger.</p>
<p>For a GNSS-disciplined oscillator project — where the PPS signal disciplines a TCXO via a DAC — two aspects of RTK are directly relevant:</p>
<p>First, position stability. A standard GNSS fix wanders by metres over time as satellites rise and set and atmospheric conditions change. This wandering does not directly affect the PPS timing — the receiver’s timing mode locks to the satellite clock independently of the position solution. However, a stable position solution means the receiver’s internal models (troposphere correction, satellite selection) are operating on solid ground. RTK Fixed provides a position that is stable to centimetres over hours.</p>
<p>Second, the disciplining loop itself. If the oscillator project ever uses position as part of its model (for instance, computing the expected Doppler from a known location), centimetre-level position accuracy eliminates one more source of modelling error.</p>
<p>For most disciplined-oscillator applications, the RTK Fixed state is not strictly necessary — but it is instructive to achieve it, because it proves the full signal chain is working: antenna, cable, receiver, correction stream, and software stack.</p>
<hr>
</section>
<section id="troubleshooting" class="level2">
<h2 class="anchored" data-anchor-id="troubleshooting">Troubleshooting</h2>
<p><strong><code>stream server start error</code> when starting str2str</strong> Port 9000 is already in use. Either a previous <code>str2str</code> instance is still running, or another service has claimed the port. Check with <code>ss -tlnp | grep 9000</code> and kill the occupying process, or change the port to 9001.</p>
<p><strong><code>serial:///dev/ttyACM0</code> vs <code>serial://ttyACM0</code></strong> RTKLIB prepends <code>/dev/</code> to serial port names on Linux. The correct form is <code>serial://ttyACM0:38400</code>, not <code>serial:///dev/ttyACM0:38400</code>. The latter produces a doubled path and either fails silently or throws a permissions error on a nonexistent path.</p>
<p><strong>ubxtool returns no data when reading via the TCP/PTY bridge</strong> You need the <code>-r</code> flag: <code>ubxtool -r -f /tmp/gps_pty -w 30</code>. Without <code>-r</code>, ubxtool sends a poll request into the PTY, which goes nowhere useful. The receiver must be configured to output NAV-PVT autonomously (Step 3) for <code>-r</code> to see anything.</p>
<p><strong>RTK Float never becomes Fixed</strong> Several possible causes: - <strong>Sky obstruction</strong>: Trees, buildings, or a roof directly above the antenna block L2 signals, which are weaker and more easily attenuated than L1. Move to a location with a clear view from horizon to horizon. - <strong>NTRIP connection dropped</strong>: Check <code>str2str</code> output — if the NTRIP stream disconnects and reconnects, the RTK engine may restart the ambiguity resolution process. A flaky internet connection causes this. - <strong>Wrong mountpoint</strong>: Some NTRIP servers have mountpoints for different constellations or message formats. Ensure <code>VRS_3_4G_BB</code> (or your regional equivalent) provides MSM4 or MSM7 messages for all constellations your receiver tracks. - <strong>Patience</strong>: In difficult conditions — partial sky cover, PDOP &gt; 3 — convergence to Fixed can take 3–5 minutes or never arrive. If <code>hAcc</code> in Float mode has been stable at 30–50 cm for more than 5 minutes, the geometry is not good enough for a fix at this location.</p>
<p><strong>Permission denied on <code>/dev/ttyACM0</code></strong> Your user is not in the <code>dialout</code> group. Run <code>sudo usermod -aG dialout $USER</code>, then log out and back in completely (closing and reopening a terminal is not enough — you need a full session restart, or run <code>newgrp dialout</code> in the affected shell).</p>
<p><strong>The receiver does not appear at <code>/dev/ttyACM0</code> after plugging in</strong> Run <code>dmesg | tail -20</code> immediately after plugging in. You should see lines like <code>cdc_acm 1-1:1.0: ttyACM0: USB ACM device</code>. If nothing appears, try a different USB cable (the ZED-F9P requires data lines, not a charge-only cable) or a different USB port. The <code>cdc_acm</code> module should be present in any standard Linux kernel; confirm with <code>lsmod | grep cdc_acm</code>.</p>
<hr>
<p><em>Written in the context of the OpenOrbitSync project — an open-hardware GNSS-disciplined TCXO using the Raspberry Pi CM4, a u-blox ZED-F9P, and a 16-bit DAC. The ZED-F9P serves as both the timing reference (PPS) and, in this experimental configuration, a precision positioning reference for evaluating the full GNSS signal chain.</em></p>


</section>
</section>

<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>technic</category>
  <category>gnss</category>
  <guid>https://blog.radio-science-institute.eu/posts/2026/05/03-rtk-with-ublox-zed-f9p/</guid>
  <pubDate>Sun, 03 May 2026 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2026/05/03-rtk-with-ublox-zed-f9p/images/img1.png" medium="image" type="image/png" height="95" width="144"/>
</item>
<item>
  <title>Determining the Beamwidth of a 60-cm Parabolic Antenna</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/11/05-oeffnungswinkel/</link>
  <description><![CDATA[ 





<section id="determining-the-beamwidth-of-a-60-cm-parabolic-antenna-by-solar-transit-on-3-november-2025" class="level1">
<h1>Determining the Beamwidth of a 60-cm Parabolic Antenna by Solar Transit on 3 November 2025</h1>
<p>The 3-dB beamwidth (half-power beam width, HPBW) is a key parameter in radio astronomy as it determines the angular resolution of a radio telescope. It describes the angular range within which the received power rises to more than half its maximum value. The smaller the beamwidth, the higher the angular resolution of the antenna.</p>
<p>Setup and measurement method</p>
<p>On 3 November 2025, the solar transit was measured with a 60-cm parabolic antenna at two frequencies: - 11.17 GHz using a Ku-band LNB - 19.78 GHz using a Ka-band LNB</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/11/05-oeffnungswinkel/images/bild1.jpg" class="img-fluid figure-img"></p>
<figcaption>LNBs used</figcaption>
</figure>
</div>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/11/05-oeffnungswinkel/images/bild2.jpg" class="img-fluid figure-img"></p>
<figcaption>60-cm dish on an iExos-100 mount</figcaption>
</figure>
</div>
<p>The antenna was installed on a PMC-8 iExos-100 equatorial mount, allowing the beam to drift across the solar position as Earth rotated. The receiver was a total-power detector (radiometer) with a 50 MHz bandwidth filter, whose output signal was recorded as a voltage trace during the transit.</p>
<p>The image shows the two transit curves for 11.17 GHz (blue) and 19.78 GHz (red) overlaid. The moments at which half the total power was reached (−3 dB points) and the maxima of the transit curves are also marked.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/11/05-oeffnungswinkel/images/bild0.jpg" class="img-fluid figure-img"></p>
<figcaption>Transit curves for 11.17 GHz (blue) and 19.78 GHz (red)</figcaption>
</figure>
</div>
<table class="caption-top table">
<thead>
<tr class="header">
<th>Frequency</th>
<th>Transit time (−3 dB)</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>11.17 GHz</td>
<td>0 h 12 min 53 s</td>
</tr>
<tr class="even">
<td>19.78 GHz</td>
<td>0 h 08 min 58 s</td>
</tr>
</tbody>
</table>
<p>Calculating the beamwidth from the drift time</p>
<p>Since the Sun drifts through the antenna beam during the measurement, the beamwidth can be determined directly from the transit duration. Earth rotates at an apparent angular velocity of</p>
<p>ω⊕ = 360° / 23h 56m 4s = 15.041°/h.</p>
<p>For a source at declination δ (on 03.11.2025: δ☉ = −15°) this gives</p>
<p>θ3dB = ω⊕ · t · cos(δ).</p>
<p>Calculation and results</p>
<ol type="1">
<li>Calculation for 11.17 GHz:</li>
</ol>
<p>t = 12.883 min = 0.2147 h θ11 = 15.041 × 0.2147 × cos(15°) = 3.11° After correction for the solar disc diameter (0.54°): θ11,corr = √(3.11² − 0.54²) = 3.06°</p>
<ol start="2" type="1">
<li>Calculation for 19.78 GHz:</li>
</ol>
<p>t = 8.967 min = 0.1494 h θ20 = 15.041 × 0.1494 × cos(15°) = 2.17° θ20,corr = √(2.17² − 0.54²) = 2.10°</p>
<table class="caption-top table">
<thead>
<tr class="header">
<th>Frequency</th>
<th>Transit time</th>
<th>HPBW measured</th>
<th>HPBW corrected</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>11.17 GHz</td>
<td>12 min 53 s</td>
<td>3.11°</td>
<td>3.06° (184′)</td>
</tr>
<tr class="even">
<td>19.78 GHz</td>
<td>8 min 58 s</td>
<td>2.17°</td>
<td>2.10° (126′)</td>
</tr>
</tbody>
</table>
<p>Comparison with theoretical values (aperture efficiency ≈ 55 %)</p>
<p>The theoretical beamwidth of a circular parabolic antenna is given by</p>
<p>θHPBW,th = k · λ / D,</p>
<p>where k depends on the illumination efficiency (aperture efficiency). For an efficiency of approximately 55 % (≈ −12 dB edge taper) the empirical value is k ≈ 1.17 rad = 67.1°.</p>
<p>Calculation:</p>
<table class="caption-top table">
<thead>
<tr class="header">
<th>Frequency</th>
<th>λ (m)</th>
<th>λ/D</th>
<th>Theoretical (°)</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>11.17 GHz</td>
<td>0.0269</td>
<td>0.0448</td>
<td>67.1 × 0.0448 = 3.00°</td>
</tr>
<tr class="even">
<td>19.78 GHz</td>
<td>0.01516</td>
<td>0.0253</td>
<td>67.1 × 0.0253 = 1.70°</td>
</tr>
</tbody>
</table>
<p>Discussion</p>
<p>The measured beamwidths of 3.1° (11 GHz) and 2.1° (19.8 GHz) are close to the theoretical expectations (3° and 1.7° respectively) for a 60-cm antenna with a realistic efficiency of between 50 % and 60 %. The somewhat larger measured value at 19.8 GHz still requires an explanation.</p>


</section>

<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>technic</category>
  <category>radio_astronomy</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/11/05-oeffnungswinkel/</guid>
  <pubDate>Wed, 05 Nov 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/11/05-oeffnungswinkel/images/bild0.jpg" medium="image" type="image/jpeg"/>
</item>
<item>
  <title>The Clarke Belt in the Ku-Band – A Stroll with the Radio Telescope</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/07/26-clarke-guertel/</link>
  <description><![CDATA[ 





<section id="the-clarke-belt-in-the-ku-band-a-stroll-with-the-radio-telescope" class="level1">
<h1>The Clarke Belt in the Ku-Band – A Stroll with the Radio Telescope</h1>
<p>A few weeks ago we carried out a fascinating observation with our 1-metre radio telescope: we scanned the so-called Clarke Belt — that is, the celestial equator populated by geostationary satellites — at a frequency of 11.3 GHz in the Ku-band. To do this we used the motor drive of our AVX mount and swept the sky a total of twelve times from east to west, each pass at a slightly different elevation — directly along the equator, and also a few degrees above and below it.</p>
<p>The receiver was once again our tried-and-tested broadband detector based on the AD8362, which we introduced in our previous article. The recorded data were logged with RadioSkyPipe, then transferred scan by scan into Excel and converted into a composite image using the Conditional Formatting function.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/07/26-clarke-guertel/images/bild1.jpg" class="img-fluid figure-img"></p>
<figcaption>Image of the Clarke Belt with 1-m satellite dish at 11.3 GHz</figcaption>
</figure>
</div>
<p>The geostationary satellites are clearly visible, lined up like beads on a string along the celestial equator. We can also identify at least one geosynchronous satellite — unlike their geostationary counterparts, these maintain a fixed compass direction but regularly change their elevation. They appear to drift up and down along the equator, which is also visible in our images.</p>
<p>But it is not only satellites that can be seen: the trees on the horizon leave a clear signature in the radio image, as do the diffraction rings typical of radio telescopes — a phenomenon most of us are more familiar with from optics. And then there is a curious, rather inconspicuous feature just below the Clarke Belt. We cannot say for certain, but on that day the Moon was unusually close to the celestial equator — could it be the culprit?</p>
<p>We are particularly pleased that this time we not only obtained interesting measurement data but also managed to produce an aesthetically appealing image. We present the results of our observation in several false-colour renderings — so that no one can ever again claim that radio astronomers are incapable of producing beautiful pictures.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/07/26-clarke-guertel/images/bild2.jpg" class="img-fluid figure-img"></p>
<figcaption>Image of the Clarke Belt in various colour palettes</figcaption>
</figure>
</div>
<p>Incidentally, the Clarke Belt takes its name in honour of the British science-fiction author and visionary Arthur C. Clarke. As early as 1945 he published an article describing the idea of placing communication satellites in an orbit above the equator — at precisely the altitude at which their orbital velocity synchronises with Earth’s rotation. This geostationary orbit lies at approximately 35,786 kilometres above the equator. Satellites in this orbit appear stationary when viewed from Earth — ideal for permanent communication links. Clarke’s vision became reality and today forms the backbone of global satellite communications. In his honour, this special zone in the sky was later named the Clarke Belt.</p>


</section>

<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>technic</category>
  <category>radio_astronomy</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/07/26-clarke-guertel/</guid>
  <pubDate>Sat, 26 Jul 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/07/26-clarke-guertel/images/bild1.jpg" medium="image" type="image/jpeg"/>
</item>
<item>
  <title>Radio Astronomy of the Moon with Simple Means</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/06/02-moon/</link>
  <description><![CDATA[ 





<section id="observing-the-moon-with-a-modified-satellite-dish" class="level1">
<h1>Observing the Moon with a Modified Satellite Dish</h1>
<p>The Moon is one of the most prominent objects in the night sky — not only in visible light but also in the radio domain. This property makes it a rewarding target for amateur radio astronomy, since its radiation characteristics can be measured with simple equipment. A TV satellite dish of one metre in diameter is sufficient to address a range of interesting questions experimentally, including measurement of the surface temperature, investigation of the thermal properties of the regolith, and the influence of Earth’s atmosphere on radio waves.</p>
<p>The thermal radiation of the Moon is not a reflection of sunlight as observed in the optical domain, but so-called blackbody radiation. It originates from the heat stored in the lunar soil, which warms under solar irradiation during the day and cools again at night. This thermal radiation falls in the infrared and radio ranges. Its intensity and spectral peak depend directly on the surface temperature. The peak lies at temperatures around freezing point in the mid-infrared, but even at frequencies in the range of 12 to 22 gigahertz it remains strong enough to be detected with amateur equipment.</p>
<p>For the observations, a satellite dish with a diameter of one metre was used. The mount was a Celestron AVX equatorial mount, enabling precise tracking along the Moon’s apparent path across the sky. The receiving units — known as LNBs — came from professional satellite technology: in the Ku-band (12.25 to 12.75 GHz) a NORSAT 1000XB was used, and in the Ka-band (21.2 to 22.2 GHz) a NORSAT 9000LDF. Both were powered via a bias tee.</p>
<p>The following image was recorded with our new ASTW receiver — a broadband detector based on the AD8362, an ADS1118 ADC, and an Arduino — for which we published a build guide in a previous article. The signal of the Moon was recorded in the 22 GHz band. Not only is the Moon’s signal clearly visible. It is also apparent that the sky towards the west becomes “brighter”, i.e.&nbsp;shows more background noise — an indication that at 22 GHz atmospheric factors are increasingly influencing observations.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/02-moon/images/Bild1.jpg" class="img-fluid figure-img"></p>
<figcaption>Image of the Moon with 1-m satellite dish at 22 GHz</figcaption>
</figure>
</div>
<p>To produce this image, 12 scans were performed above, along, and below the Moon’s apparent path. The recorded data were exported to an Excel spreadsheet, consolidated in a single table, and visualised using the Conditional Formatting function, converting the raw signal values into a recognisable image. After the image was created, the transitions between individual “pixels” were smoothed with a Gaussian blur filter to improve visual clarity.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/02-moon/images/Bild2.jpg" class="img-fluid figure-img"></p>
<figcaption>Scan curves of the Moon at 22 GHz</figcaption>
</figure>
</div>
<p>In a second step we wanted to learn more about the Moon’s properties. To improve the comparability of measurements, we switched to an SDRplay RSP1B as receiver, recording signals using SDR-UNO software together with a plugin called “SDRUnoPluginUDS” into Radio-SkyPipe. The bandwidth was approximately 200 kHz. The transit curves with the SDRplay are considerably noisier than those from the AD8362 due to the narrower bandwidth, but comparability between multiple measurements is significantly easier with this method for various reasons.</p>
<p>Before the actual observations began, the system was calibrated using the so-called hot-cold method: the radio telescope was alternately pointed at the cold sky (approximately 2.7 Kelvin) and at an object of known temperature — in this case a building wall (approximately 273 Kelvin). From the ratio of the two readings the system temperature can be determined, which is a measure of the total noise of the receiving system. For the 12 GHz system this yielded approximately 147 Kelvin; for the 22 GHz system approximately 185 Kelvin.</p>
<p>The actual observations took place over several days in September 2024 on the grounds of Archenhold Observatory in Berlin. In addition to the full Moon on 17 September, measurements were also taken on subsequent days through to 21 September. The 19th of September was particularly well-suited, as transit observations could be carried out in both the Ku- and Ka-bands on that day. In a transit observation the antenna is fixed on a point while the Moon drifts through the antenna beam. From the characteristic signal rise both the beamwidth and the radiation temperature of the source can be determined.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/02-moon/images/Bild3.jpg" class="img-fluid figure-img"></p>
<figcaption>Transit of the Moon at 12 GHz on 19 September 2024</figcaption>
</figure>
</div>
<p>In the Ku-band the beamwidth was approximately 1.72 degrees. The measured signal rise during the Moon’s transit on 19 September 2024 was 0.45 decibels. Taking into account the system temperature and the fraction of the antenna beam actually covered by the Moon, this yields an effective radiation temperature of the Moon of approximately 193 Kelvin, corresponding to about −80 degrees Celsius. In the Ka-band the beam was narrower at 1.25 degrees and the signal rise larger at 0.55 decibels. Nevertheless, the calculations yielded a lower lunar temperature of approximately 153 Kelvin, or around −120 degrees Celsius.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/02-moon/images/Bild4.jpg" class="img-fluid figure-img"></p>
<figcaption>Transit of the Moon at 22 GHz on 19 September 2024</figcaption>
</figure>
</div>
<p>This discrepancy can possibly be explained by atmospheric attenuation. Water vapour in Earth’s atmosphere plays a particularly significant role at 22 gigahertz, where a strong absorption line of the water molecule exists that attenuates part of the radiation arriving from the Moon. Since the Ka-band measurement was taken at a lower elevation — meaning the beam had to pass through a longer column of air — greater attenuation is expected. The difference of approximately 40 Kelvin corresponds to an attenuation of about 0.13 decibels, which agrees well with values for atmospheric attenuation at this frequency reported in the literature.</p>
<p>A notable effect was observed when comparing results across several days. While the highest signal rise in the Ka-band was not measured on the day of the full Moon but two days later, the radiation subsequently declined only slowly. This time delay can be explained by the thermal inertia of the regolith. The lunar surface does not release absorbed heat immediately. The deeper the layer sampled by radio waves, the more slowly it responds to changes in solar irradiation. At lower frequencies the radiation penetrates deeper into the ground, so the measured temperature fluctuates less strongly between day and night.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/02-moon/images/Bild5.jpg" class="img-fluid figure-img"></p>
<figcaption>Moon transits on 17, 18, 20, and 21 September 2024 at 22 GHz</figcaption>
</figure>
</div>
<p>A control measurement taken during a waxing half-moon in January 2025 confirmed this observation. With a comparable configuration, a significantly lower effective lunar temperature was obtained, as at that phase neither the night nor the day side of the Moon had yet reached their extreme temperatures. This again made clear how strongly the combination of lunar phase, frequency, atmospheric conditions, and elevation can influence measurement results.</p>
<p>The Moon is therefore far from a dull subject for radio astronomy. It is an excellent object for testing one’s radio telescope, determining its sensitivity and resolution, and simultaneously observing fundamental astronomical phenomena. This observing campaign shows that with simple equipment and a degree of patience, both physical and atmospheric effects can be traced — and that the Moon remains a fascinating subject of investigation even for amateur astronomers.</p>


</section>

<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>technic</category>
  <category>radio_astronomy</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/06/02-moon/</guid>
  <pubDate>Wed, 02 Jul 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/06/02-moon/images/Bild1.jpg" medium="image" type="image/jpeg"/>
</item>
<item>
  <title>Listening to the Milky Way – with a Satellite Dish</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/</link>
  <description><![CDATA[ 





<section id="observing-the-milky-way-with-a-modified-satellite-dish" class="level1">
<h1>Observing the Milky Way with a Modified Satellite Dish</h1>
<p>With the simplest of means and a budget of under €200, it is now possible to practise radio astronomy yourself and make the Milky Way visible — even in the middle of a large city like Berlin. As part of our project we have shown that a modified satellite dish, a low-noise preamplifier, and an inexpensive SDR receiver are sufficient to obtain surprisingly detailed data about our galaxy. The required technology is now within reach of anyone, and the analysis can be carried out with freely available software even without programming knowledge.</p>
<p>Our starting point was a standard 1-metre satellite dish of the kind used for television reception. We combined it with a dedicated receive feed for 1420 MHz, a Sawbird H1 preamplifier, and a Nooelec NESDR SMArTee SDR receiver.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/images/bild1.jpg" class="img-fluid figure-img"></p>
<figcaption>Our receiving setup using a modified 1-metre satellite dish</figcaption>
</figure>
</div>
<p>Even with this configuration we were able to receive clear signals from the 21-centimetre hydrogen line — the characteristic radio wavelength emitted by neutral hydrogen, the most abundant element in the universe. Despite the electromagnetic interference sources typical of a large city, the galactic hydrogen spectra were clearly visible after just a few seconds of integration time. The signal rise in the narrow hydrogen line band was up to 1.3 dB above the noise floor.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/images/bild2.jpg" class="img-fluid figure-img"></p>
<figcaption>Spectra of galactic hydrogen clouds with the 1-metre satellite dish. Dynamic averaging in SDR#/IF Average of 10,000 samples each (integration time per spectrum approximately 10 seconds).</figcaption>
</figure>
</div>
<p>To increase the resolution of our measurements further, we deployed a 1.8-metre C-band satellite dish of the type used for television reception in Africa and Asia. These are available at low cost from Chinese suppliers and, despite their simpler build quality, are perfectly adequate for radio astronomy experiments. The rest of the receiving equipment remained unchanged. Instead of a complex motorised mount, we used Earth’s rotation to perform meridian transits: the antenna was pointed south and celestial objects drifted automatically through its field of view.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/images/bild3.jpg" class="img-fluid figure-img"></p>
<figcaption>Top: Radio map of the sky over Berlin-Treptow (cylindrical projection) showing the Milky Way and Sun in June 2024, recorded with the 1.8-metre dish and the ezRA software. The colours of the Milky Way represent averaged signal strengths; the strongest signals (yellow) reach 0.25 dB above the “cold sky” noise floor (black) at a bandwidth of approximately 1 MHz. The solar signals were reduced to a bandwidth of 40 kHz (i.e.&nbsp;4% of the Milky Way bandwidth) to prevent them from drowning out the galactic emission. Centre: Optical star chart. Bottom: Radio sky overlaid with optical star chart.</figcaption>
</figure>
</div>
<p>For data analysis we used the free open-source software ezRA (“easy Radio Astronomy”), which computes signal curves with just a few clicks and generates radio images of the sky from them. This allowed us to map the Milky Way as a luminous band — even during the day and under cloud cover — something that is impossible in optical astronomy.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/images/bild4.jpg" class="img-fluid figure-img"></p>
<figcaption>Azimuthal projection of the sky towards the summer Milky Way (left) and the winter Milky Way with the Sun (right). The upper point is the celestial north pole; the white area at the bottom represents the portion of sky not observable from the northern hemisphere.</figcaption>
</figure>
</div>
<p>The images produced are based on several dozen sky transits during which we varied the antenna elevation by a few degrees each time. The software combines the data, arranges it along sky coordinates, and produces impressive radio maps. Particularly striking was the brightening in the region of the Cygnus X complex — a vast star-forming region hidden from optical view by dust clouds but clearly prominent in the radio domain.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/images/bild5.jpg" class="img-fluid figure-img"></p>
<figcaption>Mollweide projection of the Milky Way with the galactic equator as the centre line. The dark region on the right represents the portion of the Milky Way not observable from the northern hemisphere.</figcaption>
</figure>
</div>
<p>In addition to the radio images, we were also interested in analysing the motion of hydrogen clouds within the galaxy. Because the spiral arms of the Milky Way move at different velocities relative to our solar system, this manifests as a Doppler shift in the spectra.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/images/bild7.jpg" class="img-fluid figure-img"></p>
<figcaption>VLSR spectrum towards Deneb and comparison with the spiral arms of the Milky Way</figcaption>
</figure>
</div>
<p>Using ezRA we were able to evaluate these shifts and calculate the radial velocities relative to the so-called Local Standard of Rest. This gave us not just a spectrum but also a spatial distribution of the hydrogen clouds — and with it a picture of the spiral structure of our Milky Way.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/images/bild8.jpg" class="img-fluid figure-img"></p>
<figcaption>Distribution of galactic hydrogen in the observed region of sky (northern hemisphere), calculated from the shift of the hydrogen line (Doppler effect). The dark region on the right represents the portion of the Milky Way not observable from the northern hemisphere.</figcaption>
</figure>
</div>
<p>The results of our work demonstrate that radio astronomy is no longer the exclusive domain of professional research. With the simplest of means, a degree of technical understanding, and freely available software, it is possible to gain insights into our galaxy that are not only scientifically interesting but also aesthetically impressive. Our project exemplifies the potential of home-built instrumentation and is an open invitation to follow suit — whether as a hobby, in schools, or at universities.</p>


</section>

<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>technic</category>
  <category>radio_astronomy</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/</guid>
  <pubDate>Sun, 01 Jun 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/06/01-milkyway/images/bild4.jpg" medium="image" type="image/jpeg"/>
</item>
<item>
  <title>Broadband Detector Based on the AD8362</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/05/15-detector1/</link>
  <description><![CDATA[ 





<section id="home-built-broadband-detector-based-on-the-ad8362" class="level1">
<h1>Home-Built Broadband Detector Based on the AD8362</h1>
<p>In radio astronomy there are two fundamentally different approaches to signal processing: analogue and digital. Both have their advantages and disadvantages — particularly for amateur radio astronomers working with limited resources. Digital Signal Processing (DSP) is based on converting analogue input signals into digital data that is then analysed by a processor. This approach is flexible, powerful, and offers many possibilities for post-processing. Software Defined Radios (SDRs) are typical representatives of this class and are growing in popularity compared to analogue processing. While SDRs offer many advantages — high precision, adaptability, and a broad software ecosystem — they have one critical drawback: limited bandwidth. Inexpensive SDRs often process only a few megahertz at a time. Anyone wanting a wider bandwidth must invest considerably in high-end hardware, plus a powerful PC capable of handling the required computations.</p>
<p>This is where simple broadband receivers — such as logarithmic or true-power detectors — come into their own. Their strength is a large usable bandwidth, often several hundred megahertz.</p>
<p>The radiometer equation states that the sensitivity of a radio telescope depends on three factors: system noise temperature, receiver bandwidth, and integration time. For amateur astronomers with small antennas, bandwidth is often the only lever available to increase sensitivity when system noise cannot be further reduced. Greater sensitivity is essential for detecting faint continuum sources such as supernova remnants. By way of comparison: the flux density of the supernova remnant Taurus A in the Ku-band is roughly 100 times lower than that of the Moon, and the Moon’s flux density is again about 100 times lower than the Sun’s. The challenge is enormous — but not impossible.</p>
<p>Two factors work in the amateur radio astronomer’s favour: for the Ku-band, in which TV satellites broadcast, antennas and LNBs can be obtained very cheaply — satellite dishes with LNBs are sometimes given away free online. Modern LNBs in the 11 GHz range also achieve very low noise figures, enabling high sensitivity. Secondly, supernova remnants have a flatter spectral index, meaning their flux density does not fall off as quickly with increasing frequency. With the exception of the Sun and solar system objects, all continuum sources are in principle better observed at lower frequencies (for example in the L-band at 1420 MHz). However, the supernova remnant Taurus A (Crab Nebula, M1) remains detectable even at 11 GHz.</p>
</section>
<section id="the-design-ad8362-ads1115-arduino" class="level1">
<h1>The Design: AD8362 + ADS1115 + Arduino</h1>
<p>To develop the most sensitive possible broadband detector for our radio telescope, we tested various approaches, including logarithmic detectors, true-power detectors, and simple diode detectors. Many of these components are now available cheaply as ready-made plug-in modules online.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/05/15-detector1/images/Bild2.jpg" class="img-fluid figure-img"></p>
<figcaption>The new detector</figcaption>
</figure>
</div>
<p>The best results among the detector boards we tested were achieved with the AD8362. Unlike logarithmic detectors such as the AD8317, which scale the output signal logarithmically and invert it in the process, the AD8362 delivers a linearly scaled, non-inverted signal. It also features an integrated amplifier and can reliably measure input signals in the range of −55 dBm to +5 dBm.</p>
<p>Interestingly, our tests showed that simple diode detectors can in some cases yield even better results — particularly due to their very low self-noise. However, they require external amplification, as they have none of their own. A preceding LNA and a following op-amp are therefore necessary. We also experimented with circuits performing analogue signal processing. Low-pass filters can integrate signals to reduce noise; subtraction and amplifier circuits using op-amps enable offset correction and signal amplification, which increased the resolution and sensitivity of the receiver. For the initial test series, however, we opted for the AD8362 and largely dispensed with analogue signal processing. Integration, offset, and amplification can also be implemented in software via digital signal processing.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/05/15-detector1/images/Bild4.jpg" class="img-fluid figure-img"></p>
<figcaption>Rear of the detector showing the AD8362 antenna input and the Arduino R3 USB interface</figcaption>
</figure>
</div>
<p>Thanks to its integrated amplification, the AD8362 allows a very simple and compact design. This not only reduces susceptibility to interference but also the likelihood of failures — an important advantage for sensitive measurements in radio astronomy. The output signal from the AD8362 is fed directly into a 16-bit ADC (ADS1115) and then sent via an Arduino microcontroller to a PC for digital analysis. Total cost is only around €30.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/05/15-detector1/images/Bild5x.jpg" class="img-fluid figure-img"></p>
<figcaption>Circuit diagram of the detector</figcaption>
</figure>
</div>
<p>The signals are first sampled by the ADS1115; its differential ADC function allows an offset to be set, and the resolution can be controlled via an adjustable sampling range. The samples are then integrated in the Arduino.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/05/15-detector1/images/Bild1.jpg" class="img-fluid figure-img"></p>
<figcaption>The interior of the detector</figcaption>
</figure>
</div>
<p>The detailed technical background and the software will be covered in a follow-up article. The result is a highly sensitive detector at low cost. The results are promising. In a test run, the transit of the Moon was recorded — the signal curve, produced with Radio Sky Pipe, is clear and low in noise.</p>
<div class="quarto-figure quarto-figure-center">
<figure class="figure">
<p><img src="https://blog.radio-science-institute.eu/posts/2025/05/15-detector1/images/Bild3.jpg" class="img-fluid figure-img"></p>
<figcaption>Transit of the Moon on 09 May 2025</figcaption>
</figure>
</div>
<p>This gives hope that even fainter sources such as Taurus A will be detectable with this setup in the future. The broadband detector based on the AD8362 presented here demonstrates that high sensitivity can be achieved with simple means — ideal for anyone wishing to track down faint cosmic radio signals with a small antenna.</p>


</section>

<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>technic</category>
  <category>radio_astronomy</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/05/15-detector1/</guid>
  <pubDate>Thu, 15 May 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/05/15-detector1/images/Bild2.jpg" medium="image" type="image/jpeg"/>
</item>
<item>
  <title>Observing Cygnus A – A First Attempt</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/17-cygnus/</link>
  <description><![CDATA[ 





<p>Observing Cygnus A – A First Attempt</p>
<p>One of our projects last year was to observe the radio galaxy Cygnus A. Until then we had only detected two continuum sources — the Sun and the Moon — so Cygnus A was new territory for us. We used our 180 cm C-band dish with a loop feed for 1420 MHz. The LNA was a Sawbird+ H1, and the receiver a Nooelec NESDR SMArTee. Data recording was handled by ezCOL from the ezRA suite; processing and integration were done in MS Excel. The observations were carried out at Archenhold Observatory. We pointed the antenna at a right ascension of 41° and recorded a total of 19 transits at a frequency of 1425 MHz with a bandwidth of 2 MHz. In the data we could indeed observe a rise in signal level during the expected time window:</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/17-cygnus/images/Bild1.jpg" class="img-fluid"></p>
<p>The transit curves were offset by 4 minutes each day — clear evidence that we were dealing with a signal of extraterrestrial origin. In the individual transit curves the radio signal was only faintly visible, so we stacked the curves and computed the average. With each additional integrated curve the signal became more distinct. The result was a summed curve in which Cygnus A and Cygnus X are clearly distinguishable from one another:</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/17-cygnus/images/Bild2.jpg" class="img-fluid"></p>
<p>The small bump on the left comes from Cygnus A; the main peak represents the combined emission of both sources. Our antenna has a beamwidth of approximately 9° at 1425 MHz. Although Cygnus A and X are only about 4° apart, they can still be identified as separate sources. The reason: Cygnus X is not a point source but an extended star-forming region spanning roughly 10–12°. Although the radio galaxy Cygnus A has a significantly higher radio brightness, the star-forming region Cygnus X contributes substantially to the summed curve thanks to its much larger angular extent. Cygnus X is invisible at optical wavelengths — the true structure of this vast star-forming region only reveals itself through a radio telescope, or an infrared telescope, though the latter can only be operated in space due to atmospheric absorption. Below is a radio image of the region containing Cygnus A and Cygnus X. It is taken from the all-sky survey at 408 MHz and can be downloaded from the SkyView website at https://skyview.gsfc.nasa.gov/</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/17-cygnus/images/Bild3.jpg" class="img-fluid"></p>



<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>technic</category>
  <category>milky_way</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/17-cygnus/</guid>
  <pubDate>Thu, 17 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/17-cygnus/images/Bild2.jpg" medium="image" type="image/jpeg"/>
</item>
<item>
  <title>Spectral Map of the Milky Way at 1420.4 MHz between Canis Major and Sagittarius</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/07-spectralmap/</link>
  <description><![CDATA[ 





<p>Spectral map of the Milky Way at 1420.4 MHz between the constellations Canis Major and Sagittarius.</p>
<p>After observing the galactic anticenter with the 1-metre radio telescope at night, we also observed the section of the Milky Way towards the galactic centre that is visible from the northern hemisphere during winter daytime hours. We combined the observation data and produced a spectral map of the Milky Way as seen from Berlin.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/07-spectralmap/images/Bild1.png" class="img-fluid"></p>
<p>On the left side of the image the brightening of the galactic anticenter is visible; on the right side the broadening caused by the rapid rotation in the central bulge of the Milky Way.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/07-spectralmap/images/Bild2.png" class="img-fluid"></p>
<p>The spectral map was recorded using our 1-metre satellite dish, a full-wavelength loop feed specifically designed for 1420 MHz, a Sawbird H1 LNA, a Nooelec SDR, and SDR# with the IF Ave plugin. The individual spectra were merged, calibrated, and scaled to dB values using H-Line 3D by Alex Pettit. Visualisation was then carried out with the program Surfer.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/07-spectralmap/images/Bild3.png" class="img-fluid"></p>
<p>There are many programs available for visualising elevation data for geographic purposes, of which Surfer is one example. Others include QGIS — all of these are equally suitable for visualisation in radio astronomy. These programs offer various methods for interpolating data into a contour map; we used the minimum curvature method, for instance.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/07-spectralmap/images/Bild4.png" class="img-fluid"></p>
<p>For comparison, a professional spectral map recorded by John M. Dickey using the Green Bank Radio Telescope in the USA in combination with data from the Parkes Radio Telescope in Australia. Source: Dickey, J.M. (2013). Galactic Neutral Hydrogen. In: Oswalt, T.D., Gilmore, G. (eds) Planets, Stars and Stellar Systems. Springer, Dordrecht. https://doi.org/10.1007/978-94-007-5612-0_11 The region we observed is indicated by the box.</p>



<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>milky_way</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/07-spectralmap/</guid>
  <pubDate>Mon, 07 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/07-spectralmap/images/Bild1.png" medium="image" type="image/png" height="138" width="144"/>
</item>
<item>
  <title>Observing the Moon during the Lunar Eclipse of 18 September 2024</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/06-moon/</link>
  <description><![CDATA[ 





<p>On the occasion of the lunar eclipse on 18 September 2024, we observed the full Moon with our mobile 1-metre radio telescope.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-moon/images/Bild14.png" class="img-fluid"></p>
<p>Two different Norsat LNBs were used: the 12 GHz LNB produced no usable results due to interference from geostationary satellites. With the Norsat 9000 LNB for 22 GHz, the Moon was clearly detectable, as this frequency is unaffected by broadcast satellites. The narrower beamwidth of the antenna at this frequency also allows better focus on the Moon as a point source.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-moon/images/Bild13.png" class="img-fluid"></p>
<p>The radio emission at 22 GHz originates from the thermal radiation of the lunar surface rather than reflected sunlight, which makes detection challenging. The successful test demonstrates that our system is sensitive enough to enable future observations of masers in star-forming regions at 22 GHz. Unfortunately, clouds moved in around midnight, preventing continuation of the eclipse observation, which was only a partial eclipse in any case. Since the temperature of the lunar surface barely drops while in Earth’s shadow, it is also not possible to observe a lunar eclipse with an amateur-class radio telescope.</p>



<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>moon</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/06-moon/</guid>
  <pubDate>Sun, 06 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/06-moon/images/Bild12.png" medium="image" type="image/png" height="140" width="144"/>
</item>
<item>
  <title>Orion KL with a Home-Built 1-Metre Radio Telescope</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/06-maser/</link>
  <description><![CDATA[ 





<p>Observing the Water Maser in the Orion KL Nebula with a 1-Metre Radio Telescope</p>
<p>In January 2025, Berlin had exceptionally clear skies for that time of year, with the Moon clearly visible — perfect for using a red-dot finder to precisely point our 1-metre radio telescope at specific sky positions and to polar-align the mount for accurate tracking. It was the ideal moment to attempt something we had never tried before: observing an astrophysical maser in the constellation Orion!</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-maser/images/Bild3.png" class="img-fluid"></p>
<p>Orion KL is a star-forming region within the Orion Nebula that can only be observed in the infrared and radio domains, as dust clouds prevent it from being seen in optical light. What makes it special: this star-forming region naturally produces maser emission — extremely concentrated, bright radiation, much like a laser but in the microwave range. An important emission line is that of water at 22 GHz, and Orion KL radiates strongly in this spectral band.</p>
<p>On our first attempt we saw… absolutely nothing. We had tuned the receiver to the wrong frequency range — lesson learned. But on the second day things got much more exciting! We pointed the parabolic antenna precisely at Orion KL and tracked the Orion Nebula using the AVX mount’s drive. We collected data for one hour, continuously monitoring the position with the red-dot finder to prevent Orion KL from drifting out of the antenna beam. Since the half-power beamwidth (HPBW) of a 1-metre antenna at 22 GHz is only 1 degree, there is little margin for error.</p>
<p>We also took a 20-minute offset measurement approximately 5 degrees above Orion to account for system noise. This offset was subtracted from the primary data in Excel to smooth out SDR-induced spectral distortions. The baseline noise was not perfectly uniform, but the most significant irregularities were removed.</p>
<p>And there it was… a narrow, faint line at around 22.2324 GHz!</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-maser/images/Bild1.png" class="img-fluid"></p>
<p>To verify that this was not merely an artefact, we created a waterfall diagram by grouping sets of 3,000 measurements (6 minutes) into rows using Excel’s conditional formatting. The result? A continuous line running through the entire observation.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-maser/images/Bild2.png" class="img-fluid"></p>
<p>The line appears to drift slightly towards higher frequencies — probably due to local oscillator instability, or possibly due to Earth’s rotation affecting the Doppler shift.</p>
<p>Setup: 1-metre satellite dish on a Celestron AVX mount, Norsat 9000LDF LNB for 22 GHz (Ka-band), SDRplay and SDR Console for frequency tuning, Data acquisition with Radio Sky Spectrograph, Exported and analysed in Excel</p>
<p>Weather and conditions permitting, we intend to repeat the measurement to verify and confirm the result.</p>
<p>More information and a stunning JWST image of the Orion KL Nebula: https://en.wikipedia.org/wiki/Orion_KL</p>



<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>technic</category>
  <category>milky_way</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/06-maser/</guid>
  <pubDate>Sun, 06 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/06-maser/images/Bild2.png" medium="image" type="image/png" height="135" width="144"/>
</item>
<item>
  <title>The Galactic Anticenter with a 1-Metre Radio Telescope</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/06-galaktic-anticenter/</link>
  <description><![CDATA[ 





<p>The Galactic Anticenter with a 1-Metre Radio Telescope</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-galaktic-anticenter/images/Bild11.png" class="img-fluid"></p>
<p>The image shows a radio spectral map of the galactic anticenter. The galactic anticenter can be observed on winter nights from the northern hemisphere and is located in the constellation Auriga.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-galaktic-anticenter/images/Bild13.png" class="img-fluid"></p>
<p>The spectral map reveals three spiral arms of the Milky Way. At the galactic anticenter the spectra overlap due to identical line-of-sight velocities, resulting in a particularly strong signal.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-galaktic-anticenter/images/Bild12.png" class="img-fluid"></p>
<p>The data were recorded on 18 January 2025 during the night at the observatory under heavy cloud cover and fog. Yes — radio telescopes see right through clouds. Through terrestrial clouds as well as interstellar ones. Within 15 minutes, 25 spectra were captured with an integration time of 5 seconds each. Setup: - 1-metre dish - Nooelec SDR - Sawbird H1 LNA - RF Hamdesign Loop Feed - SDR# with IF AVE plugin</p>
<p>The analysis was carried out in Excel (images 2+3). For visualisation we used the program H-Line 3D by US amateur radio astronomer Alex Pettit.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-galaktic-anticenter/images/Bild1.png" class="img-fluid"></p>
<p>For comparison, here is a spectral map from professional radio telescopes (Green Bank in the USA and Parkes in Australia). Source: Dickey, J.M. (2013). Galactic Neutral Hydrogen. In: Oswalt, T.D., Gilmore, G. (eds) Planets, Stars and Stellar Systems. Springer, Dordrecht. https://doi.org/10.1007/978-94-007-5612-0_11 The region we observed is marked by the red box.</p>



<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>milky_way</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/06-galaktic-anticenter/</guid>
  <pubDate>Sun, 06 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/06-galaktic-anticenter/images/Bild11.png" medium="image" type="image/png" height="144" width="144"/>
</item>
<item>
  <title>The Milky Way and the Sun at 1420 MHz</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/06-milkyway/</link>
  <description><![CDATA[ 





<p>The image below shows a scan of the entire sky from the horizon to the zenith in the 1420 MHz frequency range.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/06-milkyway/images/bild13.jpg" class="img-fluid"></p>
<p>As part of an HI sky survey, 33 drift scans were carried out in steps of 3 degrees. The setup consisted of a 180 cm C-band satellite dish from China on a manual mount, a loop feed for 1420 MHz, a Nooelec Sawbird H1 LNA, and a Nooelec NESDR SMArTee SDR. Data recording and processing was handled by the ezRA (EasyRadioAstronomy) software. The image was captured at Archenhold Observatory under urban conditions with significant electromagnetic interference. An additional problem was that wind moved the unsteady mount, occasionally causing the antenna to shift its azimuth involuntarily. In short: conditions were poor. ezRA aggressively filters out continuum sources such as the Sun in order to bring out the faint signals of the Milky Way. The continuum sources are, however, present in the raw data. Fainter continuum sources such as Cassiopeia A, Cygnus A, etc. lie in the plane of the Milky Way and are masked by the galactic hydrogen emission at 1420 MHz.</p>
<p>The Sun’s signal is present in the raw data. We applied a trick and reduced the bandwidth of the solar signal to 40 kHz, so that ezRA no longer filters it out. This made the Sun visible in the final processed image. The Sun shines so brightly in the radio domain — ten times brighter than the brightest regions of the Milky Way — that it would otherwise have drowned out the galactic emission entirely. By reducing the solar signal bandwidth to 40 kHz, it appears dimmer and no longer overwhelms the Milky Way.</p>
<p>On the right-hand side the Sun can be seen alongside the Milky Way band. That section of the Milky Way band is only visible during summer daytime and appears less bright, as it represents the outer regions of the Galaxy in the direction opposite to the galactic centre.</p>



<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>technic</category>
  <category>milky_way</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/06-milkyway/</guid>
  <pubDate>Sun, 06 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/06-milkyway/images/bild13.jpg" medium="image" type="image/jpeg"/>
</item>
<item>
  <title>The Sun at Three Wavelengths</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/05-sun/</link>
  <description><![CDATA[ 





<p>The Sun at Three Wavelengths</p>
<p>Software Defined Radios (SDRs) open up possibilities in amateur radio astronomy that would have been unimaginable just a few years ago. SDRs are available from as little as €30, as in the case of the Nooelec Smart SDR. The first radio telescope we built some time ago from an old 1-metre satellite dish is fully mobile and mounted on a Celestron AVX mount. What makes it special is the ability to install different receiving feeds at the focal point and to track objects. Until recently we had feeds for 12 GHz (Ku-band) and 1420 MHz (L-band). We later purchased an additional LNB for 22 GHz (Ka-band) from Norsat. To use it with the dish we had to fabricate a custom feedhorn ourselves. We designed it in a CAD program and had it machined from aluminium at a local metal workshop. In summer 2024 we were able to observe the Sun with it for the first time — and it worked! The images show the 1-metre radio telescope with the three different feeds and the results of a drift scan of the Sun.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/05-sun/images/Bild9.png" class="img-fluid"></p>
<p>At 1420 MHz (loop feed with Sawbird H1) the time between the half-power points is approximately 60 minutes for the 1-metre dish. In mid-August the Sun was at a declination of 13°, giving a correction factor of cos(13°) = 0.97. The half-power beamwidth is therefore 1 × 15 × 0.97 = 14.55 degrees.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/05-sun/images/Bild10.png" class="img-fluid"></p>
<p>At 12 GHz the transit time is approximately 8 minutes, yielding a beamwidth of 1.9 degrees.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/05-sun/images/Bild11.png" class="img-fluid"></p>
<p>At 22 GHz the transit time was approximately 5 minutes, giving a beamwidth of about 1.2 degrees.</p>
<p>It is clearly evident that the beamwidth depends on the observing frequency for a given dish aperture: the higher the frequency (i.e.&nbsp;the shorter the wavelength), the narrower the beam and the better the angular resolution of the radio telescope. While at higher frequencies (11 and 22 GHz) the Sun’s thermal emission dominates, a significant fraction of its radio emission at 1420 MHz is non-thermal in origin, produced by electrons spiralling through strong magnetic fields in the solar atmosphere.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/05-sun/images/Bild12.png" class="img-fluid"></p>
<p>This image shows a scan of the Sun at 1420 MHz, obtained with the same receiving equipment during a sky survey to map neutral hydrogen in the Galaxy.</p>



<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>technic</category>
  <category>sun</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/05-sun/</guid>
  <pubDate>Sat, 05 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/05-sun/images/Bild12.png" medium="image" type="image/png" height="137" width="144"/>
</item>
<item>
  <title>Observing the Sun with a Simple SAT Finder</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/05-sat-finder/</link>
  <description><![CDATA[ 





<section id="observing-the-sun-with-a-simple-sat-finder" class="level1">
<h1>Observing the Sun with a Simple SAT Finder</h1>
<p>The Sun is not only the brightest object in the sky in visible light, but also the strongest natural source of radiation in the radio domain. At higher frequencies, the Sun’s thermal emission dominates, while at lower frequencies synchrotron radiation prevails, generated by electrons moving through strong magnetic fields.</p>
<section id="what-is-thermal-radiation" class="level2">
<h2 class="anchored" data-anchor-id="what-is-thermal-radiation">What is thermal radiation?</h2>
<p>Thermal radiation is heat radiation emitted by every body with a temperature above 0 Kelvin. The intensity and the peak wavelength of the radiation depend on temperature. The Sun has a surface temperature of approximately 6000 K, which places its radiation maximum in the visible range. Nevertheless, it also emits thermal radiation in the infrared and radio domains, albeit at lower intensity.</p>
<p>A straightforward way to observe the Sun’s thermal radiation yourself is to use a standard satellite dish with an off-the-shelf LNB (frequency range 11–12 GHz). These can be acquired cheaply second-hand or sometimes even obtained for free. We used a prime-focus TV satellite dish from Technisat with a diameter of 1 metre, a standard Ku-band LNB (Invacom flange LNB SNF 031), and a SAT finder. The LNB is normally powered through the TV receiver via the coaxial cable (12–18 V). This power supply must now be injected into the coaxial cable independently. For the first experiment it was convenient that the SAT finder came with its own battery compartment (see image). Alternatively, any 12-volt DC source (e.g.&nbsp;a car battery, lead-acid accumulator, a powerbank with a 12 V output, or a mains power supply) can be used, injecting the power into the coaxial cable via a bias tee. The LNB is mounted on the satellite dish and connected to the SAT finder and the power source via coaxial cable. When the dish is pointed at the Sun or another object, the SAT finder displays a signal strength reading. To confirm that the Sun rather than a geostationary satellite is being detected, the movement of the signal can be monitored — the Sun drifts through the antenna’s field of view and the signal decreases over time.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/05-sat-finder/images/Bild7.png" class="img-fluid"></p>
<p>To record the data, the output signal of the SAT finder can be digitised using an analogue-to-digital converter (we initially used a LabJack U3) and displayed on a PC. The free software Radio SkyPipe enables graphical analysis of the measurements. Using a so-called drift scan, the movement of the Sun through the antenna’s field of view can be observed, producing a Gaussian bell curve whose half-power beamwidth determines the angular resolution of the radio telescope. In our experiment with a 1-metre dish, a resolution of approximately 1.7° was obtained.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/05-sat-finder/images/Bild8.png" class="img-fluid"></p>
<p>This simple experiment is an excellent introduction to radio astronomy. Using a standard satellite dish and a SAT finder, the thermal radiation of the Sun can be readily detected and measured. At the same time, a transit measurement of the Sun — via the half-power beamwidth — allows the antenna’s beam pattern and angular resolution to be determined.</p>


</section>
</section>

<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>technic</category>
  <category>sun</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/05-sat-finder/</guid>
  <pubDate>Sat, 05 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/05-sat-finder/images/Bild6.png" medium="image" type="image/png" height="94" width="144"/>
</item>
<item>
  <title>Observing the Moon with the Logarithmic Detector AD8313</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/04-ad8313/</link>
  <description><![CDATA[ 





<section id="observing-the-moon-with-the-logarithmic-detector-ad8313" class="level1">
<h1>Observing the Moon with the Logarithmic Detector AD8313</h1>
<p>On 28 January 2024, shortly after midnight (23:06 UTC), we succeeded in recording the waning Moon at approximately 11 GHz from a field outside Berlin, using a 1-metre satellite dish, the Invacom LNB, a logarithmic detector (AD8313) connected to an analog-to-digital converter (LabJack U3) and a PC running Radio Sky Pipe. Several transit measurements were carried out that night, and the Moon was clearly identifiable in every one.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/04-ad8313/images/Bild5.png" class="img-fluid"></p>
<p>The diagram shows a parabolic curve representing the radio emission of the Moon at approximately 11 GHz. The Moon drifted into the field of view of my antenna, causing the signal to rise to a maximum, then drifted back out again. The Moon’s radio emission at 11 GHz is thermal radiation — it does not arise from the reflection of sunlight as in the optical domain, but from the thermal glow of the warm lunar surface. Although this radiation is very weak and the result demonstrates the high sensitivity of the system, the Moon is a relatively straightforward object at 11 GHz. Even with a small satellite dish, the Moon should be detectable without difficulty, provided a good LNB and a sensitive receiver are used.</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/04-ad8313/images/Bild4.jpg" class="img-fluid"></p>
<p>One of the characteristics of the logarithmic detector is its very wide bandwidth. For continuum sources such as the Moon, this means that a larger amount of radiation is measured, making it possible to detect potentially weaker signals. On the other hand, the wide bandwidth also means that a large number of interference sources are picked up. On the evening in question, strong interference occurred regularly during every lunar measurement. The initial suspicion that it was caused by unwanted emissions from a mobile phone fed in via the cables proved to be incorrect — the interference persisted even when the phone was switched off. Could it have been signals from radio amateurs using the Moon as a communication relay (EME)? Or interference from satellites (the Starlink constellation also transmits in the 11 GHz band)? Or environmental interference? But why did it occur precisely whenever the Moon passed through the antenna’s field of view? No answer could be found. The logarithmic detector does not allow filtering by individual frequencies, which makes analysis difficult. To analyse or suppress such interference, one would need either analogue narrow-band filters or a software-defined radio (SDR) as the receiver, enabling digital signal filtering.</p>


</section>

<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>technic</category>
  <category>moon</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/04-ad8313/</guid>
  <pubDate>Fri, 04 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/04-ad8313/images/Bild4.jpg" medium="image" type="image/jpeg"/>
</item>
<item>
  <title>Using a Logarithmic Detector for Radio Astronomy</title>
  <dc:creator>Dr. Klaus Henning</dc:creator>
  <link>https://blog.radio-science-institute.eu/posts/2025/04/03-logarithmic-detector/</link>
  <description><![CDATA[ 





<section id="using-a-logarithmic-detector-for-radio-astronomy" class="level1">
<h1>Using a Logarithmic Detector for Radio Astronomy</h1>
<p>Instead of a SAT finder, a logarithmic detector can also be used to detect cosmic radio radiation. Such a detector produces a much more uniform signal than a SAT finder and is therefore also suitable for detecting weaker objects than the Sun, such as the Moon. Logarithmic detectors are currently available as thumb-sized boards at very low cost on the internet. What do these log detectors do? They convert a high-frequency AC input signal into a DC signal whose magnitude depends on the strength of the RF signal, i.e.&nbsp;its amplitude. The special feature of the AD8317 is that the output DC voltage does not increase linearly with rising signal strength, but instead decreases on a logarithmic scale. The output voltage typically ranges between 2 volts for a weak or absent signal and slightly above 0 volts for a very strong signal. The exact figures vary by device (the AD8317 ranges between 0.5 and 1.5 V) and can in some cases be adjusted. More detailed information can be found in the datasheets available online.</p>
<p>The simplest way to use the detector is to connect it directly to an analog-to-digital converter. We have successfully tested both the AD8313 and its successor model AD8317 with a LabJack U3 and an Arduino. To smooth the signal and adapt the sampling range of the ADC, an operational amplifier can be inserted between the logarithmic detector and the analog-to-digital converter. Shown here as an example are a schematic with an AD8317 log detector, an LM358 op-amp, and an Arduino R4, as well as the result of a solar transit on 23 Feb 2025 at 14:20 UTC in Berlin-Treptow (using the 1-metre dish, the Invacom LNB, the AD8317, and RadioSkyPipe as recording software).</p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/03-logarithmic-detector/images/Bild1.jpg" class="img-fluid"></p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/03-logarithmic-detector/images/Bild3.png" class="img-fluid"></p>
<p><img src="https://blog.radio-science-institute.eu/posts/2025/04/03-logarithmic-detector/images/Bild2.jpg" class="img-fluid"></p>


</section>

<a onclick="window.scrollTo(0, 0); return false;" id="quarto-back-to-top"><i class="bi bi-arrow-up"></i> Back to top</a> ]]></description>
  <category>radio_astronomy</category>
  <category>technic</category>
  <guid>https://blog.radio-science-institute.eu/posts/2025/04/03-logarithmic-detector/</guid>
  <pubDate>Thu, 03 Apr 2025 00:00:00 GMT</pubDate>
  <media:content url="https://blog.radio-science-institute.eu/posts/2025/04/03-logarithmic-detector/images/Bild1.jpg" medium="image" type="image/jpeg"/>
</item>
</channel>
</rss>
