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.

Latest new & things

New TLE of Aenaes (and friends) from DK3WN makes collection a lot easier. These are a couple of packets I just received:

APRS: KE6YFA-1>CQ,TELEM:4341455255531D0040020008090B020D072837050000001000F075000070130049C08F13411D4F
APRS: KE6YFA-1>CQ,TELEM:4341455255531D0040020008090B020D080037050000001000F075000070130049C08F1341D581

Which means that the port to GnuRadio 3.7 now seems to work - it took a lot of effort due to the relocation of a whole bunch of classes from one module to another (and also some bugs the GnuRadio maintainers introduced on the way). So after a week of effort I'm back to where I was with version 3.6, and don't really have anything more to show for it! Ho hum.

I did order some better crystals for my RTLSDR receivers - although as they're at 14.4MHz I need to do some more work in order to get them usable - but it should cure the really crap frequency drift I see with the recent received I purchased.

I've just ordered a Rigol DS1052E oscilloscope - I'm not expecting much, but it should take some of the guess work out of some of the things I do! Now I just have to win the lottery and I can get that VNA I need!

I now have some test data (from HO-68) which I can use to evaluate the new CW mode in MultimonNG.