- Eagle (INACTIVE) - mailman.amsat.org

Category Required (was Re: Orphaned and uncategorized files and articles in EaglePedia)
by Emily Clarke 28 Nov '06

28 Nov '06

Hi Stephen, Part of the upgrade was to install an Extension to the core MediaWiki software that does not allow you to save an orphan pages. Whenever you edit a page this extension checks to make sure that there is at least one [[Category:something]] reference. The NOTICE is pretty much the instruction - simply add in the category as shown in the NOTICE and substitute the appropriate Eagle category for "something". You can then save it. I have discovered one problem with the "Category Required" Extension. If you are editing a section (the edit link to the right of a section header) it still checks for a category. I think this is punitive, so I have contacted the "category required" extension author. The work around is to either edit an entire page or duplicate the category reference in the main article. 73, Emily At 08:29 PM 11/27/2006, you wrote: >Emily, > > Going slightly nuts am I? > > Every time I edit an existing page (attempting to correct missing > file links, etc.) I get a: > > "NOTICE: There must be at least one [[Category:something]] link." > And no save! Now..... how should I correctly recover from this? > > BTW- Good work on all the changes/new features! > >Regards, >Stephen >-- > >kc0ftq(a)amsat.org --------------------------------- N1DID formerly W0EEC - CM87tm Support Project OSCAR - http://www.projectoscar.net

1 0

Re: Orphaned and uncategorized files and articles in EaglePedia
by Emily Clarke 28 Nov '06

28 Nov '06

Thanks for reporting this Steve. It was a definite bug (un-initialized variable.) Fixed, Emily At 08:34 PM 11/27/2006, you wrote: >Emily, > > Oh and I'm getting a: > > Notice: Undefined variable: overrideReq in /var/www/docs/amsat-new/ \\ > eagle/EaglePedia/extensions/restrict.php on line 102. > > ...at the top of the same failed [Save]. > > (i'm having to deduce this from having only the tops of the letters of the > message as the buttons are overlaying the message.) I hope i have enough > of the message correct so it helps you to find the issue... > >Regards, >Stephen >-- > >kc0ftq(a)amsat.org --------------------------------- N1DID formerly W0EEC - CM87tm Support Project OSCAR - http://www.projectoscar.net

1 0

Orphaned and uncategorized files and articles in EaglePedia
by Emily Clarke 27 Nov '06

27 Nov '06

Since the upgrade, I made a big effort to improve the navigation in EaglePedia and now that the coding changes are completed spent some time going through EaglePedia to see how well things have improved. The answer is that it is still difficult to locate articles and files in EaglePedia - mostly because things are unused or uncategorized. It would be very helpful if the uploaders/article authors could review the list of unused and uncategorized files and add categories and link them into an article (even if that article is just a short summary.) An unused file is a file that has been uploaded and hasn't been linked into an article. For true images (JPEG, GIF or PNG) this means there is no article that contains the embedding reference (for example) [[Image:MyImage.jpg]] to display it. For non-image files (PDF or DOC) this means there is no article that references it using (for example) [[Media:MySpecification.pdf]] You can find a list of unused files (and the name of the user who uploaded it) here: http://www.amsat.org/amsat-new/eagle/EaglePedia/index.php/Special:Unusedima… Files should also be categorized when uploaded. This means that when the file is uploaded you should add the category it falls into. This which should normally be the same category as the article that will reference or embed it. Before you upload a file you should probably browse the project categories (now shown on the front page of EaglePedia) and locate the appropriate category. When you are at the file upload screen add the category into the summary by typing in [[Category:This Category]] To see a list of uncategorized files go to: http://www.amsat.org/amsat-new/eagle/EaglePedia/index.php/Special:Uncategor… To categorize a file that is already uploaded without uploading another copy click on the "Edit" tab at the top of the description page, and then add the category information as shown above. Thanks in advance! 73, Emily --------------------------------- N1DID formerly W0EEC - CM87tm Support Project OSCAR - http://www.projectoscar.net

1 0

3-axis inertial sensor
by Matt Ettus 18 Nov '06

18 Nov '06

http://www.analog.com/en/prod/0%2C2877%2CADIS16350%2C00.html

2 1

EaglePedia Upgrades
by Emily Clarke 16 Nov '06

16 Nov '06

EaglePedia is online and most everything is working. The exception to this is that the WYSIWYM editor doesn't work. One of the dependencies (a perl routine) has not been installed. It should be shortly, but if you try to use that functionality you will receive an error that basically says a required module is not installed. Everything else is working - I encourage everyone to read the online release notes: http://www.amsat.org/amsat-new/eagle/EaglePedia/index.php/EaglePedia_1.1_re… This should explain the upgrade. 73, Emily --------------------------------- N1DID formerly W0EEC - CM87tm Support Project OSCAR - http://www.projectoscar.net

1 0

TeamSpeak conference for 15 November
by Jim Sanford 15 Nov '06

15 Nov '06

Team: Reminder of the conference tomorrow night. My draft agenda is posted in EaglePedia; please modify. The conference is at 2100EST, 1800PST, 0200Z. 73, Jim wb4gcs(a)amsat.org

2 1

Re: Solar Power Systems -- White Paper FYI
by Paul L Rinaldo 13 Nov '06

13 Nov '06

Tom, We've been watching this subject for some time in ITU-R Study Group 1 (spectrum management). As I'll be traveling this week, I've asked Jon Siverling to review the relevant ITU documents and advise. Paul At 01:59 AM 11/11/2006 -0500, Tom Clark, K3IO wrote: >>>> I am a member of URSI (International Scientific Radio Union) Commission J (Radio Astronomy). The US National Committee of URSI has asked its members to review the attached document on Orbiting Solar Power Stations. I send it along to you for information. You will see that the concepts might involve Microwave Power transmission at S-Band (2.45 GHz) and/or C-band (5.8 GHz). In the main footprint of the beam, the power flux density might reach (near fatal!) levels of ~300W/m. The orbiting antenna will certainly have sidelobes likely would wipe out many services. You will note comments indicating that that this worries many radio astronomers who routinely make measurements as sources with flux densities of 1 mJy (1 Jansky =s a power flux density of 1x10e-26 w/(mHz) . In the event of a failure of just one active element, the beam-forming properties of the orbiting antenna would certainly degrade. Inside the report you will note a statement that even with a MTBF of ~30 years for magnetrons, this implies a failure of one element/day for the array! It is interesting to note that the report indicates current launch costs of ~$10,000/kg (this is about the going rate for a Dnepr launch to LEO), decreasing significantly by 2025 (good news for us, if true). It is also interesting to note that the report still indicates the use of (relatively) low efficiency solar cells and doesn't even note the ~28% cells that we have been using. I have no idea of the reality of these systems. I presume that AMSAT/ARRL/IARU could make comments to URSI. The following is the "charge" given to URSI members which calls for responses a scan 1 weeks hence: <fontfamily><param>Helvetica,</param>Dear USNC-URSI Colleagues: The past president of URSI, Professor Kristian Schlegel, has asked me for the USNC opinion on the proposed URSI white paper on solar power, copy of which is attached. Even though it appears that the conclusion is foregone because a majority of URSI member countries are in favor of the proposal, it is important that the US opinion be registered and our objections, if any, be forwarded to URSI and remain a matter of record. I am therefore asking that you let me have your reactions by e-mail on or before Monday, November 20. I will collate them into a memorandum that I will send to Prof. Schlegel by his deadline of November 22. It is especially important that I hear from the Commission Chairs, and crucial that I receive the opinion of Commission J. I apologize for the short notice. I was hoping that we could discuss this matter at the USNC business meeting in Ottawa next summer, but it now appears that URSI is in a hurry to decide the issue soon, and is not willing to wait. Best regards, George Uslenghi Chair of USNC-URSI. _________________________________________ Piergiorgio L. E. Uslenghi, Ph.D. Professor and Associate Dean Department of ECE, College of Engineering University of Illinois at Chicago 851 South Morgan Street, Chicago, IL 60607, USA</fontfamily> Dave Woodie (CalTech), the current USNC Commission J chairman, appended these notes from last January's submission by the Radio Astronomers: <fontfamily><param>Helvetica,</param>Discussion of the solar satellite white paper: Commission J members are concerned about the process for producing such a white paper and whether there is an implied approval by each commission. Many of the issues with this project are beyond the technical scope of the URSI commissions and hence it is inappropriate for URSI to take a strong position on this project. Individual commission J members expressed strong reservations about this project and do not want to be associated with a white paper supporting solar satellites for beam power to earth. (The commission J chair, David Woody, expressed these concerns to the URSI executives during the Saturday morning executive session.)</fontfamily> Comments? 73, Tom Attachment Converted: "c:\eudora\attach\URSI white paper on solar power.doc"

1 0

TeamSpeak conference for Tuesday 14 Nov 06
by Jim Sanford 11 Nov '06

11 Nov '06

Team: I have posted my proposed agenda for the conference on EaglePedia. Please DO modify it. See you Tuesday night. Thanks & 73, Jim wb4gcss(a)amsat.org

1 0

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 07 Nov '06

07 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 05 Nov '06

05 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:rjansson@cfl.rr.com> rjansson(a)cfl.rr.com ---------------------------

2 1

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

01 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

Power system thoughts and comments
by Phil Karn 01 Nov '06

01 Nov '06

I was fascinated by Lou's talk at the Symposium. His idea of a "parallel" power system is an excellent one if a few potential problems can be addressed. The first and most obvious one is efficiency. Switching converters tend to be much less efficient at low voltages and high currents, though power MOSFETs have gotten very good of late. Every Pentium 4 motherboard has had a DC-DC converter that takes 12V and produces ~1V at up to 100A to power the CPU. The fact that there isn't a massive heat sink and fan for the supply as well as the CPU says that these converters can't be too terribly inefficient. I'll be interested in some actual figures for the "virtual battery" converters. The second issue is robustness. Just as serial architectures are vulnerable to single-point open faults, parallel architectures are potentially vulnerable to single-point shorting faults, e.g., of the power transistors and diodes in the converter. I'm hoping a judicious application of fuses can take care of this. Super caps look very promising thanks to their claimed long cycle lives, but I wonder about their radiation robustness. Imagine what a highly energetic, totally ionized particle might do as it rips through the Aerogel holding large numbers of electrons a few microns apart from large numbers of holes. Have any radiation tests been performed on these things? Also, I would not take their cycle life claims as gospel without some tests to back them up. Electrolytic caps have become some of the most unreliable components in electronics today. They fail on a regular basis in computer power supplies and motherboards, often spectacularly. While super caps aren't built quite the same way, both kinds of caps achieve their high capacities with lots of extremely thin dielectric material. Cycling the cap must place some pretty serious electrostatic compression stresses across this material. What happens, e.g., after many cycles at very low temperatures? At a system level, I see a potential "gotcha" with multiple paralleled virtual battery units. You can never get multiple voltage references to exactly agree, so if the control loop gains are too high, then one virtual battery might think the bus voltage is a little too low when another might think it's too high. Then you'll have large amounts of current flowing from one virtual battery into another, obviously an undesirable situation. The simplest fix I can think of is to program the control logic in each virtual battery to follow a specified current vs voltage characteristic. The slope of this curve must be gentle enough so that small differences in reference voltages across the units will not produce significantly different I/V curves. Bus regulation won't be quite as tight, but hopefully the loads won't mind. Overall I think Lou's proposed architecture is an excellent idea, and with attention to a few details it should be a lot more reliable than the conventional power systems we've had in the past. --Phil

5 10

Eaglepedia articles
by Alan Bloom 29 Oct '06

29 Oct '06

I have set up a new category on Eaglepedia called "Hardware Design Guidelines". http://www.amsat.org/amsat-new/eagle/EaglePedia/index.php/Category:Hardware… I seeded the new category with two new articles, "SMT Thermal Design" and "HEO Radiation Environment". I also added several old Eaglepedia articles that should be useful to hardware designers. I'm new to posting Wikepedia-type articles so I'm not sure I got the category thing right. Also I'm not an expert on thermal design or the space radiation environment, so I hope other members of the Eagle team will do the Wikipedia thing and add to, modify, correct what I've done. Al N1AL

1 0

AMSAT award
by Robert McGwier 28 Oct '06

28 Oct '06

It pleases me greatly to announce that Eric Ellison has been presented with an award from AMSAT. It is sometimes easy to take for granted what seems to many to be a small thing. In the case of AMSAT, Eric's work made virtual meetings not only possible but easy. AMSAT has literally run its Eagle project using VOIP facilities which Eric set up on behalf of the technical groups active today in amateur radio in satellites, technology, and in particular software defined radio. AMSAT and TAPR both recognize Eric's work, AMSAT with the award and TAPR membership with Eric's election to its board of directors. Someday Eric's TEAMSPEAK server will be universally recognized for the spectacular impact it has had and will continue to have. Eric, the award is in the mail from the AMSAT office along with a gift membership in AMSAT for a year. Jim Sanford, Eagle project manager, and I and the entire organization give you our thanks for your generosity and help. 73's Bob McGwier 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

2 1

CONGRATULATIONS TO N2UO
by Robert McGwier 24 Oct '06

24 Oct '06

I know all of the Eagle designers will join me in congratulating Marc Franco, N2UO on his being granted permanent residency here in the U.S. His skills represent a major asset to Eagle, Lintech, and the U.S. [in that order ;-)] and it is good when the immigration office does something sensible for a change. CONGRATULATIONS Marc! 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

3 2

Eagle Team Leadership change announcement
by Jim Sanford 22 Oct '06

22 Oct '06

Team: I wish to announce that Bob Davis, KF4KSS, has assumed the role of Structure and Mechanical Team Leader. Bob has experience in finishing and integrating AO-40, and is employed in the aerospace industry, where he has acquired significant experience since the AO-40 campaign. Dick Jansson, WD4FAB, has led this team for several years and is not going away. Dick will support Bob as a team member, focussing on structural team coordination and thermal design and analysis. Dick told me this afternoon, "I'm really excited to see the new blood coming in and assuming leadership roles. I look forward to supporting Bob and being on his team." I thank Dick for all that he has done for AMSAT and WILL do for Eagle and AMSAT. Thanks for all you've taught us. Bob, thanks for stepping up to the plate. I look forward to working with you, and I look forward to learning from you. Thanks and very 73 to all, Jim wb4gcs(a)amsat.org Eagle Project Manager

1 0

AVP -Engineering team
by Robert McGwier 21 Oct '06

21 Oct '06

I have asked the following folks to be AVP for Engineering. Jim Sanford as Eagle project manager Lou McFadin as Manned Space chief engineer Bob Davis as lab director and spacecraft integration leader Please add them to the officers mailing list if they are not already on it please. Welcome and thank all of them for their continued great service to AMSAT. 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

S1 downlink coordination and interference mitigation
by Howard Long 18 Oct '06

18 Oct '06

Folks, Coincidentally at the Symposium, Graham Shirville spent some time coordinating proposed frequencies to some satellites, including Eagle, and after a suggestion I had from from Drew KO4MA, I reiterated to Graham that it may be advantageous to propose S1 frequencies right down at the bottom 1MHz of the 2.4GHz satellite allocation. 802.11 specifies a 1MHz guard band at 2400 to 2401MHz for regulatory OOB emission reasons. Signals +/-11MHz from the centre must be at least 30dB down from the carrier. Channel 1 is at 2412MHz. Taking into account Doppler, the recommended S1 coordinated frequencies will be at the bootom end of 2400MHz without the possibility of OOB emissions on Earth due to Doppler. 73, Howard G6LVB

2 2

Service class names
by Jim Sanford 17 Oct '06

17 Oct '06

Team: A few days ago, I made a proposal for naming Eagle's communications services and solicited comments. I received many good comments. I really think it important that we have unambiguous service class names. Based on all the comments, I propose: U/V "linear" L/S "linear" Text messaging Low Rate ACP High Rate ACP While I'd prever something less ambiguous than "linear", our customers seem to understand that "linear" means SSB/CW/PSK31/SSTv . . . . etx. Any strong objections to this? If not, I'll get the announcement on AMSAT.org changed. It's time to get precise. Thanks & 73, Jim wb4gcs(a)amsat.org

2 1

Module Paper
by Dick Jansson-rr 15 Oct '06

15 Oct '06

I have been asked if I can provide a copy of the module paper of mine that was so skillfully presented by Bob Davis at the recent AMSAT Space Symposium. This is for those of you who were not able to be at the symposium and receive the Proceedings. This paper is now available on Eaglepedia at: <http://www.amsat.org/amsat-new/eagle/EaglePedia/index.php/Module_Design> http://www.amsat.org/amsat-new/eagle/EaglePedia/index.php/Module_Design Dick Jansson --------------------------- <mailto:rjansson@cfl.rr.com> rjansson(a)cfl.rr.com ---------------------------

1 0

Module Temperatures
by Dick Jansson-rr 14 Oct '06

14 Oct '06

Last evening I tried to convey the concept that the critical-command modules needed to be of low-power design to insure their operability during the occasional rather lengthy eclipse cooling of the spacecraft. My message apparently did not sink in. John reports that his design of such a U band receiver would be dissipating some 3.5W due to its bullet-proof nature against 3rd-order IM products needed for protection on the U band. If we go forward with such a module of that nature, it will need to have thermal control tapes on it to provide a mean emittance of about e=0.45. In a 3 hour eclipse we can expect to see spaceframe temperatures down to -100°C (173K) or lower. With such an environment John's module would be expected to see temperatures down to at least -44°C, which is a bit frosty for electronics that are expected to provide the critical services of commanding the spacecraft. Such operating temperatures are not felt to be advisable for that service. If John's module were of the 1W category, temperatures of the receiver could be expected to be in the range of -15°C to -20°C which would be more operable for the service. The above numbers are, of course, based on estimates which will be confirmed after we have the new spaceframe fully designed and analyzed. The "warmer" temperatures of the lower power modules are those that have been experienced and measured by telemetry from AO-10 and AO-13. These projections are thus based on 25 years of experience in these design concepts. Dick Jansson --------------------------- <mailto:rjansson@cfl.rr.com> rjansson(a)cfl.rr.com ---------------------------

4 4

ARRL Letter Mentions Eagle
by JoAnne Maenpaa 13 Oct '06

13 Oct '06

The ARRL Letter, Vol. 25, No. 41 released on October 13, 2006 mentions Eagle. Here is a copy of the Eagle item for those who don't get this via ARRL channels ... -- 73 de JoAnne K9JKM k9jkm(a)amsat.org ==>AMSAT'S PROJECT EAGLE SATELLITE SHIFTS DIRECTION AMSAT-NA has announced it's revamping the design of its high-Earth orbit (HEO) Project Eagle satellite, currently in the development stages <http://www.amsat.org/amsat-new/eagle/>. The next generation satellite will take maximum advantage of software-defined transponder (SDX) technology to offer a broader range of easily accessible Amateur Radio payloads. The AMSAT Board of Directors okayed the Eagle upgrade plans during the 2006 AMSAT-NA Space Symposium and Annual Meeting held October 6-8 in San Francisco. Eagle Project Manager Jim Sanford, WB4GCS, outlined the changes at his Space Symposium forum October 7. "The structure which we have been presenting for several years is not going to meet our mission needs," Sanford explained. "We have moved on to a later structure." Under the new plan, Sanford says, Eagle's communications payloads will include a mode U/V linear transponder for SSB, CW and other modes. A second SSB/CW transponder will uplink on L band (1.2 GHz) and downlink on S1 band (2.4 GHz). Both would be usable over 75 percent of the satellite's orbit by an AO-13 or AO-40-capable ground station, AMSAT says. Something new to Amateur Radio satellites is a planned low-rate text messaging system similar to cellular telephone SMS. Sanford said the text-messaging capability may prove valuable for providing emergency and disaster communication. It will operate in mode U/V and also will be available to modest ground stations over 75 percent of Eagle's orbit. Eagle will also carry an advanced communications payload (ACP). The ACP will accommodate voice communication using an S2 band (3.4 GHz) uplink and a C band (5.8 GHz) downlink via a single 60 cm dish on the ground. As an alternative -- for stations in those parts of the world where 3.4 GHz is unavailable -- Eagle will provide an additional L band uplink. The ACP also will offer high data rate communication including the possibility of full-motion compressed video in S2/C mode. The same mode also could support an Internet link. Ground-station antennas for Eagle may even pass muster in neighborhoods governed by private deed covenants, conditions and restrictions (CC&Rs), Sanford suggested. During a presentation on the ACP, Matt Ettus, N2MJI, said one of the goals of the package is to open up the satellite to a new base of users, not just restrict it to elite satellite operators and sophisticated ground stations. Embracing SDR technology simplifies signal handling, he explained, because going digital is just a matter of transmitting bits up and down. "The satellite doesn't really care what the bits mean," he said. The satellite "just reflects bits," and most policy-type issues will be handled by ground stations. The satellite's signal will present one wideband downlink containing multiplexed data. "There will be room for many, many carriers in the passband," Ettus predicted. The mix of users would be apportioned among both low and high-rate modes, depending on overall traffic. Plans call for electronically steering the satellite's antennas to mitigate the effects of the spacecraft's spin and maximize the spacecraft's accessibility. In a subsequent forum, AMSAT board member and well-known satellite expert Tom Clark, K3IO (ex-W3IWI) discussed some of the mathematics and physics that would permit steering a 37-element S band antenna array on Eagle. "We would intentionally steer that pattern, so the array is always pointing toward Earth," Clark said, regardless of spin factor. He described a system of interferometers to do the pointing on the basis of "master beacon signals" uplinked from different points on Earth's surface. "It [Eagle] will measure where they are and know where to point the beam," he explained. In a presentation on applying SDR techniques to satellite transponders, Howard Long, G6LVB, described and demonstrated a prototype SDX board. "This is the holy grail of what we've been trying to do," he told his audience. Long showed how his hand-soldered SDX could be configured to accommodate various signal strengths and types within the same passband and even to easily notch interfering signals quickly and flawlessly. Sanford concluded his presentation by saying it's time to take the AMSAT board's concrete decisions and plan, schedule and build Eagle. "We're about to start spending some serous money," he said. During a later question-and-answer session, Sanford stressed that reliability of the ultimate Eagle satellite is a key goal. "I want no single-failure mission kills on this satellite," he said. Project Eagle still needs to raise $33,500 by December. Eagle could launch by 2010. The whole project will cost some $600,000. During the AMSAT-NA annual meeting October 8, President Rick Hambly, W2GPS, expressed his enthusiasm for Project Eagle. "I think it will be the greatest thing we've ever done!" he said. The 2007 AMSAT Symposium and Annual Meeting will take place in Pittsburgh.

1 0

Amateur Radio Newsline Mentions Eagle
by JoAnne Maenpaa 13 Oct '06

13 Oct '06

Bill Pasternak, WA6ITF sends out a pre-release copy of the Amateur Radio Newsline broadcast script to the ANS editors. This week's Newsline will include news about Eagle. Here's a copy for anyone interested ... -- 73 de JoAnne K9JKM k9jkm(a)amsat.org HAM RADIO IN SPACE: THE EAGLE WILL FLY AMSAT's Board of Directors has approved the payloads for the upcoming Eagle ham radio satellite. Bill Pasternak, WA6ITF reports: -- Of primary concern to most radio amateurs world-wide was the decision to include an SSB and C-W transponder transponder with uplink on 70 centimeters and a downlink on 2 meters. What AMSAT calls U-Band and V-Band. This means that Eagle will be usable over 75% of an orbital pass by any AO-13 or AO-40 capable ground station. In other words, Eagle will be backward compatible with most previous ham radio satellites. Other transponders include SSB and C-W with an uplink on L-band and a downlink the 2.4 GHz S1-band and a low rate text message system operating on the UHF and VHF bands. These transponders will be implemented using Software Defined Radio technology. But thats not all.. AMSAT says that Eagle will also carry an advanced communications payload or A-C-P. The A-C-P will allow voice communications uplinking on the S2-band at 3.4 Ghz and downlinking on C-band at 5.8 Ghz. It will do all of this using a single 60cm dish. The satellite antennas will be electrically steered to reduce spin modulation and allow use over 75% of any given orbit. An additional, fix-pointed, uplink will be available at L-band. This L-band uplink will require a separate antenna at the ground station. Also on-board will be C-band equipment for high rate data communications such as streaming video. For the Amateur Radio Newsline, Bill Pasternak, WA6ITF, in Los Angeles. -- The AMSAT board announced its selection following a meeting on October 5th in Sam Francisco. It also said that AMSAT will develop and make available an affordable ground segment for the ACP system. Additional information will be posted at www.amsat.org in the near future. (AMSAT)

1 0

3.4 GHz
by RaySoifer＠cs.com 13 Oct '06

13 Oct '06

Hi all, Further to my earlier e-mail about the Omnibus R&O, my recommendation for now is that AMSAT proceed with the IARU coordination process for the proposed Eagle frequency plan, but that any out-of-the-ordinary action with FCC is unwarranted. The proposed orbital debris language is not now in effect, for the reasons discussed in my earlier e-mail. It is AMSAT's position, as stated in our recon petition, that FCC does not have the authority to adopt or enforce it. The ITU notification process provided for in the R&O is just that, notification, and is not in any sense a scheme for licensing space stations in advance. FCC's position on that is very clear, and stated in Sec. 97.207: any amateur station may be a space station. Full stop. We may not like that for whatever reason, but as the shady mutual-fund operator Bernie Cornfeld once said about the SEC, "they may be schmucks but they're the government." The way things will work in practice is that when we file our notification with FCC, they will in due course inform the ITU Radiocommunication Bureau. The Bureau will, in turn, inform member states, any of which may object. If they do, it is up to them and FCC to work it out. In such a case, our response would be very simple: "Our uplink causes no interference, harmful or otherwise. If you don't like it, just tell your country's amateur licensees not to use it." In the meantime, the fewer waves made, the better. My 3 cents worth (before tax, that is). 73, Ray

1 0

Re: [Advisors] Re: Re: FCC Omnibus R&O
by RaySoifer＠cs.com 13 Oct '06

13 Oct '06

Rick, Bob, Art et al, I finally got around to reading the Report and Order, and agree that FCC is out to lunch. In footnote 169, they say that orbital debris matters have already been addressed in Docket 02-54, and are therefore moot. The footnote also goes on to state that a recon petition (ours) is pending in 02-54. However, the revised regulation language includes all of the orbital debris garbage (pun intended) they adopted in 02-54, which would thus become effective 30 days after publication in the Federal Register unless FCC takes the same "escape hatch" that they did in 02-54, where the actual Fed Reg notice excludes Sec. 97.207. My suggestion, then, is that someone (Perry, Art, Paul Rinaldo??) call FCC and ask them if, in view of the recon pending in 02-54, they plan a similar exclusion in the Fed Reg notice of this Report & Order. If so, then we need not do anything until action is taken on our recon petition, whenever that is. If not, then we should file a recon petition in 04-140 that mentions the footnote, and incorporates by reference our earlier recon petition and the associated Reply to Oppositions. Such a new petition could also include new material as suggested by Art. When thinking about this, please bear in mind that the purpose of a recon petition is not to persuade FCC to change its mind. That won't happen: their mind is already made up and don't try to confuse them with the facts. Rather, its purpose is to lay the groundwork for a possible future challenge in court (as ARRL is now doing in the BPL matter), since you cannot raise in court any issue that was not before FCC when it made the decision you are challenging. Hope this helps. 73, Ray

1 0

Matt Ettus, IEEE Spectrum
by Robert McGwier 13 Oct '06

13 Oct '06

In the October issue of the IEEE Spectrum is a review of GnuRadio and the USRP and in the contents is a picture of Matt with his USRP and some attachments. The article by Stephen Cass is in the "Tools and Toys" section. It is quite favorable and points out what we all know. The software needs to be easier to install and maintain and as always, there needs to be better documentation. The one software module they mention as working is the FM Stereo demodulator I wrote so I am awfully glad we did it. He mentions that he got the TV demodulator going but that its rasterization was as yet, incomplete. We in the process of getting the digital subcarrier demodulated and decoded (RDS) at this moment. This is being done by someone else. This was a thoroughly written, and very positive review for Matt and GnuRadio, both important contributors to Eagle. Congratulations to Matt of USRP and Eric Blossom of GnuRadio, both Eagle team members. 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

3 2

FCC Omnibus R&O
by Tom Clark, K3IO 13 Oct '06

13 Oct '06

6 7

Re: [Advisors] Re: Re: FCC Omnibus R&O
by RaySoifer＠cs.com 12 Oct '06

12 Oct '06

Rick, Bob et al, I have not read this document yet as I have been occupied with other matters. I'll get to it in the next couple of days and make whatever recommendations then seem appropriate. 73, Ray

1 0

SMT heat dissipation in the space environment
by Alan Bloom 11 Oct '06

11 Oct '06

This is a note I wrote some years ago during the AO-40 project. If people think it's useful, perhaps I could post it to Wikipedia. Alan N1AL ------------------------------------------------------------------- Our local PC board technical expert here at HP has done an extensive study on power dissipation of surface-mount parts. While his report is based on non-space applications, there are a number of conclusions that are very interesting. I won't include the entire report, partly because it is much too long, and partly because it is HP proprietary. But here are a few highlights. He found surprisingly little discussion of these issues in the literature. So he performed a series of experiments using an Inframetrics 760 infared camera system to measure component temperatures. All measurements were taken on similar-sized PC boards mounted horizontally with no significant airflow. One main conclusion: "Part ratings by the vendors have little meaning by themselves since trace width and part density have a huge impact on heat dissipation." For example, what is the allowable power dissipation of an 0603 resistor? The answer is somewhere between 12 mw and 526 mw, depending on layout! This is based on a 60 degC temperature rise. (Most resistors have a 125 degC max case temperature spec.) Temperature rise is directly proportional to power dissipation. The 12 mw number was measured on 112 parts packed into a 0.75 square inch area and all dissipating the same power. The 526 mw measurement was on a single part soldered between two half-board-sized ground planes and tied through many vias to another ground plane on the back side of the board. Manufacturers rate 1206-case resistors at 125 mw, versus 62.5 mw for 0603-case resistors, a 2:1 ratio. Actually, for most reasonable trace widths, an isolated 0603 resistor can dissipate roughly 80% as much as a 1206. When parts are packed densely together, power dissipation is limited by the maximum watts per square inch. Note that I used a 30 degC temperature rise for the following table: 0603 1206 Isolated Resistor: Large ground plane: 263 mw 403 mw 0.060 inch traces: 170 mw 199 mw 0.040 inch traces: 148 mw 177 mw 0.012 inch traces: 106 mw 128 mw 0.005 inch traces: 77 mw 100 mw 0.0025 bond wires: 55 mw 79 mw High-density part layout, 0.75 square inch (4.84 cm^2) area: Number of parts 112 32 Power per part 6 mw 20 mw Total power 672 mw 640 mw Number of parts 56 16 Power per part 11.5 mw 43 mw Total power 644 mw 688 mw Number of parts 20 8 Power per part 31 mw 80 mw Total power 620 mw 640 mw Since the power dissipation depends so strongly on trace width, then clearly most of the heat must be conducted, not radiated, on SMT resistors (and other parts). Even in the thin-trace case, much of the heat is conducted to, and radiated from, the PC board. You can see that on the infared photos: the PC board surrounding the part is quite hot. Thermal resistance of isolated SOT-23 transistors was very similar to 0603 resistors up to 0.040" line widths. SOIC-8 voltage regulators had about 1/2 the thermal resistance of SOT-23. The above numbers are probably conservative, since they are based on still air, even though most earth-based applications have forced-air cooling or at least natural convection (vertical PC board). The rule of thumb I generally use is 1 watt per square inch (155 mw/cm^2), which gives an average temperature rise of around 35 degC in still air. I have been told that for space applications, 15 mw/cm^2 is a more appropriate limit. Assuming radiation cooling is only 1/10 as efficient as convection cooling, then that seems a reasonable spec. Conclusion: I have heard several rules of thumb on what percentage you should derate component power specifications for space applications. For through-hole devices, such a rule of thumb probably makes sense. THD devices dissipate most of their heat from the component body, and relatively little heat is conducted out the leads. On earth, most of that heat is conducted to the air; only a little is radiated. In space, radiation is the only heat-dissipating mechanism, so the power must be derated by a large factor. But SMT devices are cooled mainly by conduction out the leads to the copper traces on the PC board, so they are not directly affected by the lack of air. It seems to me that as long as I keep within the 15 mw/cm^2 limit on the PC board, that allowable power dissipation of individual components should be governed by trace width, per the above table. If I have a hot component, I'll connect it to lots of copper and make sure no other hot components are nearby. <END>

5 6

programmable I/V curves for power devices
by Phil Karn 10 Oct '06

10 Oct '06

After thinking about it some more, I recommend that each device on the power bus have a programmable I/V characteristic. This is especially important to avoid wasteful "sloshing" of large currents between energy storage devices. Ideally, the storage devices would have a dead band in their I/V curves around a nominal operating point. They'd begin discharging only when the voltage falls below the lower edge of the dead band, and they'd begin charging at voltages above the dead band. Also, the I/V slopes outside of the dead band (i.e., their effective resistances) would be set to balance charging and discharging currents. The controllers would act like ballasting resistors, only they'd do it more efficiently. You can do some useful things by reprogramming these I/V curves. For example, if you have both supercaps and conventional batteries, you might want to discharge the supercaps in an eclipse before the conventional batteries. You'd do this by setting a higher discharge kick-in voltage for the supercap modules than for the chemical batteries. The IHU could also reprogram the I/V curves to run periodic tests on the individual storage modules. While normally you'd want to keep the batteries at equal charge states, you might want to intentionally charge and deplete one battery to measure its capacity while keeping the others full. Some care will have to go into this to ensure that the module controllers always come up from a power failure with reasonable default I/V curves, but I think this is doable. Phil

1 0

Module Thermal Dissipation
by Dick Jansson-rr 10 Oct '06

10 Oct '06

Eagle module power dissipations as noted in my paper recently published for the AMSAT Space Symposium, are shown below.. The allowable dissipations presume a module temperature of 20°C in a 0°C spacecraft. Table 1 Mean Emittance, v Allowable Power Dissipation, Q 0.045 0.4 W 0.15 1.3 W 0.45 3.9 W 0.91 7.9 W It would be exceptionally presumptuous on my part to assume that all modules will be of 7.9W dissipation as the spacecraft will not have that level of power generation (12 "low power" modules at 7.9W = 94.8W, plus 4 "high power" modules at 50W = 200W, totaling 295W). To achieve that level (7.9W) of power will require the use of internal heat sinking. On the PCB dissipation, if we are to limit the temperature rise, in a 20°C module, to 40°C or a PCB of 60°C total, then the PCB dissipation would be 5.35W, somewhat less than the 7.9W allowed in a 20°C module. Thus to achieve the 7.9W other heat sinking methods would need to be used. I fully realize that modern-day electronics are quite compact and have significant power densities, but I personally shudder at some of these above noted power densities in a vacuum environment. This is the basis of my previously noted conservatism in PCB power densities. There are some particularly critical modules that MUST be low power. These are those involved in the commanding of the spacecraft, the command receiver and the IHU. The noted reason for this mandate is that of the cooling effects of the spaceframe during eclipse and the need to maintain the command-loop equipment in suitable operating condition regardless of the radical eclipse cooling of the spaceframe. During a 2-3hour eclipse, the spaceframe can cool to as low as -80°C or below. These conditions have been observed in prior P3 spacecrafts. This whole ongoing discussion merely further reinforces my concept that close work between the electronic designers and the thermal designer for Eagle is sorely needed. In this environment I feel that the days of wily-nily electronic design, damn the thermal torpedoes, are gone. Module design must be done as a cooperative, multi-technology effort. This is why I again emphasize that all designers should read my recently presented paper. Dick Jansson --------------------------- <mailto:rjansson@cfl.rr.com> rjansson(a)cfl.rr.com ---------------------------

1 0

comments on Li-ion batteries
by Phil Karn 10 Oct '06

10 Oct '06

I read through some of the comments on this list about lithium-ion batteries and have a few things to add. Lithium-ion batteries require *very* tight control of the charging voltage. If you let it go too high, metallic lithium can be produced inside the cell with disastrous results. The expected lifetime of a li-ion battery depends on more than the number of cycles and the depth of discharge. Unlike Ni- or Pb-based batteries, li-ion batteries degrade significantly even when unused. The rate depends on state of charge and temperature, with high states of charge and high temperatures being the worst. You may have noticed that while NiCd and NiMH batteries arrive from the factory fully discharged, li-ion batteries usually arrive at 40-50%. This is the level at which degradation is the slowest. This means we should probably design our li-ion battery management algorithms to keep them half full rather than completely full. We can still use the extra capacity to get through an eclipse season, but when the extra capacity is not needed the batteries should not be kept at 100%. Like all batteries, li-ion batteries are better cold than hot. Since they perform fairly well when cold, some thought should be given to a spacecraft thermal design to keep them cold. --Phil

2 1

Service class names
by Jim Sanford 10 Oct '06

10 Oct '06

Team: I learned at Symposium that some don't like some of the class names we've been using to discuss various services. I reaffirmed at Symposium that we need consistent names for the services we'll provide, just like we've settled on band names. To give us the precise nomenclature I think we need for effective communication, I propose: Class A for what we used to call Class 0 (A from the old "Analog", which we need to stamp out.) Class S for what we used to call Class 1 (S from SMS) Class V for what we used to call Class 2 (small station digital Voice) Class H for what we used to call Class 3 (High rate) I started with A, B, . . . and decided to propose more intuitive names. Unless one of you strongly objects in the next few hours, I'll have the ANS announcement and AMSAT web page updated. It was great to see many of you this weekend. Thanks & 73, Jim wb4gcs(a)amsat.org

13 24

TeamSpeak conference for Tuesday 10 Oct
by Jim Sanford 09 Oct '06

09 Oct '06

Team: Since many of you will be still at SFO or travelling back, I don't think there's a point in having a conference. HOWEVER, tomorrow represents a GREAT opportunity to brief those who weren't there on Symposium. SO, I will be there. I ask all of you who were at Symposium to attend. There will only be one agenda item -- to brief those who weren't there on Symposium. And the discussions can range from there . . . . NEW SUBJECT: I've read the feedback on my "classes of service" note. Several people told me to just do it, I'm glad I didn't. Here's where I am. 1. I feel VERY strongly that we need a concise class of service designation. I don't much care what the designations are. 2. It was very clear to me, particularly in watching Matt's presentation at Symposium, the value of having such designations. Things like "mode U/V" have precise meanings to our designers, members, and users. We need similar precision in defining our classes of service. "Analog" is very confusing when we're talking about an SSB transponder that is more digital than analog. 3. Some are offended by calling the traditional or old analog transponders "class 0". I think that's crap, but remember that perceptions are reality. 4. I'm going to make and publish a decision in the next few days. I'm going to tell the members and readers of the web site and -bb what those are, so we can all speak from a common understanding of terminology. 5. The proposal I sent was the best I could come up with to get the discussion started. 6. I've seen some good suggestions. I'll digest the suggestions tomorrow night, send a proposal before the teamspeak conference, and we can go from there. Thanks & 73, Jim wb4gcs(a)amsat.org

1 0

2nd Tuesday
by John B. Stephensen 09 Oct '06

09 Oct '06

Is there a teleconference scheduled for tomorrow (10/10)? 73, John KD6OZH

1 0

The thorny issue of SDX/Analog linear transpnder
by Howard Long 04 Oct '06

04 Oct '06

Folks I know that the current documented thinking is to have two SDX's and no analog transponder, however we did say we'd bring up for discussion at a telecon prior to the Symposium. I know that this was brought up in July 2005 where it was clear that the answer to the members was yes, we'd have a backup _analog_ linear transponder. As we won't now have an opportunity to discuss this in a telecon, can we have a clear line on this? I can just see that someone's gonna ask me this question at my presentation. 73, Howard G6LVB

11 13

S2
by Grant Hodgson 02 Oct '06

02 Oct '06

Hello Thanks for being invited to join the group. For clarification, am I correct in reading that the plan is to formally propose S2 (3.4GHz) as the uplink for the ACP? Regards Grant Hodgson G8UBN

4 8

Proposed Eagle Antenna Arrays
by Louis McFadin 01 Oct '06

01 Oct '06

Here is a proposal for arranging the Eagle antennas that Stan Wood and I worked out today. By moving the 2M dipoles to the corners we have sufficient room for full sized elements over the ground plane. The 2M antennas should get about 8dB. Three L band patches in cavities should give us greater than 12 dB gain. By putting the S1,S2 and C band patches in hex shaped cups we maximize the available space. The cup arrays can be NC machined out of a solid blank and therefore attain precise control of the spacing. It may also serve as heat a radiating device. Each patch will be circular polarized and fed with a single feed from it's matching amplifier. The 70 CM Circular polarized patch should have around 6 dB gain. We will look at getting more gain on 70 cm. Seven S1 patches will be mounted on top the 70CM patch. They should get about 15dB gain. Tom's S2 interferometric patches are included. Omni antennas similar to that used on P3D will be required on the opposite side of the spacecraft. There should also be room for the Sun Sensors on both sides of the spacecraft. Lou McFadin W5DID w5did(a)mac.com

8 17

Presidents club reception - San Francisco
by R.Haighton 27 Sep '06

27 Sep '06

Hi All, As members of the Board of Directors and members of the Eagle group, You are invited to the "Presidents Club" reception on Friday Evening October 6th 7.00 pm. The object of this reception is to allow the major financial Supporters of AMSAT , our Prominent designers and Builders, and the Board of directors to meet, exchange views, and Gain enlightenment on the various aspects of our organization. I look forward to seeing you there. 73 Robin Haighton VE3FRH

1 0

Eagle 2007 budget input
by Jim Sanford 26 Sep '06

26 Sep '06

All: Attached is my input for the 2007 budget. It is based on a few inputs, some carried over items from 2006 that we didn't (but need to) do, and my best guess on a couple of things. 73, Jim wb4gcs(a)amsat.org

4 4

Antenna Plans
by Dick Jansson-rr 26 Sep '06

26 Sep '06

It is well that the antenna plans are starting to congeal. I do have some comments upon the diagram that John presented, herewith attached. 1) There is an option, whether employed or not, that the U band could be the stacked CP patch design previously shown, with the L band array mounted thereon, also as previously shown. 2) The U band antenna currently shown in John's design could use a modification of the dipole design used for all of the AMSAT-DL P3 satellites. We call that "design adaptation" (not stealing!). 3) The V band antennas are of a great concern as shown in John's design. The P3D V antennas were more than 880mm end-to-end span, and a nominal 144mm spaced off of the spaceframe. Three of these on top of the Eagle seems to me to be of a gargantuan, unwieldy concept. These antennas would greatly impact the spacecraft envelop as mounting in a launcher. John has talked of a bent-end antenna design, is that really practical from an RF sense? I am wondering if some form of dual-feed full-wave V band loop might not serve better in this application. Stan Wood had shown such a full-wave loop design for the Small Eagle that was only about 50mm high. Properly designed, it would not necessarily have to be 144mm high, so I am led to believe. Can some astute antenna designer look at this for us? I feel that we need to look at the options. Dick Jansson --------------------------- <mailto:rjansson@cfl.rr.com> rjansson(a)cfl.rr.com ---------------------------

4 7

Another New Rocket Fails
by Tom Clark, K3IO 26 Sep '06

26 Sep '06

>From the "It Really Is Rocket Science" department -- this one from New Mexico -- see http://news.bbc.co.uk/2/hi/science/nature/5377958.stm

1 0

Eagle power requirements
by Louis McFadin 25 Sep '06

25 Sep '06

Jim, Do we have any idea how much power Eagle will require in the two different modes 1 In sunlight and 2 during eclipse? Should we design for the 10 hour orbit that Ken used for his studies? In that orbit the worst case eclipse is about two hours and most of the time it is far less. I know we have asked that question before. Maybe it's time to get serious about establishing a power budget. The answers to these questions will drive much of the design of the spacecraft. Lou

2 1