Hacker News Reader

Comment by Novosell | Hacker News Reader

How much data do you guys reckon they gather during this 24-second window? Gigabytes? Terabytes? I imagine they have redundant sensors for every measurement, if possible. The LHC generates 1 PB/s, though it filters it down to roughly 200MB/s[0]. I wonder how this compares.

0: https://www.lhc-closer.es/taking_a_closer_look_at_lhc/0.lhc_...

View on HN

I would imagine far less. The LHC captures many channels of sensors (for spatial resolution) and captures at very high frequency (because the time scales involved are fast and also because LHC is doing time-of-flight measurements).

I doubt that a rocket has anywhere near as many sensors (have you seen pictures of the LHC’s instruments? They’re basically all sensor), and I also expect that the timescales involved in rocketry are rather longer than in high energy physics.

Here’s a slide deck about ATLAS building an ASIC that reads something at 25 picosecond precision:

https://indico.cern.ch/event/799025/contributions/3486157/at...

Unless someone at Blue Origin is trying to localize a specific part of their flame by time of flight of light, I don’t see why time resolution even close to that would be at all useful. Perhaps they’re very fancy and want to tell which part of their rocket initiated an explosion by time of flight of sound, but that’s rather less demanding.

With the caveat, of course, that LHC events don’t explosively destroy the instrumentation. If you want useful telemetry in the last milliseconds before a rocket failure, you had better seriously harden your data logger or have very low latency transmission to a remote receiver :)

Combustion in the chamber happens at roughly the speed of sound in the F/O mixture. I don't know what the speed of sound in gCH4 is, but it's probably within an order of magnitude of air - air at 250 bar.

This is actually extremely important to model. Early F1 engines (Saturn V, not motorsport) were exploding and the engineers pretty much got lucky with the baffle design. Having a suite of sensors and then a computer model it would have saved lots of hardware and time - and really would have pretty much assured success. They were unsure if they'd succeed right up until they did.

Still way slower than what particle physics throws at you

(Wolphram Alpha gives me 743 m/s @ 250 bar and 1000C - could be wrong but probably the same OoM)

Yes, of course. I was clarifying, not disputing.

Speed of sound also depends on the temperature (i.e. speed of the gas molecules) which is high and variable. These kinds of coupled interactions make combustion instability really hard to model in CFD hence the importance of full-scale testing.

If you solve the formulas for calculating it, the speed of sound only depends on temperature. Mostly because temperature is dependant on pressure itself.

Temperature and molecular properties.. which guess what are also highly variable in combustion! Very messy stuff. Especially when you get into the actual nitty gritty of all the intermediate chemical species involved.

Not pure luck though, they tried 15 different baffle configurations. Would of course be easier to filter configuration in simulations.

There was enormous engineering effort put in with close coordination of physicists, but those 14 prior baffle configurations could have just as easily been 140.

For a relevant example, even just the oil formulation for Water Displacement on the exterior of the steel Atlas rockets took 40 iterations. Hence naming the product WD-40.

I wonder how many of the other baffle designs and water displacement formulations would still have been "good enough" - not optimal but usable?

At least for the baffles: None. That's why they kept going. Presumably there are even better possibly designs, but they were not discovered because one that works was found.

I don't know about the prior WD formulations.

You can fly to space with a 40ms control loop. It's a surprisingly low accuracy affair especially compared to particle physics. You're more likely capturing some actuator positions and discrete outputs and ensuring that everything sequences and responds to limits correctly, more on the level with an automobile CAN bus capture than it is anything else, and likely less than even 1 gigabyte.

There's likely more data stored in the video files from the cameras that observed the test than test data itself.

I'm just remembering that the images we got from Doves @ PlanetLab DWARFED the telemetry from the bus.

The system I worked on in the 2010s was pretty meager: 192kbits-per-second for the bus and about 54kbits-per-second (BITS, not BYTES) for the propulsion module. This is without video and doesn't count payload. It was also before we got the license for the beefy GHz S-Band, so we were sort of forced to make due.

But... you CAN get a lot of decent info from a low bandwidth link.

It depends on the number of PIDs and the speed of the data acquisition system. When I worked on the RS-25 engine project the engine had hundreds of PIDs, the low speed DAS was 250 samples per second, and the high speed DAS was 250,000 sps. The high speed DAS generated so much data that it was only started a few seconds before engine start so the recorders wouldn't fill up before the end of the tests (which were typically 500 seconds).

EDIT: something to add is that not ever PID was tied into the high speed DAS–only a couple-few dozen important PIDs.

Formula 1 car has over 300 sensors and generates 1.5Gb a lap.

So I would imagine this is generating hundreds of megabytes.

You are going to be limited by what you can transfer over radio.

I would wager the actually important data is far smaller. A single camera would probably dominate throughput

presumably the goal is to have the smoothest and most consistant combustion, and therefore less vibration, and known ,predictable resonant frequencys in the system. Which makes very small increments of time important.These rockets are consuming ? tons/sec of fuel, and then its a question of how "small" of an inconsistancy will break things. A simple but true engineering pricipal, is that any noise, is proof of ineficiency, and therefor a full examination of the audio frequency , coupled with video of the flame.Other data that might be nice would be to know exactly what is happening inside the turbo pumps,and fuel lines. The whole thing is so violent, that resonant phenominon not seen anywhere else, could be doing very weird things inside tanks and lines. And sensors for that, especialy video, could be challenging to engineer. Here is a wierd fact about a high pressure diesel fuel line: the pressure pulse (-+ 10000psi) causes a travelling expansion in the fuel line, that then causes a magnetic pulse, which can be detected, but you want to be quick about it, eh!

can confirm.

Not much, really. Most sensors are low speed: tens to hundreds of Hz. Then you have some high speed sensors, like strain gages, that are up in the 30+ kHz range.

I'd be surprised if it was more than a gigabyte. I work in spacecraft operations and the sampling and telemetry rates are not that high. At most they'll be monitoring a few hundred parameters at the order of 10Hz. That doesn't add up to a lot over 24 seconds. The biggest contribution to the data budget is most likely to be the video.

Probably gigabytes. When I worked with other systems in the past we needed to upgrade our gigabit ethernet to handle the full-rate telemetry

Do you mean upgrade to gigabit or from gigabit to 2.5Gbps or 10Gbps?

1 gigabit wasn't enough for full rate telemetry

> Terabytes

Terabytes to petabytes. Much is noise. But you’re already making sensor-level keep/discard decisions due to the magnitude of the deluge.

Note that this includes cameras, of which modern telemetry includes many.

Reply on news.ycombinator.com