DSP-10 EME2
A
detection from a
single antenna - brickette-only station.
back to DSP-10
Advanced Operations page
So I was reading along in the DSP-10 Operators Manual, trying to get
familiar with all the software and hardware features when I came across
one of the first weak-signal modes, EME2. EME2 is a mode that
lets a single operator look for his own echos from the moon. It
does not have stringent frequency or timinig requirements (at two
meters, ~ 1 Hz
stability over 5 seconds and clock within a few seconds of UTC) because
all
it does is transmit a carrier for two seconds then waits a little over
half a second (575 milliseconds) until the leading edge of an echo from
the moon would be arriving, then integrates reception for two
seconds. This
repeats every five seconds automatically collecting signal and noise
statistics as long as the operator can stand it.
Of course, something like 40% to 50% of the signals I've ever generated
in amateur radio have been intercepted and re-radiated by the moon, a
little of it back towards earth, but this is the first time I've ever
thought I had a shot at detecting those
returns.
Since we're looking for signals that may well be far below the noise,
the DSP-10 hops carrier frequencies around (within a window of a few
hundred Hz) in order to reduce the effect of any birdies or other QRM
that may also
be far below the noise. It also calculates the moon position and
Doppler for
the indicated frequency (times two) and listens exactly where it should
for the return. In the mode I'm using, it collects 21 frequency
bins of 2.3
Hz each. The bin in the center is the "zero frequency" where the
signal is expected and the twenty bins, ten above and ten below are
used to determine
the system noise level. This is 49.3 Hz total bandwidth that is
monitored in detail.
These are non-coherent integrations so what is supposed to happen is
that the noise variations average toward their mean power value
(everything else remaining constant) while the signal in bin 0 builds
up slightly above that mean (being noise plus signal). Depending
on EIRP and things, if this is working, you
should see a peak forming in bin zero while the rest tend to flatten
out.
What you'd expect to see is something like this:
This is a beacon in DM05, about 100 km from here over rough
terrain. On a really good day, I can hear the CW well enough to
copy it in several tries. (N6NB/B). This day was pretty
typical, not quite enough to hear audio but enough to see easily after
integrating for a few minutes. Note in the waterfall where I was
tuning around trying to get the peak on the red frequency line (323
Hz), changing the sensitivity, and so forth. You can also see a
little frequency drift. Is that the beacon, me, or both?
This is a different
mode (LTI-1) but is the same idea as EME2 just without any transmitting.
Back to reading about EME2 in the manual; this seemed pretty exciting,
and the moon happened to be up, so I
pointed in the indicated direction and tried pinging for a couple of
hours. The first several tests of this type, conducted over
several days, ended up looking like
this:
No, even with my big imagination, I'm not seeing any central peak even
starting up there. I corresponded with Bob Larking and others on
the list. He had done brickette EME2 on about ten times as many
points with an array that is about equivalent to four stacked of my one
yagi and with all that improvement over my situation (11 dB) was only
pretty
sure he
had seen something "statistically."
The yellow trace covers about 200 Hz, the 49.3 Hz segment we're talking
about
is demarked by the little red lines at the bottom of top display, with
the big 323 Hz center frequency marked by the big red line in the
middle.
Just for the record, I'm using the brickette at 7.2 watts to an M^2
2M12
beam. Very
nice antenna, I easily work San Diego and
surrounding areas from my location north of Los Angeles on 7 watts USB
(390 meters MSL),
but EME is ... apparently somewhat more challenging.
So I did some more tests and would see things like this:
and I'd be thinking, "Maybe the Doppler calculation is a little
off." So, I corresponded with the list about this and learned
that, at two meters, any Doppler errors ever experienced with this
software ought to be well under 1 Hz (which is well under 2.3 Hz) so
that
all "signal" should really be in
bin 0. I compared to Instant Track (an AMSAT product) and learned
(corresponding with one of the IT maintainers, KB5MU)
that Instant Track truncates the moon trajectory polynomials and
computes Doppler with straight linear interpolation, not centered, so
shouldn't do as good a job (and doesn't need to) as EME2. Bought
a
copy of Meeus "Astronomical Algorithms" from an amazon.com store and
studied Chapter 45 (which has the huge tables of polynomials) for a
couple of hours, eventually convincing myself that being off frequency
was not the problem here. So, that peak there at bin -9 is just
luck
(ill luck).
What about libration effects? Well, if you look at the pictures
and discussion of 10 GHz EME2
tests a few years ago, and divide the spectrum by 72 (that is, 10.368
GHz / 0.144 GHz ), it looks like all of those effects fall well within
one Hertz at 2 meters, well within one bin.
Talked to the list about other possible problems:
Is linear polarization hurting me? Faraday rotation of the
outbound and inbound signal will effectively randomnize linear
polarization leading to a mean 3 dB loss. My circularly polarized
satellite antenna is broken and down. I'd have to wire right hand
to left hand switching with the T/R sequencer. Make a note for
possible future improvements. Eat the 3 dB for now.
Is being constrained to looking near the horizon hurting
(helping)? There are situations in which ground reflections can
help, but in general the effect of being near zero degrees elevation is
increased earth and man-made noise. Pointing around in different
directions and listening at different times of day I see variations of
10 dB or more in the noise level reported by DSP-10. Make a note
to make better noise temperature measurements one of these days.
Make a note to figure out how to listen only to "quiet" returns.
Make notes about noise level with each tracking session.
I'm just using the DSP-10 straight off of 100 feet of coax to the
antenna. No preamp anywhere. Would a preamp help?
Sure, if you aren't looking at a pile of noise already (see prior
paragraph).
Studied the 2M12
documentation and single-antenna beam pattern diagrams
and specs. Went outside and spotted the moon or sun down the
antenna on the rare occasions when I could see the object in
the sky and stand where I could sight down the antenna to it.
Noted
that I was way off, 10 - 17 degrees depending on heading (steer -10 for
west, -17 for east). This is
disturbing given the fact that the controller has 1 degree
resolution. Didn't
change anything mechanically, but made corrective notes to use in
future sessions. Antenna aiming is manual, not tough for the moon
on a 36 degree beamwidth.
But, those errors mean up to another 3 dB loss, not even counting loss
of gain
due to moon elevation above zero, so these early tests were weak anyway.
I tried hooking up the only amplifier in the house, an ancient Henry
10-50 which was intended for FM but put out 32 watts driven by the
full-out brickette. I had myself convinced that this 6 dB of gain
would improve things to the point of seeing detections in a single
"pass", but <clack> <clack> <clack> and then it would
CW ID, wearing that poor old relay out, and I'd watch and see
nothing. Like watching a pot boil. I snooped around at the
JPL Amateur Radio Club, E-Bay-like places, amateur radio catalogs, and
asked my buddies about amplifiers to buy or borrow. Came up with
nothing helpful short term.
In the process, I discovered that I was able to measure through the
DSP-10 that I had a two foot RG-58 BNC cable with 1.6 dB loss!
(This, by the way explains why I could never get more than about 6
watts out of the brickette here.
Now
I'm getting 7.2 - 7.5 watts! Duh!) I was also able to
measure (and see in the waterfall)
over a dB of loss in receive signals coming back through the Henry
amplifier. I replaced the cables, took the Henry out, and posted
this to the list:
But let me just say that it is so great to be using a
radio where you
can just do some built in measurement and figure out stuff like
that!
When I originally did the "U15 Mixer Ground Modification" and was just
able to diagnose and fix an important problem using measurements that
the box would just take itself I was very impressed by what we've got
to work with here. What a great architecture!
Larkin recommended checking out the system with at least a hundred
watts before proceeding. Sound wisdom, but I'd already struck out
on a short term amplifier. After considerable thought, I reminded
myself that that I didn't want
to rush into an equipment upgrade like that. I take my own motto
"Every
Chip, Every Bit" seriously. I want to build that amplifier someday and
when I do will certainly try it on EME2 again, among other things, but
I don't want to rush that for this.
Sooo...
Another possibility was breaking down and adding an elevation
rotator. It is inevitable, I'll want to do that someday too and,
no,
I'm not going to build the thing myself (I do soldering and software,
not machining), but every time I went out and looked at my antenna that
I like, I'd think, "I like it just the way it is, the contest is coming
up, and I don't want to risk messing with it if I don't have to."
Besides, I had full-up az-el back in my AMSAT
days and it seems like I spent about half of my AMSAT time maintaining
az-el antennas and unsnagging feedlines from trees and things.
Again,
someday in due course, but not
now, not for this.
Pointing at the horizon with a horizontal beam that has something like
36 degrees
vertical beamwidth, I could only expect this to be working up to 20
degrees
elevation. This is the first hour or two after moon rising or
before moon
setting. The only way to integrate multiple passes in the current
DSP-10 software is to leave it in that mode and stop and start the
transmissions at appropriate times. The DSP-10 is my two meter
rig, I
don't want to tie it up like that!
None of this looked promising.
Then, it occured to me to do something risky. DSP-10 can capture
datasets to disk in various modes, including EME2. I'd been
looking for a
software project to get me going with this, and with Xcode on my new
Mac laptop. How hard could this be? Yeah.
I messed around with some old link budgets and never could really
decide how much power I should see back from the moon on my setup and
therefore how much averaging it would take. On the faith that (1)
my system was working right (after all, I do work San Diego > 200 km
away) and (2) that I was within 10-15 dB based on Bob's brickette test
and inference from other EME-like work, I ought to be able to take a
bunch of moonrise and moonset datasets and write a program to average
them
all together and see if that
got some sort of echo detection.
Without showing any (potentially embarrasing) numbers, here's the
general approach I took to the link budget:
- Start with my link budget template that does work correctly for radio
to radio links at some distance, frequency, losses, etc.
- Compute how much of my power is intercepted by the moon, assuming it
is small in my beamwidth (which it is). (OK, here's a number,
-2.2 dBm intercepted by the entire
moon).
- Assume that this power is re-radiated in all directions (yeah, it
might be two steradians rather than four or some ugly, bumpy spherical
integral, "all directions" is worst case).
- Take that -2.2 dBm as EIRP from the moon (just like a transmitter and
antenna with that same performance) and use my regular link calculation
the rest of the way.
This all gets into the ballpark of "pretty weak." Various
assumptions said I needed to integrate between 5 and 500,000 points to
get a clean detection. Incoherent averaging is sensitive
to every dB like that. True, I was not be seeing anything
yet. I might not ever see anything....
So, I made a list of upcoming moonrise and moonsets in my notebook and
made an effort to capture the ones when I was going to be home.
It's not that hard, just get it started and come over every ten or
fifteen minutes to check progress and bump the antenna a little in
azimuth. While these were going on, I was often sitting here
trying to
get my post processing program running.
One thing I knew I needed to do was re-measure my horizon mask. I
work San Diego to the south, but have a big blockage to the
north. Counting data points in the sums where it was not even
possible that the moon was visible would dilute the results, at best.
Here I am with my protractor, string, and plumb weight taking data to
re-estimate my elevation mask. N6NB/B in DM05 is at about 360,
the DM12 stations I typically work 130-150. When I work CM94,
it's on heading 300
(all true).
|
|
A more detailed view, but which agrees well with this survey can be
viewed here.
By 2006 May 27 I had my program ingesting
the numbers from a uhfa_1.dat
file of 4000 EME2
points taken into a dummy load. (No detection, as
expected.) I was
ready to move on to implementing processing rules and starting to
figure out what the numbers meant for data reduction. The startup
with Xcode was incredibly simple. I was doing "hello world" in
five minutes! (It uses GCC 4.0.) KB5MU made suggestions
about cross platform builds and plotting outputs. These were
filed for activation in later versions. For now I'm putting
numbers out of my C++ program, pasting them into Excel, and making
plots there.
Sometime around 2006 June 6 I had the first version of the program
fully working. The first thing that I found was that if I set the
noise
blanker level low enough (that is, throw away points with a lot of
signal in all bins), I was seeing something that looked non-accidental
peak in the central bin. (This limit also threw away 85% of the
data.) Posted to the list that I thought I had
a detection and would soon report the results here (and there).
2006 June 6, posted results from Version 1.0 processing 11 rise/set
session files. Thought I was seeing a central peak and was
looking to the list for comfirmation, but still needed
more work.
On 2006 June 13 I had a Version 1.1 with the following features.
EME2 Records:
HA - time tags
HE - noise bins and other information
Monotonically increasing time tags and alternating HA and HE records
are enforced. (This is not too much to ask.)
Control records:
PD - Set Debugging level to None, Summary, or Detail.
PF - Read another File. Can be a renamed (or not renamed)
UHFA_1.DAT file or another file of instructions. (Can also read a
uhfa_1.dat directly.)
PI - Set an inclusive time Interval inside which points are
processed and outside which they are ignored. Up to 100 such
intervals can be set (for multiple passes).
PN - Set the maximum Noise level for which a record will be
processed. The 'pave' field is read and normalized. If it
is greater than this number, the record is skipped.
PR - Put a Remark in an input file. The remark must end
with a # character by itself. The remark will be printed at Debug
level Summary or higher.
PT - Set the system Temperature in Kelvin for signal and noise
level calculations.
PX - Set "fiX bit 128" to On or Off.
Other:
# File comment, must end with another #. Used to leave commentary
in the control file or quickly comment out PF files or other
instructions.
The basic function is to read all 21 bins out of the HE records and
find the average and standard deviation per bin (also the 'pave' noise
level bin). Ignoring the three central bins (-1, 0, and 1), find
the mean and standard deviation of all the noise bin averages.
Compare this to the level in bin 0 in standard deviations. Put
out numbers suitable for plotting in various forms (power ratios, dB,
statistics, etc.) Also compute from the noise temperature (PT)
what the corresponding measurement level is and the implied power of
the central peak, if any.
Summary also includes numbers of points seen, processed, and thrown
away for various reasons. The result presented here said this:
Total points
seen: 14664
Points
processed: 5476 =
37%
Points
skipped:
5604 = 38%
Points skipped for noise:
3584 = 24%
Reasonable commentary throughout the source, including excerpts of
UHFA.C, UHFA.H, and U_CODE.C with my commentary about what I think it
means, what I thought I was doing, and lists of what else I might do.
After trying different sets of files, different maximum elevations, and
different noise levels, I finally settled on this result as the best
one to present.
This is the "yellow trace" equivalent of the integration of all the
uhfa_1.dat renamed data files processed in the run. The noise
bins are not near as flat as those shown in the first screen capture
above, but this is definitely a statistically significant peak.
This is the control file that provides
the
input instructions to my EME2 post processing program. Some of
what
it says is:
Ignore all points with average noise more than 13.05 (raw power out of
DSP-10 in an HE record), that is, 11.2 dB. Go much above that and
the peak diminishes then dissappears into the noise. Go much
below that and there aren't enough points left for good statistics, and
the peak goes down too. In the end I'm processing about a third
of the points I took
System temperature is estimated at 600K based on something I vaguely
remember reading about DSP-10. This is just the DSP-10 on the
beam with no preamp anywhere. I plan to use the "soldering iron
and resistor" method to get an estimate of what my actual system
temperature is and will post the result here too when I have it.
In addition to the moon trajectory issues, I became concerned about the
two-byte recombining code in UHFA.C. Wrote a routine to detect
when
an
error in the bit representing value 128 was allegedly being made then
fix
it.
In short, bit 7 of the low order byte represents 256 in
unsigned representation or -128 / +128 in signed representation.
I couldn't tell from reading UHFA.C which way it was being treated but
I had decided that it needed to be unsigned to be correct. This
fix algorithm assumes that UHFA.C has taken the byte as "signed" when
it should have been "unsigned", reverse engineers the record and
reproduces the "corrected" one. To use the fix if it is not
needed or to not use the fix if it is needed is to throw away the
information in that bit, but it doesn't hurt the information in the
other 15 bits. I still see a peak either way. Turning the fix on (PX On) makes the
statistics worse, so I
turned it
off.
Bottom line: Results are better with the fix turned off implying
that UHFA.C is doing the right thing.
I put in PI records for every file, a set for each data file running
from horizon mask to 12 degrees, horizon mask to 16 degrees and horizon
mask to 20 degrees, and commented in the ones that would
allow only points between my horizon mask (charted above) and 20
degrees
elevation. This seemed to work best. A later version of
this program could do the Meeus calculations and greatly simplify this
part.
After all this setup the renamed UHFA_1.DAT files are listed
last. Notice that there
are 19 sessions of which three are commented out meaning that this
result is from 16 rise or set passes, probably a total of around 20
hours data (7.5 of it used, amounting to about 3 hours of key-down
carrier
integration).
The 4.2 sigma in the plot is the number of standard deviations of the
bin 0 peak above the average of the 18 "noise bins", that is, [-10, -2]
and [2, 10]. This is the same thing Larkin does in his code,
leaving out the three in the middle since the two adjacent to bin 0
might also have some signal in them, as they seem to here. 4.2
sigma over mean noise in bin 0 means that this is nearly certainly a
detection of the desired signal, returns
from the moon!
Here's the remarkable thing about all
this: It was an
up-from-the-bottom attempt. Ignoring Bob's wisdom to just
verify
with higher power that things were basically working before proceeding
at lower power, I was in a position where I'd see something only if
everything was right, hardware, software, assumptions, noise, setting
of the clock, and so forth after several weeks of data taking, program
development, and related efforts. No single run saw anything by
itself, none of them
had time to average down to anywhere near the 0.07 dB level. I
have lots of screen captures
that look just like the ones at the top of this page. It took the
post processing software working right and over a dozen capture files
thrown in before I started seeing anything at all.
What's neat to me about it all,
however, is that using a radio I built myself and an antenna I put
together
myself and software that I wrote myself, I've touched the moon!
For
my particular set of passions, this is about as good as going.
Maybe better.
Never merely satisfied, however, here are a couple of preliminary
thoughts about EVE -- Earth Venus
Earth.
Back in the 80s, W3IWI wrote an article saying that modern home
computers (he was thinking TRS-80 at the time) might bring something
like Venus bounce within amateur reach, at least for the ultra patient
(like today's PUA43 users!)
What we have here takes us a long way in that direction, and we're
nearly
close enough to give it a try.
Going to Algonquin or equivalent
doesn't count. Government installations have already done Venus
bounce, Sun bounce, Mars and Mecury bounce, and Saturn ring bounce
(called "Solar System Radar"). For amateurs to use
these facilities to do the same thing on their own time is fine and
should go in some sort of record book, but it doesn't prove anything
with respect to what we're talking about here.
What I'm talking about here is an amateur radio
installation on amateur radio resources. With such amateur
installations, we're talking, at this stage, about high probability
detection, not science. Rather than analyzing a signal from Venus
to determine things like the Astronomical Unit or length of Venus Day,
we are using what we already know about such things to design a signal
and detection methodology then study noise statistically as I've done
here..
During an "integration season" Venus would be 120 - 200 times as far
away as the moon, but it is four times larger in diameter (about like
the earth). This comes to about 75 dB further down than
EME. Venus' rotation is slow, in fact, slightly slower than its
revolution, making it a very cooperative target from a rotation-doppler
induced signal spreading point of view, very similar to the moon, in
fact. What's more, we learn from the early JPL experiments (Muhleman,
1961) that radio reflections from Venus (at least at L-Band) are
about 10% compared to a perfect spherical reflector, compared to the
moon which he cites as 2%. Using that factor of five, let's say
that EVE is 68 dB down from EME.
A good reference on Venus Radar (which this is, essentially) is Radio Science
and Venus. Note in particular the pictures of the antennas
used for Venus bounce in the competitive inferior conjunction of 1961
and the discussion of chirp and "circles of constant echo delay" with
respect to signal design for detection.
Other planets (like
Mars) are even further down (smaller, further away) and rotate faster
(hundreds of meters per second at the equator, leading to significant
signal spreading), though Mars has the advantage that, when it is
close, at opposition,
it would be in the night sky away from the sun, whereas Venus, when
closest, is near the sun in our sky.
My station here (7.2 W through some coax to an antenna that claims 12.8
dBi is about 140
watts EIRP (51 dBm).
I can imagine an amateur 2 meter moonbounce station at 85 dBm EIRP or
maybe a little more. I think such things are not uncommon for the
"serious." Counting 23 dB for the power increase to 1500 watts
and 10 dB
for the antenna, twice, (transmit and receive) Let's call that 43 dB
improvement. We need 25 dB
more.
I can imagine doing ten times as many sessions for ten times as long
each. With an elevation rotator I could track all day. If I
did sufficient automation of everything and did this for 100-150 days
(the season during which Venus would be "close enough") rather than 16
passes and didn't have
any serious problems, that would yeild maybe a million or more usable
points,
12 dB improvement over what I've done here. We still need 13 dB.
Well, hmm. Circular polarization and switching: 3 dB.
Still need 10 dB.
Actually, we could transmit and receive at different locations
("bi-static") giving
up to 100% duty cycle, 2 dB, but that would involve two big stations
working right all season. Let's skip this and call the current
estimate an "individual effort" for now, meaning that our signal design
would be near 50% duty cycle, not much better than the 40% of
EME2. (Venus, being a couple of light minutes away, would we call
this EVE300?)
A good preamp (estimate 60 Kelvin, well within amateur reach at 0.144
GHz) could buy 10 dB over what I'm using here. Now we're at
break-even. Given the expense and trouble of all these efforts,
the result would be similar to mine given above, if succesful.
And at this point I'm out of good ideas.
I think everything I've just listed pushes the limits of what an
obsessed ham will do. Adding multiple "inferior conjunction"
seasons would only give further improvement at the square root of the
number of seasons (i.e., 3 more dB for four tracking seasons as opposed
to one). I think one season
is all we can expect from a ham, particularly since it is a blind
up-from-the-bottom deal and inter-seasonal windstorms have a way of
"dealing with" big antennas. A plot like the one above (but with
a peak 0.01 dB out of the "noise") would be
the
result of thousands of dollars and hundreds of days effort. If
anything was wrong, there wouldn't even be that, but you wouldn't know
for a long time that success was even "likely."
And, all of those things, like Venus signal design and detection
processing, would be much
more difficult than EME2 has been. It would be serious work and
expense, maybe 100 - 1000 times what I've done here (20-30 dBWork!), to
attempt it.
But, hey, before EME2, we were 45-50
dB away from EVE, now it is within reach. That's progress!
W5UN could do it, full gallon
to the Mighty Big Array
is something like 91-92 dBm....
Things still to do here:
Measure the DSP-10 noise figure as mentioned above and post.
Figure out how to post, share, or compile my program for different
platforms if there is interest.
Enhance DSP-10-Post with readers for the other DSP-10 file types (like
HB) and add
some internal plotting (maybe gnuPlot).
Scratch my head about doing sun noise with this setup.
back to DSP-10
Advanced Operations page
n5bf-at-amsat-dot-org
last modified 2006 July17, cbd
added heywhatsthat view 2008 March 14, cbd
(c) 2006 Courtney B. Duncan