[DSP-10] More EME-2 tests

Sat May 27 16:33:37 EDT 2006

>Hi Courtney,
>
>I've been away for the last week or so. Thanks to W7CQ for catching 
>the fact I missed this e-mail!
>
>The accuracy of the EME-Doppler corrections in the DSP-10 was felt 
>to be important, as most of the special modes were quite frequency 
>sensitive.  The goal was to make the Doppler error smaller than the 
>spreading due to libration.  More on the accuracy in a moment.

<snip>

>
>We have had various opportunities to check the accuracy. Most of 
>these were several years ago. One example is an accuracy of 29 Hz, 
>observed by W7LHL at 10 GHz ( 
>http://www.proaxis.com/~boblark/wksig1.htm )  Some of that error may 
>be caused by a few seconds of clock error.  The Doppler changes 
>quite rapidly and an accurate setting of UTC is important.  In any 
>event, the 2-meter error must be less than one Hz.
>
>If anyone does EME-2, please report back the Doppler error observed. 
>More measurements are always good!!

I'm scrounging a copy of Meeus and will flip through there and see if 
I can get a feel for how accurate the epoch 2000 polynomials would be 
in 2006.

Based on the discussion here, it looks like all the effects, 
libration and polynomial rot, should be sub-bin sized (2.3 Hz) on two 
meters as long as my clock is within a few seconds of UTC, so I'm 
going to assume for now that I'm looking only at the central bin for 
the signal.

>
>
>Again any confirmations or other data on this question would be most useful.
>
>73, Bob  W7PUA
>
>Also, keep after that integration of the data. It is an amazing 
>process, and lots of fun.

I have the program reading the uhfa_1.dat files and parsing them into 
numbers.  I also did a dumb average on the 28 values in the HE array 
and got reasonable answers over 4000 points collected into a dummy 
load.  Not that I know yet what those values represent but they look 
like noise being averaged down to less noise.

The next steps are to

- implement a few rules and the multiple input file mechanism
- perform the proper operations on the data and figure out various outputs.

The basic operation is that you run my program on a uhfa_1.dat file 
or on a text file that you made yourself that includes a list of 
instructions (what points or ranges to include and exclude, etc.) and 
a list of [renamed] uhfa_1.dat type files to process.

I'm working in Xcode on the Mac which is GCC 4.0.  When I'm up to 
version 1.0, which I'll be using with my own collected data, I'll try 
compiling it at work (on linux) and then release what I have to the 
rest of you guys if anyone else is interested in QRPpppp EME-2.

I took the Henry amplifier out and am now just using the Brickette at 
7 - 7.5 watts.  Receiving through the Henry had 2 dB more noise in it 
and the relay chatter on the CW-ID was unpleasing.

Courtney

>
>At 12:03 AM 5/16/2006 -0700, you wrote:
>>I'm conducting more moon-rise and moon-set EME-2 tests at 30 watts 
>>to a 12 element yagi.  I've decided not to invest in an amplifier 
>>or elevation rotator just yet (and struck out trying to borrow one, 
>>at least so far).  I've decided, rather, to attempt a 
>>post-processing program.
>>
>>This will lead to more questions.  I'll try to figure it all out 
>>from the source code, documentation, comments, and inspection, but 
>>if I get really stuck I'll post questions here.
>>
>>This program will allow some editing of the data, deciding to throw 
>>away more points for more reasons (good ones or arbitrary ones). 
>>The "noise blank" feature already does this sort of thing.  In post 
>>processing, I'll be able to "try things" on the same set of data.
>>
>>I expect to need maybe a dozen of the hour-long passes I currently 
>>get (quiet ones at that).  I have two in the can so far.  :-)
>>
>>So here's the first question.  As I sit here watching EME-2 slowly 
>>make integrations (watching a pot boil....) I sometimes see 
>>features develop that seem like they might be something.  Like, 
>>five adjacent bins will make a nice little hill, but not 
>>necessarily centered at Cntr Sig.
>>
>>At first I was worried that there might be a Doppler error of a few 
>>bins.  Before I continue, let me say that I've decided (after 
>>watching several of these pots boil) that I'm just seeing 
>>coincidences and they don't represent the signal that I'm looking 
>>for beginning to emerge.  However, it did get me to wondering how 
>>accurate the Doppler calculation is.
>>
>>I compared to a 90s vintage satellite tracking program (from AMSAT) 
>>Instantrack 1.50.  IT's az/el for the moon was exactly the same to 
>>0.01 degree display resolution, as far as I could tell by eyeball 
>>synchronizing the clocks.  This means that the two codes agree in 
>>moon/station position to a few tens of km.  The Dopplers, however, 
>>were different by several Hz, varying from time to time in the 
>>month. Right now, for instance, they are 13 Hz different.
>>
>>I corresponded with one of the maintainers of IT (KB5MU) and 
>>learned that IT uses what they call the "truncated Meeus model", 
>>that is, the polynomials are truncated to the A + BT or first order 
>>terms.  This is for computational speed where amateur-grade 
>>pointing accuracy is the only competing requirement.  Your average 
>>OSCAR user would think 10-20 Hz Doppler accuracy and 0.05 degrees 
>>in az/el was great.
>>
>>So the question is, how accurate is the DSP-10 moon Doppler 
>>calculation?  I saw in the documentation that (five years ago) 
>>there were errors on the order of 15 parts per billion.  That is 
>>about the same size as a bin at 2 meters the way I'm set up right 
>>now (323 Hz center) so I would expect to not quite be able to see 
>>that.  Is there something about the formulation that might degrade 
>>over several years?  (If there's a place in the code that discusses 
>>this, just point me to it.)
>>
>>The reason I ask is that I could put a per pass (or per point for 
>>that matter) frequency offset in my program if it would help.
>>
>>2.3 Hz at 2 meters is 4.6 meters per second.  Not a bad precision 
>>for the three-body problem!
>>
>>Courtney
>
>
>_______________________________________________
>DSP-10 mailing list
>DSP-10 at mailman.qth.net
>http://mailman.qth.net/mailman/listinfo/dsp-10