2 bytes of data gives you 64k analog resolution, so 1,000 samples per second would only be around 120KB raw data per minute if you had some nice clean software that only stored results. Been in this discussion with airliner folks who were convinced that you couldn't send real time system monitoring without using "Huge" amounts of bandwidth. You can pack a pretty impressive number of high resolution/rate analog readings into a small data stream if you're old enough to remember when efficiency counted and you didn't get to use 4 thousand lines of code to read a switch.
3) I bet it'd uses the Falcon 9 avionics bus, which I believe is ethernet-based (and thus higher bandwidth than older legacy digital buses which might not be able to handle the necessarily throughput), so is the "former." An embedded processor of that capability is pretty common-place, though... Since the data is presumably already digitized, you just need to get the requisite streaming throughput, which I highly doubt would be over 100MB/s. I don't know if the rad-hardening requirements would that great for a first stage "black box" like this. You could probably get by with just good ECC.
Which they are finding out isn't a good format to downlink
Quote from: Antares on 12/29/2010 04:51 amAlso, I demand photographic proof of "WWED" - and I hope the amazing people are given junk assignments.Demand proof from the Orlando Sentinel. That's where the "WWED" stuff comes from. Or is independent verification needed before any news story can be discussed here? Hardly.
Also, I demand photographic proof of "WWED" - and I hope the amazing people are given junk assignments.
Now, imagine you have 70 such channels plus a couple of tri-axial accelerometers you want to sample at 20kHz. On each engine. And you have another hundred or so channels on the stage and FTS. And you have a similar situation on the upper stage, just with one engine. I make that at over 1.5GB/s.
Now, imagine you have 70 such channels plus a couple of tri-axial accelerometers you want to sample at 20kHz. On each engine. And you have another hundred or so channels on the stage and FTS. And you have a similar situation on the upper stage, just with one engine. I make that at over 1.5GB/s.It can add up when you have a few high-rate channels and when you have hundreds and hundreds of channels.
Quote from: Lee Jay on 12/30/2010 02:02 amNow, imagine you have 70 such channels plus a couple of tri-axial accelerometers you want to sample at 20kHz. On each engine. And you have another hundred or so channels on the stage and FTS. And you have a similar situation on the upper stage, just with one engine. I make that at over 1.5GB/s.Wouldn't that data be very easy to compress? High frequency samples of a continuous signal?
Quote from: Nomadd on 12/30/2010 12:18 am 2 bytes of data gives you 64k analog resolution, so 1,000 samples per second would only be around 120KB raw data per minute if you had some nice clean software that only stored results. Been in this discussion with airliner folks who were convinced that you couldn't send real time system monitoring without using "Huge" amounts of bandwidth. You can pack a pretty impressive number of high resolution/rate analog readings into a small data stream if you're old enough to remember when efficiency counted and you didn't get to use 4 thousand lines of code to read a switch.Now, imagine you have 70 such channels plus a couple of tri-axial accelerometers you want to sample at 20kHz. On each engine. And you have another hundred or so channels on the stage and FTS. And you have a similar situation on the upper stage, just with one engine. I make that at over 1.5GB/s.It can add up when you have a few high-rate channels and when you have hundreds and hundreds of channels.
...Do you really want extra messages on the data bus for a black box? The nature of the bus choice dictates you want to keep the traffic on it to a min so you do not have bottle neck's that keep time critical messages from reaching the intended hardware....
Quote from: Nomadd on 12/29/2010 05:55 pm2. I never could figure out what was so hard about feeding data to an epoxy foam encased memory stick that would survive a thousand Gs and float.2. Because most of the telemetry is analog and voluminous. Especially for nine engines
2. I never could figure out what was so hard about feeding data to an epoxy foam encased memory stick that would survive a thousand Gs and float.
Quote from: Robotbeat on 12/30/2010 01:06 am3) I bet it'd uses the Falcon 9 avionics bus, which I believe is ethernet-based (and thus higher bandwidth than older legacy digital buses which might not be able to handle the necessarily throughput), so is the "former." An embedded processor of that capability is pretty common-place, though... Since the data is presumably already digitized, you just need to get the requisite streaming throughput, which I highly doubt would be over 100MB/s. I don't know if the rad-hardening requirements would that great for a first stage "black box" like this. You could probably get by with just good ECC.Which they are finding out isn't a good format to downlink
Most likely to random ... compression only works really well if it is LOSSY (not a good idea for this need) or has a fair amount of duplicate data. High resolution AtoD data never compresses very well.
Remember all the video and audio compression we are very familiar with is lossy and "modifies" the original data.
It would be more important to record it along with extra checksum like data that indicates the data is intact and untampered with or corrupted.
Quote from: Lee Jay on 12/30/2010 02:02 amQuote from: Nomadd on 12/30/2010 12:18 am 2 bytes of data gives you 64k analog resolution, so 1,000 samples per second would only be around 120KB raw data per minute if you had some nice clean software that only stored results. Been in this discussion with airliner folks who were convinced that you couldn't send real time system monitoring without using "Huge" amounts of bandwidth. You can pack a pretty impressive number of high resolution/rate analog readings into a small data stream if you're old enough to remember when efficiency counted and you didn't get to use 4 thousand lines of code to read a switch.Now, imagine you have 70 such channels plus a couple of tri-axial accelerometers you want to sample at 20kHz. On each engine. And you have another hundred or so channels on the stage and FTS. And you have a similar situation on the upper stage, just with one engine. I make that at over 1.5GB/s.It can add up when you have a few high-rate channels and when you have hundreds and hundreds of channels.No, you're wrong.You skipped two zeros.It'd be 15MB/s based on what you just said.((70*1000Hz+2*3*20000Hz)*9+300*20000Hz)*2Bytes = ~15MB/s(you can easily check this in Google if you wish)
And the Saturn recoverable film pods where? They did something similar to Talon on film for Saturn, though if memory serves, not every film pod was recovered.