Saturday, 30 November 2013

X-ray Telescope on a HAB

Readers of this blog are probably aware that I'm interested in launching an X-ray (or gamma-ray) telescope (XRT) on a high altitude balloon (HAB) in order to detect astronomical sources.The brightest source at gamma-ray (and certainly is one of the brightest at X-ray - perhaps about 50% as bright as GX5-1 in soft (2-30keV)  X-rays) is the Crab nebula/pulsar. Below is the combined 'best fit' spectra to a number of XRT missions:

This plot shows the Crab's characteristic 'power-law' spectrum and shows the typical photon flux observed for the 4 XRT missions which were used. From the graph it is clear that the place to be to get the most photons is in the soft x-ray region. (Note: I've only calculated the spectrum down to around 2keV to avoid absorption by interstellar Hydrogen which will start to significantly absorb lower energy photons). The graph is plotted on a log-log plot but perhaps I should have taken this advice - but I'd need a much bigger screen!
 
The flux calculated in the above plot is for the top of atmosphere, and a balloon will typically only get to around 30-40km in altitude - so how much will that change the flux levels? If I combine the above spectrum with the X-ray absorption data I've mentioned previously, I get the following plot:
I've highlighted the altitudes to which you could hope to get a balloon. As you can see there is a very strong absorption of soft x-rays in the atmosphere. So what does this all mean? If we could get a balloon up to, say, 30km, with a 4cm^2 detector and could detect between 2keV and 1Mev photons with a 100%  efficient detector, we would get a count rate of  0.06 counts/s. This is pretty low - we'd either have to stare for a very long time (which would be challenging for a number of reasons) or we need a much bigger detector (again, challenging). There is also the fact that we would be effectively looking through an optically think medium to observe the astronomical object which makes me uncomfortable. Another issue to consider is what noise level (background counts) should be expected.
 
So in summary some further work to determine background count levels, detector efficiency, detector weight, etc in order to roughly model the mass and performance of the XRT. For example, shielding can be used to reduce the background noise level, but what is the optimum amount or material. However, realistically it isn't looking too hopeful due to the low flux rate from the source and the (relatively!) low altitude of a balloon.

Sunday, 13 October 2013

ISS/GRAVES, X-ray telescopes & things......

One quick observation I've noticed over the last week or so of measuring the returns from GRAVES via the ISS is that to get a strong signal I need ISS to be at 20 degree elevation angle. The pass yestersay at around 19:20 (local) I only got the following short detection:

In order to investigate why ISS was only detectable in a small amount of the pass I made the following graph:
The areas in blue are outside of the nominal azimuth & elevation pattern of the transmitter at GRAVES. Hence it is quite obvious why only a small part of the pass I managed to detect ISS. There was an earlier pass which had an elevation of 5 degrees to me here, which I didn't detect at all. If I make a plot for that pass then I get the following:

From the graph it is clear that ISS would have only been illuminated briefly and when combined with the extreme range (and local trees/houses/etc) would make it difficult to detect it.

The things I intend to investigate further are:
  1. If H-polarisation improves the signal-to-noise (ideally I'd do this using 2 identical sets of antennas and receivers but that would have to wait a while).
  2. Create a program which analyses the data collected and detects all the meteors/planes/etc and saves the 'interesting' data to be further analysed.
  3. Use the program I've developed to make the graphs above, be able to search for suitable times for me to attempt to detect the moon.
As an aside I've ordered the parts to make the frequency doubler which is necessary to improve the frequency stability of the RTLSDR dongles and hopefully allow me build a 2 (or maybe more) channel coherent receiver.

One of the other projects I'm currently looking at is building an X-ray telescope to be launched on a high altitude balloon. To be honest calling it an X-ray telescope is a bit grandiose, it'll be a 1 pixel detector! Anyway the first stage of the design process is to see what the atmospheric attenuation of X-rays is like. The graph below shows the altitude at which 0.5, 0.1 and 0.01 of the incident radiation is left.
The X-ray absorption data (for O2, N2, Ar) is from "AD-A278 139, NBS Circular 583" and the atmospheric model is from the C implementation of NRLMSISE-00 which returns the number density for O2, N2 & Ar. In order to check that I've not made any blunders, I compared with the only other X-ray atmospheric graph I could find here in fig 2.4, page 46. Although the line for 0.5 agrees well, the other lines do not. In order to double check my answers I tried using the classic 1976 atmospheric model (which just returns the density of air) and the X-ray absorption data for air. Using these new set of data I get a very similar graph to that above (and get very good agreement at sea level which I also check with NIST). I'm unsure how to proceed at the moment with this, but will start to look at some of the other issues, such as energy resolution, collimation, weight, power, etc.


Saturday, 12 October 2013

Doppler corrections to the ISS/GRAVES data

In order to see if there is any additional ISAR signatures in the ISS reflections, I thought it would be a good idea to Doppler correct the data. This was easily done using the Doppler correction GnuRadio block I've already written for my GroundStation software I've described previously (and which is available here). I applied 2 corrections - one for the transmit path from Dijon and one for the receive path to my home. After applying these corrections I get the following waterfall plot:

It can be seen that compared to the 'raw' data (shown in here) there is a very significant reduction in the frequency shift of the signal. There is still some residual frequency fluctuations which I suspect are due to
  1. The poor stability of the receiver - its quite temperature sensitve
  2. Orbital modelling inaccuracies - I'm using a TLE from today and predicting where it was a week ago
  3. Timing - I don't have a time index into the raw data I record
  4. Atmospheric propagation
I don't think item 4 will have much of an effect. I roughly optimised the timing to minimise any drift - I should improve the capture flowgraph to improve its metadata capture (although I'm unsure how to determine latencies or if I even need to).

I think the bottom line is that I can do a reasonable job of performing the Doppler corrections, but there are no other signatures to observe. I should now do the calculations to see if its even possible to observe them!

For interest, below is a picture of my antenna set up - as you can see its hardly sophisticated!


Sunday, 6 October 2013

Reception of ISS from GRAVES radar

GRAVES is a CW radar transmitter located in Dijon, France. Most of its energy is transmitted in a southerly direction and at an angle of around 20 degrees above the horizon. To listen to the echos from Graves I point my 4 element yagi in roughly a south east direction, I rotate it to use V-polarisation (the general consensus is that V-pol is better than H-pol - at least for meteors) and then feed that into my rtlsdr receiver (with a pre-amp to get over the cable run). The antenna is balanced on my wheelie-bin to give it around 1.5m above the ground - hardly an optimum antenna position. The receiver is tuned to 143.05MHz and a waterfall plot is created showing Doppler against time. Most of the time only noise is recorded, however about every 30 seconds or so a 'ping' will be heard from a meteor. Last night I listened when ISS was over Spain/France which meant that it should be illuminated by GRAVES and recorded the signal, shown below:

I've added some scruffy annotations below:

The Doppler signature from ISS is clearly visible along with a number of meteors and possibly a plane. (I'm not totally convinced that its a plane - the rate of change of Doppler is a lot to be explained by just a change in geometry). Anyway, some interesting results and a number of avenues for improvement:

  1. Change RTLSDR to use a TCXO to have some confidence in the absolute Doppler values measured.
  2. Use of multiple RTLSDR to measure returns from both polarisations to determine optimum - for all scatterers observed.
  3. Improve antenna location - move antenna to my roof when best polarisation determined.
Another object that I'm interested in receiving via the GRAVES transmitter is the moon - but I don't know how difficult that will be from my location and with my current antenna position.



Sunday, 29 September 2013

CW Decode from HO-68 using MultimonNG - Update II

(This is an update to this post)

I tweaked the string that my stupid search script uses to be "BJ1SA " - this should then take into account the proper spacing of the characters. The best result I got out from that was this (I used the data to which I'd applied a narrow band filter):

 J1RA XW XW AAA TTT AW- ATE ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW EE
BJ1SA XW XW AAA TTT AU4 TBE ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW
BJ1SA XW XW AAA TTT AU4 TNT ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW
BJ1SA XW XW AAA TTT AU4 AVT ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW
BJ1SA XW XW AAU T5H H 5 <._.......>DHSH IIIEIS

BJ1SA XW XW AAA TTT AU4 AVE ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW
BJ1SA XW XW AAA TTT AU4 TBE ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW E
BJ1SA XW XW AAA TTT AU4 AVT ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW EIE
BJ1SA XW XW AAA TTT AW4 TDT ENTTTT TTTETTNTTTTTNAAAVATUA<....._>


This appears to be better than the previous decoding. The graphical representation of the search space is show here:

As you can see there is a much smaller range of parameters where the best decoding occurs.

I have now integrated in the multimonNG decoding of CW signals into my GroundStation software and have decoded signals in realtime from a number of satellites including FO-29 and CO-55. The current implementation I use is far from optimum as I have around 2.5kHz of audio going into multimonNG, so as mentioned previously I'll be able improve the performance by additional filtering.

I've also improved the calibration of one of my RTLSDR receivers such that I can receive meteor signals from the GRAVES transmitter - more data to follow on that subject at a later date.


Saturday, 21 September 2013

CW Decode from HO-68 using MultimonNG - Updated

(This is a follow-up to my previous here.)

The author of MultimonNG suggested that in addition to altering -d and -g, I should also use a bandpass filter before passing it to MultimonNG as the code does no filtering of itself. I applied a bandpass filter of around 400Hz wide. This filter is wider than I would have liked to have used, but the signal drifts due to, probably, instabilities of my RTLSDR receiver and errors on the Doppler corrections - there are ways to automatically correct this, but I've not had time to implement them yet.

If I now decode the data after applying the filter I get the following ASCII:

            W X W A A A T T T A U   A T E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W E E
B J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T N T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A U T 5 H H 5

B J 1 S A X W X W A A A T T T A U 4 A V E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W E
B J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W EIE
B J 1 S A X W X W A A A T T T A U 4 T D T E D T N N T T T N E


Which is significantly better than without the filter (see previous post) and better than dl-fldigi.

Next I investigated altering the -d and -g parameters. To do this I wrote a Python script to run multimonNG that counted the number of occurrences of the string "T T T T T" were in the output. I looped over values for -d from 0 to 202, and -g from 0 to 198. The out put can be see in the graphic below (sadly I forgot to label the axes before I created it) - the y-axis is -d and the x-axis is -g:
From this is can be seen that for this data the value of -d is not too important, but the value of -g is more critical. However looking at the output for the best combination of -d and -g shows no significant difference from the results above. It is also questionable if the number of "T T T T T" in the output is really a good metric to measure decoding quality - but for the moment it will suffice!

In conclusion - make sure you appropriately filter your input to MultimonNG and you should get good results. Over the coming weeks I'll be trying with data collected from other sources which won't be so nice and clean.

Wednesday, 18 September 2013

CW Decode from HO-68 using MultimonNG

Using the pass from 09:45 UTC this morning, I recorded some CW from the beacon which peaked around 35-40dB over the noise. If I decode it in dl-fldigi (via an 8kHz, 8 bit WAV file) I get this output (for reference it should look like this):

* J 1 S A X W X W A A A T T T A U 4 A T E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
* J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
* J 1 S A X W X W A A A T T T A U 4 T N T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W 

* J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
* J 1 S A X W XWUA AT**R*W X W
* J 1 S A X W X W A A A T T T A U 4 A V E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W 

* J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W 
* J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W 
* J 1 S A X W X W A A A T T T A U 4 T D T E T T T G T T T T M T M X T M M A D**

If I use the new version of MulitmonNG I get this (using the standard default arguments - i.e. not changing -g or -d):


              X W A A A T T T A U 4 A T E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T N T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W

                W A A A T T T A U 4 A V E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U <..._..>A V T E T T T T T T T T T T T T T T T T T T T T T T F


So multimon certainly doesn't do a bad job, but it has some room for improvement. I'll try tweaking the values of -g, -d, etc and see how that changes  things.