Team Anant (Birla Institute of Technology and Science, India) #306
Replies: 26 comments
-
Hi and thank you for considering using gr-satellites in your satellite mission. The hyperspectral camera looks like a very interesting payload. Hopefully Amateur radio operators over the world with appropriately equipped stations will also be able to collect hyperspectral images from the satellite. Regarding low-datarate communications, your original idea to use two different FSK transceiver chips seems a bit strange, but anyway. Other than this, my advice would be (as always) not to use AX.25. It doesn't have any FEC, so it is not suitable for space applications. My suggestion would be to use something based on the CCSDS recommendations or maybe the AO-40 protocol, which has been used successfully on several Amateur cubesats, such as the FUNcubes. Regarding the S-band downlink, the requirement of a 4Mbps downlink from a cubesat should not be taken lightly. It is certainly possible, but it will require careful consideration regarding the link budget, ground station, etc. You can look at the HAM TV payload on the ISS for a similar example, perhaps. Even though I recommended CCSDS for the high-speed downlink in #134, now that I think about it again it seems to me that DVB-S2 or DVB-S2X would also be a good choice, perhaps using the GSE protocol. At such high rate you'll need fast FEC decoding, either on COTS hardware (which would be an option if you choose DVB-S2), on a fast computer using an optimized library such as this LDPC library by xdsopl, or even an ad-hoc FPGA implementation if necessary. Although CCSDS would be a really good and safe choice, DVB-S2 is also a great protocol and you have much more COTS hardware and other Amateur tools, especially now that DVB-S2 is extensively used on the QO-100 WB transponder. Speaking of which, since QO-100 covers India, you can already start using it to experiment receiving DVB-S2 with COTS hardware or with a software approach, of which leandvb is perhaps a popular choice (but there are others). I would really try to forget about FSK and use QPSK for the S-band downlink (especially if you use DVB-S2 this would be mandatory). If you stick to CCSDS you might be able to use GMSK and demodulate it coherently, but you will need to fine-tune a coherent GMSK demodulator for those fast rates. We used a coherent GMSK demodulator for the Longjiang-2 mission, and this is available in gr-dslwp, but this was used at 250 and 500 baud. I'm looking forward to those further details. |
Beta Was this translation helpful? Give feedback.
-
Thanks for making us a part of your community and for your recommendations. Our team is extensively working on our frequency shift we will update you with the details as soon as we make our primary report along with the link budget, bit error rate, etc. This should take around a month's time. Due to the ongoing pandemic currently, we are working remotely so most of our team is unable to work on the hardware equipment. Regarding the AX.25 uplink part, the official document of AX.25(please refer to https://www.tapr.org/pdf/AX25.2.2.pdf page 6) states that 16 bit CRCis added behind the information field. Regarding why we choose AX.25 for uplink purpose was for its extensible documentation, simpler nature, and space heritage. However, we may consider changing it based on your recommendation. Also, I had a few doubts. I would once again like to thank you for your support and quick updates. |
Beta Was this translation helpful? Give feedback.
-
Also sir it would be great if you share some examples and some documentation on how to perform CCSDS encoding using GR-satellites. Thanks. |
Beta Was this translation helpful? Give feedback.
-
Check out the guidance video here https://youtu.be/TceMth67r9c |
Beta Was this translation helpful? Give feedback.
-
Regarding the documentation part, CCSDS documentation is far vast check it out.... also the best kind of FEC documentation in the language a layman(engineer) can understand is given by Phil Karn for AO-40 and by far that is considered as quite a great standard. Also if you use PSK based modulation in UHF also, u can get higher data rates as PSK modulation require nearly 1Hz/bps of bw as far as I have read. Although I am not sure you can get something like 1-2 Mbps or something. But surely you can do much better than 9600bps. For transceiver checkout PQ9ish design by LibreSpace foundation. If you wanna go for S-band try contacting Surligas in Satnogs community, ask him about Satnogs-Comms system they are developing for ESA, it is open-source design. About the community your last CD&H head, Nishant Gupta is a good friend of mine. K.J.Somaiya Insititute Mumbai is always open to help and collaborate... Feel free to contact. |
Beta Was this translation helpful? Give feedback.
-
Hi @ShayanMajumder, Regarding AX.25, there are compliant implementations of HDLC deframer and framer blocks in GNU Radio and in gr-satellites. The main difference between these two are the following: the GNU Radio blocks are in C++, the framer uses only one preamble and postamble I suggest you use any of these as a reference implementation, if you still want to go the route of AX.25. Also see the AX.25 examples in gr-satellites for how HDLC fits together with NRZ-I and G3RUH scrambling. There are some aspects of these protocols that are tricky, so study the documentation carefully, and check that your implementation works against some of these reference implementations. For instance, HDLC sends bytes least-significant-bit-first, which is related to one of your questions. Regarding FX.25, I personally don't like that protocol very much, but there is an implementation for the Astrocast 0.1 FX.25-like protocol in gr-satellites that might help you. See this post and note that the protocol used by Astrocast 0.1 is not completely compliant with the FX.25 protocol. That post maybe also shows some lessons about the difficulties of implementing FX.25 correctly. In any case, I think that gr-satellites already has all the building blocks for a compliant FX.25 implementation. I wouldn't say that AX.25 has extensive documentation, and while it certainly has space heritage, it also has a history of mission failures due to the inability to correct for bit errors.
Currently there is no chat group or other online group devoted to gr-satellites, since the community of gr-satellites users is perhaps not so large. I could be persuaded to use something other that GitHub issues if it seems appropriate.
Amateur satellites are supposed to publish the full information about the protocols they are using to downlink telemetry and other data. So not only me, but the whole community is expecting a detailed enough description that would allow anyone to build independently a decoder for your satellite. For background information, see my open letter to the ESEO team. From my side, since you've expressed interest in using gr-satellites for your groundstation, I am expecting that you provide this information so that I can help you identify which blocks of gr-satellites can already be re-used for your decoder, and which new blocks need to be implemented, and also to guide you in the implementation of any new blocks that are needed, in such a way that they can be integrated in the upstream branch of gr-satellites. |
Beta Was this translation helpful? Give feedback.
-
That's a fair point. gr-satellites is mainly focused on decoding, so there is a ready to use CCSDS decoder, but there is no CCSDS encoder block that does all the job. However, all the pieces are there, and if you study the decoder you'll be able to see what you need for the encoder. |
Beta Was this translation helpful? Give feedback.
-
Sir, They weren't able to achieve their data rate requirements. So can you please suggest us if we should move to a higher frequency to achieve the required data rate? Also, we got a deep insight into K2sat's encoding while reading your blog . Also, it would be great if you share some of your experience performing ack/nak in previous CubeSat missions. We had another doubt that why do we need to use FEC for uplink which has a very less bit error rate in the order of 10^-5 due to its high SNR?
Sir we are getting our GitHub page ready and will make our work open as soon some of our things get finalized. For now, we can mail you if you require to know some information/work/calculations. Thank you. |
Beta Was this translation helpful? Give feedback.
-
Have you made a link budget yet? Moving to C-band or X-band won't make things necessarily easier. Comparison between pros and cons of different frequencies is best done with the link budget at hand.
No idea about it. This was entirely handled by the K2SAT team.
I don't understand your question. Generally you would send packets on the downlink, use the uplink to inform which packets have been missed, then resend those packets on the downlink.
No that I know of. Ad-hoc software tends to be used for that.
Because maybe you're not going to have the high SNR you think you're going to have. There is fading due to the satellite tumbling, and also plenty of interference. Undeployed antennas and other unexpected hardware failures also. Uplink failure equals not being able to command the satellite, which means mission failure. |
Beta Was this translation helpful? Give feedback.
-
https://docs.google.com/spreadsheets/d/1CAKJWKIq8X7q4UWenp2J8Cp_TBNyN8nvrlxVTmSdR-U/edit?usp=sharing our tentative S band link budget |
Beta Was this translation helpful? Give feedback.
-
I was just asking that ack/nak in different frequencies will work right?I had some confusion regarding this . |
Beta Was this translation helpful? Give feedback.
-
I'm reviewing your S-band link budget. These are my comments:
Is that serious? That is crazy low. Consider at least one or two watts. Edit: In retrospect I see that the real transmit power is 24dBm. That is still a bit low, I think.
Why? This is a cubesat. You don't need a long run, do you? Try to bring that down a bit. Still, you have the constraint of not using very thick coax, and all the connectors will add up to the losses, but probably you can do better than 2dB.
Is this based on a particular antenna you've selected? Seems about average, so good.
Why?
Where does this comes from? You have 3dBm - 2dB + 6dB = 7dBm. Edit: I now see it is 24dBm from the PA plus 6dB from the antenna.
I don't know where this comes from. For a noise temperature of 172.8 K you have N0 = -174+10*log10(172.8/300) = -176.4dBm At some point the calculations get difficult to follow and are probably wrong. Let's say we work with the 30dBm EIRP you have above. The power at the LNA input is 30-166.15+29.4-1-0.5-0.1 = -108.35dBm. So the C/N0 is -108.35 + 176.4 = 68dB. At 1Mbps you would have 68 - 60 = 8dB Eb/N0. So yes, this technically works. Even with the typical CCSDS concatenated code (r = 1/2, RS(255,223)) you have maybe 6dB of margin. But watch out for implementation losses in the demodulator, your antenna temperature not being 100K because you have interference (say from WiFi or other 2.4GHz devices), your LNA not being 0.38dB NF, etc. Any of these could break the system. Now, what I find worrying is that you arrive at an Eb/N0 of 48.7dB for a 1Mbps cubesat S-band link and do not notice that you must have made a very large error in some of the calculations. This means that you don't understand the usual orders of magnitude of the things you're dealing with. So, can a cubesat S-band 1Mbps link work? Yes. As I already mentioned, the HAM TV system on the ISS and several cubesats show this is certainly possible. Your link budget, when correctly calculated, also shows the same. Is this very easy to do? No. The link budget also shows that there is not that much margin. Everything needs to be engineered correctly. |
Beta Was this translation helpful? Give feedback.
-
Still unclear what you are asking. What is in a different frequency from what? As said above, the ACKs and NACKs are sent in the uplink. The uplink frequency is often different from the downlink frequency. Does this answer your question? |
Beta Was this translation helpful? Give feedback.
-
We have made progress finalising our S band architecture. I will mail you a preliminary documentation regarding this in 2-3 days giving you a brief overview of our compression algorithms, corrected link budget, telemetry, retransmissions etc. Thanks |
Beta Was this translation helpful? Give feedback.
-
Hi @ShayanMajumder, thanks for reporting your progress. I'm looking forward to that documentation, but I would rather you share it here in case some other people from the community also want to contribute with advice. You can easily attach files to your Github messages, or you can store them elsewhere and include a link to them. |
Beta Was this translation helpful? Give feedback.
-
@ShayanMajumder probably make a project public description repo like we did for BeliefSat and write as much details as you want to keep open to public.Share the repo link rather. This wil help you with getting help from other projects as well as publishing it as info source in case you are going for amateur band Co-ordination. You gotta anyway open you comms protocol to public if you will be using Amateur band. |
Beta Was this translation helpful? Give feedback.
-
Yes we are planning to create a github repo . However I feel that having a chat group on Slack or Microsoft teams can bring the community closer and more organised. |
Beta Was this translation helpful? Give feedback.
-
@daniestevez link to our updated link budget https://docs.google.com/spreadsheets/d/1oLBv1heWP3PJqLshgSTFfOdnVaBZ_p9I3aPIkdL8Mhk/edit?usp=sharing |
Beta Was this translation helpful? Give feedback.
-
I'm missing the details for the coding gain of 6dB you state. You don't even specify which FEC you intend to use. Usually, you don't work directly with coding gain. You would specify a modulation, FEC and target BER, and then get the EbN0 for that. |
Beta Was this translation helpful? Give feedback.
-
For instance, DVB-S2 with rate = 1/2, QPSK and long FEC frames would need an EbN0 of 1dB for almost error-free copy. With an EbN0 of 7.6dB you would have 6.6dB link margin. |
Beta Was this translation helpful? Give feedback.
-
Sir we intend to use concatinated coding (rss(255,223)+ 1/2 rate convulation) though the gain is a little more than 6 db however we are taking a lower limit for it. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the document. gr-satellites already has everything needed to decode CCSDS rate=1/2 concatenated frames, and this is already used for several satellites. The figure 6-4 from the Green book that you attach in the document is correct (why wouldn't it be?). As you can see there, you need around 6.5dB for your target BER of 1e-6. Since you have computed 7.6dB EbN0 in your link budget, you only have 1.1dB link margin, which isn't much. Whether you want to implement some form of selectively downlinking missed file blocks/packets or re-download the complete file again is for you to do decide. Do a trade off analysis. How much time do you take to uplink the list of missing blocks and respond by sending those on the downlink? How much time do you take to uplink a single telecommand and then download the full image? An important question is how large are your images. I think you don't say. Since you plan on downlinking at 1Mbps, I guess they will be at least a few Mb large. So at BER = 1e-6 typically some bits will be wrong. Are you very confident in your link margin or do you think you will have occasional fading or drops due to loss of lock in the demodulator? Maybe you want to use some application-level erasure FEC instead of requesting missing blocks. Regarding the basic beacon: gr-satellites doesn't have any OOK decoder. If you plan on using Morse, there are already several Morse decoder applications. From an information theory point of view, Morse is much worse than any digital protocol, so you should only use Morse if for some reason intend that humans are able to copy the data by ear, without any software. I strongly discourage you from using Morse to transmit information. But maybe it's good to put a trace on the waterfall so that the satellite signal can still be detected if things go badly. Maybe even transmit the satellite callsign in Morse. But not more than this. Use a real digital mode for the data. Regarding the advanced beacon: well, you should have a clear idea of what telemetry variables you need/want to transmit periodically, if you will be also transmitting whole orbit data autonomously (i.e., without request), etc. Then you'll be able to see if this fits in a single packet, or you need several packets of different type. I strongly discourage you from trying to add Reed-Solomon to AX.25. They don't mix well, and most people that have tried have failed badly. Instead, you can design a simple telecommand frame that uses an ASM followed by a Reed-Solomon codeword of suitable size. Since you're following CCSDS, maybe you also want to take a look at the TC Synchronization and Channel Coding Blue Book. CCSDS CLTUs are designed with small frame size in mind, use 8 byte BCH codewords to easily allow a variable packet size, and can be as short as 18 bytes. Regarding image decompression, I think this is best implemented outside GNU Radio. Typically you'll want to store images compressed on the disk, and only decompress on the fly for viewing. This is best done with an external application. gr-satellites receives SSDV and JPEG images from several satellites, but only handles these as files. Image processing algorithms are done externally. As said, gr-satellites already has everything needed to decode the S-band CCSDS concatenated coding downlink. The details of the UHF downlink are still not defined, but most likely gr-satellites will have most or all that is needed to decode this as well. For the uplink, gr-satellites doesn't have as many features, but this is a good opportunity to implement the building blocks for the uplink protocol you use. I think that it is a good idea to organize your groundstation solution in these modules:
The beauty of this approach is that users from the community, which are not expected to uplink to your satellite can use just modules 1 and 3 without any changes to the architecture. |
Beta Was this translation helpful? Give feedback.
-
We will do the calculations and let you know what will be our expected block size and the final Ack/nack protocol.
Since our satellite is a student satellite a major percentage of defining our mission success would be a safe reception of atleast some sort of beacon so we were trying to keep it a simple OOK modulated beacon with our call sign perhaps.
Noted! we will start working on this. We will share our onboard architecture in 1-2 days also we will start working on some channel to keep documentation of our work in public domain. Thanks |
Beta Was this translation helpful? Give feedback.
-
@daniestevez could you give an idea of how beacons are for satellites in general. Like the modulation scheme, contents and how long should it be on like in 1 min should it be on for 15 sec ,more or less. |
Beta Was this translation helpful? Give feedback.
-
There are many variations, so I can't suggest any particular scheme. You may study successful cases of Amateur satellites for ideas. I suggest you try to work from requirements: as yourselves what you need of the beacon, and technical choices will follow from that. |
Beta Was this translation helpful? Give feedback.
-
Hi, since gr-satellites is starting to use discussions, I'm moving this thread to a discussion, as it seems more appropriate. |
Beta Was this translation helpful? Give feedback.
-
Team Anant is an undergraduate student satellite team of Birla Institute of Technology and Science, Pilani. Our objective is to design, build, and launch, a 3U nanosatellite with a hyperspectral camera as a payload. Field Programmable Gate Arrays (FPGA) will be used to implement computationally intensive compression algorithms for hyperspectral images, the science objective will be performing land imaging for vegetation mapping. The orbit is a near-polar, sun-synchronous orbit with a radius of about 600km and 22 minutes of pass time above the ground station per day. We are hopeful to get a launch as a part of ISRO's student satellite project.
Initially, we had planned to use the VHF Band (144MHz) for uplink using the ADF7021-N transceiver onboard and downlink in the UHF band (435MHz) with Texas Instruments CC1101 transceiver. However, the data rates achieved by our downlink were constrained to 9600bps given bandwidth constraints. The payload will take multiple images and even after compression we require a high data rate, about 1-4Mbps, and hence have recently decided to shift to the S-Band (2.4GHz) for our downlink.
Given frequency allocation constraints we will use the UHF band for our beacon and uplink. Two forms of the beacon will be present. One simple beacon in morse code, which will consist of the call sign, satellite name, and some basic housekeeping data, will be sent at some regular intervals while the satellite is in an initial stage and the onboard computer is not switched on. Second is an advanced beacon, which will consist of data from various sensors, and other significant events that might have taken place on board. This beacon will be AX.25 encapsulated and transmitted at a rate of 9600bps, GMSK. It will be sent using the UHF radio (CC1101).
Our uplink will mainly consist of direct commands for reconfiguration of spacecraft, application-specific commands, TLE,date-time, etc we plan to use the AX.25 protocol for this purpose and may modify it to some extent for our convenience. The uplink will be GMSK at 9600bps.
For our downlink purpose, we are still searching for an optimal protocol that provides an optimal code rate. We are searching for transceivers for use in the S-Band, we found one contender the CC2500 that provides rates up to 500kbps but falls short on the data requirements set by the payload. We are currently in the review and preliminary design process of this S-Band communication system and are looking into its feasibility with regards to link budget/ power requirements etc.
Our Ground station transceiver is the USRP SDR and we will be purchasing one of the B2xx models. We would be happy to be a part of GR-Satellites satellite teams and would like to thank you in advance for the support Gr-satellite will provide us in setting up the ground station. We will communicate further details with you in the coming days.
Link to our website->http://www.team-anant.org/
Beta Was this translation helpful? Give feedback.
All reactions