Introducing SLARS-BCG-1: Sri Lanka's First School-Made CubeSat Project – Seeking Community Advice!

[slars2012]

Hi everyone in the Libre Space Foundation community!

We are the SLARS Team (Student-led Advanced Research in Space), a passionate group of student developers and space enthusiasts based in Sri Lanka. We are currently working on an incredibly exciting milestone: SLARS-BCG-1, Sri Lanka’s first school-built CubeSat project!

Our vision is to make space research and satellite data open and accessible for students across our region. We’ve even been exploring the concept of a dedicated Research Hub to eventually crowdsource and analyze satellite data, keeping everything deeply rooted in the spirit of collaborative, open learning.

Current Progress

We have officially transitioned from the drawing board to the physical lab! Our current focus is hardware bring-up. So far, we have:

• Assembled our initial development boards and core components on the bench.

• Begun the process of powering up, debugging, and flashing bootloaders to our subsystems.

• Started verifying basic power distribution and initial microcontroller functionality.

• Continued development on a prototype web framework/research hub to manage future data and community-driven space analysis.

Where We Need Your Help

Because we are a school-level team tackling a full CubeSat project and are currently in the thick of hardware bring-up, we are running into the typical hurdles that come with limited aerospace hardware experience. We are huge fans of LSF’s open-source philosophy and would love to get your guidance on a few things:

1. Hardware Bring-up & Debugging Best Practices: What are some common pitfalls or “gotchas” we should look out for while bringing up our initial CubeSat boards? Are there open-source debugging tools or workflows the community recommends?

2. Open-Source Comms Integration: We want to align our design with open-source standards. What are your recommendations for reliable, beginner-friendly UHF/S-band communication modules (like SatNOGS-compatible hardware) that interface well with a custom hardware stack?

3. Telemetry & Ground Stations: How can we best prepare our satellite’s firmware and transmission systems during this early stage to easily integrate with the SatNOGS global network once we are in orbit?

We are eager to learn from the experts here, and we intend to document our journey openly so other student teams around the world can follow in our footsteps.

Thank you so much for your time and for maintaining such an inspiring community!

Best regards,

SLARS Team,
Sri Lanka

[deckbsd]

Hello @slars2012 ,

I’m going to ping some person that i believe can have a look to the different topics you have and will be able to give you detailed answer about. It is just to ensure that they are going to see this message

Hardware Bring-up & Debugging Best Practices

and

Open-Source Comms Integration

I believe @surligas , @sdoukos , @pierros , @aris12 , … all the ppl that worked on LSF missions/comms can have a look at your writing and answering you.

Telemetry & Ground Stations

For this matter. Regarding the sat firmware and tx system matters, i would say the same person as above. And for the Integration part, well i would say @fredy our head of operations ^^ to give you the big picture, i will also provide more details about the decoding and dashboard parts.

[deckbsd]

Pinging also @dbita and dbita and @nickstouras

[aris12]

Hello SLARS Team,

Sorry for the late reply. As you can imagine, we have been quite busy with a few projects. Also, thanks to @deckbsd for reminding us so we didn’t forget to reply.

First of all, congratulations on your amazing work!

I’ll give you a general overview first and answer some of your questions. Then, if you have any more specific questions or run into any issues, feel free to ask them here. We’ll be happy to help.
To start with, one thing I would strongly recommend is that everyone on your team uses Linux on their laptop or desktop computer (any distribution you like is perfectly fine). It may seem like a small change, but it will help you get familiar with the open-source ecosystem and the tools that are widely used in embedded systems, software-defined radio, and space projects.

In the long run, this will make development, debugging, and collaboration much easier, and it will help you become part of this amazing open-source community.
When working with CubeSat boards, one of the most important things is to handle them carefully and work in a proper environment. For engineering model (EM) boards, I highly recommend setting up an ESD-safe workspace. Use an ESD mat on your workbench and always wear an ESD wrist strap when handling the boards. These simple precautions can prevent accidental damage from electrostatic discharge.

(This advice is mainly for Engineering Model (EM) boards. I’ll talk about Flight Model (FM) hardware and the additional handling requirements later.)

The most important tools I would recommend having are a bench power supply and an oscilloscope. These are essential for bringing up and debugging your hardware.

It is also very useful to have a spectrum analyzer, although they can be quite expensive. If you don’t have access to one, a PlutoSDR is a great low-cost alternative. While it doesn’t replace a spectrum analyzer, it is more than good enough to verify that your board is transmitting and to perform basic RF debugging during development.
For your communications board, I would recommend taking a look at the SatNOGS COMMS project. There is a lot of documentation explaining how the board was designed, both from the hardware and software perspectives.

You will also find detailed instructions on how to bring up and test the board, what equipment you need, and how to verify that everything is working correctly. Even if you decide to design your own communications board, the SatNOGS COMMS documentation is an excellent reference and can save you a lot of time during development and debugging. For the ground station side, I would recommend starting by testing your communications board with an SDR. This is the easiest way to verify that your radio is transmitting and that you can receive and decode the signal correctly.

At the same time, you can build a SatNOGS Kit, install it on a rooftop or another location with a clear view of the sky, and start making your first observations. This will help you understand how satellite observations work in practice and give you hands-on experience with the receive (RX) capabilities of a ground station.

Later on, we can also help you design and build a more capable ground station that you can use to operate your own satellite once it is in orbit. To keep things simple and avoid overwhelming you with too much information, I would suggest the following:

First, spend some time reading about and understanding the SatNOGS COMMS project. The communications system is one of the most important parts of any CubeSat, and the project contains a lot of useful information about both the hardware and software.
Next, build your first SatNOGS Kit and start making satellite observations. This will give you valuable hands-on experience and help you understand how ground stations work in practice.
As you progress, don’t hesitate to ask more specific questions here. It is much easier to discuss real problems that come up during development than to cover everything in advance.

I would also recommend taking a look at the QUBIK project. It is a PocketQube, which is a smaller type of satellite, but you can still learn a lotabout satellite integration, assembly, testing, and the overall development process.

[aris12]

Some of the main open-source tools we use during satellite development are:

• KiCad for PCB schematic capture and board design.

• Qucs for electronic circuit simulation and analysis.

• FreeCAD for mechanical design and creating 3D models of parts and assemblies.

• openEMS if you want to simulate and analyze antennas or other RF structures.

• GNU Radio for SDR development, signal processing, and testing communication systems.