Forum | Communications framework

These are all very good questions.  Unfortunately, we can't answer many of them because we have an extreme shortage of communications knowledge.  Every time somebody who claims to know their comms shows up to the project, they make one or two posts and then leave for good.  None of our active and dedicated members really know what we are talking about.

With regards to what we will need to transmit:

• The astronaut will need to be in voice contact with someone on Earth at all times, except for brief blackout periods when the moon is in the way.  Note that this will need to work while the astronaut is inside the Command Module (the majority of the trip) and on the lunar lander and during lunar EVA.
• We will want to have HD video footage sent from inside the CM cockpit, on the lunar lander, and possibly other places.
• We will want to have telemetry data sent from the CM to Earth pretty regularly (detailing temperature and pressure readings, gas supplies and voltage levels, estimated positions and velocities, perhaps a few medical sensors, etc.).  I don't know whether it would be best to have an automated system send these things constantly on some kind of loop or have a situation where a ground system can interrogate the CM for specific values (or both).
• Ideally we will want the CM to be remotely controllable so we can do unmanned test missions.  This probably just involves being able to send a pre-defined set of control commands.  We would probably want to do some sort of authentication over this channel.

This is all I can think of for now, but others may chip in with more (most of our members are in the Northern hemisphere so you may not see any replies for hours, but rest assured you will get feedback on this).

As for power requirements, we are anticipating that communication will be one of our biggest power drains.  The answer is basically "as little as we can get away with while ensuring everything will work reliably".  Basically, the Communications Workgroup gets to say "comms will need x kW of power to do this properly" and the Spacecraft Engineering Workgroup has to come up with a power solution to make this possible (right now we are considering using oxygen-methanol fuel cells for power generation, I should be able to chase down the power specs for these if you like).  Right now we have no idea – if you could give us even an order of magnitude estimate that would be a huge help.

Things like modulation schemes will be left up to people like you who know what they are doing!  Just post whatever you think would be the most appropriate modulation scheme to get what we want from the moon to Earth, with as little power as possible but bearing in mind that we want it to be reliable and won't have access to big expensive antennas.  Eventually another comms engineer will come along and either agree with you or disagree.  Once we have a few people agreeing on one scheme being the best choice, we can "lock that in" and go from there.  If you don't feel confident making a decision, just post a list of good candidates with Wikipedia links and others can have a read and offer their opinions.

Right now you are the only person here who knows what they are doing in this field, so you can basically lead the charge for now.  CLLARE is a long term project so if you make mistakes, somebody will notice them well before it matters.  Be bold!

What precisely do you mean by "limited in our error correction…due to large propogation delays"?  I can see how this would be the case if we used a system of, say, including checksums at the end of data packets and requesting a resend if the checksum is wrong, but aren't there error correcting codes (like Reed Solomon, for instance) where the point is that as long as the number of errors in a given packet is below some threshold, the error can be recovered from without resending data, due to redundancy in the encoded version?  I'm sorry if this is a stupid question, I'm sure you know more about error correcting codes than I do, but I know a bit about them and this confused me.

Robustness is definitely important.  I don't know anything about CDMA (my mind translates it into "not GSM"), but I'll read up on it soon.

With regards to security:  I actually know a lot about cryptography (wrote my honours thesis on maths very relevant to it and originally planned to be a cryptographer) but relatively little about stream ciphers (although I know the basics and wrote the Wikipeida article on correlation attacks), which is what I expect it would be easiest to use in this case (although I don't really know anything about digital radio communications, maybe block ciphers would actually work just fine).  I am happy to help out with regards to security planning where my understanding of telecoms allows.  Maybe you could expand a little on what you had in mind when you mentioned the use of pseudo random codes?