[DSP-10] More EME-2 tests

David Garnier dgarnier at wi.rr.com
Mon Sep 4 14:55:17 EDT 2006 

Hi Guys,

It's raining outside, I am still here sorting though old emails... 

I must say - what some of you have accomplished is quite humbling,
maybe someday you will see my call "off the far side of the moon."  :-)

73's & Regards to all,

Dave Garnier - wb9own



Courtney Duncan wrote:
>> 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
>
> _______________________________________________
> DSP-10 mailing list
> DSP-10 at mailman.qth.net
> http://mailman.qth.net/mailman/listinfo/dsp-10
>

More information about the DSP-10 mailing list