thadjones

Appreciate it! Totally agree, your experience is what drove me to start building Vesper in the first place. Not only do you have to find the right hardware and manually scrape the specs, but then any time you change hardware you have to update it across a number of docs - keeping them all synced is a pain. And the alternative is an incredibly time-intensive and bloated MBSE model... My end hope is that Vesper can blend the low barrier-to-entry of an excel analysis with the interconnectedness of an MBSE model.

The goal is to get to exactly what you describe, with drag and drop tools that then basically give you an export of all your interconnects and performance analyses. As you point out, the reality is that the devil is in the details. For now, Vesper is focused mostly on surfacing the high-level, sanity check interface concerns and performance calculations, but I hope it can still add value at the concept definition -> proposal -> PDR phase of a program.

I also agree wholeheartedly with your other comment that some of the biggest challenges are jumping through the regulatory hoops like FCC licensing and range safety, so maybe once I've got the technical stuff limping along I can take a look at how to incorporate that process somewhat.

Thanks! The goal is for it to be primarily an architecture tool, although right now it leans more towards SatSearch as I think that will get eyes faster and because there needs to be a decently robust component library for the architecture tools to work. The idea is that you can set your primary mission parameters and CONOPs, and then to get immediate feedback on spacecraft performance metrics as you trade/change hardware in the Master Equipment List. Maybe the best way to think of it is as "PCPartPicker for spacecraft".

For example if you add/change a radio transmitter, you can see in real-time how that changes your system mass, power, and link margins, or be alerted if your flight computer doesn't support your radio's data interface.

This (hopefully) lets a spacecraft systems engineer iterate through trades more quickly, track performance and margin evolution over a program lifecycle, or quickly develop a baseline for a given mission class.

Definitely quite a bit of work to go to get there but feel free to create an account and poke around and break things.

Very cool, glad to see interest in this space. How does this differ from SkyDweller?

In practice, considerable difficulty. Like you said LEO moves fast. You are talking 10 min in line of sight (LOS) depending on the orbit. So the handoff algorithms (and necessary network) are very challenging and cost prohibitive. I mention it in my earlier response but if you have a LEO network you need pretty substantial arrays to accommodate such a power load, and during “night” for whoever is using the network, you need transfer mechanisms to relay the data, using even more power during eclipse. This is a real challenge.

Lasercom has been demonstrated well on Earth but it still is a very nascent technology in the space domain. There are several challenges that lasercom faces.

First, in order to enable global communication you need a constellation and good constellation management. This requires fewer spacecraft if you are in GEO, but GEO spacecraft tend to be larger and more expensive.

Second, lasers draw a lot of power. Most is waste heat as far as the spacecraft is concerned, but this can become a problem if the duty cycle is high. High power means much larger arrays, and for a LEO constellation, serious eclipse challenges.

Finally and most importantly, pointing is a challenge. Maintaining pointing control in space is hard, and lasers require much greater accuracy as compared to RF. With RF, the lobes are relatively large and allow some play when it comes to downlink to ground. Lasers are unforgiving.

I’ve led several spacecraft missions with lasercom terminals, and every time it has made development markedly more challenging. I think it will be quite a while before it is mainstream, and certainly before it replaces fiber.