Scientific Method - Neutron Star Group

Vela Pulsar Project – Early Results
Steve Olney (VK2XV) – NRARAO
13 April 2015
Some encouraging results are described and possible future developments
Introduction
main GUI overview. As you can see there is a lot of information
crowded onto the screen.
For over two years now (starting from the end of 2012) I have
been pursuing the gaol of trying to detect the Vela Pulsar signal
with a small antenna – arbitrarily defined as an antenna with a
physical capture area of less than 5 m2.
During that time, upon advice of Joe Taylor (K1JT), I have gone
from lower observational frequencies to higher frequencies. The
current attempt is conducted at an observational frequency of
400 MHz.
NOTE: The following results are presented as general interest
only and do NOT constitute any claim of being valid.
The general methodology used can be found in any good reference
book on pulsar astronomy. I use “Handbook of Pulsar Astronomy”
by Lorimer & Kramer as my Vela Pulsar Project 'bible'.
The ONLY unique aspect to the method used is a bespoke
selection of system parameters tailored specifically to the
properties of the Vela Pulsar signal. This is done because I have a
theory that this particular configuration increases the chance of
successful detection. For the sake of convenience I term this
configuration the “FFT Sweetspot”. The theory behind this
configuration has been presented elsewhere and won't be
discussed here. In the near future details of this bespoke
configuration will be re-presented if the project achieves success.
Figure 1: Main GUI Screen
This main GUI screen is comprised of a number of sections. Topleft is a section containing general information (Figure 2), most of
which is updated in real-time.
Suffice to say at this point is that the “FFT Sweetspot”
configuration, in my opinion, turns the usual negative effect of
dispersion into a positive factor. This theory remains to be
proven by practical results. Here presented is information about
efforts to prove my theory with practical results.
Summary of Results So Far
The project development has progressed to the point where some
real data can be acquired and analysed. Initially – to test my
“FFT Sweetspot” theory, simulations in software were done. The
results of those simulations led to the selection of the Vela Pulsar
as the target pulsar, as well observational frequency of 400 MHz
and observational bandwidth of 5 MHz in accordance with the
principles of the “FFT Sweetspot” theory. Details of that
principle will re-presented ina note later on as mentioned above.
Figure 2: General Information
Next came the development of software for data acquisition and
analysis closely followed by a start on the parallel development of
hardware.
The next section contains Vela positional information (Figure 3).
This is also updated in real-time.
The next section across the screen contains a visual
representation of Vela's position in the sky (Figure 4). Note that
it is not a true altitude-azimuth plot, but simply represents that
path traced while looking at the south celestial pole. Specifically
it tells me visually when Vela is above or below the horizon and
when it is tranversing the antenna beamwidth.
Software – Data Acquisition and Analysis
The software is written in C# in a Windows environment
(apologies to all those UNIX aficionados out there) using
Microsoft Visual C# Express 2010. I find this a great software
development environment for my purposes. Figure 1 shows the
1
length, filename tags, and various other factors. There is a
“Record Now” button as well as a button to assert the automatic
recording scheduler which runs unattended commencing from the
hour angle specified.
Figure 3: Vela Positional
Information
Figure 5: Time Mode
Panel
The remaining section on the GUI residing at the bottom left is an
antenna positioning control. At the moment the coding for this
function is done, but untested, as this may or may not be a
requirement of the future.
Figure 4: Vela Visibility and Period Data
Below the visibility section in Figure 4 is a small section (“Vela
Pulsar Period Data”) containing the predicted frequency by two
different methods. The linear fit value in green is used during
the offline analysis stage to mark the predicted frequency.
Figure 6: Data Acquisition Control Panel
From the menu bar across the top of the main GUI a number of
modal windows can be launched. A number of them are test bed
functions, while some of them are analysis tools. Included in this
group are test file generators, experimental processing modules
and the like.
The next section across to the right on the GUI is time control
(Figure 5). Here the display can be set to update in real-time, or
in time lapse mode (increments every second by user selectable
steps of months, days, hours or minutes). Lastly the time can be
set manually to within 1 second to any time so desired. A cool
feature of this is that I can, via a drop down menu, specify that a
range of parameters are written to a file while stepping through a
time range. For example, by writing predicted frequency to the
file I can produce data that can be loaded into a spreadsheet
allowing the plotting of the frequency versus time. This plot can
be very interesting as it shows the effects on the instantaneous
observed pulse frequency caused by the Vela Pulsar's intrinsic
spin down plus the doppler shift caused by the earth spinning as
well as its orbital trajectory around the Sun.
Also accessed from that menu are the daily working modules used
to apply RFI excision and to do offline analysis of the data.
As an example Figure 7 shows the “DFT Dynamic Track Search”
module. This is the module used to analyse the data and produce a
display of the result along with some statistical analysis.
Analyses can be done at various levels of bin zoom and number.
The graph is annotated with predicted Vela pulse frequency, the
maximum peak frequency and some statistics and a panel
containing file data parameters.
The section on the bottom right (Figure 6) is the data acquisition
control panel which contains controls for sample rate, data run
2
Figure 7: DFT Dynamic Track Search Window
Hardware – RF Chain and Data Acquisition
Figure 9: 45 MHz IF Amplifier and Detector
Working backwards through the hardware chain from the data
acquisition computer (Windows 7 Pro OS) which runs the
previously described software, we have an external USB
soundcard interface. This external soundcard ( the blue object in
Figure 8) is a cheap eBay purchase and was selected because it
has a relatively large case which can be disassembled – important
because it needed to be modified.
The input to the FRG-9600 comes from a MiniCircuits ZKL-2R7
amplifier whose output is padded by a 3 dB attenuator to enhance
stability.
Figure 10: Operating Position
A connection is then made to a LNA (0.6 dB NF, 20 dB gain)
through a 9 dB attenuator pad. The LNA is the “kitmanlaw2008”
product tested by Whitman Reeve and Christian Monstein in the
July-August 2013 SARA Journal.
Figure 8: Soundcard Interface and Rubidium Vapour Frequency
Source
From the input of that LNA there is a 25 m run of RG-58 to the
roof where a plastic lunch box contains a LNA→BPF→LNA
configuration which finally connects to the antenna.
The modifications done were the removal of the low value chip
input coupling capacitor – replacing it with a 4.7uF value to lower
the LF corner frequency to 5 Hz – and the replacement of the
onboard 12 MHz quartz crystal with an interface allowing
connection to the external Rubidium Vapour Frequency Source as
shown in Figure 8. This gives an accuracy and stability of the
sampling clock of the order of 1 part in 1011.
NOTE: The configuration for Result #1 below had the
LNA→BPF→LNA chain located inside the house at the operating
position.
Currently there is 12V SLA battery powering the LNAs in that
same plastic lunch box.
The soundcard is digitising (at 1500 sps) the output of a 45 MHz
IF amplifier whose output is full wave detected and lowpass
filtered. Included just before detection is a 5 MHz bandwidth
filter operating at the IF frequency. The amplifier/detector is
pictured in Figure 9 which shows a heatsink and fan which is
necessary because the ERA-5 amplifiers dissipate a fair amount of
heat.
Initial Activities and Early Results
A regime of software testing was carried out to verify the
algorithms by firstly using artificially generated files to stress
test the code. Another test was to use a second, separate
Rubidium Vapour Frequency Source to gate noise at 10 times a
second into the RF input and checking that the spectrum spike
occurs exactly at that frequency (10 Hz). Note that no
calibration is needed as the sampling clock frequency is known to
The input to the 45 MHz IF amplifier comes from a tap into a
Yaesu FRG-9600 connected to the first IF output of the tuner.
3
within about 1 part in 1011. No discernible sidebands were
detectable indicating that the USB soundcard interface was not
dropping samples.
Repeating the process over 15 days and incoherently summing the
spectrum data (15 x 4 hours = 60 hours of data) showed a peak
again at the predicted frequency as shown in Figure 13.
To determine what antenna might be needed in terms of
directivity and sidelobe pattern a rough RFI survey was done. It
was during this survey that some unexpected results were
obtained.
Result #1
The RFI survey was conducted over a number of days using an
existing 6M dipole mounted about 3.5 m above ground level as
shown in Figure 11. Antenna simulation software gives this antenna
a directivity of about 4 dBi @ 400 MHz.
Figure 12: Result #1: Summing the 9 Best Days out of 28 Days
Not only that, but the peak was at a frequency about 27 ppm
lower in frequency as calculations show the Vela pulse frequency
should have moved over the intervening 29 days between the two
data runs.
Figure 11: 6M Dipole RFI Survey Antenna
On examining the results it was found that on some days (9 days
out of 28) a significant peak was evident right at the predicted
Vela frequency. This was unexpected. Upon summing the
spectrum data from those 9 days incoherently ( 9 x 4 hours = 36
hours of data) this peak was enhanced and is shown in Figure 12.
As stated, when presented in a previous post, this is an interesting
observation, but in no way constitutes a positive result for at least
two reasons. Firstly, the result was arrived by looking at results
and then going back and cherry-picking the input data to make the
results look better. Secondly, the result is not conclusively
statistically significant enough.
Figure 13: Result #2: Summing of all 15 days of Data (No Cherrypicking)
It was postulated at the time that perhaps, because the 6M dipole
is linearly polarised, the bad days could be the result of cross
polarisation of the antenna with incoming linearly polarised signal –
while the good days were more aligned. Note that the Vela pulsar
signal polarisation swings almost 90 degrees in position angle
during the ON phase of the pulse.
Considering the data was plagued by high levels of RFI, especially
from day 12 onwards (and day 7 was severely chopped around by
an electrical storm), this is an unexpected result.
Note that there is no cherry-picking of data in the second run as
all 15 consecutive days data were included in the summation.
While it took 60 hours of data summation to get the result in
Figure 13, the expected advantage of the second antenna
configuration was likely to have been largely neutralised by the
high levels of RFI during the second data run which was not
evident during the first data run.
Result #2
Being not convinced, but certainly encouraged, I decided to
change the antenna and re-locate the LNA->BPF->LNA chain to a
position in close proximity to that antenna.
The antenna used for this second data run was an existing
quadrifilar antenna used for amateur satellite reception (436
MHz). This antenna has some directionality (perhaps 8 dBi). It is
a circularly polarised antenna and so there should be no good days
and bad days. All days should middling. What the quadrifilar
antenna directivity and axial ratio is @ 400 MHz is unknown.
Comments
So, once again we are left with a result where there appears to be
a signal which behaves like a Vela Pulsar signal (tracks exactly as
4
the expected daily drift in topocentric frequency) which holds
over a time span of some 43 days.
Conclusions
I can think of no mechanism which could cause such an artefact or
any signal that could mimic a Vela Pulsar signal so well.
A suite of software and accompanying hardware has been
developed for the express purpose of detecting a signal from the
Vela Pulsar. This configuration is built according to principles of
my “FFT Sweetspot” method.
None of the clocks in the hardware is synchronised to the Vela
Pulsar pulse period. Nowhere in the software is the processing
synchronised with the pulse period.
Early results are encouraging but remain unverified.
Extensive testing with data which are known NOT to contain Vela
signals (i.e., data collected when Vela is below the horizon) shows
no such peak.
The construction and successful commissioning of an antenna
specifically designed for the purpose of detecting a signal from
the Vela Pulsar should show an improvement on the results
obtained so far.
Nevertheless – it seems an extraordinary result and so needs
further observations to establish whether it is a real result or
not.
If an improvement is observed within reasonable bounds as
predicted the results presented here could be considered as real.
Nevertheless they cannot be viewed as verified as their statistics
are not significant enough.
I am in the process of building an antenna which is specifically
designed for reception of the Vela Pulsar signal (as opposed to the
current two which were just 'lying around').
If an improvement is not observed within reasonable bounds then
these results can be discarded, but remain as a good lesson in the
need for good statistics to establish validity.
This antenna should show a marked improvement if these results
are valid.
5