Devlog #2 – From Theory to Implementation

Project Progress

This session marked the transition from learning concepts to beginning the actual development of the Collision Risk Analysis Tool. I continued strengthening my Python skills while also applying orbital mechanics to real satellite data.

What I Worked On

• Completed one additional Python lesson to improve my understanding of programming concepts and syntax.
• Learned about Two-Line Element (TLE) data and how it is used to describe a satellite’s orbit.
• Studied the different parameters contained within a TLE and how they represent a satellite’s position and motion.
• Used TLE data to manually calculate the miss distance between satellites, helping me understand the mathematics behind conjunction analysis rather than relying on existing software.
• Began writing the first sections of code for the Collision Risk Analysis Tool, laying the foundation for future development.

Challenges

• Understanding the structure of TLE data required careful study, as each value represents a specific orbital parameter.
• Translating orbital calculations into code was more challenging than performing them manually, requiring additional planning before implementation.

What I Learned

• TLE data provides the essential orbital information needed for satellite tracking and conjunction analysis.
• Calculating miss distance manually gave me a much better understanding of how collision risk is determined.
• Writing software for orbital analysis requires both programming knowledge and a strong understanding of the underlying physics.

Next Goals

• Continue developing the Python codebase for the application.
• Automate the process of reading and interpreting TLE data.
• Implement calculations directly within the software instead of performing them manually.
• Begin testing the program with real satellite datasets to verify the accuracy of the calculations.
• Research methods for estimating collision probability once miss distance calculations are functioning correctly.

This session was an important milestone because it connected the theoretical concepts of orbital mechanics with practical software development. By combining Python programming with real TLE data and beginning the implementation of the tool, the project has now moved from the research phase into active development.

Devlog #1 – Collision Risk Analysis Tool

What I’m Building

I’m starting work on a Collision Risk Analysis Tool that aims to estimate the probability of collisions between objects in Earth orbit. The long-term goal is to use publicly available orbital data to analyze satellite trajectories, identify close approaches, and visualize potential collision risks in an easy-to-understand way.

What I Worked On

During this session, I focused on building the knowledge needed before starting development.

• Completed 4 introductory Python lessons to learn the fundamentals.

• Learned about:

  • Variables and data types
  • Loops and conditional statements
  • Functions
  • Basic input/output

• Began understanding the basics of orbital physics, including:

  • How satellites stay in orbit
  • Orbital altitude and velocity
  • Different types of Earth orbits (LEO, MEO, GEO)
  • Why orbital paths can intersect and create collision risks.

• Explored where real orbital data can be obtained and researched publicly available satellite datasets that can be used later in the project.

Challenges

• Understanding orbital mechanics was more difficult than expected because many concepts rely on physics and mathematics that are new to me.
• Finding reliable and usable orbital datasets required comparing multiple sources to determine which ones would be suitable for analysis.

What I Learned

• Python is much more approachable once the basic concepts are understood.
• Collision prediction depends heavily on accurate orbital data rather than just writing code.
• A strong understanding of orbital mechanics will be just as important as programming throughout this project.

Next Goals

• Continue learning Python and begin writing small practice programs.
• Learn how to read and process orbital datasets using Python.
• Research orbital elements (such as TLE data) and how they describe satellite orbits.
• Build a simple program to load satellite data and display basic information before moving on to collision analysis.
• Begin planning the overall architecture of the Collision Risk Analysis Tool.

Overall, this session was focused on building a solid foundation in both programming and orbital physics. Although no code for the final application has been written yet, the knowledge gained will make future development much more structured and efficient.

I finally fully finished the PCB, I had to change the layout entirely to be able to do the wiring correctly without getting stuck. I added some art which I was able to, Which will be visible in the 3D model. The next goals are: Working on the 3D model of Aegis Pad on Fusion360!

Today’s session was focused on improving the readability of my KiCad schematic before continuing with PCB routing. Although I did not make significant progress on the PCB itself, I spent time understanding how the schematic should be organised and how keyboard matrices are represented using net labels instead of long crossing wires.

What I worked on:

Reorganised the schematic into separate sections for the:
Microcontroller (XIAO RP2040)
OLED display
Switch matrix
Rotary encoder
Replaced many long wires with net labels (e.g., ROW1, ROW2, COLUMN1) to make the schematic much cleaner and easier to read.
Learned the difference between normal text and KiCad net labels/global labels after accidentally placing the wrong type.
Verified that all row and column labels matched the correct GPIO pins on the XIAO RP2040.
Added section titles to improve readability and make the schematic easier for others to understand.
Ran KiCad’s Electrical Rules Checker (ERC) and confirmed there were 0 violations, meaning the electrical connections are valid.

Challenges encountered:

I initially struggled to understand how experienced keyboard designers create such clean schematics.
I accidentally used normal text instead of net labels, which caused confusion because they looked almost identical.
I spent a considerable amount of time checking whether the row and column assignments were correct before removing the original wires.
PCB routing is still proving difficult, and I have not yet found an efficient routing strategy for all the switch matrix connections.

What I learned:

Schematics should prioritise readability rather than showing every physical wire.
Net labels make complex circuits significantly easier to understand.
Organising components into functional blocks improves documentation and makes debugging easier.
Passing ERC does not necessarily mean the PCB is finished, but it confirms that the schematic is electrically consistent.

Next steps:

Finish organising the remaining components and labels.
Update the PCB with the revised schematic.
Continue routing the switch matrix while minimising trace crossings.
Add silkscreen artwork and labels once the PCB layout is complete.
Run PCB Design Rule Check (DRC) after routing to identify any layout issues.

Finally Started with the PCB of my Macro Pad after finishing the schematic, However, I do feel like there can be some improvements since I am currently struggling with the wiring. I will try to figure out if there is a better way to make the PCB. For now I am happy there were no major errors when running the schematic.

I just started my own custom macropad after finally finishing the tutorial, currently figuring out how to draw the schematic since I want to add more keys and an oled screen! Still under progress though… As a beginner this is quite challenging without any experience but I am learning throughout the process! The goal is to make 9 keys (similar to a number pad) and a cute oled screen with a custom animation.