As of S2023, significant progress has been made for the comms sub-team. We’ve done some solid preliminary research and produced several prototypes that have some success in testing. This doc will outline the current projects we’ve taken on, as well as some key terms associated with each project.
This one is definitely one of the heftier tasks, and as of now, it's mainly an electrical task. The entire custom transceiver revolves around the CC1120 transceiver chip, made by Texas Instruments (TI). This is the chip that will actually send and receive/process radio signals.
Since we just buy the chip, we have to actually design the electrical board that goes with it, which is known as the CC1120 board. The first iteration of the board has been successfully manufactured and assembled.
However, just a transceiver chip is not enough for us. We also need amplifiers, specifically, a power amplifier (PA) and a low-noise amplifier (LNA). PAs amplify the signal as they leave the transceiver, while LNAs amplify them as they come in.
The PA and LNA are combined together in what is known as the RF Front-End. Two revisions of an RF Front-End development board have been manufactured, assembled, and tested. The results of the v2 board are extremely promising with power and basic transmit gain tests passing.
This entire project combining the CC1120 board and the RF Front-end board is referred to as the Custom Transceiver. For the last cycle of the competition ending May 2023, the first iteration of the custom transceiver was designed, manufactured, and assembled. While this board helped us win this competition cycle, it has not been properly tested and is not currently capable of performing all our required functions.
For this term, extensive testing needs to be performed on the custom transceiver board to determine to what extent it is operating to spec. Specifically, RF testing related to transmit and receive needs to be performed. Since the design of this board was rushed, it most likely needs to be redesigned in a second iteration. The custom transceiver also needs to be tested working with other boards and the firmware.
Just making a transceiver alone is not enough, we also need to write the firmware that will control the custom transceiver via the OBC (on-board computer).
You could imagine that this would cause some problems. We cant write firmware for the custom transceiver at least until the CC1120 Custom Board is ready, but at the same time, it likely won't be fully ready for a while. Also, we likely wouldn't have enough custom boards for everyone. We can't just neglect all firmware, so the solution is a development transceiver.
These are just simple off-the-shelf boards that we can buy. Each one contains a transceiver and with some sort of microcontroller (e.g Arduino), you can write firmware for it. We’ve already selected our development transceiver, the ccRF 3 Click Board by MikroElectronika. This board actually contains a CC1120 on it, which is nice because it should behave similarly to the custom transceiver.
Now, whenever the custom transceiver is ready, the transition from the dev transceiver (ccRF 3), should be relatively simple.
Since both the custom and dev transceiver boards use a CC1120, it can get complicated when we talk about them. To clarify, anytime we mention the ccRF 3, we’re talking about the off-the-shelf dev transceiver that we purchased. If we mention the word custom or explicitly say “CC1120”, we’re probably talking about the custom transceiver.
It’s possible for some slip-ups to happen, so if you’re ever confused, feel free to ask for clarification, even if it's mid-conversation. That being said, we (the leads) will try to be consistent with how we address each of the boards.
Finally, the last key component/equipment we use for firmware is the SDR. An SDR is a software-defined radio. It acts just like a normal radio, but it plugs right into and interfaces with a computer. When the satellite is in orbit, Amateur Radio Operators (ARO’s) are going to be interfacing with the satellite. The SDR simulates that. We can send data from SDR→ccRF 3, or ccRF 3→SDR, depending on what we want to test.
Making interfaces as web apps can be very useful and make our mission significantly more user-friendly. It also allows us to use comic sans professionally. Right now, we plan to develop 3 web apps.
The first one is the ARO Selfie Pass Request. This web app allows ARO’s to request that they want their image taken by the CubeSat. This will hopefully validate them as registered ARO’s, and give them a selfie-sat pass, which they can use later to actually get the image. So far, Roselyn has made substantial progress on the front-end and is currently working on the back-end
The second app is for the Mission Control Center (MCC). This app will help us easily send commands from the ground station (MCC), up to the CubeSat. This app can also provide a lot more, like a way to view the current health or telemetry of the CubeSat.