Hi Martin,

that's a bit of a wide field there :) In essence, there's not a single answer to your
question: whether your hardware is sufficiently fast depends on what you do with it!

For example: 192 kb/s is really not much data to process, if there's a simple (say,
Hamming(4,7) ) error-correcting code to be decoded on it. It's going to be tough to
calculate if it's been through a large LDPC code and you want to do 50 iterations of a
message passing decoder to really get even the last bit out of your channel.

But, you say "amateur satellite communications", which probably at a first approximation
means you're using modes that are currently common in that community, or such that are
currently constructed with complexity in mind. So, yeah. Most things should work on the
four 1.5 GHz ARM Cortex-A72 cores of a raspberry pi 4 Model B. Note that there's very
different Raspberry Pi models, so make sure you get the latest generation. Also note that
your Raspberry Pi doesn't have to do all the work, if in doubt: for example, the
relatively compute-intense steps could be, on demand, done on a laptop with significantly
more computational power.

So, it should work. However, that's a "should": I've got exactly zero knowledge of people
who have done that, and a back-of-envelop calculation saying, hm, yeah, that compute power
should suffice assuming the usage of sufficiently optimized software doesn't say
sufficiently optimized software is available to you. But honestly, I think there's really
a treasure trove of online information and working groups on that topic. Maybe pay the GNU
Radio Amateur Radio Working Group a virtual visit [1]; I'm sure there's much experience
with satellite comms in that channel. If text-chatting isn't very much your thing, maybe
also try showing up to one of their monthly video calls[2], and hang around before or
after the invited talk and chat a bit.

Of course, as the largest community of citizen-operated satellite groundstations, I bet
satnogs[3] has guidance on hardware. I do know they have raspberry Pi images, but I
honestly don't know whether they're doing the digital communications part on that, or
whether they are just recording the spectrum and maybe do some simple demodulation (FM
demod?). Admittedly, and regrettably, not my prime area of expertise. However, whenever I
meet satnogs people, they're a friendly bunch! They have a well-kept online forum[4],
that's very active, and also a matrix presence[5].

Best regards,

Marcus

[1] via Matrix chat: #HamRadio:gnuradio.org; easily reachable via
https://chat.gnuradio.org/#/room/#HamRadio:gnuradio.org
[2] https://wiki.gnuradio.org/index.php/Talk:HamRadio
[3] https://wiki.satnogs.org/Main_Page
[4] https://community.libre.space/t/new-users-welcome/29
[5] #satnogs:matrix.org (I think you really might want to have a Matrix account on some
arbitrary homeserver ;) )

On 21.05.21 10:20, Martin Elfvelin via USRP-users wrote:

Hello Marcus,

Many thanks for your reply. The ground station is intended to primarily
support future educational CubeSat projects so it's difficult to say
exactly what communications protocols will be used but you are right to
assume common amsat modes. Currently we are developing a 1U cubesat that
will use a 9.6 kbps GFSK/ASM+Golay/Reed Solomon configuration. However it
might be of interest in the future to add support for reception of higher
frequencies and data rates (say amateur S-band for example) which would
mean adding another SDR to the same PC and there I'm worried about creating
a bottleneck in terms of computing power. Thank you for the links I will
have a look and investigate further.

Best regards,
Martin

On Fri, May 21, 2021 at 11:16 AM Marcus Müller marcus.mueller@ettus.com
wrote:

Hi Martin,

You're more than welcome! USRPs in ground stations are fun stuff!

Well, in that case, a slight case of overdimensioning can't be bad – would be stupid if
you found out in a year that had you spent a few kronor more, things would be working.

Well, if you're in the "business" of building your own satellites, then by all means, just
slap a PC of some kind (intel NUC? or any micro-ATX board, maybe with a Ryzen 5 even?) on
there – really can't hurt if you've got a little headroom for doing more advanced stuff
such as attitude tumble estimation, better doppler prediction / correction, or simply more
modes (and simultaneous modes).

Regarding the Golay code: is that the classical perfect binary Golay (23,12)-code, for
hard decoding? If you pick a PC over a Pi, you get higher memory bandwidth, and can
implement Maximum-Likelihood decoding (it doesn't get any better ;) ) simply by having a
precomputed table of 2²³ 12-bit words; that's 16 MB of RAM when you put each 12 bit info
word into a 16 bit machine word (if you implement it in a packed manner, it's only 12 MB)
of a lookup table, and a single memory access would then give you the fully decoded 12
bits. Not that you're anywhere near computational trouble with the 9600 bits a second
doing a traditional decoder. In fact, Daniel Estévez, himself of GNU Radio and satellite
observation/gr-satellites fame [10], has a nice article on algebraic decoding of the
(24,12) Golay [11] and the (23,12), too [12] (note that you can solve the 1-bit-reduced
error correction capability by actually trying to decode both parity hypotheses).

Go do a bit of "receiver shopping" in gr-satellites. In fact, Daniel even has guidance for
teams developing ground stations for smallsat missions [13].

Best regards,
Marcus

[10] https://github.com/daniestevez/gr-satellites/
[11] https://destevez.net/2018/05/algebraic-decoding-of-golay2412/
[12] https://destevez.net/2018/05/using-a-golay2412-decoder-for-golay2312/
[13] https://github.com/daniestevez/gr-satellites/blob/master/satellite_teams.md