Communications framework | Communications Workgroup | Forum

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!

Another afterthought: I don't know if you already saw the link to this in the "Relevant discussions from Reddit" thread, but early on in this project, back when we were based on the Reddit social bookmarking site, someone who appeared to know that they were talking about made this post with rather a few communication related details.  However, he didn't hang around very long at all and is no longer active.  None of us know enough to tell if the things he recommended were sensible or insane, hopefully you can make sense of it and borrow good ideas where he had them and suggest better alternatives where he did not.

As far as I know, that one post is the most detailed communication related discussion that the project has ever had.

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?

Okay, let's try to re-open discussion of this and nail down some specifics.  After reading a little more on comms in Gemini I am feeling more confident about outlining definite requirements.

First, for the CM:

• Continuous, bidirectional voice link with ground controllers.
• HD video streaming to ground controllers which could be switched off to save power in an emergency but should be capable of running continuously if it's safe to do so.  While there may be multiple cameras on board, we should only need to send footage back from one at a time.
• Intermittent, one directional telemetry from CM to ground.  This will basically be a matter of sending bursts of data on a regular basis.  The time between bursts should normally be short (10 seconds tops) but should be adjustable so that we can send bursts every five or ten minutes to save power in an emergency.  The data bursts will be quite small, a few kilobytes at absolute most – probably just a bunch of floating point numbers for navigation data, cabin pressure, temperature, consumables levels, etc.
• Continuous, one directional control signal from ground to CM.  This will need to be able to send instructions consisting of a command from a predefined list and optionally some parameters.  The instructions will be quite short.  There's no way we'd have more than 128 different commands so commands could be encoded as an 8 bit string.  No command should require more than 10 parameters, even if each parameter was a 64 bit floating point number we're still in at way less a kilobyte.

Now, firstly, with regards to priority: the voice link is the most important, by far.  If the video stream dies, no big deal, it's not that important and it will all be saved to hard drives in the CM anyway.  If the telemetry dies, the astronaut can just read the relevant data out over the voice link as needed.

The control signal is the second most important, because on unmanned test flights, everything will be over if it fails.  On manned flights, the control signal should only be needed if the astronaut is incapacitated, which is probably an emergency situation and we want it to work.

The other two channels should of course be reliable but if they fail it is not super-critical.  Telemetry is probably more important than video.

So, order of importance: Voice link is the most vital, then control signal, then telemetry, then video.  Control signal and telemetry will require quite low bandwidth because we're not sending much over them at all.

Now, with regards to security: this is only important for the control channel.  We are bound by our Social Contract to release whatever is sent over the other channels anyway, so there is no problem with people picking them up themselves – in fact, good on them for doing it if they can, it would be awesome.  The control channel needs to be authenticated.  This does not necessarily mean encrypted.  We don't have a problem with people being able to see the control signals, just with people being able to send them if they aren't us.  Digitial signatures on the instructions would be enough for this, although encryption would do the job too – it may be easier to find off-the-shelf radio encryption hardware than signing hardware, I dunno.  Any way, this should be real security, not security by obscurity in the form of secret frequencies etc.

That's all we will need for the CM.  All of the above will need to have a range of around 400,000 km to get from lunar orbit to Earth.  Squid, any estimates on the power required to do this, the mass of the transmitting equipment or the shape/size/whatever of the antenna(s) would be appreciated a lot!

Now, for the lunar landing part of the mission:

• Once again, constant bidirectional voice link
• Once again, HD video stream.  We may want to send more than one stream at once here since this is where the exciting footage will be, but it will depend on what the lander's hardware can handle.
• Once again, telemetry back to Earth from the lander itself and the suit.
• No control signal this time – the time lag between Earth and the moon is too great for the prospect of landing the lander safely by remote control, so there is no need for it.

The interesting problems here are:

• A lot of the data (voice, video, some telemetry) will come from the suit, so the suit needs to have a comms system capable of relaying data through the landers' comms system.
• We have to make a decision about how to get data from the surface of the moon to Earth.  We could send it directly from the lander (meaning the lander's comms gear needs a 400,000 km range) or we could relay it through the orbiting CM (meaning the landers' comms gear needs a ~100 km range).  The big problem with relaying through the CM is that when the CM is on the far side of the moon, the suit and the lander are in complete radio black out.  This is not necessarily terrible, but if we could avoid it, it would be nice.  I guess the big question is: how much difference in power consumption, equipment size and antenna size are we going to see between a 100 km range lander and a 400,000 km range lander?  Squid, can you give us a rough, order of estimate idea?  If it is a considerable difference we should probably go with the CM relay and just plan around radio black outs.

That's everything I can think of, for the whole mission.  Any thoughts you can give us on this would be hugely appreciated.

I would love to have some real comms details in the CLLARE Project Overview document we are hoping to have ready by the end of Jan.  It doesn't matter if it isn't a perfect solution, if we have it all spelled out somewhere definitive, another comms person can come along at any stage later and improve it.  Something is better than nothing!

Post edited 2:30 am – January 13, 2010 by Luke Maurits

So, from what I understand, CDMA lets you send multiple signals over the same channel simultaneously, right?  By using a different code to interpret what you receive you can recover the individual signals?  Does this mean that we could use a single channel (i.e. a single transceiver) to handle all 4 tasks of voice, video, telemetry and control?  Or would the wide range of different bandwidths involved there make that a poor solution?

If this is the case, then using a single USRP we could have two identical transceivers in it (the board has 4 expansion slots, two for transmission and two for receiving) which would provide some redundancy of RF equipment.  However, if some common part of the board, like the USB interface, died then both transceiver sets would be out.  For full redundancy we might want two boards, with one transceiver in each.  They look fairly small and not very heavy.

The websites for the USRP boast of a pretty experienced userbase.  We may want to approach a mailing list or something to try to recruit more people to the Comms Workgroup.  This is assuming that the USRP is fundamentally an appropriate device to base our comms system on.  I don't know enough about radio hardware to know the answer to this.  The analogue-to-digital converters on the USRP have a sampling rate of 64 MS/s, is this good enough for our purposes?  The sampling rate puts some limitation on how fast we can send data, right?  Shannon Nyquist theorem or something?  (*pretends he knows what he's talking about*)