3 ms·
>It happened so fast that there were only a few bits of telemetry between "everything normal" and "no signal". SpaceX also had an architecture that added a lot
by Rebelgecko 5mo ago
>It happened so fast that there were only a few bits of telemetry between "everything normal" and "no signal".
SpaceX also had an architecture that added a lot of latency to their telemetry transmission (IIRC basically Ethernet bufferbloat)
- GMoromisato 5mo agoThis is a good article about Amos-6: https://www.americaspace.com/2017/01/02/spacex-closes-amos-6-investigation-aims-to-launch-10-satellites-next-sunday/ https://www.americaspace.com/2017/01/02/spacex-closes-amos-6... "Investigators scoured more than 3,000 channels of video and telemetry data covering a very brief timeline of events – there were just 93 milliseconds from the first sign of anomalous data to the loss of the second stage, followed by loss of the vehicle." I haven't seen anything about latency--are you sure that's a problem in the telemetry stack?
- Rebelgecko 5mo agoIt featured heavily in the CRS-7 anomaly investigation (https://www.nasa.gov/wp-content/uploads/2018/03/public_summary_nasa_irt_spacex_crs-7_final.pdf https://www.nasa.gov/wp-content/uploads/2018/03/public_summa...). > SpaceX’s new implementation (for Falcon 9 “Full Thrust” flights) of non- deterministic network packets in their flight telemetry increases latency, directly resulting in substantial portions of the anomaly data being lost due to network buffering in the Stage 2 flight computer. However it looks that finding might've actually been corrected in the months before Amos-6, so moot point!