November 2006 - Eagle (INACTIVE)

Solar Power Systems -- White Paper FYI
by Tom Clark, K3IO 11 Nov '06

11 Nov '06

1 1

New integration lab, new relationships
by Robert McGwier 09 Nov '06

09 Nov '06

This note is informational and not for publication. The official announcement will come from Rick Hambly on behalf of AMSAT and be made in the form of a press release. Let me say that I consider these happenings to be a serious beginning of the activities towards a real spacecraft. I want to apologize for my being a wee bit quiet in the last few weeks but there have been nice things brewing. A few weeks ago, Bob Davis, KF4KSS, and I had a conversation about his future in business and his future with us. Bob was an AMSAT employee in the labs in Orlando during the integration of AO-40. Many credit Bob with doing some of the best work done in the mechanical area during that program. Bob was a aerospace engineering student and AMSAT made a great move hiring him. Dick Jansson, Lou McFadin, Jan King, Karl Meinzer, and more were/ are universally supportive of Bob and his abilities as a spacecraft mechanical engineer. After the AO-40 program "went to bed" and into orbit, the Orlando activity wound down. Bob wound up at SpaceDev and was an important part of the Chipsat program. He eventually left SpaceDev as their fortunes changed (which had nothing to do with the spectacularly successful Chipsat) and became an employee of Swales, a well known aerospace firm in the D.C., Maryland,Va. area. Bob and his peers became successful and landed a good support contract with Wallops-NASA. Eventually, they decided to leave Swales and join the University and the Maryland Hawk corportation and to become an important partner to the university, Wallops, and now AMSAT. When it became clear to me the scope of their ambition, and many other factors, but most importantly, having Bob Davis involved, I recommended to Rick that we consider this as our new facility. Rick Hambly, Tom Clark, Jim Sanford, Bob Davis and I have been working with the University of Maryland on the eastern shore and this spin off of the university called Maryland Hawk Corporation with the goal being to enter into a working relationship that we hope will last for years. Maryland Hawk operates the Hawk Institute for Space Sciences in Pocomoke, Maryland. HISS has access to the spacecraft engineering facilities at Hawk and at Wallops (including machine shop, thermal vacuum chamber, and shake/shock test apparatus). The University of Maryland branch affiliated with HISS is in Princess Anne. Md. They are both within 1/2 hour of NASA's Wallops facility. We have decided that this is a spectacular opportunity for AMSAT to do a win-win-win deal. The deal is done on AMSAT's side. The AMSAT board of directors unanimously approved a memorandum of understanding with the University of Maryland and another with Maryland Hawk. Maryland Hawk will be our integration and testing facility. We will have 6000 square feet of machine shop and integration facility. The clean room from AO-40 will become the first clean room in the new facility. The employees of HISS will be on our satellite building, testing, and integration team along with lots of help from volunteers but we will definitely have a superb core unit on site at all times. This will also allow us to maintain the controlled access which will be required (legally) for our operations. Hawk is very ambitious and AMSAT is going to get ambitious with them. HISS is a not for profit, 501c3 organization (like AMSAT), affiliated with UMES through the Hawk corporation. UMES is attempting to grow their involvement in providing excellent technical jobs in the area and to increase the content of their curriculum. AMSAT will assist HISS in working with Cubesat, small sat, etc. of all types. The members of AMSAT that choose to work with HISS on their programs will be encouraged to do exactly that and with AMSAT's blessing. AMSAT types would be adjunct faculty at UMES and UMES will support us with local facilities and student involvement in our projects. HISS wants to become a player in all sorts of small satellite activities and AMSAT, in concert with these two groups, wants to seriously enhance its educational profile. I am very excited about this opportunity for AMSAT. So is the board of directors and the Eagle Project manager all of whom have been terrifically supportive and actively involved. The board asked lots of tough questions, and were quite careful with AMSAT's interests here. On a personal note, I REALLY like these people at UMES and Hawk. They are "our kinds of folks". They are aggressive, ambitious, and have a vision of where they want to go. I want us to go with them and they want to go with us along the path we want to take our programs. We (unanimously) believe this is the right thing for us to do at this juncture. The launch environment has been undergoing major shifts in the last few years and major U.S. policy is about to be sprung on us. We believe this will impact us very positively. We believe we are poised to take advantage of this changing environment. With this new facility and the new environment, expect us to move out aggressively in several areas and keep your fingers crossed for results. We are working on a technical assistance agreement (a term of art in the ITAR/Import/Export regime) that we will submit to AMSAT-DL, AMSAT-UK, etc. so we can again enter into working relationships with them as well and to do it with the blessing of the U.S. government (which is now required). I thank each and every one of you for your spectacularly generous contributions to AMSAT and we hope we are now poised to take maximum advantage of these contributions. I have attached google earth map pointers to the University, the HISS facility, and finally to the "visitor center, launch viewing area" at Wallops. Please remember, you are not authorized to release this. We have an agreement with the university and Hawk about press releases and this is not one of them! Thank you all for your patience. Bob N4HY -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein

1 0

[Fwd: Re: EaglePedia Upgrades/Enhancements]
by Jim Sanford 08 Nov '06

08 Nov '06

Team: What are your choices regarding the TeamSpeak conference for Tuesday? All: Thanks to Emily for all this work. I'm still digesting the note. I wish to add a note regarding Dave Hartzell: Some of you remember me asking for help because I was spending too much time editing in EaglePedia. Dave stepped up to the plate and has been taking my delusions ("I want . . ..") and turning them into reality. This is incredibly valuable, and I am very grateful to Dave. Finally, regarding the TeamSpeak conference for 7 November: I will not be able to make it. Tuesday is election day here in PA, and I also have a Township Planning Commission meeting that night -- which I have to run, since the Chairman is out of town. Monday is also out for me, since I need to attend the Board of Supervisors' meeting. So, options as I see it: 1. Cancel the meeeting for this month. 2. Hold it Tuesday without me. I'll still put together an agenda (I have no inputs so far.) 3. Reschedule to another evening Wed - Friday. I'd prefer option 3, but will live with your consensus. What say the team? Thanks & 73, Jim wb4gcs(a)amsat.org Emily Clarke wrote: > > I wanted to update you on EaglePedia, specifically about upgrades to > the base MediaWiki software and about personnel. This is a rather > long email to explain what changes will take place - I encourage all > of you to read it and provide any feedback. > > First of all I'd like you all to welcome Dave Hartzell N0GTD who is > joining the team as co-sysop of EaglePedia. Most of you have had a > chance to meet Dave at the Symposium - Dave, along with Eric, served > to introduce speakers during presentations. Dave is on the IT staff > at NASA Ames and is not a programmer, but Dave will take > responsibility for the EaglePedia system administration which will > free me up to concentrate on software development. > > The EaglePedia core software desperately needs an upgrade. The > current version is 1.5.0 and we are plagued by compatibility issues. > I propose that the upgrade take place beginning on the day following > the next Teamspeak conference (which I think will be the 7th of > November - if not, let me know). We will have to shut down EaglePedia > during the upgrade period. The details follow. > > Over the past few days I have upgraded the staging server from 1.5.0 > to 1.8.2 (current version) however it was not trivial. I basically > had to upgrade to 1.5.7, then to 1.6.0 (which is very unstable but > included database changes), then to 1.8.2 (which seems very stable but > also introduced database changes.) At the 1.6.0 level the current > configuration documents become unusable and it took almost a full day > to resolve. To resolve it the Wiki had to be initialized from scratch, > which creates new (blank) configuration settings. These were then > changed to fit our configuration. From there upgrading to 1.8.2 had > no issues. Since I now have a 1.8.2 set of configuration settings it > is may be possible to upgrade from 1.5.7 to 1.8.2 directly - I will > probably roll back the staging server and test this before upgrading. > It will save several hours if we can. > > There are a number of other changes that were required. > > 1) In 1.8.2 the core Monobook Skin was re-written. Our version of > Monobook skin was highly customized and had to be re-written. This was > primarily to support the hierarchical menu structure in the left side > menu. > > 2) Version 1.8.2 gives programmers access to a global user object > (1.5.0 kept the user object as a protected subclass of the global wiki > object) so this now allows me to authenticate users. This is a much > better solution - in the past I had to rely on a custom skin > (MonoNoTabs) to be the default skin and have all registered users set > their skin to Monobook. Now Monobook can be the default skin since I > can turn off the tabs, search field and toolbox based on user > authentication. We will no longer need to support the MonoNoTabs skin. > > 3) Unfortunately the additional buttons on the Edit Toolbar still > require modification of the EditPage code. There is a proposal to > move this to the Monobook javascript code, but no work has been done > for this and I don't agree with this implementation. My proposal to > the MediaWiki community is to change this to a separate include file > that will be easier to maintain, and this is what I have done for > 1.8.2. I've submitted the proposed solution to MediaWiki. > > 4) Extensions were broken in 1.5.0. In 1.8.2 they work, and as a > result I have created one (and will create others) to do some of the > security tasks for us. By moving this code into extensions we will be > able to upgrade in the future without making changes to the base code > (other than the Monobook and toolbar modifications.) The first > extension I wrote will necessitate a change in protected pages, but > adds functionality. The old function was: > > {{NoPublish}} > > This used a template, and about three other files (Monobook, > SkinTemplate and Skin) had to be extensively modified to detect and > modify the existing page data. The new function is in one extension > and uses the syntax: > > <restrict [group = somegroupname]>Restricted text ... > </restrict> > > There are two advantages to this > > * it can restrict all or part of a page depending on where the > <restrict></restrict> tags are placed and > * the restriction can be lifted for an individual group. > > Up to this point we haven't used groups, but we can. So for example, > if you wanted something to be seen by Rick, Jim and Bob only Dave can > create a group called "executive" and using <restrict > group=executive>Some text...</restrict> only the executive team could > see the restricted text - everyone else only sees a comment that there > is a group restriction. > > 5) Additional extensions have been installed and tested. These include: > > * Citations - you can put in <ref>Some reference</ref> and then at > the bottom of the page use <references/> to list the citations. > * Inputbox - this will allow us to create a dedicated "Create New > Article" page. Although not entirely needed, this will > eliminate the confusion of searching for a page name and getting > a "not found - click here to create". > * CategoryTree - this dynamically produces a browse-able tree of > categories down to individual articles. This eliminates the > need to manually create the Eagle Project Categories tree page. > * RequireCategory - this requires someone to enter a category name > for a new article before it is saved. This way all articles > ultimately are browse-able using the CategoryTree tool > > Other extensions can be installed if needed. See > http://meta.wikimedia.org/wiki/Extensions for a comprehensive list of > additional extensions. > > 6) Non-native characters can be added - I've added an extension and > modified the edit page template to display groups of non-native > characters that people may wish to insert. These are grouped as > Latin-1, Greek, Math Symbols, Currency Symbols, Misc. Symbols and > Geometric Shapes. Below the edit box the list will appear - if a user > needs a Symbol, they merely click on it. > > 7) No integrated WYSIWYG Editor yet - unfortunately there is still no > viable WYSIWYG solution for generating Wiki markup that is reliable > and supported. The WINOR project was abandoned and as near as I can > tell there is only debate, but no real progress. Most disheartening, > FCK still carries the warning that it may corrupt the document > database (which would be fatal). > > One solution I am considering is to provide FCK in a popup > window. The editor will operate in a separate window and when saved > it will pipe input through some HTML to Wiki conversion utility to > convert the HTML to Wiki markup and insert it into the editor window. > At first glance CPAN has HTML::WikiConverter that could be used, but > it would be better to have something written in PHP so that the > process could use a memory pipe rather than having to write the HTML > to a temp file, convert the file, and read it back in again. This is > not trivial, and I'm not sure how much of a priority I should put on this. > > > 73, > > Emily > > > --------------------------------- > N1DID formerly W0EEC - CM87tm > > Support Project OSCAR - http://www.projectoscar.net > <http://www.projectoscar.net%A0%A0%A0/> >

5 5

China Announces Their Own GPS
by JoAnne Maenpaa 06 Nov '06

06 Nov '06

This came in via the ans-editor e-mail box. This short item doesn't say which frequencies yet so not sure if there will be any impact such as from the the EU Galileo system we analyzed previously. Here's the link: China to build satellite navigation system URL: http://www.physorg.com/news81676247.html 73 de Joe KC8RAN -- 73 de JoAnne K9JKM k9jkm(a)amsat.org Editor, AMSAT News Service

1 0

Re: [Fwd: Re: Re: Please check these calculations]
by Phil Karn 05 Nov '06

05 Nov '06

> I think that we said the data rate was 30-50 bps in the meeting. The > bandwidth will be determined by the rate of the error-correcting code. > Phil needs to determine that. More coding makes for a wider signal which > reduces the effect of spin modulation. However, it also means more > processing in the SDX. The signal bandwidth has no effect on spin modulation as the fades are pretty much flat over frequency. So there's no frequency diversity and no benefit to spectral spreading here. You need either space or time diversity to get you through a spin fade, and that means either 1) another pair of physically separate TX and RX antennas, and/or 2) interleaving in combination with FEC coding. As for optimal code rates, it depends on the modulation and especially the type of demodulator and the channel. On a fully coherent channel with fixed power you get steadily more capacity as bandwidth goes to infinity. Most of the gain comes with relatively little excess bandwidth and then you reach diminishing returns. Between 1 bit/sec/Hz and zero bps/Hz (i.e., infinite bandwidth) the increase is only 1.6 dB. Fully coherent means the receiver has perfect knowledge of carrier phase. This doesn't come out of thin air. You can derive carrier phase from the data itself, or you can dedicate some fraction of the transmitter power to a reference pilot (carrier). Deriving carrier phase from data is a non-linear squaring process. It works well at high SNR, but breaks down at low SNRs. That means you can't use it with strong, low-rate FEC codes, especially if the carrier phase is changing rapidly and unpredictably as it is on a fading channel. You have to put some power into a reference pilot that can be tracked linearly, and that takes power away from the data. The extreme form of deriving carrier phase from the data is non coherent demodulation, e.g., the differentially coherent BPSK I used on AO-40. It uses each symbol as the phase reference for the next. This responds very quickly to the carrier phase changes that occur during a spin null, but the squaring loss is very high. The non coherent demodulator essentially has a threshold effect just like a FM demodulator. Below some SNR, the output SNR falls much more rapidly than the input SNR. Because a very low rate code puts very little energy into each channel symbol, you fall below the demodulator threshold and you lose more than you gain from the code. So on a non coherent channel there's an optimum code rate. It depends on the order of the modulation (binary, M-ary, etc) and the nature of the fading, if any, but rate 1/3 to rate 1/2 is the usual rule of thumb. My FEC scheme for AO-40, which I designed to be as strong as possible against spin fading, was rate 0.4, i.e., rate 1/2 convolutional * (160,128) Reed Solomon, i.e. 0.5 * (128/160) = 0.5 * 0.8 = 0.4. In my AO-40 system I figure I lost about 3-4 dB because of my use of non coherent BPSK, but that was the price I paid to deal with deep, rapid spin fading. It's a trade off, so I really need to know whether fading is going to be a serious problem here or not. If it will be some of the time but not others, then perhaps we need two modes. In practice, nobody seems to go lower than rate 1/6 on deep space channels even when they don't fade and coherent demodulation is used. The Cassini convolutional code is rate 1/6, and the lowest CCSDS standard Turbo code is also rate 1/6. I wouldn't go any lower than this. --Phil

3 3

3.3 GHz Band
by Bill Tynan 05 Nov '06

05 Nov '06

Paul: Drew, KO4MA, forwared your note to the AMSAT Eagle Team. Thank you for sharing with AMSAT your group's vision for use of the 3.3 GHz band. I do not speak officially for AMSAT but can provide some factual information about the band. 1. The ITU Amateur Satellite Service allocation is 3400 to 3410 MHz. So, only that segment of the band can be used for satellites. Therfore, anything AMSAT would do in that band, would have to be in that segment. 2. Although it has nothing to do with AMSAT, I wish to inform you that the weak signal people use the segment around 3456 MHz. Since weak signal work requires a low noise floor, it would be well to keep broad band digital work away from that area. Just as an aside, I note that I am active on that band and have worked well over 1,000 miles with only 8 Watts. In fact I hold one end of the North American record for 3.3 GHz having worked a station in Florida from the Texas Hill Country northwest of San Antonio. So, the band can do great things when conditions are right. It is not possible to comment on your "band plan" as you did not provide a key for what the various colors stand for. Please provide that information so that I, or others from AMSAT, can respond to your question. I wish you good luck on your project. We need more activity on all of our microwave bands. 73, Bill Tynan, W3XO/5 EM00kd

1 0

Fw: 3.3 GHz ARBA Band Plan
by Andrew Glasbrenner 05 Nov '06

05 Nov '06

Hi Guys, I am forwarding this email to the Eagle amsat list, which consists of just about everyone involved with our new satellite effort. Hopefully the right person will respond so we can work together on this issue. 73, Drew KO4MA Amsat-NA VP Operations LM 2332 ----- Original Message ----- From: Paul Toth-NA4AR To: ko4ma(a)amsat.org Cc: Dave Anderson Sent: Saturday, November 04, 2006 5:53 PM Subject: 3.3 GHz ARBA Band Plan Drew... A new group call ARBA, the Amateur Radio Broadband Alliance, has formed in the ashes of ARRL's HSMM Working Group. Both Dave Anderson and I are part of ARBA. One of the things we are working on is the development of a band plan for the 3.3 GHz to 3.5 GHz allocation. I know that AMSAT is planning something for Eagle that makes use of the 3.3GHz band. Would you please review the chart below and provide some input to allow this band plan to peacefully co-exut with whatever AMSAT is planning? Please feel free to share with others in the AMSAT leadership. 73 de Paul-NA4AR ARBA BAND PLAN 3.3 GHZ - 3.5 GHz 3300-3310 3310-3330 3330-3340 3340-3350 3350-3370 3370-3380 3380-3390 3390-3410 3410-3420 3420-3430 3430-3450 3450-3460 3460-3470 3470-3490 3490-3500

3 2

Please check these calculations
by Robert McGwier 03 Nov '06

03 Nov '06

We have done all of these calculations for the links and published these spread sheets. The spread sheets show the typical bias towards taking thermal noise and some "guesstimate" as to interference levels but not really taking into account LO noise. "Everybody" can understand that noise performance in a mixer that has a 50 ohm input port (which is hooked to a 50 ohm load) with the pretend noise power density of -174 dBm/Hz (k T0). The noise factor of the mixer is taken into account in the usual way Noise Factor = kT0 (F-1) where k is Boltzman, T0 is room temperature and F is the noise factor in the mixer. But, we have these oscillators that we say we want tunable. I doubt we actually want them to be tunable but let's start to go through this so we can calculate if I am right. Reciprocal mixing is the crap that gets thrown into your receive pass band by a strong signal (strong compared to our weak SMS text signal for example) and raises the receiver noise floor. We have these computed signal strengths at the spacecraft and we do not want to raise the noise in our signal bandwidth by more than a few dB (none?) ;-) Let's make some simplifying assumptions that the bottom end of the passband will be as empty as it has always been and the upper half band will have the usual ten suspects in them and not much more. The usual 20 people using the linear transponder on the satellite. So we will assume that we are out in the "flat part" of the LO noise and that a signal of level S is out there. Our bandwidth of our desired signal (the undesigned SMS text message signa for example) is B and the LO noise floor is L. and we worry that RN (reciprocally mixed noise) = S * L * B will appear and hurt us to the point of signal being covered and for example, SMS not working. SNR(in)/SNR(out) = F + RN/(kT0 B) If we wish to see signal level Text at our receiver then we can estimate the noise floor required of the LO (L) to be (using the previous formulae) L = Text - S - C/I - 10log10(B) where C/I is the carrier to interference ratio required at the output of the mixer. Notice that the reciprocal noise specification depends directly on the input blocking signal strength S. So this is a bit more complex than one might think at first so some more thought needs to be put into this before we leap to say the 70 cm design is good, bad, or indifferent. We need to resolve this in the next few days so John, Juan, and the rest of our receiver friends can have a design to build to. Please everyone, check over my formulae before I go and do a ton of work that is all wasted. If you don't like the form of them, suggest something different. I suggest we build a spread sheet that does these calculations in a "mutually coupled" way. I am off to Lyle's on Thursday and will not be able to do much more on this before I return. Somebody jump all over it please if you want to. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein

4 5

Award
by Dick Jansson-rr 03 Nov '06

03 Nov '06

Gentlemen: In amongst all of the trappings of Halloween trick or treat comings and goings last evening, we had a knock at the door saying "UPS", which I immediately thought was a hoax - but it was not, it was a package from AMSAT. The contents of the box was of a total unexpected nature. Your placing on me an "AMSAT 2006 Presidential Achievement Award" was of great surprise and very humbling at the same time. (I personally feel that I have caused more trouble than good.) Be that as it may, the award is greatly appreciated, and from this point on I am at a loss for further words of appreciation The AMSAT box also contained a really neat travel laptop/office case that I expect will be very well used in coming times as we progress on the Eagle Project. Thank you ever so much for this gift and award. Dick Jansson --------------------------- <mailto:[email protected]> rjansson(a)cfl.rr.com ---------------------------

2 1

Re: [Bod] FCC Omnibus R&O
by Dr. H. Paul Shuch 02 Nov '06

02 Nov '06

Hi, Tom, I too am still in CA (funny, I didn't see you on the street last night!) With restricted access. Unfortunately, your 301 kByte PDF confounded Mr. Blackberry. It got stuck in his windpipe and blocked 68 othetr messages (not to worry, they were all spam). My point is, we should be careful with large email attachments. Rather than posting them to multiple lists, anything other than brief ASCII text should probably be posted to a website somewhere, and only the URL forwarded around. That way, we can download the files at will, when back home connected to the Real World. Mr. Blackberry thanks you for your consideration. 73, Paul -- H. Paul Shuch, Ph.D., Chief Engineer Microcomm Consulting +1 (570) 494-2299 121 Florence Drive, Cogan Station PA 17728 paul(a)microcomm.net http://microcomm.net ---------- This document may contain proprietary information, intellectual property, trade names, and logos which may be confidential to Microcomm Consulting. Dissemination for any purpose of any part of the data contained herein without specific prior written authorization from Microcomm Consulting is hereby prohibited.

3 2