November 2006 - Eagle (INACTIVE)

Update on WYSIWYM editor
by Emily Clarke 30 Nov '06

30 Nov '06

You may have noticed that the WYSIWYM editor is not working properly. There is a dependency for the HTML to Wiki converter that hasn't yet been met. The problem appears that the converter will not build under FreeBSD, the OS on the AMSAT server. So although it works on my staging server (running Fedora Core) it will take some additional work to get it working in EaglePedia. 73, Emily --------------------------------- N1DID formerly W0EEC - CM87tm Support Project OSCAR - http://www.projectoscar.net

1 0

Improving your ability to search in EaglePedia
by Emily Clarke 28 Nov '06

28 Nov '06

When you search inside EaglePedia you will generally find articles you are looking for. However, if you are looking for information about an EaglePedia user or a help topic you probably aren't getting the results you need. This is because by default EaglePedia searches for articles in the Main namespace. What is the Main namespace, you ask? The core structure of EaglePedia is organized into "super-categories" called Namespaces. You can find a list of these by clicking on "my preferences" in the TOP RIGHT links on every EaglePedia page, and then clicking on the "Search" tab. By default these will generally only have "(Main)" checked. I would recommend at a minimum you check the following Namespaces: Talk User Help Image Category 73, Emily --------------------------------- N1DID formerly W0EEC - CM87tm Support Project OSCAR - http://www.projectoscar.net

1 0

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