I think I see the next natural progression in the open-source movement:
1) Open-Source Software
2) Open-Source Hardware
3) Open-Source Spacecraft
So ... if NASA and the other space agencies aren't willing to make use of this spacecraft, would they be willing to cede ownership to a group of hackers dedicated to helping the hardware continue its mission?
I've got quite a bit of ancient hardware in my basement, and while I was a broad-band RF engineer (in the cable industry), I know the theory behind narrow-band transmission. Anyone think we should start a Github project?
UPDATE:
It looks like the highest bit-rate that would be required would be 2048 bps:
"Tracking and telemetry support have been provided by the DSN (Deep Space Network) since January 1984. The ISEE-3/ICE bit rate was nominally 2048 bps during the early part of the mission, and 1024 bps during the Giacobini-Zinner comet encounter. The bit rate then successively dropped to 512 bps (on 9/12/85), 256 bps (on 5/1/87), 128 bps (on 1/24/89) and finally to 64 bps (on 12/27/91)."
This should be pretty easy to achieve with any UART. Now to find the frequencies used during communication.
UPDATE 2:
I'm currently working at the Pennsylvania State University and just sent an e-mail to a friend who's the Flight Operations Team Lead of the SWIFT Mission Operation Center here (http://www.swift.psu.edu/). More information as I hear back from those I've contacted!
The problem isn't a mater of openness, it is Could new transmitters be built? Yes, but it would be at a price no one is willing to spend. I imagine that it would be feasible to obtain the proper documentation, but there is the matter of building the hardware. More significantly, I suspect that duplicating DSN is a rather monumental task.
The transmitters and receivers that were designed and built in the '70s required lots of discrete components. The up-converters, amplifiers and matching networks will still need to be discrete components, but I'm estimating that the other 80% of the radio equipment can be implemented as a software-defined-radio (SDR - see http://spectrum.ieee.org/geek-life/hands-on/a-40-softwaredef... for an example).
I'll be reaching out to a friend and former colleague who specializes in this type of hardware/software.
I have no expectation that we can replicate even a tiny portion of the DSN, but I'm talking with people that already have big dishes and tracking capabilities. Remember that we don't have to talk to this spacecraft continuously. I think even downloading the last of its collected data would be a win but positioning it to do more science, then collecting data from it again in several months/years would be really cool.
"The Very Large Array, one of the world's premier astronomical radio observatories, consists of 27 radio antennas in a Y-shaped configuration on the Plains of San Agustin fifty miles west of Socorro, New Mexico. Each antenna is 25 meters (82 feet) in diameter. The data from the antennas is combined electronically to give the resolution of an antenna 36km (22 miles) across, with the sensitivity of a dish 130 meters (422 feet) in diameter. For more information, see our overview of the VLA, and the configuration schedule."
So, yes, with multiple IP-connected software-defined radios, you could provide the required signal strength without a Deep Space Network antenna.
At best, your signal will improve linearly with the number of antennas (N), while the noise will be completely incoherent and scale like sqrt(N). Thus your signal-to-noise ratio will improve like N/sqrt(N)=sqrt(N). You're going to need an awful lot of radios...
True ... and in this case, you don't have to worry about getting the spacecraft into space. The mechanical challenges are quite a bit simpler (steering antennas to track the space-craft). Perhaps we should make a high-level list of what needs to be done?
1) Find/track the spacecraft
2) Steer antennae to follow the spacecraft
3) Create transmitter and receiver hardware capable of communicating with the spacecraft's radio equipment (perhaps software radios).
4) Write software capable of handling the transmit and receive protocols.
5) Write software that captures the state of the spacecraft.
6) Write software that can control the spacecraft.
7) Decide where the spacecraft should go (hopefully, if we were to reestablish communications, perhaps NASA would help with the physics).
I think the bulk of the project consists of performing the research required to actually "speak the spacecraft's language". Fortunately, this part of the project is most conducive to crowd-sourcing and collaboration.
The problem is, how do you intend to introduce collaboration in this? It may be worth the shot, but it'd expect there's a big chance you won't be able to achieve that -- the "control space" of valid commands is likely very large and unstructured. You can't risk brute forcing it and seeing what happens because of the low rate and risk of failure from a bad command. There's also the responsibility of issuing a bad command. For such a scientific reverse-engineering you also need proper tools to observer the aircraft behavior which I imagine can be quite difficult -- what if a command sets the rotation rate of the aircraft to +1 arcsec/hr and that causes an antenna misalignment?
Unless, of course, you get full specification from relevant agencies and check with them before issuing any command. But that implies they're willing to apply resources on this project, which is another though barrier.
Anyway, sounds like quite an adventure. My sincere good luck.
Good points ... I don't intend to try this devoid of all NASA input (I've already reached out to a contact I have at SWIFT). I'm assuming two things right now:
1. That the documentation for the commands exists and that it's available to the project.
2. That NASA (or someone with sufficient knowledge) helps avoid issuing dangerous commands (e.g. running the spacecraft into the ISS).
Otherwise, it's probably better to do nothing. As I noted above, I view this more as crowd-sourcing the expensive "reengineering".
5.5) Determine how much fuel it still has. Per Wikipedia, "a [2008] status check revealed that all but one of its 13 experiments were still functioning, and it still has enough propellant for 150 m/s of ΔV. ".
I'm guessing that is not much. (Amazing that it still had any at all)!
As the comments in mention, with authorization from the FCC the HAM community would jump on this, there are lots of folks playing around with software defined radio who can build pretty much an arbitrary transmitter/receiver at any frequency band. Not sure if they would be successful but they would make a heroic effort to get it done.
1) Open-Source Software
2) Open-Source Hardware
3) Open-Source Spacecraft
So ... if NASA and the other space agencies aren't willing to make use of this spacecraft, would they be willing to cede ownership to a group of hackers dedicated to helping the hardware continue its mission?
I've got quite a bit of ancient hardware in my basement, and while I was a broad-band RF engineer (in the cable industry), I know the theory behind narrow-band transmission. Anyone think we should start a Github project?
UPDATE:
It looks like the highest bit-rate that would be required would be 2048 bps:
"Tracking and telemetry support have been provided by the DSN (Deep Space Network) since January 1984. The ISEE-3/ICE bit rate was nominally 2048 bps during the early part of the mission, and 1024 bps during the Giacobini-Zinner comet encounter. The bit rate then successively dropped to 512 bps (on 9/12/85), 256 bps (on 5/1/87), 128 bps (on 1/24/89) and finally to 64 bps (on 12/27/91)."
This should be pretty easy to achieve with any UART. Now to find the frequencies used during communication.
UPDATE 2:
I'm currently working at the Pennsylvania State University and just sent an e-mail to a friend who's the Flight Operations Team Lead of the SWIFT Mission Operation Center here (http://www.swift.psu.edu/). More information as I hear back from those I've contacted!