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