Observations of the Geminid Meteor Shower Using GRAVES

The Geminid meteor shower peaked on Friday night. Unfortunately I'm not yet in a position to be able to monitor GRAVES 24/7. So I was only able to start recording data from around 07:13 GMT the next morning (it was a Saturday and really hard to drag myself out of bed!). I used my usual setup of a 4 element yagi (vertical pol) orientated about SW in direction and 10 degrees above horizontal (on my wheelie bin!) with a preamp feeding my RTLSDR receiver. For the first couple of hours there was near constant meteor activity, but by lunchtime it had trailed off into normal levels. This can be seen from the following images:

Below are some (a very small fraction) of the events in much greater detail (in the following images the y-axis (time) is relative to the start of the block I reprocessed, not to the start of observation):

Its interesting to see that a number of the events have very complex Doppler profiles. I'll be starting to think about how to investigate this behaviour further over Xmas (multiple coherent antennas?....). I also think there must be a better way to present the data. The other thing I'm working on is an automatic detection & classification system - but that may take a little time.

I've not yet finished making the oscillator improvement to my RTLSDR dongles, so they still drift like crazy with temperature changes. I know there are other ways to improve the thermometer like behaviour - like stuffing them in a drainpipe filled with foam - but as this isn't (yet) a permanent set up its not practical solution. Using a new (external) oscillator with the dongles also may allow them to be phase locked to each other allowing phased arrays to be used.

Really looking forward to the next big meteor shower - especially if I've got my 24/7 monitoring working!

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.

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.

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!

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.

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.

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.

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.

Balloons & things

It has been a bank holiday this weekend - and weirdly hasn't been too wet. Well, actually it poured with rain on Saturday. Anyway,  there were a number of high-altitude balloon launches on Saturday and again today. More information can be found here but I don't know where that page gets archived. Another good link is here. I could pick up all 4 balloons from today when they got reasonably high - and when I switch my yagi to be in V pol - d'oh! (Using one of my RTL_SDR receivers). I'm having difficulty in getting dl-fldigi to decode the output via pulse audio (it works if I save the stream to an 8k samps/s WAV file and then replay that in dl-fldigi) - I'm sure there are better ways to connect 2 programs. I shall explore further and see what I can do. its not helped by my recent transition to GnuRadio 3.7 which seems to have broken a lot.

In other areas I've got my stepper motor working with my beaglebone black - now just have to get the rest of the engineering sorted.

ISS Pass

A photo of the ISS pass last night. Just put my camera on a wheelie bin pointing up with a 10 second exposure and crossed my fingers! Of the 3 photos I took, one has ISS going through it.

The photo won't win any prizes, but its good to see what can be done with very simple equipment. If only it had been clear during the Perseids a few days back.

I got a couple of new RTL-SDR USB sticks last week and am currently roughly calibrating them (estimating the frequency offset error and will look at the noise figure to compare with my other USB sticks - although the latter is tricky due to the lack of equipment I have.)

Software Announcement!

The GroundStation software I've been working on for the last few months is now available from github here - below are a couple of screen shots of the realtime view of where the sats are and the pane on the right shows what frequency they are at (x-axis is frequency in MHz, y-axis is time in hours from now).

The second image show that I've select a part of the RF spectrum to capture (width determined by the fact its just a RTLSDR receiver).

When the times comes along, up pops an appropriate 'channel' which decode the signal (with real time Doppler corrections) - all by the magic of GnuRadio (and a fair amount of swearing!!). Its still pretty rough around the edges (and its very polyhedral....) but has got a fair amount of potential - so by the 10th rewrite it'll be great!

This week I also got my beagleboneblack running Debian and now happily streaming my RTLSDR dongle back to my desktop.

This looks like a very nice bit of kit, HackRF I look forward to getting mine.

Updates and things....

Here's the latest I've got from Aeneas from the pass today at around 13:45UTC:

AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006190B0611391424050000001000F07500007013004900398341A5C5
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006190B0611392824050000001000F07500007013004900398341CEC4
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006190B06113A0024050000001000F07500007013004900398341C764
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006190B06113A1424050000001000F07500007013004900398341119C
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006190B06113A2824050000001000F075000070130049003983417A9D

And here's some from the pass yesterday (3rd Aug) at around 13:30UTC:

AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006180B0511271424050000001000F075000070130049C0004D41AD4C
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006180B0511272824050000001000F075000070130049C0004D41C64D
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006180B0511280024050000001000F075000070130049C0004D410E83
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006180B0511281424050000001000F075000070130049C0004D41D87B

also STRaND-1 has been a strong signal (25-30dB above noise), but I've not yet sorted out the decode of it yet.

I've continued to work on my groundstation software and now have a working Doppler correction gnuradio block. I've made a bunch of improvements to the GUI and should have something pushed to github in the next month or two. One of the features I've added is a frequency against time plot which allows you to have multiple channels receiving different sats with different modes & Doppler corrections applied.

I'm still working on getting my beaglebone black working with my rtl-sdr receiver to make a PoE powered remote device - the main issue I'm having is updating the OS to be debian so I can easily put all of the dependencies - I know have a way forward with this - but not the time to do it!

Aeneas

From the pass that just occurred (20:25 GMT):

AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006040B0617132808050000001000F07500007013004930C617423C83
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006040B0617140008050000001000F07500007013004930C6174285FE
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006040B0617141408050000001000F07500007013004930C617425306
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006040B0617142808050000001000F07500007013004930C617423807
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006040B0617150008050000001000F07500007013004930C61742E9C9
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006040B0617161408050000001000F07500007013004930C617428B68
AFSK1200: fm KE6YFA-1 to CQ-0 via TELEM-0 UI  pid=F0
4341455255531D0040020006040B0617162808050000001000F07500007013004930C61742E069

Testing with NOAA-19

I've got my software to the point where I can just click on a button and it will record (and perhaps decode) that pass. I have come to the conclusion that my Doppler corrector isn't good enough, so I'll have to re-engineer that. I don't support all the modes & modulations & baud rates that I need yet, but am working on it. Some, for example, APT I'm still having to do by hand. When the weather cools down, I'll start to design a much better Gnuradio backend which will allow me to construct & control flow graphs better than the GRC ones I'm currently employing. Anyway, to end on here's a pretty picture that I just decoded from NOAA-19 on my RTL-SDR dongle:

Todays progress

I've actually made a fair bit of progress on the software side of things. I can now kick off the GnuRadio bits'n'bobs as required from the GUI and then control them with XMLRPC. This allows me to do the Doppler corrections in real time - as you can see from the attached picture of the pass of ISS a few minutes ago. I'm having some issues with processes & zombies, bit hopefully I'll get to the problem that is causing me some robustness issues over the coming week.

Has anyone seen any recent TLEs for AENEAS?

Todays sats

I attempted listened to the following:

• HO-68 (09:50 GMT)
• CO-65 (10:05 GMT)
• FO-29 (10:30 GMT)
• CubeBug-1 (10:54 GMT) - Not heard
• ESTcube1 (11:27 GMT) - Not heard
• SO-50 (12:44 GMT)
• ITUpSAT (13:04 GMT)
• AENEAS (14:35 GMT)

The equipment was the same as last week. Times are approx AOS.

Started to restructure my software to start to allow me to do real time doppler corrections and then decode it - however its going to take a few more weeks of coding 'till I get something useful.

I ordered a comb generator from AMSAT-UK, which turned up yesterday. Hopefully this will allow me to quantify the drift I think I'm seeing in my RTLSDR (E4000) USB dongle. I started to assemble it but the SMD components have slowed me down.

Satellites heard today

I heard the following sats:

• SO-50 (08:03 GMT)
• HO-68 (09:30 GMT)
• CO-65 (09:53 GMT)
• FO-29 (10:33 GMT)
• ESTCube1 (11:26 GMT)
• ITUpSAT-1 (13:08 GMT)

Over the next few days I'll be improving my software to start to decode the beacon signals. I can already do most of the modes, its more a case of just making it less of a pain to work! It is based on GNUradio.

Messing around this morning picking up a few satellites with my cheap'n'cheerful RTLSDR receiver. The antenna is a 9 element yagi pointed directly up with a couple of mini-circuit amplifiers to get over the cable loss. Attached is a plot of the pass of FO-29 (orbit 82835). Time is vertical (about 3 minutes), and frequency is horizontal (about 192kHz bandwidth centred at around 435.9MHz). This image represents only a fraction of the actual data recorded which is around 12 minutes long and 1.5MHz in bandwidth. The data shown consists of the CW beacon on the left and downlink on the right including a number of SSB and CW signals.

Oddly no signals were heard in later passes from ESTCube-1 which I've heard on a number of previous occasions.

Introduction

So what I intend to do with this blog is document some of the RF projects & measurements I do. Expect graphs of power vs frequency for a whole bunch of amateur satellites and hopefully astronomical objects over the coming years. Just don't hold your breath for the next blog posting!!