emusan

Blue Origin has not sent a rocket to mars in the sense that SpaceX wishes to send Starships to mars. They have sent a probe. SpaceX has launched probes to far further celestial bodies than Mars.

They have copied the external look of the rockets (which is, for obvious reasons, not protected by ITAR), but to my knowledge no one, China or otherwise, has managed to match the internal engineering prowess nearly a decade later.

To say that China is "very effective at copying all the stuff SpaceX is doing" is quite the stretch.

These are quite often used in defense and space applications where the flexibility of the DSP allows for custom waveform implementations that would otherwise require incredible CPU processing power or small batch ASICs. The versal fabric will only expand the potential use cases even further in these domains. Cost is often lower on the priority list for these as well.

There is hope for us lowly humans!

This is a difficult question to prescribe an answer for that works for everyone, but the best I personally can think of is "practice".

To make that more actionable... My approach in life has generally been to find a project (even something seemingly incredibly dumb, as long as it is fun), then work through it, learning what I need to know as I go along. To learn "well", you must then also constantly question what you have done as you complete various stages of the project to see if you have done them as effectively as possible, and try to incorporate any lessons learned into future projects.

I have found that how individuals do the learning required for this differs significantly from person to person, so it is hard to recommend any particular approach.

There are a few factors that make this possible:

1. As others have pointed out, the link budget (how much energy loss a particular radio link can handle before it is broken) for D2C satellites assumes a nearly direct line of sight from your handset to the satellite. This is much easier to achieve with satellites in space than it is with traditional cell towers that might have numerous walls/buildings in the way.

2. The D2C satellites use massive phased array antennas that are able to point a very narrow beam very accurately to the ground. This provides a substantial amount of antenna gain that further helps the link budget. The gain from the antennas allows the satellites to pick up even relatively weak signals from a handset.

There are other tricks as well, but these account for the largest differences. Of course, doppler gets in the way, but it is a solvable problem.

Curious to know what app you are using to get boundaries and layers, OnX?

I think “low speed” is quite a relative term here. PCIe serdes lanes are for very high data rate communication (> 1gbps per lane). This is the realm of the Syzygy XCVR standard.

The lower speed Syzygy standard, while not operating at these speeds, is capable of much higher rates than a typical microcontroller. There are many peripherals with I/O requirements beyond a simple LED or SPI device, but below that of a PCIe or other high rate transceiver such has:

- moderate to high end ADCs and DACs (LVDS and parallel)

- image sensors (LVDS, parallel, and HiSPI)

- various networking PHYs

The lower end syzygy connector has pinouts to support LVDS differential pairs, which can easily achieve hundreds of Mbps data rates.

With many of these types of standards (FMC and Syzygy) it becomes helpful to include some form of memory on the peripheral cards. With Syzygy it is required in order to store some helpful data about the card (product name, manufacturer) along with supported voltage ranges for an adjustable voltage rail from the carrier board. FMC used standard off the shelf I2C eeproms for this task, with some pins on the FMC connector used to indicate the address for the particular slot that the peripheral was attached to on the motherboard. We wanted to lose as few pins as possible for address lines on Syzygy, so we opted to instead use a microcontroller with an ADC for our peripheral flash memory. There was a single pin used to indicate the peripheral address. This pin had a fixed resistor to a power rail on the peripheral and the carrier would have a port-specific resistor to ground on the same pin. By reading the voltage across these resistors we defined 16 addresses with just a single pin. IIRC the microcontrollers we selected were almost the same cost as the I2C flash we would have used in their place!

It was a pretty neat hack.

Placing small microcontrollers on the peripherals also opened up other functions like using them for basic power supply sequencing.

Hadn’t expected to see this here! I helped put this standard together while working at Opal Kelly.

I think we had some nifty ideas in there (using an analog voltage for peripheral addressing was one of my favorite). It has slowly seen more adoption as time passes. Would always love to see more adoption!

I owned the first CAT phone with a FLiR thermal imaging sensor and this was by far my biggest gripe. The hardware felt like it was built to last a decade or longer, but the software was chock full of vulnerabilities from day 1, and I think they only provided a few months of proper software updates. I have since (reluctantly) moved to iPhone where I expect that (with my usage) the software should outlast the hardware.