Hi Daniel, Marcus My advice would also be to get some kind of x86 mini-PC. A RaspberryPi 4 > definitely has the power to handle the typical modems used by Amateur > satellites, but I think it's quite limited and it's easy to get into > performance problems if you try to do more. > A mini-PC with a fairly powerful processor (Ryzen 5/Intel i7) sounds like the way to go here, I appreciate the feedback. By ASM+Golay/Reed Solomon I think that Martin refers to the typical > modes supported by the GOMspace AX100 radio. gr-satellites has decoders > for these two modes, since they are used by many satellites. > Correct, our upcoming mission (1U CubeSat APTAS) uses an AX100 radio with mode 5 (ASM synch word and Golay coded length field). Besides what Marcus has said, and what I wrote in that link, my > suggestion is that you check out gr-satellites to see what you can reuse > already and what things that you would need for your mission are missing > (uplink capability perhaps?). We are fairly familiar with gr-satellites and should make an introduction post on your github as soon as possible now that the design of the satellite is finished. Indeed the uplink capability we've been developing on our own and currently we are trying to send the first TCs to the AX100 but so far haven't had any success and we've been unable to verify that we are sending correct data since the grc core GFSK mod and demod block don't seem to work together. Maybe this is a discussion we could continue under a different topic. Best regards, Martin Elfvelin On Sun, May 23, 2021 at 10:30 AM Daniel Estévez <daniel@destevez.net> wrote: > El 22/5/21 a las 17:05, Marcus Müller escribió: > > >> Currently we are developing a 1U cubesat that will use a 9.6 kbps > GFSK/ASM+Golay/Reed > >> Solomon configuration. > > > > 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). > > Hi Marcus, > > Thanks for putting me in copy. Since I'm not subscribed to the > usrp-users list, I would totally have missed this thread. > > My advice would also be to get some kind of x86 mini-PC. A RaspberryPi 4 > definitely has the power to handle the typical modems used by Amateur > satellites, but I think it's quite limited and it's easy to get into > performance problems if you try to do more. > > By ASM+Golay/Reed Solomon I think that Martin refers to the typical > modes supported by the GOMspace AX100 radio. gr-satellites has decoders > for these two modes, since they are used by many satellites. > > > 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). > > That's an interesting idea to decode Golay (23,12). The results would be > equivalent to algebraic decoding, I believe. This is because the balls > of Hamming radius 3 centred on the codewords are a partition of the > total code space. Algebraic decoding solves for the centre of the ball > that the received word belongs to. Your lookup table would be a table of > just that: each possible word, together with its corresponding centre. > > I wonder which algorithm is faster. The lookup table seems like instant > decode, but since the table is large-ish, it wouldn't fit in cache and > the entry would need to be fetched from RAM. In comparison, algebraic > decoding takes a handful arithmetic operations and that's all. So > algebraic decoding might be faster, after all. > > However, your idea about maximum-likelyhood decoding makes me think what > would happen if we try to do decoding from soft symbols. That's a much > more difficult problem. I haven't given to it any serious thought, but I > think a naïve approach is computationally intractable. A quick Google > search shows some papers doing different tricks to speed this up. > > In any case, for the AX100 modem I think that this would be an overkill. > The Golay code is used to protect the packet header, which basically > contains the packet size. The payload itself is a Reed-Solomon codeword. > So the Golay code is not the "weakest link in the chain". It is more > likely that the Reed-Solomon codeword can't be decoded in the presence > of errors. > > >> 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. > > > > 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]. > > Besides what Marcus has said, and what I wrote in that link, my > suggestion is that you check out gr-satellites to see what you can reuse > already and what things that you would need for your mission are missing > (uplink capability perhaps?). > > PS: Please keep me in CC, since I'm not on the mailing list. > > Best, > > Daniel. > >