An act of frequency folly

Working through some software problems today ended in some rather funny solutions this morning (why do programming breakthroughs always seem to happen when everyone else is asleep??).

It just so happens that both the Rubik's Cube Solver and the Solar Flare Detector are going to require me to become a pro at manipulating PC soundcards, both for sending and receiving signals.

Sending signals is fine:

1. Find a nice stable interface library, 
2. Bash together some sample values,
3. Send them off to generic 'write' function,
4. Play sweet sweet music,
5. Become single most hated person in the lab for constantly playing annoyingly pitched sine tones...

Receiving signals is proving slightly trickier, or rather analysing the received signals in the frequency domain is proving rather mind bending. To illustrate, some nice graphs:

An arbitrary signal received through my PC's microphone (in the time domain). Ignore both axis for the moment.

The reported amplitude spectrum of the above signal. The fact that is is clearly just a copy of the original signal put through an 'magnitude' function rang many alarm bells. Another bell ringer was the fact that is not symmetrical around the Nyquist frequency (~22 kHz), a necessary outcome of an FFT. We can read the bottom axis as frequency directly.

An example of what I was expecting to see, a nicely prepared amplitude spectra of two superimposed sinusoids with a large DC offset. We can use the bottom axis as frequency again. Note that it ends at about 22 kHz, the magics of digital sampling mean that anything above this frequency is simply a reflection of the spectra below that point - it is easier to not show it.

What appeared to be happening was that the Fast Fourier Transform (FFT) function I was using seemed to like synthesised, simple, waveforms - but not horrible real life ones.

At this point it is probably a good idea to give some indication of the software I am using, as it turned out my interpretation of it was the cause of most of my errors. In general when programming on a PC or large computer I like to use Python 3, and for this particular task I deployed the potent Numpy/Matlibplot library combo. Initially I was using PyAudio to interact with sound related hardware, but I quickly realised that the sounds it was producing were awfully messy and did not correspond to the carefully crafted sine waves I was trying to generate. After digging around and seeing some other people complaining on various forums I switched to the SoundDevice library which promised to be more stable. It was, and I quickly progressed from producing signals to trying to receive them.

That was when I started producing graphs like those above. I dug around, maybe my received data needed to be in another format ... maybe I needed to change the sampling frequencies ... e.c.t. (That last 'solution' turned out to be an incredibly bad idea, I can only guess that the software  and hardware supporting the soundcard and Python interface is optimised for specific sampling rates, because who would want to change that? :) )

Several hours of digital sampling theory, frequent code double checking and desperate internet searches ended when I realised that I had misunderstood some documentation and got my rows and columns mixed up when feeding data to the FFT function.

As quickly as I realised my problem all anger at my poor computer subsided, I had been asking it to compute the frequency content of thousands of individual samples (which gives the amplitude of said samples at DC/0 Hz) and then plot the results. Instead of plotting a bunch of data points at x = 0, Python had plotted each individual result like a column graph which (unsurprisingly) produced a copy of the original signal with all negative results flipped to be positive. The reason the synthesised waveform had not had this problem was because it was stored differently and so did not have its rows and columns confused.

Once I started using the data correctly my issues quickly resolved and I began producing graphs like the one below, cheering and waking up all my flatmates...

A nicer frequency amplitude spectrum of the signal incorrectly processed above. It has had its spectra cut off around 22 kHz in the same manner as the spectra of the synthesised signal. I am fairly sure that everyone in my terrace of houses knows I was able to produce this graph. 

Sorry that this has been a bit of a dry post, I have to take the opportunity to write when something happens that is both applicable, and has shiny images!

Anyway, until next time....

New academic year == new projects

Another year of Uni has now begun, with the promise of a number of awesome projects to work on. This is not to say that the current work is going to be dropped, the Blake project in particular is continuing with the deadline of being complete by June next year.

However, the excitement always lies with the shiny new projects with all of the potential and none of the pragmatism (yet):

Being on the committee for the university's space society has meant that I was hoping to be able to push some electronics into the normal roster of rocket and rover projects. This push has resulted in the Solar Flare Detector being adopted as a project for this year. Consisting of a VLF radio receiver the end product will be able to track the sudden ionospheric disturbances that usually accompany flares hitting the Earth. Before you go and talk about us heading towards a solar minimum at the moment, which we are, there are still flares to be detected - just slightly smaller and less frequent flares. This project is currently starting up and already providing interest in the society from a broader range of subject disciplines, beyond the usual Aerospace Engineers.

The society is also re-entering the UKSEDS lunar rover competition after our successes last year (we came second), hoping to build on our design which ended up being decidedly improvised towards the end. It is likely the electronics are going to get a major overhaul but this should not be too hard given we now have experience.

Finally (for the moment) being the third year of the degree part of the assessment this year involves a group project. The aim of this project will be to produce a machine capable of solving a Rubik's cube. There are several restrictions that are going to add cool (and not obvious) electronics - I am sure that these will turn up in a future post.

Ongoing projects include the brilliant Blake Project, now cruising to completion - some sneakery is going to allow the accelerometer problem to be sidestepped, again I am sure that this will be written about somewhere else. The track itself is also slowly being completed - the workshop restocked perspex for the new term, and I immediately helped myself and spent a happy couple of hours producing all the parts needed.

At an even slower pace is the telescope, dredged from the depths of the blog. While I have really enjoyed using it so far there have been certain areas that either need improving or have already been improved. The mount (both tripod and pivot) have both been replaced with far more capable, but sadly not quite as DIY-y, elements. My range of eyepieces has also increased beyond a single dodgy 7.5mm plossl. Using the new setup I can clearly see all four stars in Mizar/Alcor, some awesome detail on the moon, the rings of Saturn e.c.t. However there is still more to do, I would like to 3D print an eyepiece holder and at some point I am going to need to replace the current optical tube frame.

All good things to look forward to, an hopefully write about!

A Summary:

Ongoing Projects:

1. Blake Project (at a slower speed during the academic year)
2. Telescope (gradually improving portability and stability)

New Projects:

1. Solar Flare Detector (cooler acronym incoming)
2. Rubik's Cube Solver (for degree)
3. Lunar Rover Mk. 2.