Author Topic: SpaceX COTS Demo 1 Updates  (Read 676030 times)

Offline Lee Jay

  • Elite Veteran
  • Global Moderator
  • Senior Member
  • *****
  • Posts: 8854
  • Liked: 3951
  • Likes Given: 360
Re: SpaceX COTS Demo 1 Updates
« Reply #1300 on: 12/30/2010 02:02 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.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 38196
  • Cape Canaveral Spaceport
  • Liked: 22667
  • Likes Given: 432
Re: SpaceX COTS Demo 1 Updates
« Reply #1301 on: 12/30/2010 02:24 am »


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

Offline Lee Jay

  • Elite Veteran
  • Global Moderator
  • Senior Member
  • *****
  • Posts: 8854
  • Liked: 3951
  • Likes Given: 360
Re: SpaceX COTS Demo 1 Updates
« Reply #1302 on: 12/30/2010 02:31 am »
Which they are finding out isn't a good format to downlink

They're trying to downlink ethernet?  That's a catastrophically horrid format to send over a long-latency noisy communications channel.  It would take some thought to design a format that's worse.

I thought everyone used one of the PCM formats for this?

Offline Antares

  • ABO^2
  • Senior Member
  • *****
  • Posts: 5181
  • Done arguing with amateurs
  • Liked: 371
  • Likes Given: 228
Re: SpaceX COTS Demo 1 Updates
« Reply #1303 on: 12/30/2010 03:58 am »
Also, 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.

Peace, not my intent.  I know things mentioned here are seen by a LOT of high-level lurkers and others who could substantiate Mr Block's account.  So the gauntlet is down.

As for freedom of expression, culture is fragile and sudden swings produce a LOT of unexpected results.
If I like something on NSF, it's probably because I know it to be accurate.  Every once in a while, it's just something I agree with.  Facts generally receive the former.

Offline mmeijeri

  • Senior Member
  • *****
  • Posts: 7772
  • Martijn Meijering
  • NL
  • Liked: 397
  • Likes Given: 824
Re: SpaceX COTS Demo 1 Updates
« Reply #1304 on: 12/30/2010 06:17 am »
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.

Wouldn't that data be very easy to compress? High frequency samples of a continuous signal?
Pro-tip: you don't have to be a jerk if someone doesn't agree with your theories

Offline Nomadd

  • Senior Member
  • *****
  • Posts: 8977
  • Virginia
  • Liked: 61021
  • Likes Given: 1372
Re: SpaceX COTS Demo 1 Updates
« Reply #1305 on: 12/30/2010 11:40 am »

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.

 The 20khz sample on the accelerometers surprises me some, but I can see it if you're using them to collect accoustical data or sub millisecond events. Or getting time stamps accurate enough to use them for figuring the propogation of such events. I didn't have the impression SpaceX went to that level, but I can see how it would add up.
 
 I'd think that if they were trying to use ethernet for downlinking, they'd use that spoofing whatchacallit protocol that geo sats use sometimes to stream it without the acks garbaging things up. Lose a lot of packets that way in noisy links though.
Those who danced were thought to be quite insane by those who couldn't hear the music.

Offline rklaehn

  • interplanetary telemetry plumber
  • Full Member
  • ****
  • Posts: 1259
  • germany
  • Liked: 191
  • Likes Given: 318
Re: SpaceX COTS Demo 1 Updates
« Reply #1306 on: 12/30/2010 12:07 pm »
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.

Wouldn't that data be very easy to compress? High frequency samples of a continuous signal?

Yes. Most telemetry compresses extremely well, especially if you do not mix different kinds of data before compressing. But to get optimum compression, you need to compress each telemetry stream separately, which requires a buffer for each stream. And obviously compression requires a lot of computing power.

However, you must be able to handle a situation where compression rate goes down quite a bit, for example because all signals become noisy because something "interesting" happens.

A system that is close to some limit (memory bandwidth, CPU usage, etc.) when processing normal telemetry might break down as soon as you feed it more "interesting" data.
« Last Edit: 12/30/2010 12:08 pm by rklaehn »

Offline kevin-rf

  • Elite Veteran
  • Senior Member
  • *****
  • Posts: 8823
  • Overlooking the path Mary's little Lamb took..
  • Liked: 1318
  • Likes Given: 306
Re: SpaceX COTS Demo 1 Updates
« Reply #1307 on: 12/30/2010 12:32 pm »
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.

Wouldn't that data be very easy to compress? High frequency samples of a continuous signal?

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.

If you're happy and you know it,
It's your med's!

Offline Robotbeat

  • Senior Member
  • *****
  • Posts: 39464
  • Minnesota
  • Liked: 25599
  • Likes Given: 12246
Re: SpaceX COTS Demo 1 Updates
« Reply #1308 on: 12/30/2010 03:03 pm »
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)

If 20kHz is "high rate," then data storage is no problem, even with hundreds of channels!
(And fiber gyros typically have update rates in the ~1000Hz range, not 20kHz, FYI)

The avionics bus would saturate long before you get to a data rate too high to store in something the size of a book of matches, if you only need 15 minutes of such data.
« Last Edit: 12/30/2010 03:05 pm by Robotbeat »
Chris  Whoever loves correction loves knowledge, but he who hates reproof is stupid.

To the maximum extent practicable, the Federal Government shall plan missions to accommodate the space transportation services capabilities of United States commercial providers. US law http://goo.gl/YZYNt0

Offline kevin-rf

  • Elite Veteran
  • Senior Member
  • *****
  • Posts: 8823
  • Overlooking the path Mary's little Lamb took..
  • Liked: 1318
  • Likes Given: 306
Re: SpaceX COTS Demo 1 Updates
« Reply #1309 on: 12/30/2010 03:39 pm »
Why are we arguing something no one here has any insight into ... We don't even know if they have even recovered what ever Talon is.

Yes we assume it is a data recorder designed to return data that will aid in future recovery efforts. RECOVERY EFFORTS are the key words.

We have no clue what data it records, to aid in recovery. It could be as simple as an accelerometer and gyro in a box that has zero interactions with the actual Falcon 9 avionics.

Does it record powered flight parameters? does it need to? How does that aid recovery?
Does it tap into the Falcon 9's data bus? Does it need to? Is the bus still active after the end of powered flight?
Are not the rockets brains in the US and not the First Stage? So it can not be directly attached to the brains (which are tasty with a of beans).
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.

It could even be a network analyzer that just records all the TCIP packets that get transmitted across the bus during the powered portion of the flight. That is within the realm of hardware one can use a paypal account to buy on ebay...
If you're happy and you know it,
It's your med's!

Offline Robotbeat

  • Senior Member
  • *****
  • Posts: 39464
  • Minnesota
  • Liked: 25599
  • Likes Given: 12246
Re: SpaceX COTS Demo 1 Updates
« Reply #1310 on: 12/30/2010 04:00 pm »
...
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.
...

The avionics have very strict timing and/or bandwidth requirements. It is set up so that time-critical messages always reach the intended hardware in time. That's what real-time programming is all about... The amount of "extra" bandwidth left over for other uses (like recording data from sensors) is finite but very well-defined. It's not risky to use this "extra" bandwidth, the time-critical messages are still guaranteed to reach their destination in time. This is different from "regular" non-realtime networks like you find in an office or data center.

But I agree that this is off-topic. I merely wanted to correct a mistake made by Lee Jay so that no one is left with an incorrect understanding of the situation.

I am very interested to hear more news about "Talon."
Chris  Whoever loves correction loves knowledge, but he who hates reproof is stupid.

To the maximum extent practicable, the Federal Government shall plan missions to accommodate the space transportation services capabilities of United States commercial providers. US law http://goo.gl/YZYNt0

Offline MP99

Re: SpaceX COTS Demo 1 Updates
« Reply #1311 on: 12/30/2010 05:08 pm »
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.

2.  Because most of the telemetry is analog and voluminous.  Especially for nine engines

I thought that the Talon was there to help with 1st stage recovery? If so, ISTM the period of interest is from stage separation onwards, so the Merlins would be shut down before this point.

I'd have thought the relevant info would be stage attitude before reentry, and then attitude & stresses on the frame during reentry?

cheers, Martin

Online meekGee

  • Senior Member
  • *****
  • Posts: 15716
  • N. California
  • Liked: 15870
  • Likes Given: 1443
Re: SpaceX COTS Demo 1 Updates
« Reply #1312 on: 12/30/2010 05:32 pm »
Do they know if the stage was in one piece by the time it was supposed to deploy the first chute?

If it's a deployment issue, a camera view would give a lot of information about the mis-deployment.   If the stage breaks up before deployment, then g loads and orientation is what they're after.

I wonder if the beacon stayed stuck to some piece of structure, and sunk slowly as they were racing for it.   I am sure they will be (have been) trying to downlink from the stage rather than look for a thumb drive in the middle of the ocean.
ABCD - Always Be Counting Down

Offline TexasRED

  • Full Member
  • ****
  • Posts: 429
  • Houston
  • Liked: 3
  • Likes Given: 9
Re: SpaceX COTS Demo 1 Updates
« Reply #1313 on: 12/30/2010 07:29 pm »


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

I thought the dragon page said they were on good ol' Mil Std 1553 and RS-422 also?

Offline rklaehn

  • interplanetary telemetry plumber
  • Full Member
  • ****
  • Posts: 1259
  • germany
  • Liked: 191
  • Likes Given: 318
Re: SpaceX COTS Demo 1 Updates
« Reply #1314 on: 12/30/2010 10:36 pm »
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.

No, if you have an analog signal representing a physical quantity that is slowly changing such as a temperature, you will only have noise in the last bit. So even common analog data does compress very well using a simple lossless algorithm such as deflate.

Quote
Remember all the video and audio compression we are very familiar with is lossy and "modifies" the original data.

Nobody would ever dare to use lossy compression for telemetry. But lossless compression works just fine. Let's say that you want to store a calibrated temperature as an IEEE 754 double. Each sample consumes 64 bit (plus the time stamp if you have a nonuniform sampling rate). But if the source of the data is a 12 bit A/D converter, there are only 2^12 distinct values. And assuming the temperature changes only slowly compared to the sample rate, only the last bit of these 12 will be random. So the compression might get the whole thing down to 1 bit per sample or less.

Quote
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.

If you use gzip compression, a simple checksum of the compressed data is calculated. But if you really care about data integrity, you should use a better checksum such as SHA1 even if it takes some time to calculate.

Offline kevin-rf

  • Elite Veteran
  • Senior Member
  • *****
  • Posts: 8823
  • Overlooking the path Mary's little Lamb took..
  • Liked: 1318
  • Likes Given: 306
Re: SpaceX COTS Demo 1 Updates
« Reply #1315 on: 12/30/2010 11:44 pm »
A few points on that

1. If the telemetry you are returning is time limited (like must come down during the powered phase of flight) you must have enough bandwidth for the worse case compression case. Something just south of uncompressed.

2. Not all data is slow changing some like say vibration which you would want to be sampling at a high rate (though it should be cyclic which leads to other ways to compress effectively).

3. I was trying to point out that many familiar (non space) high compression methods like jpg, mpg, ect. are lossy, loss less does not achieve as high a rate of compression for similar data.

4. Data corruption on compressed data usually results in making it very difficult to restore the data unless additional info is encoded (more bandwidth) into the data stream to pick up wayward bits. Yeah CRC's are not great. There are some fairly light weight ones I vaguely recall...

5. Though I really like SHA1 it is a little heavy weight. Besides, technically it is deprecated for new government work. You need to switch to SHA2 ;)  (I've been sitting through to many FDA 21 CFR Part 11 certifications meetings as of late ).


If you're happy and you know it,
It's your med's!

Offline jimvela

  • Member
  • Full Member
  • ****
  • Posts: 1696
  • Liked: 965
  • Likes Given: 84
Re: SpaceX COTS Demo 1 Updates
« Reply #1316 on: 12/31/2010 12:10 am »
Back in the bad old days when we actually had the capability to land men on the moon, telemetry meant that you collected the signals you needed, and downlinked them.  They were then recorded.

I know that we live in a brave new digital world, but everyone wanting to build some super duper flight recorder for the F9 first stage is mucking it up, in my opinion.  Unnecessarily complicated, unnecessarily rugged.

Do the same thing that the OGBs did- perhaps as simple as a couple of rocket cams to watch what happens and a simple transmitter spewing TLM for a ground station to record. 


Offline kevin-rf

  • Elite Veteran
  • Senior Member
  • *****
  • Posts: 8823
  • Overlooking the path Mary's little Lamb took..
  • Liked: 1318
  • Likes Given: 306
Re: SpaceX COTS Demo 1 Updates
« Reply #1317 on: 12/31/2010 12:20 am »
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.
If you're happy and you know it,
It's your med's!

Offline Lee Jay

  • Elite Veteran
  • Global Moderator
  • Senior Member
  • *****
  • Posts: 8854
  • Liked: 3951
  • Likes Given: 360
Re: SpaceX COTS Demo 1 Updates
« Reply #1318 on: 12/31/2010 12:24 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)

Actually, we're both wrong.  I wrote 1.5GB/s but I meant 1.5GB/min (since you used "120KB raw data per minute") but, force of habit, I just wrote "/s" without even engaging a neuron or two.  You didn't copy my channel counts exactly right, but the idea is the order of magnitude is about right (these are made up numbers anyway).

Yes, you could store it on a UDMA Compact Flash card for the whole ascent.  I wouldn't want to try to find it in the ocean, however.

Offline jimvela

  • Member
  • Full Member
  • ****
  • Posts: 1696
  • Liked: 965
  • Likes Given: 84
Re: SpaceX COTS Demo 1 Updates
« Reply #1319 on: 12/31/2010 12:27 am »
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.

True, but today we don't need to use film, we have the capability to broadcast, receive, and store HD quality video using tiny devices.

Then you don't have to hope that any magic box survives in order to tell you what went wrong.

Tags:
 

Advertisement NovaTech
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1