Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They intentionally need to populate a certain number of terminals into specific geographic areas to test, measure and refine how time-sharing contention and the equivalent of TDMA is being setup. Each terminal has a GPS receiver in it and reports home with its location.


Do you think it's TDMA? I just assumed it would be whatever the latest CDMA technology is. The download probably doesn't really matter much one way or another since there's so much space between receivers that there's no practical chance of collisions. The satellite certainly must be able to receive multiple uplinks simultaneously, even in order to maintain a modest 15Mbps for multiple customers.


Satellite typically doesn't use cdma. See dvb-s


There's no reason to assume starlink works like a typical satellite, though. Digital video broadcast in particular is in one direction from geostationary orbit. Latency is on the order of several seconds due to all the forward error correction that's necessary to tolerate bit errors in reception. There's not really any need for a "multiple access" scheme because "channels" are statically allocated frequency bands.

I would think the radio technology in starlink should more closely resemble modern LTE and 5G cell networks, whether you want to call that CDMA, OFDM, or whatever the specific techniques these days are called.


> There's no reason to assume starlink works like a typical satellite, though.

And it does not. Starlink satellites do active switching unlike BSS satellites which only transmodulate and redirect.


Not true. Most modern geo satellites for internet have switching capabilities.


Satellites are interference limited and power limited. Dbv is not just for broadcasting, despite its name. It's used for pretty much all non-proprietary satellite waveforms.


That sounds like more conspiracy theories. For all we know it has a GPS receiver as a precise reference clock.


no, quite literally, if you move a beta terminal from your designated service location, it won't work. I know at least 4 people who also have beta terminals who have tried it. It depends on the size of your 'cell' - some people have been able to go a few km away, some people report it doesn't work even a few hundred meters away from their house. When you sign up for the beta you have to specify your street address and also click on an aerial map where you intend to install it.

And of course a GPS receiver is useful for timing.


I have heard speculation that the issue is actually satellite signal steering. They’re using phased array antennas on both sides so the satellites need to know where to be listening


They haven't released any real info on it. But there's been teardown videos of the CPE showing the phased array design. And the patent for the terminals, which is public, shows a dual beamforming phased array. It clearly needs to be in order to maintain a seamless make-before-break with rising and descending satellites that are illuminating specific areas on the ground with spot beams.


If it was just knowing where to focus, the terminal could send a low bitrate signal with that information. And/or they could let you punch in new coordinates before you go somewhere.


The satellite doesn't steer towards the user. Steering is too slow and there are too few beams to steer to all users.

Instead the satellite steers towards an arbitrary area on the ground, and the users must be within that area to work.


That's why it would break if you leave the active cells entirely. It's not why it would break if you move from one active cell into a different active cell.

And they don't have that many satellites. Each one needs to have a pretty large active area.


Taat makes sense, with a small number of users they are not likely to spend CPU time doing fast Fourier transforms and whatnot for areas with zero subscribers


They don't use cpus. They use fpgas, and the signal processing is done regardless of whether a user is there.


Are you sure about that? I see there's an article from a couple years ago talking about quad-core A53 CPUs with FPGAs. That's most likely used for the satellite avionics, rather than for the starlink radios. While it's possible the avionics and the radios are tightly coupled, I would be surprised if they were. They're probably mostly separate for fault tolerance reasons.

I suspect FPGAs wouldn't be fast enough to do the RF magic. I figure they likely partnered with a company like Qualcomm to develop some custom silicon, or adapted some existing cell tower silicon, since those chipsets are largely "software defined" these days anyway.


FPGAs are extremely commonly used in the RF telecomm space. You don't implement a multiplier in the free-form FPGA fabric, instead such FPGAs have banks of 'DSP blocks' which essentially give you hard silicon ALUs which you can then hook up however you want. This gives you extremely flexible and potentially massive parallelism with very tight latency guarantees, and you don't lose a huge amount of performance because most of the heavy lifting is in hard silicon anyway. Also FPGAs excel at high bandwidth I/O, which is usually extremely important in these use-cases. A DSP or even a GPU might give you more FLOPs per W or $, but they'll usually struggle with latency.

The quad-code A53 CPUs with FPGAs sounds like Xilinx's RFSoCs, which are explicitly designed to basically give you a custom high-performance base station on a chip (though they can't directly convert to the frequency range Starlink is using).


Not sure what your comment on the frequency range is implying. All signals are converted to baseband before processing. Nobody processes signals on the ground at Ku/Ka frequencies.


FPGA are also way easier to harden to sustains radiations in space. The custom silicon you mention is done by a french foundry, STmicroelectronics.


The response below mine goes into great deal, but yes, it's going to be fpgas, or an FPGA with a management cpu core in there. They had many reqs open for fpga developers early on.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: