Ground Station

I've been looking at that. Do we have a template for the requirements document?

I would suggest basing it off of the Shepard Test Stand Requirements Document

Instead of STSR for "Shepard Test Stand Requirement", it could be GSR for "Ground Station Requirement". That is, unless you want to put choose a name for this project. For example, if you named it "Terra" you would add the T onto the beginning - TGSR.

One of the things I want to bring up in the Shepard documentation review is how far we want to carry this naming convention. Right now we only use it on the requirements and safety procedures (STSSP), but it probably would make it easier to refer to specific parts of the documentation if we carried the convention all the way the documentation, or at least through the operating manual. It's much easier to refer to "STSSP 1.1" in an after action report than to say "item 1 under the heading "Fire Safety" in the safety procedures document".

Now that the requirements document is complete, though not necessarily gelled, the next step seems to be the architecture study. This does not seem to have an analog in the STS arena... so what is expected here?

There's no precedent for the architecture study on ODE yet, and I've only had time to think about it a little bit. It would be good to try to find examples of other engineering architecture studies (a quick Google search didn't yield any), and I think it would be best to check in with J. or Greg to see what their thoughts are as well.

If neither one of them already have a doc structure in mind for it, I think I can add two cents or so based on the information that you've published in this post. A few items that J. has already shared off channel about what he'd like to see in the architecture study are as follows:

1. Identify the major elements of a ground station.
2. Break those elements down into kite-level phases.
3. Identify existing implementations of the major elements and score them (open source has some preference over closed options, but closed options are fine by me if there are many suitable and easily substituted ones).

You have all of these elements in this post I think, everything just needs to be pulled together into a cohesive document. I need to take a good look back through this post over the next few days to see what I think we need to pull from it.

That's pretty much where I was going with it. We have covered all the salient points in the forum, and once again all we need to do is pull this into a coherent document for the wiki.

I've had some thought which represents a fairly substantial departure from what we discussed so far. I mentioned some of it in our discussion in the monthly meeting and it seemed to be well received, but we should of course make this formal. I am recommending the following with all appropriate changes made to the requirements document:

Version 1.0 should have the following kites:

Receiver "Goldstone" is a level 1 kite. It involves construction of an eggbeater antenna with phasing network and SDR in base. SDR is a generic USB TV dongle based on the RTL2832U chipset which allows coverage in a wide band to include VHF Ham bands used by amateur satellites and ISS public channels. This device is grounded by either screw terminal if mounted on a vehicle or structure, or spike driven into the ground to serve as both grounding and stabilization. Connection to the computer is standard USB cable which provides both power and data. Satellite pass prediction and operation of the SDR dongle use a computer running GPredict and GNUradio software. Since this device is receive only, no licenses are needed in the US for operation. and will allow those interested in hearing space utilization to do so easily with little expense.

Transmitter "Parks" is a level one kite. It involves construction of an eggbeater antenna with phasing network and SDR in base. SDR is a generic USB TV dongle based on a full digital synthesis hybrid chipset which would allow operation in a wide band to include UHF Ham bands used by amateur satellites and ISS public channels. This device is grounded by either screw terminal if mounted on a vehicle or structure, or spike driven into the ground to serve as both grounding and stabilization. Data connection to the computer is standard USB cable, and power is provided by an external source since it would be difficult to provide more than a watt of output power using USB. Satellite pass prediction and operation of the transmitter use a computer running GPredict and GNUradio software. The software must be by the user programmed to observe frequency and power limits for the specific location (national jurisdiction) and license class.

Directional System "Guymas" is a level one kite. It involves construction of X-yagi directional UHF and VHF antennas as well as an azimuth-elevation rotator assembly. Using it's own microcontroller for control and communication, this unit will interface with a PC running Gpredict to accurately point the antennas using stepper motors. The unit should be designed to use off the shelf components and 3D printed plastic parts throughout. The unit will be designed to clamp on to a 1 3/8" pipe to mount to the top of a radio tower or speaker stand for portable operation. Connection to the radio transmitter and receiver is performed by extracting the SDR transmitter and receiver from the Goldstone and Parks assemblies (or getting new ones) and attaching them to the new directional antennas. For simplicity in portable operations, a power supply and USB hub should be mounted to the mechanism. Since this is not a transmitting project, no license is needed in the US for operation.

Version 2.0 should add transmit and receive capability on an L-band dish for command and control functions. This can be accomplished in two level one kites, one for the receiver and one for the transmitter. It should be noted that the electronics portion of this project will be relatively simple since the hardware selected for Goldstone and Parks is already capable of hitting those frequencies. They only require construction of the feedhorns and procurement of the dishes. Software wise, effort should be made to be able to stream the ground station data and audio to the internet.

Version 3.0 and beyond is where the real challenge comes in the form of the software. While some effort has been made to standardize telemetry datasets and command sets, this is far from perfect. A central server should log the raw information coming from all ground stations, reconciled by time stamp. Server software should take data from elements of the telemetry and control present it custom web based control panels. This technology would allow open space missions to be spooled up quickly, with no requirement for specialized or identical hardware, or even for the mission control operators to be in the same place.

That sounds good to me (including the names), but I do have a few questions.

1. Do you need to re-specify the construction of the eggbeater antenna in Parks if you've already done it for Goldstone? Maybe add some wording to make it clear that you're just building a duplicate from the Goldstone plans?
2. Under Parks, "The software must be by the user programmed..." should be "The software must be programmed by the user..." or "The software must be configured by the user..." if it's GPredict and the user doesn't have to write any code. The current wording sounds like you're channeling Yoda :) "Programmed by the user the software must be...hmmmm..."
3. In Version 3.0, "...from elements of the telemetry and control present it custom web based..." seems awkward. I'm not quite sure what you mean.

Nice work, I like it.

Some changes were proposed which led to a whole new train of thought and a better project. These are outlined below:

1. To allow people to use the equipment, satisfy curiosity, and listen in on space activities, all without a license, the first project is a simple radio receiver with an omnidirectional antenna.
2. One of the least expensive and most capable receivers is an inexpensive USB TV dongle based upon the Realtek RTL-2832U chipset running GNURadio software. It is capable of 24-1766MHz reception.
3. When this is combined with a rugged circular polarized omnidirectional antenna, a ground station receiver may be designed which fits in a very small space for under $100.00.
4. Using a Software Defined Receiver (SDR) helps to create a much more versatile project since this device can tune from HF to L/C band microwave with only the replacement of the antenna assembly.

These changes alter the entire architecture of the project, and will result in radical changes to what had been designed before. Over the next few days we will review the project documentation and make it match the current project details. Any thoughts on procedure or recommendations would be greatly appreciated.

One of the things we have been talking about in hangouts and over email is how we can tie lots of ground stations across the planet together into a cohesive network with complete coverage of the sky. While looking at some Youtube videos about SDR I found this very interesting site: http://www.websdr.org/ It let's users access SDR servers all of the country (planet?) from a web page. The server software is not open source, but the developer is willing to give people access to it if they are running a publicly available server. It might be worth talking to the developer about what we want to do to see if he can share lessons, source code, etc with us.