Seeking help with UHF tracking ground station

bdweber1 · October 28, 2022, 2:42am

Hello! I’m a junior in aerospace engineering and have spent the last year refurbishing my school’s UHF ground station. I recently heard my first satellite this past weekend (Observation #6646518). However, I don’t think my station is capable of receiving packets. Below I’ll list my RF and rotator equipment:

RF Equipment: M2 420XP22 Antenna → 2m LMR 400 Coax Cable → EME2-432 LNA / Preamplifier → RTL-SDR → Raspberry Pi

Rotator Equipment: SPID AZ/EL Rotator → ROT2PROG Controller → hamlib → gpredict

Below is an image of me and the setup:

The lab I work at has a Keysight FieldFox VNA that has allowed me to perform some measurements on the RF equipment.

I cannot upload more media images as a new user, but I do have S11 and VSWR plots of the antennas as well as a S21 plot of the LNA that I can attach later.

Some of my next steps are: follow the “Setting the Gain” guide and find the gain and have the SATNOGS client communicate with the rotator (right now I just schedule the pass and then track the pass on gpredict).

Is there anything else I can do to improve my station? I’m a bit concerned about my signal strength. When looking at the waterfalls produced by other users (Observation #6646277 occurred roughly at the same time as my observation listed above), their signal strengths are notably higher. I know the equipment between stations is different, but my goal is be able to receive packets on UHF and then install an S-Band dish. Any help or advice would be greatly appreciated. Thanks!

Apologies in advance if any of the formatting is hard to read.

~ Ben Weber KK7HJU

mfalkvidd · October 28, 2022, 5:23am

Welcome to the forum!

Yes, adjusting the gain is the next step. Your observation used 0 gain wile the other observation had 32.8. The eme2 432 has 20.3dB (assuming it is on). That’s a difference of 12.5dB which is quite a lot.

vi3wroy4l · October 28, 2022, 5:29am

Glad to hear that you’re getting the setup back and running… Yes your gain is set to 0…Just Run satnogs-setup, open the ‘Advanced’ menu, then the Radio settings. Set the gain in the SATNOGS_RF_GAIN variable.
Your comparison observation had, like 32.8 for the gain. You can find this out by looking at an observations Metadata

PE0SAT · October 28, 2022, 6:02pm

A very nice setup, maybe you can share your satnogs-client configuration?

sudo satnogs-setup and then select Advanced and next Support please share the output.

bdweber1 · October 30, 2022, 6:58pm

Hey!

Here’s the support report:

------------[ copy here ]------------
{
“versions”: {
“satnogs-client”: “1.6”,
“satnogs-client-ansible”: “202109022142”,
“satnogs-flowgraphs”: “1.4-1”,
“gr-satnogs”: “2.3.1.1-1”,
“gr-soapy”: “2.1.3.1-1”,
“gnuradio”: “3.8.2.0-14satnogs2”,
“satnogs-config”: “0.12”
},
“state”: {
“is-applied”: true,
“pending-tags”: null
},
“system”: {
“date”: “2022-10-30T18:00:48.792617+00:00”,
“distribution”: {
“DESCRIPTION”: “Raspbian GNU/Linux 10 (buster)”,
“RELEASE”: “10”,
“CODENAME”: “buster”,
“ID”: “Raspbian”
},
“pending-updates”: true,
“platform”: {
“system”: “Linux”,
“node”: “ii-lab-satnog-uhf”,
“release”: “5.10.103-v7+”,
“version”: “#1529 SMP Tue Mar 8 12:21:37 GMT 2022”,
“machine”: “armv7l”,
“processor”: “”
},
“memory”: {
“total”: 968052736,
“available”: 693534720,
“percent”: 28.4,
“used”: 203833344,
“free”: 325009408,
“active”: 220110848,
“inactive”: 353509376,
“buffers”: 41594880,
“cached”: 397615104,
“shared”: 6483968,
“slab”: 51810304
},
“disk”: {
“total”: 31078248448,
“used”: 3332460544,
“free”: 26428657664,
“percent”: 11.2
}
},
“configuration”: {
“satnogs_antenna”: “RX”,
“satnogs_api_token”: “[redacted]”,
“satnogs_rf_gain”: “0”,
“satnogs_rot_model”: “Rot2Prog”,
“satnogs_rot_port”: “/dev/ttyUSB4”,
“satnogs_rx_samp_rate”: “2.048e6”,
“satnogs_soapy_rx_device”: “driver=rtlsdr”,
“satnogs_station_elev”: “347”,
“satnogs_station_id”: “2602”,
“satnogs_station_lat”: “33.417565”,
“satnogs_station_lon”: “-111.93322”
}
}
------------[ copy end ]-------------

Right now my SATNOGS_RF_GAIN is at 0 dB. I’ve been switching the SATNOGS_RF_GAIN around during passes to see how the system performs but I’m getting mixed results.

I am most confused on the SATNOGS_RF_GAIN how that interfaces with the LNA and rtlsdr. I have been reading through the setting the gain article and this forum post. However, when I would adjust the rtlsdr gain through satnogs-setup and checked the noise floor on CubicSDR or gqrx, I didn’t see the noise floor change. Is there an equation or expression I can use to calculate what my SATNOGS_RF_GAIN needs to be? I might be going about the process wrong…

Thanks!

PE0SAT · October 30, 2022, 7:36pm

Hi,

Yes, the gain settings can be a problem, not all SDR’s can use the same values, below a list with the allowed values and some best practices.

The supported gain values for a RTL-SDR, there are 29 in total, use the exact values, no rounding.

0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6

For a non LNA setup with short coax length use something like 38.6 and go higher following the values from the list if necessary.

A LNA setup (where the pre amp is close to the antenna) start with 22.9

danwhite · November 7, 2022, 5:40am

The SATNOGS_RF_GAIN variable is read at the start of an observation and thus can’t be adjusted in real time, in contrast with using CubicSDR or gqrx.

GRIFEX is a good satellite to listen to for data.

The UHF repeater downlink on the ISS “Mode V/U FM - Voice Repeater” would be good to listen to in real-time with gqrx since it is usually active. Then you can adjust gains during the pass to watch the noise floor move and transfer the number over to the SatNOGS client.

bdweber1 · November 14, 2022, 7:14am

I went ahead and paused the tracking station. The antennas used were measured as broken and I am in contact with M2 about how to fix them.

I did install an UHF Eggbeater antenna this last weekend and it has been performing a bit better than the tracking system. When the pass is ideal, the M2 has been able to get TLM packets somewhat reliably. Seen here in Observation #6735476 and Observation #6735493.

There’s a few potential issues with this setup I’m looking to solve in the upcoming week. Specifically:

New power supply for the Raspberry Pi, I’m currently not supplying enough current for the pi.
Get a UHF bandpass filter. Being on a campus, I think I might have a fair amount of interference. Any recommendations? Looking into some from antennas-amplifiers.
Switch from an RTL-SDR to a HackRF One. I have a spare one on hand and have been playing around on L-Band. From what I’ve been seeing on GQRX and CubicSDR, the more advanced gain options are super helpful when detecting a signal.

Thanks for the help all! I’ll keep updating here if I have any questions.

bdweber1 · March 2, 2023, 7:01pm

Hey again,

It’s been a bit. Busy with classes and all that, but slowly making progress on our ground station. I have a few updates and inquiries.

I’ve replaced my RTL-SDR with a HackRF One and it’s been performing much better. I still have to tune the gain settings, but I am to see weaker signals. I am a little suspicious that I haven’t had much success with the RTL-SDR…

I did not observe much of benefit with a bandpass filter. There are several transmitters on campus close to my setup that interfere with my reception when pointing at them.

My first inquiry is related to this forum post: Rotator control - Parking. I’m having a similar issue with my rotator. I currently am running a simple post path script that sends the rotator to (0,0). As stated in the post, this is an issue because the rotator will take shorter path to it’s parking spot. When I schedule passes that cause the rotator to turn clockwise past 180 deg in azimuth, the rotator will wind up and eventually hit the mechanical limit. There is also the potential for this to occur when I schedule passes that cause the rotator to turn counterclockwise past 180 deg in azimuth and wind up in the other direction. I’ve found that after a single night of passes, the rotator hit it’s mechanical limit.

The two solutions I’ve been experimenting with are as follows:

Define electronic limits of the travel through the rotator. The manual (Section 3.1) states that there are programmable high and low limits. In the forum post above it appears that they defined their limits as +175 and -175. When I was using gpredict, I had set up the rotator like this in the software and it was working fine. I haven’t tried changing the limits electronically, but I would prefer a solution where I can have all 360 degrees of travel.
Write a post path script that fixes this for me. The current post path script I have running is: rotctl -m 2 -r localhost:4533 P 0 0. I have the rotator running through a separate computer from the raspberry pi and so I’m commanding it over the network. When reviewing the Hamlib manual for rotator control, I found this command:

   M, move 'Direction' 'Speed'
         Move the rotator in a specific direction at the given rate.

        Values  are  integers where Direction is defined as 2 = Up, 4 = Down, 8 = Left, and
        16 = Right.  Speed is an  integer  between  1  and  100.   Not  all  backends  that
        implement  the  move  command  use  the  Speed value.  At this time only the gs232a
        utilizes the Speed parameter.

I’ve been trying to implement this command via the command line, in something like this: rotctl -m 2 -r /dev/rotator P 0 0 M 8 -1. I’m sure there’s something to separate the commands, but I haven’t gotten to that part yet. I haven’t been able to find an example of someone using both of these. Regardless, I’m getting an error message:

move: error = Feature not available
write_block(): TX 6 bytes
read_string called, rxmax=64
read_string(): RX 9 characters

I do think that the move command is supported for this controller in the current release of Hamlib due to lines 388 - 435 in the spid.c source code file. I’m going to go ask on the Hamlib repo, but I thought I would ask here if anyone has had success with this command? I think if I can get the command to work, I could write a script that allows me to send the rotator back to a home position without winding up.

My second inquiry is related to transmission. My laboratory handed off our CubeSatellite in December and are preparing to launch on Dragon CRS-2 SpX-27 in a few weeks. We’re expected to deploy sometime in early April. I believe I will need a linear amplifier for transmission purposes. Does anyone have good recommendations for UHF linear amplifiers? I was looking at these two: Toptek Communications PA-80U UHF Power Amplifiers PA-80U and MKU PA 70CM-60W HY, UHF MOSFET-Power Amplifier. But I don’t really know what I’m supposed to be looking for…

Thanks!

~ Ben Weber KK7HJU