Please excuse this basic question about the constraints on a single ground station.
If I want to make available two stationary (non-rotating) antennas, each with their own RTL receiver, can they both be hosted on the same Raspberry Pi? I see some stations on the network that list two bands/antennas, so I assume this is possible.
I’m curious about the constraints of a single “ground station entry”. Could a single Raspberry Pi host four RTL receiver dongles, since the Raspberry Pi has four USB ports.
I assume a scheduled observation could only use one of the receivers at a time. Correct?
All of this assumes no rotator controller. I have some questions about stations with moving antennas, and I’ll ask those questions later.
Some of the demodulators require about ~150% of the available 400% CPU power of a RPi3 when operating with an RTLSDR. It is quite possible that using two RTLSDRs on a single RPi3 may lead to problems with the CPU not keeping up with both demodulators and the other ongoing programs.
Most of the stations which have two antennas connected use a diplexer combines the inputs of two or more antennas before they are fed to a single SDR. At least one station uses a GPIO controlled switch to switch between antennas (and possibly LNA’s filters).
All of the multi-band stationary setups we have in the network today are, as I understand it, using individual raspberry pis for each band (each one running a satnogsclient).
There has been chatter about doing 2 on the same device through setting a serial for the pi through rtl_eprom and then passing the dev ID through each instance of the client. However I’m not sure how successful this would be on a raspberry pi. One would need to lower the sample rate of each rtlsdr to avoid overruns on the USB bus if there are simultaneous observations (and the idea of doing 4 on a single raspi is complicated even more by that choke point). I won’t say its impossible as it just hasn’t been done yet.
Each ground station entry in network is going to correspond to a satnogsclient configuration. On rotator configurations it makes sense to just run one client as, for the most part, you’re only going to be pointing at one object for one observation at a time. So in this config most people run UHF/VHF antennas into a diplexer and run that to the singular rtlsdr. When they are stationary there’s no reason you couldn’t observe something on UHF and VHF antennas at the same time because you aren’t pointing at one or the other. From a software perspective, however, a client and the sdr script are only going to handle one observation at a time so this config would require 2 clients running.
So, from a network perspective the thing to keep in mind is that a single ground station can only be occupied with a single observation at a given time. This goes back to your point of multiple ground stations, you could definitely do, say, 2 in UHF and 2 in VHF for 4 different simultaneous observation capabilities, but I would recommend they be done with individual raspis (or maybe all 4 from a beefier desktop - mind you the raspi is all we provide an image for today though and the other option would be built by hand).
Hope this gives you some details to chew on. Let me know if I left any questions unanswered.
Thanks for the fast reply. Just to make sure I understand, I’ll summarize.
One “Ground Station” is one Raspberry (running one satnogsclient) with one installed RTL receiver. That “Ground Station” may or may not have a single rotator controller. The RTL receiver may or may not have an RF combiner to allow reception from two or more antennas (on separate RF bands).
If this is correct, it helps me visualize the constraints much better.
If the station is registered or described as VHF 2m and UHF 70 cm, I assume it is up to the observer to schedule an observation on a suitable frequency for that station, i.e. NOT an L-band frequency.
I also assume you guys don’t mind me registering more than one station to accommodate more antenna setups.
When you say “demodulators”, do you mean the on-Raspberry client software process that is producing the water-fall and audio file?
Is the actual “decoding” (extraction of payload data) from recorded/uploaded audio done in post-processing by the Satnogs servers.
For the satellites typically observed, how long are the actual paket or transmissions. I assume they need to be much shorter than the average LEO pass time of approximately 10 minutes.
We go one step further and build those restraints into the scheduling software. If you look at my station for example I have a UHF Yagi and VHF Yagi listed. Behind the scenes those antennas have frequency ranges applied to them, so the scheduling interface will only offer transmitters that fall within those frequency ranges. (if you have an antenna or band not listed just let us know and we will add it!) So, where my station supports both it will be offered observations for both, but each of the individual UHF/VHF stationary stations would only be offered what they support.
Please do!! We are always looking for ways to improve the software model but I don’t see this multiple-receiver scenario changing anytime soon so that is the best way to go about it for now.
The client is a python app that checks in with network.satnogs.org for scheduled observations and manages the rotation of a rotator (if applicable) and doppler frequency correction through rigctld. When an observation starts it kicks off a gnuradio script. These scripts tend to be modulation and encoding-specific, so different observation modes will trigger different scripts. The ideal scenario is to support the full demodulation and decoding of all satellites (which happens on the rpi) and then the resulting waterfall, audio, and data files are uploaded back to network.satnogs.org
We support many modes in production with a few more in development. Today these include FM, SSB, CW (very partial decode today), DUV, FSK1k2, FSK9k6, APT…
Here is an observation where multiple data packets were decoded on the fly and uploaded along with the audio and waterfall: SatNOGS Network - Observation 182731
They are typically very small but it all depends on the encoding and speed of the transmissions, which varies per satellite. That link above you can see how small the packets were (in hex) and can see the 9k6 baud bursts on the waterfall (or listen to them in the streamer)
When I browse through the Satnogs “observation” database, it looks like most observations are scheduled by the station owners. I would think that satellite administrators would do this. I also understand that all observations are uploaded anyways, so they are available to anyone no matter who scheduled them. Are these observations well utilized by the satellite owners ?
From the standpoint of the actual satellite owners, what bands are in the most demand? Are there any weak-points or holes in your network that need attention … Like L-band or C-band ? Or are these bands not favored by the non-commercial cubesat community?
You have dual polarized Yagis pictured, but I assume they are phased for a single CP feed? Are they RHCP or LHCP? Is there a preference, or are most cubesats linearly polarized ?
I’m going to stop asking questions, and let you get back to your weekend !
We don’t have much data (yet) in terms of which satellite operators use our data, as typically we find out after the fact. Last night’s tweet from the equisat team is one example, they used a screenshot from one of our waterfalls.
Then there are cases when we can provide assistance to other hams:
You can see a breakdown of the bands in our db at https://db.satnogs.org/stats/ . UHF and VHF are definitely the most prevalent. I’m not too sure if there are any birds active today in L band anymore. The DSLWP lunar satellites run in 2.2ghz but right now our client software is pretty limited to “earth orbits”. Anyway, as long as there’s something in our db that’s active in a band, we could use some antennas to collect it.
They are wired for RHCP, though M2 antennas now offers a polarization switch. My experience is that RHCP works well across most of the satellites out there.
I really appreciate your time in providing all of the answers. I’ll work to getting a fixed UHF antenna up and running on the network in a few weeks. I have an M2 Antenna Systems EB-432/RK70CM on hand here. It is their 70 cm “eggbeater”, a RHCP omni. I’ll run it through the chamber tomorrow with some other work, and publish the 3D vector gain data. I’m curious to see the actual gain patterns since they boast 6 dBi. They also claim that it has good axial ratio skywards, and it degenerates to horizontal polarization on the horizon. We will see !
