We are a group of university students building a ground station on campus. The goal of the ground station will be to do VHF/UHF communication with LEO small satellites. Our first-order requirement is to be able to downlink from MCubed-2, with the higher-order requirements including downlinking from other compatible satellites and being able to do uplinks. Eventually, we want to be able to decode all signals we downlink. The ground station will be located on the roof of a 144ft tall building.
The current list of hardware we’ve picked out is as follows: Rotator: SatNOGS Rotator v3 SDR: RTL-SDR Controller: SatNOGS Arduino Uno/CNC Shield Based Rotator Controller SatNOGS Client / Platform: Raspberry Pi 3
We have the following questions:
What is the max size/weight/wind load that the Rotator v3 can handle?
What frequency band do satellites usually fall under?
How do you determine the gain requirement for antennas? What are your parameters to consider when picking out antennas? We were looking at M2’s 436CP16, 436CP30, and 436CP42UG models as well as WiMo’s X-Quad 432MHz. What are the opinions on them?
If we wanted to add a VHF antenna later on, is it advisable to place the UHF antenna directly on the rotator for now?
Could you provide some advice on how we should interface the ground station with an operations center (not at the same location)?
What hardware would you recommend for temperature/condition monitoring? What other parameters should we monitor within the electronics box?
Is there anything else we should consider with the current hardware we’ve picked out?
All the technical requirements for the SatNOGS Rotator v3 (max torque etc.) can be found here.
Your desired frequency of operation for uplink and downlink depends on several factors. Firstly, you need to take care of legal requirements with RF transmissions. Permission to transmit is usually (most easily) granted to satellite operators operating in VHF, UHF and S-band, although you may be able to be given access to other bands (e.g. X-band) if the demands of your experiment/scientific unit can justify it. Secondly, it depends on what you wish to transmit. If high data rate transmission is a requirement, you are leaning towards a high frequency (e.g. S-band or X-band). Lastly, you’ll need to verify that your frequency of operation is low enough to ensure the reliability of your link budget. The free-space path loss (FSPL) in dB can be derived from the formula: 10log((4πdf/c)^2), where d is the distance between the satellite and your ground station, f is the frequency of operation and c is the speed of light. You can see that the by lowering the frequency of operation, the FSPL gets minimized.
You’ll need to calculate the link budget for your satellite, both for uplink and for downlink. You can have a great antenna, and have the final signal-to-noise ratio degraded due to losses in the transmission line and what not. Calculating the link budget allows you to account for all the gains and losses of the system.
I’m not sure I completely understand what you mean by that. If the rotator can handle both antennas, then you won’t have a problem. See the link with all the technical specifications attached in the first point.
Have you decided on the block diagram of your ground station? Depending on how far the operations center is and whether real-time digital signal processing/data analysis is required or not, you can upload the data from the Raspberry Pi online and apply further analysis to the data at the operations center.
The built-in CPU temperature monitoring system of the Raspberry Pi should be sufficient. If you’re using a high-power amplifier for TX, it would also be advised to acknowledge the heat that can build up on the unit. A webcam would also help ensuring the rotor is working fine and is not vulnerable to high winds etc. I’d also monitor the technical state of things (e.g. ensure the Raspberry Pi is acquiring the data with no problems like packet drops etc. due to CPU/memory overloading etc. (commands like top/htop should help you with that)). I could write some scripts for monitoring the CPU temperature, memory usage and disk space for you if needed.
I’d like to see the block diagram to get a better idea of your project and provide better advice.
For transmission purposes:
Being a radio amateur (in most countries and depending on your ham class) grants you permission to operate in all radio amateur bands without any other permission/license required. Please do not confuse frequency coordination with legal requirement of additional licensing (which is not there for radio amateur band usage).
I was referring to downlink operations (i.e. the on-board transmitters being in operation). Of course you do not require a license to operate in the radio amateur bands if you’re a licensed ham operator.
Your S/N will (mostly) depend on the characteristics of the receiver (the RTL-SDR in your case), which is not taken into account when computing link budgets. You’ll also need to take antenna temperature into account (T_sky, T_ground etc.) in order to find how much noise enters your system. The simpler traditional link budget alone will only give you your signal (received power, or P_RX). To understand the theory behind S/N derivation, check out these slides here. If you don’t want to dive into much theory, you can use an easy-to-use tool like gr-leo, which can provides the tolerance of your S/N given a relatively low BER value.
