Teaching

My teaching and mentoring style is based on building small systems that expose the real problem. I prefer experiments that start with a physical or computational question, produce something measurable, and make failure modes visible. Code is part of the explanation, but so are data provenance, assumptions and validation.

Areas

The subjects closest to my current work are:

• machine learning for scientific data
• astronomy archives, catalogs and cross-matching
• radio astronomy and digital signal processing
• embedded systems and real-time software
• CubeSat flight software and onboard autonomy
• computer security and reverse engineering
• programming languages, interpreters and virtual machines

Learning materials

The blog contains practical notes that I use as supporting material. They are records of implementations and experiments rather than a formal course sequence.

Astronomy and scientific machine learning

• Astronomy Data Is Messier Than It Looks
• TAP for Astronomy Data
• Cross-matching Gaia and TESS with Python
• Training an Astronomy Model from Scratch
• Transit Vetting with a CNN

Radio astronomy and signal processing

• Fast Radio Bursts
• Dedispersion
• Matched Filtering from Scratch
• Building a Small RFI Classifier
• Beamforming and Aperture Synthesis

Embedded systems and software architecture

• Pulse: a Tiny Scheduler for Small Flight Software
• Porting Pulse to the Raspberry Pi Pico
• Building a Minimal Virtual Machine in Go
• TinyML under a Power Budget

Student projects and supervision

I am interested in supervising or collaborating on focused projects where the student can produce a reproducible artifact: a dataset, experiment, model, instrument, embedded prototype or documented software component.

Possible directions include:

• classifying or ranking radio transient and technosignature candidates
• measuring RFI and testing mitigation methods
• exoplanet transit detection and vetting
• astronomical catalog cross-matching and uncertainty analysis
• onboard ML for CubeSats and constrained hardware
• deterministic flight-software components
• autonomous ground-station scheduling
• biosignal or biosignature detection with interpretable models
• retrocomputing, compilers and small virtual machines

These are directions rather than pre-defined assignments. A useful project needs a narrow question, accessible data or hardware, a measurable result and a scope that matches the available time.

Working with me

Students contacting me about a project should include:

• their program and current stage
• the topic or problem that interests them
• relevant programming, mathematics or hardware experience
• the expected duration of the project
• links to code, reports or previous work when available

I value clear technical writing, reproducible code and honest reporting of negative results. A small experiment with well-understood limitations is better than a large project that cannot be validated.

Project inquiries can be sent to paolocmo@gmail.com. My existing software and experiments are available on GitHub.