Radio Telescope Mode

We were probing the MOT submenu when a command appeared in the help output that didn’t seem to belong in a motor control menu: azscanwxp. The description said something about azimuth scanning with transponders. That turned out to be the most interesting command in the entire firmware.

Finding azscanwxp

The MOT submenu help lists 25 commands. Most are what you’d expect — a for position, g for goto, h for home, e and r for engage/release, PID tuning, velocity control. Then there are two that stand out:

MOT> ?
...
azscan    — AZ sweep with per-position RSSI readings
azscanwxp — AZ sweep with transponder cycling
...

azscan sweeps the azimuth axis while recording signal strength at each position. azscanwxp does the same, but cycles through multiple DVB transponders at each position — so you get signal readings across multiple frequencies at each pointing angle.

This is a radio telescope scan pattern. Move the dish to a position, measure the signal at frequency 1, frequency 2, frequency 3, step to the next position, repeat. The output is a 2D grid of RF power measurements indexed by angle and frequency.

What it does

The command takes four parameters:

azscanwxp [motor] [span] [resolution] [num_xponders]

Parameter	Type	Units	Meaning
motor	int	—	Motor axis (0=AZ, 1=EL)
span	float	degrees	Total sweep range
resolution	int	centidegrees	Step size (100 = 1.00 degree)
num_xponders	int	—	Transponders to cycle per position

So azscanwxp 0 10 100 3 means: sweep 10 degrees on the azimuth axis, stepping 1.00 degree at a time, measuring 3 transponders at each stop. That’s 10 positions with 3 readings each — 30 data points in one sweep.

The output format (from the ADC scan documentation, which uses the same reporting):

Motor:0 Angle:18000 RSSI:523 Lock:0 SNR:0 Scan Delta:100
Motor:0 Angle:18100 RSSI:519 Lock:0 SNR:0 Scan Delta:100
Motor:0 Angle:18200 RSSI:547 Lock:1 SNR:8 Scan Delta:100

Angle in centidegrees, RSSI as a raw ADC count, lock status (0 or 1), SNR in dB when locked, and the step size. Each line is one measurement at one position on one transponder.

Safety: homed motors required

azscanwxp targets motor positions by absolute angle. If the motor axis is uncalibrated (unhomed), the firmware may interpret the position register’s INT_MAX sentinel value (2147483647) as a target angle and attempt to drive the motor there. This deadlocks the firmware shell — the motor task blocks forever, no serial input is processed, and only a hardware power cycle recovers.

Always home both axes before running scan commands: h 0 then h 1 in the MOT submenu.

The connection to winegard-sky-scan

Chris Davidson’s winegard-sky-scan project was already using this. His code automates the G2 over RS-422 to perform azimuth sweeps at multiple elevation angles, collecting RSSI data into grids that can be rendered as sky maps. He was using the Carryout G2 as a radio telescope before we knew the firmware had a dedicated command for it.

Davidson’s approach drives the motors and reads RSSI separately — send a move command, wait for it to complete, query the signal. The azscanwxp command is the firmware doing both in a single coordinated operation: move, measure, advance, measure, advance. Less serial traffic, more precise timing, and the firmware handles the motor-to-measurement synchronization internally.

The signal chain

To understand what RSSI means on the G2, you need to understand the signal path. The dish has a standard Ku-band LNB (Low Noise Block) at the focal point. The LNB does three things:

1. Amplifies the incoming RF signal (10.7-12.75 GHz range) with a low-noise amplifier
2. Downconverts it to an intermediate frequency (950-2150 MHz) by mixing with a local oscillator
3. Sends the IF signal down the coax cable to the BCM4515 tuner on the main board

The BCM4515 DVB-S2 demodulator then:

1. Selects a specific frequency (transponder) from the IF band
2. Demodulates the DVB-S2 signal (carrier tracking, symbol timing, FEC)
3. Reports signal quality metrics: RSSI, SNR, lock status, AGC levels

So when azscanwxp reports RSSI:523, that’s the BCM4515’s measurement of received power at the selected transponder frequency, after the LNB’s amplification and downconversion. It’s not a raw antenna voltage — it’s a processed measurement from a purpose-built signal analysis chip.

RSSI: two flavors

The firmware provides RSSI readings through two different paths, and they have different characteristics:

DVB RSSI (dvb rssi <n>) — reads the BCM4515’s internal signal strength register, averaged over n samples. This is bounded (the command returns after n readings) and gives both average and current values:

DVB> rssi 10
Reads:10  RSSI[avg: 512  cur: 507]

The noise floor here is around 500. Anything above ~550 is signal, not noise.

ADC RSSI (adc rssi) — reads the raw ADC channel connected to the signal detector, bypassing the BCM4515’s processing. The noise floor is lower (~233-238), and the readings are faster but noisier:

ADC> rssi
RSSI: 237

There’s also adc m which streams continuous RSSI readings using carriage-return overwriting (the cursor stays on the same line, values update in place). Good for real-time monitoring, less useful for automated capture.

For sky mapping, the DVB RSSI path is better — it’s already averaged, it’s frequency-selective (tied to the selected transponder), and the azscanwxp command uses it internally.

LNB polarization control

The LNB supports two polarizations — horizontal (H-pol, 18V bias) and vertical (V-pol, 13V bias). The polarization is selected by the DC voltage on the coax. The firmware provides control:

DVB> lnbdc odu

This sets the LNB to 13V (V-pol) in “ODU mode.” The boot default is 18V (H-pol). The voltage determines which set of transponders you can receive — satellite TV uses both polarizations to double the available bandwidth.

For radio astronomy, polarization matters because celestial sources have polarization signatures. The PEAK submenu’s rssits command exploits this:

PEAK> rssits
Even_sig = 489, Odd_sig = 235
Even_sig = 491, Odd_sig = 238
Even_sig = 487, Odd_sig = 233

It alternates between H-pol (18V, even transponders) and V-pol (13V, odd transponders), reporting signal strength for each. The asymmetry in the noise floor (489 vs 235) is the LNB’s gain difference between polarizations — the amplifier chain isn’t identical for both.

DiSEqC: controlling the LNB from firmware

The BCM4515 includes a DiSEqC 2.x controller. DiSEqC (Digital Satellite Equipment Control) uses 22 kHz tone bursts superimposed on the coax DC bias to send commands to the LNB. In a typical satellite TV installation, this controls switches (selecting between multiple LNBs), band selection (low/high band on the same LNB), and polarity.

The DVB submenu exposes the full DiSEqC interface:

DVB> ovraddr
Override Address: 0x11
DVB> rrto
Rx Reply Timeout: 210 ms
DVB> pretx
Pre-Tx Delay: 15 ms

Address 0x11 is the standard first-LNB address. The timeout and delay values are within DiSEqC spec. The firmware can send raw DiSEqC packets:

DVB> send E0 10 38 F0

That’s a standard DiSEqC 1.x command: framing byte E0, address 10 (any LNB), command 38 (Write N0), data F0 (port 1, option A, low band, V-pol). The combination of lnbdc odu (coax voltage control) and DiSEqC commands gives full control over the LNB’s operating mode without rewiring anything.

For our purposes, the important part is frequency selection. The LNB’s local oscillator frequency determines which RF band gets downconverted to the IF passband. By controlling the 22 kHz tone (band select) and coax voltage (polarity), we can shift the LNB’s reception window across the Ku band. Combined with the BCM4515’s internal frequency selection (transponder tuning), this gives us coverage across roughly 10.7-12.75 GHz.

What this means for amateur radio

A Ku-band LNB on a motorized dish with RSSI readings is, functionally, a radio telescope. Not a particularly sensitive one — the LNB noise figure is around 0.5-0.7 dB, which is good for satellite TV but nowhere near what a proper radio astronomy receiver achieves. But it’s enough to detect strong sources.

Sun transit detection. The sun is a powerful broadband RF source. At Ku band, solar flux is high enough that pointing the dish at the sun produces a dramatic RSSI increase — easily 10-20 dB above the noise floor. An azimuth scan around solar noon should show a clear peak at the sun’s azimuth.

Moon transit. Weaker than the sun but detectable with averaging. The moon’s thermal emission at 12 GHz produces a few dB of signal above noise. Longer integration times (more RSSI samples per position) or repeated scans averaged together would pull this out.

Geostationary satellites. These are the easy targets — they’re literally what the dish was designed to see. A Ku-band azscan across the geostationary arc produces a forest of RSSI peaks, one per satellite. The Lock and SNR fields in the scan output distinguish between “there’s RF power here” (RSSI) and “there’s a decodable DVB signal here” (Lock=1, SNR > 0).

Radio source imaging. Run azscanwxp at multiple elevation angles and you get a 2D grid: azimuth on one axis, elevation on the other, RSSI as the value. Render it as a heatmap and you have a sky map at Ku band. Davidson’s winegard-sky-scan project does exactly this.

The scan workflow

Putting it together, a sky mapping session on the G2:

1. Home both motors: mot then h 0, h 1
2. Enable the LNA: dvb then lnbdc odu
3. Select a transponder frequency: dvb then t <n> to pick a transponder, or use e to set a specific frequency
4. Return to MOT: q then mot
5. Run the scan: azscanwxp 0 <span> <resolution> <num_xponders>
6. Capture output (serial terminal logging or script)
7. Adjust elevation, repeat

Each scan produces a one-dimensional strip. Stack strips at different elevations and you build a 2D image. The resolution trades off against scan time — 100 centidegrees (1.0 degree) steps are fast but coarse, 10 centidegrees (0.1 degree) steps give finer angular resolution but take 10x longer.

Note

The dish’s beam width at Ku band is roughly 2-3 degrees (determined by the reflector diameter and frequency). There’s no point stepping finer than about 0.5 degrees — you’d be oversampling the beam pattern. For 1-degree resolution strips stacked at 1-degree elevation increments, a 90-degree azimuth sweep at 5 elevations takes about 15 minutes.

What we haven’t tried yet

The azscanwxp command is the firmware’s built-in version of what Davidson’s code does manually. We haven’t run a full sky map with it yet — so far we’ve confirmed it executes, verified the output format, and tested short sweeps to check motor-RSSI synchronization.

The next steps are practical:

• Calibration scan: Point the dish at a known geostationary satellite and verify the RSSI peak aligns with the expected azimuth/elevation. This validates the motor position accuracy end-to-end.
• Solar scan: Sweep through the sun’s position and measure the peak-to-noise ratio. This establishes the system’s sensitivity floor.
• Full sky map: Raster scan a large area (maybe 90 degrees azimuth by 30 degrees elevation) and render it as a heatmap. This is the proof-of-concept for using the dish as an RF imager.
• Multi-frequency mapping: Use num_xponders > 1 to get simultaneous data at multiple frequencies. Different celestial sources have different spectral profiles — the sun is broadband, satellites are narrowband, atmospheric attenuation varies with frequency.

The hardware is capable. The firmware commands exist. The mechanical platform (45 lbs, 33” x 23” reflector, 0-455 degree azimuth, 18-65 degree elevation) can point at most of the sky visible from the installation site. The gap is software to orchestrate the scans, capture the data, and render the results. That’s what birdcage is building toward — not just satellite tracking, but RF imaging with surplus satellite TV hardware.