Mro On Approach, TCM-3 not required Options

[Redstone]

MRO has shifted from the cruise phase to Approach phase. Apparently, the trajectory is so good that TCM-3 was cancelled. This is good news for the prospects for a long life for MRO supporting future missions. TCM-4 is on Feb 28, and MOI on March 10. Only 5 weeks away!

[edstrick]

I think we're dealing with paleolithic technology standards, maybe from the 70's or 80's.
<grin>

[Airbag]

I think we're dealing with paleolithic technology standards, maybe from the 70's or 80's.
<grin>

Perhaps, but the Small Deep Space Transponders are new technology and used by many current missions. There are only so many X-band channels and they are simply all used up. This is all from the DESCANSO MER telecoms report (very interesting reading I thought).

The spacecraft do have their own IDs, but best not to tempt fate with multiple bit errors etc. and perhaps accidentally accept and decode a command not intended for that spacecraft. And yes, that can happen - Opportunity accidentally went into safe mode during a solar opposition experiment in which a bunch of NOPs was changed into something else as multiple bit errors slipped by the error checking etc.

There are several techniques (other than the obvious one of using Mars itself as a "blocker") that can be used to make sure X-band signals intended for MRO (and that is the important one during aerobraking) only get to MRO. From memory, I can recall these (there were others too):

- Change Opportunity's antennas' polarization (so that it is opposite to that of MRO)
- Doppler adjustment for specific target
- Reduce transmit power level (MRO has more gain)

Airbag

PS BTW, receivers are typically *never* turned off (except during Opportunity's Deep Sleep).

[Bob Shaw]

Can I patent interplanetary MAC addresses - they could be stored digitally in a small solid-state pod, perhaps?

We could call, them, oh, iMACs and iPods...

Seriously, if a $10 network card can have a unique identifier burned in, why don't spacecraft?

Bob Shaw

[helvick]

Seriously, if a $10 network card can have a unique identifier burned in, why don't spacecraft?

I had a long boring waffle about bit rate, harmonics, the history of MAC addresses, Ethernet's emergence in the late 1980's and collisions on ARCNET networks in the early 1990's here but re-reading it made my eyes glaze over so I thought it would be better to simply point to the CCSDS website and in particular the Space Packet Protocol Blue Book Specification as an example of just hom much thought has to go into doing this sort of thing properly.

If only it was as simple as tagging each packet with a 12 byte target identifier.

[Bob Shaw]

I had a long boring waffle about bit rate, harmonics, the history of MAC addresses, Ethernet's emergence in the late 1980's and collisions on ARCNET networks in the early 1990's here but re-reading it made my eyes glaze over so I thought it would be better to simply point to the CCSDS website and in particular the Space Packet Protocol Blue Book Specification as an example of just hom much thought has to go into doing this sort of thing properly.

If only it was as simple as tagging each packet with a 12 byte target identifier.

I followed the links, and yes, there's a lot of work been put into the definition of the systems and architecture pertaining to Space Packets and wholly laudable commitments to international and interplanetary interoperability. But nowhere do I see such a thing as an analogue of a MAC address, which has historically provided a more-or-less fail-safe identifier for almost any bit of hardware. I still can't see why not...

...am I missing something?

Bob Shaw

[mcaplinger]

...am I missing something?

See the Global Spacecraft ID document: http://public.ccsds.org/publications/archive/320x0b1s.pdf

Of course, these are only 8 or 10 bits long.

But has been already pointed out, just relying on an ID field to reject commands would be foolish in the presence of bit errors. If you were designing a mission-critical system based on Ethernet (which probably wouldn't be a good idea anyway because of single point failures in the shared transmission medium) you would hopefully not rely on MAC uniqueness to keep the wrong receiver from doing something. It might be unlikely for a burst of errors to corrupt one MAC address into another in such a way to get past CRC checking, but it's not "fail-safe". Even with your home LAN, there are acknowledgement protocols in TCP/IP to keep such problems from happening.