From brideout at haystack.mit.edu Thu Dec 4 10:53:36 2003 From: brideout at haystack.mit.edu (William Rideout) Date: Wed Jul 21 10:29:07 2004 Subject: [gps-developers] Movie making methods on hyperion Message-ID: <3FCF5880.3090105@haystack.mit.edu> Two methods to make tec movies from tec files are on hyperion. One makes movies in cartesian coordinates, one in polar. They are make_gps_movie_cart make_gps_movie_polar Type help in matlab to get usage. make_gps_movie_cart allows you to keep solar noon in the center if wanted. Both also generate jpegs of each frame. To install elsewhere, copy *.m files from /opt/madrigal/lib/madmatlab to your local directory, and run matlab from that directory. Bill -- Bill Rideout MIT Haystack Observatory Email: brideout@haystack.mit.edu Phone: 781 981-5624 From brideout at haystack.mit.edu Wed Dec 10 13:08:15 2003 From: brideout at haystack.mit.edu (William Rideout) Date: Wed Jul 21 10:29:07 2004 Subject: [gps-developers] Modifications to GPS processing Message-ID: <3FD7610F.7000603@haystack.mit.edu> Anthea and I decided it would be better to use satellite biases from the daily files generated by JPL or CODE, rather than our yearly files, since satellites are replaced on times besides Jan 1st. This change will again improve our data processing quality, although not as drastically as the svbias bug we found on Oct. 30, 2003. The code has been updated to implement this change, and installed on my pc, John Holt's, and on /usr/oasis/experiments/gps/algo. You shouldn't notice any difference, unless you try to process data you downloaded before today (12/10/2003). In this case you'll get an error message saying no bias file was available. You have three choices to solve the problem: 1. Download the file jpl*i.Z manually from ftp://cddisa.gsfc.nasa.gov/pub/gps/products/ionex/ 2. Throw out the old data and get new data with gps_retrieve.py. 3. Tell process_gps.py to use an existing svbias file by using --useSvbias=. (I didn't make this work by default, since either 1 or 2 above are prefered.) Let me know if there are any problems with this change. Bill -- Bill Rideout MIT Haystack Observatory Email: brideout@haystack.mit.edu Phone: 781 981-5624 From brideout at haystack.mit.edu Wed Dec 10 16:53:53 2003 From: brideout at haystack.mit.edu (William Rideout) Date: Wed Jul 21 10:29:08 2004 Subject: [gps-developers] The next improvement in gps processing Message-ID: <3FD795F1.3060201@haystack.mit.edu> Now that the satellite bias issue is settled, its time to consider the next step in improving the processing of gps data. Our long term goal remains processing the data using any ionospheric model, and solving for both the ionosphere and receiver bias at once since they are coupled problems. All the raw data needed for such a full solution is now available, which is really just time, az, el, and effective line-of-sight tec (along with receiver location). However, what steps can we take to make our present processing better until that full solution is ready? We agree that our present method of finding receiver bias is not perfect, since we assume TEC goes to zero at some time. However, I'm not convinced that our use of a fixed mapping function to get vertical TEC is not equally significant an error. Pat Doherty suggested a method for getting receiver bias that assumes a perfect mapping function, as I mentioned in a previous email. I propose we improve on that suggestion to find an optimal receiver bias and slab height. This is a small step toward the complete solution described above, but I think that its better than considering receiver bias alone. Here's the approach that Phil and I worked on this morning: The fundamental assumption Pat Doherty makes is that TEC shouldn't depend on elevation angle, especially at night. (I'll argue that it shouldn't depend on elevation angle ever as long as the sample is large enough, but that's a different email). Given that, we simply need to find the receiver bias and mapping function that minimize elevation angle dependence. To simplify things, I keep the slab model, and simply vary the slab height, so that we only have two input parameters. There are standard methods (Levenberg-Marquardt technique) that Phil pointed out to find the best solution for this kind of well-behaved problem. There's no reason to expect that the solution space has more than one minimum. These methods are available in python at http://cars9.uchicago.edu/software/python/. So all I'd need to do is write a python method that accepts receiver bias and slab height and returns a measure of the flatness of tec versus elevation angle. Here's how I think this method might work. If I bin TEC data by elevation, get a mean for each bin, and then plot mean versus elevation, it should approximate a parabola (where elevation 0 is straight overhead). Given the fitted line, mean = a + b*el^2 b is the flatness measure I'd return. To make the method fast, I'd load each site's elevation versus line-of-sight tec into global memory from the *.dat file. Then with each method call, I'd loop through that array, recalculating vertical TEC given the new receiver bias and mapping method, and binning as I went. The last step would be a fit to a small number of data points. I don't think this should take more that a few days to implement, and see how it works. The other method is what we have is coincidence measurements between receivers that works for receivers that are close to other receivers. This method has the following drawbacks: 1. As presently implemented in Matlab, its very slow. 2. It assumes a perfect mapping method also (especially important when receivers are not that close). 3. It fails utterly for isolated receivers. Let me know what you think. Bill -- Bill Rideout MIT Haystack Observatory Email: brideout@haystack.mit.edu Phone: 781 981-5624 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 66212 bytes Desc: not available Url : http://openradar.org/pipermail/gps-developers/attachments/20031210/449e5105/Screenshot.png From w_suparta at yahoo.com Fri Dec 12 08:04:19 2003 From: w_suparta at yahoo.com (I Wayan Suparta Atmanawijaya) Date: Wed Jul 21 10:29:08 2004 Subject: [gps-developers] Help me... Message-ID: <20031212130419.33377.qmail@web20022.mail.yahoo.com> Dear for all, I'm now have diffcully, so please helpe me for to solve a problem was how read data from GPS using matlab 5.3 and how method calculating precitable water or integrated water vapor (IWV) from meteorological data GPS (temperature, pressure, and humidity). And then, how plot this graph IWV vs gps time (one day = diary). Thanks for your help me and your attention. Regard, Mr. Wayan __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/