From ajc at haystack.mit.edu Tue Oct 14 16:43:19 2003 From: ajc at haystack.mit.edu (Anthea Coster) Date: Wed Jul 21 10:29:04 2004 Subject: [gps-developers] logistics and agenda Message-ID: <3F8C5FE7.3040206@haystack.mit.edu> Hello GPS workshop attendees, More logistics and information. To make your hotel reservations (and make them within the next week or so): We have switched hotels to Hawthorn Suites, 25 Research Place, North Chelmsford, MA. 978-256-5151. Rooms are $99.00/night breakfast included (I have been told that this is a REAL breakfast). Please identify yourself as being with the Haystack GPS Group. You can go to the web (www.hawthorn.com) choose "MA" and select Boston/Chelmsford. There are directions on this page. Limousine Information. This became to complicated to arrange for "group" travel. If you are interested in transportation to and from the Hawthorn Suites, please make your own arrangements with the following companies. We WILL PROVIDE SHUTTLE SERVICE to and from Haystack/Hawthorn Suites - just let us know if you will need it. For passengers traveling in/out of Boston/Logan Airport: There are 2 choices: 1. C&L Air Limo - 1-800-247-7080 - You will need to provide them with the name of the airline, flight arrival time, and a credit card number 2. TWC Airport Limo - 1-800-223-2325 - You will need to provide them with the name of the airline, flight arrival time, and a credit card number For passengers taveling in/out of Manchester, NH Airport, use TWC Airport Limo (option #2, above.) Prospective passengers should make their limo reservations NO LATER THAN 1 WEEK PRIOR TO THE DESIRED PICK-UP DATE IN ORDER TO ENSURE AVAILABILITY OF LIMO SERVICE. Agenda for the workshop. Our primary goal with this workshop is to keep it as a workshop - not a conference. This has worked successfully for us at Haystack in the past. Our goal is to emphasize round-table discussion. People are encouraged to bring viewgraphs that will aid their discussions in the various areas - but realize that no one will be allowed to talk for more than 20 minutes straight! We are going to organize the workshop around "topics" and allow for free-form discussion, with the one limitation above (no one can talk for more than 20 minutes straight!). We will have various "recorders" throughout the workshop, and I may ask each of you to take notes for an hour or two during the workshop. As a format, what we are recommending is this: Introduction to different group's activities. Strictly limited to 2 viewgraphs a person and 5 minutes talk. 9:00 - 11:00 (Break at 10:15) Introductions 11:00 - 12:00 Begin general discussion I would like some input from our attendees. Can you rank these three workshop goals in order of importance to you and your group. Please also send me additional topics that you would like covered. 1. One goal of this workshop is to examine how best to form collaborative teams to work on merging GPS data products with other data products to address larger science issues. This includes planning for special sessions at upcoming conferences, and working towards a goal beyond just GPS. 2. Another goal is to examine how to best share software tools and data products amongst ourselves, and to discuss issues with data processing (mapping functions, receiver bias determination). 3. How to discuss how best fill in the gaps of GPS data coverage in South America/Africa, and how to bring GPS data products more to the forefront within the atmospheric science community. Can everyone rank these three goals in order of what they are most interested in? (and send other topics you would like covered). Current list of Attendees: Paolo Spalla November 8,9,10,11 Bruce Tsuratani November 9,10 Tony Mannucci November 9, 10, 11 Hyunho Rho November 9, 10, 11 Richard Langley November 10, 11 Pat Doherty no hotel necessary Susan Skone November 9, 10 Paul Kintner November 9, 10 Brent Ledvina November 9, 10 Catheryn Mitchell November 8, 9, 10, 11 Manuel Hernandez-Pajares November 9, 10 Brian Wilson November 9, 10 Eduardo Araujo November 9, 10, 11 Jonathan Makela November 9, 10 Paul Spencer November 8, 9, 10, 11 others from AFRL and Haystack. Thank you everyone, and comments are welcome. Anthea -- ****************************************** Anthea J. Coster MIT Haystack Observatory Atmospheric Sciences Off Route 40 Westford, MA 01886 phone: 781-981-5753 fax: 781-981-5766 email: ajc@haystack.mit.edu ****************************************** From brideout at haystack.mit.edu Fri Oct 31 16:52:55 2003 From: brideout at haystack.mit.edu (William Rideout) Date: Wed Jul 21 10:29:05 2004 Subject: [gps-developers] A better vertical tec mapping method Message-ID: <3FA2D9B7.3020502@haystack.mit.edu> A part of our effort to squeeze every last bit of noise out of our TEC data, I'd like to make the following suggestion for how to improve the vertical tec mapping method. Now that we've fixed the satellite bias issue, the low elevation data is remarkably tight when you plot tec versus time for a given receiver. The one significant source of distortion is now imperfections in dealing with the mapping of low elevation data to vertical data. The general trend is that for a given receiver and day, the low elevation data is trending either above the baseline tec, below the baseline tec, or (rarely) shows no trend. Our present approach is to use a mapping method that has only one input: elevation angle. If we stay with that approach, there's not much we can do to improve things. This mapping method is based on a model of the ionosphere, and clearly the real ionosphere differs from that model in ways that cause the elevation effect to be both over and under-estimated. I proposed that we use a mapping method with two inputs: 1) elevation, and 2) average % change in TEC between 60 and 40 degrees for that receiver and that day. To the extend that the ionosphere is uniform above a given receiver for a given day, this should allow us to improve the mapping function considerably. Algorithm: The second parameter will be calculated as follows: For any given satellite, any time the elevation goes smoothly from 40 to 60 or from 60 to 40 degrees, that will count as a measurement. Of course there are slower background changes in the tec occuring at the same time, but these should be averaged out since satellites are both rising and falling at any time, plus a day usually includes tec rising and falling (but more slowly than elevation effects). By smoothly, I mean no time gaps of more than a few minutes (I don't want to include data from separate passes). I'll call this second parameter the elevation effect. My plan is to pick some receiver data, calculate the elevation effect, and then modify one parameter from the mapping method to make the graphs look the best (okay, I'm planning to do this by eye unless there a better way). I then plan to get a simple function that calculates the modified mapping parameter to the elevation effect. Please let me know if you have any comments. Bill -- Bill Rideout MIT Haystack Observatory Email: brideout@haystack.mit.edu Phone: 781 981-5624