Micronut V2

Posted on May 10, 2012 by VK5QI

After a few unfortunate float incidents, Project Horus desperately was running low on telemetry payloads. While a completely new design, using a RFM22B radio is in the works, we needed some telemetry boards fast. I didn't want to just make more Micronut boards, so I made some updates to the design (with advice from Matt VK5ZM), and so Micronut V2 was born!

Micronut V2, with old Micronut for comparison.

Micronut V2 has the following changes from V1:

  • SPI Flash removed. Never got used due to the reliability of the ground RX system.
  • Bigger pin headers for temp sensors, for ease of soldering.
  • Option for a battery voltage measurement tap, via either a voltage divider or a 100K resistor to an external battery pack.
  • TPS76633 LDO instead of a LD1117 - smaller dropout voltage.
  • uBlox MAX-6Q GPS instead of a NEO-6Q - smaller, and less current draw.

Hopefully one of these will be flight tested shortly, and will then become Project Horus' standard telemetry payloads - until we come up with something better!

Posted in Uncategorized | Leave a comment

RF Head has a new Home !

Posted on April 28, 2012 by PsionicOz

RF Head has found a new home on the internet.   With Debian discontinuing support for "lenny" earlier this year the blog needed either a live upgrade or to find a new home.   We didn't like the look of the live upgrade option, here be Dragons!.

Thankfully the internet is chock full of people wanting to sell VPS services at quite reasonable rates.  So armed with a new VPS service and linux distro we took the plunge and moved the blog.

We certainly hope that the DNS war that ensues when you move a server settles down quickly.  If anyone spots any odd behaviour then we're all ears.

Now we can concentrate on getting back to writing up some more interesting DF articles.  We've certainly been busy between server rebuilds hamming it up. Stay tuned.

Posted in Uncategorized | Leave a comment

The Prey Project, and how it got my laptop back.

Posted on February 20, 2012 by VK5QI

On the 8th of February 2012, my Macbook Pro 15" (8,2) was stolen from my office at the University of Adelaide. It was mostly my own fault; I'd left the office to go photocopy something, and got caught up in a meeting. Thinking I'd only be away for 30 seconds I didn't lock the door.

1 hour later, I arrive back at my office to find the door ajar. I walk to my desk to find my laptop is missing. Oh shit. Quickly look around the room, nope, not there. Freak out for a few minutes. All my university work was on the laptop! While the majority of it was backed up to SVN I did have some MATLAB code which hadn't been committed yet.

So, I immediately ring University Security, who dispatch a security guard (great guy) who asks me all the relevant questions, what time was it stolen, etc. I then rang the police and filed a police report. IT support worked out that the laptop (which was open when I left it) dropped off the wireless network at 12:39pm, about 20min after I left the room. This information, along with the Macbook's serial number all went to the police.

About an hour after this, I realised 2 things:

  1. I had Time Machine backups, last run that morning - I still had all my data.
  2. Prey was running on the machine.

Prey is a very nice bit of software. You install it, and it thereafter sits in the background, hidden away, checking the Prey website for commands. Once your device is marked as missing on the Prey site, it springs into action, recording location information, taking photos using the inbuilt webcam, and collecting all sorts of useful information.

I had my laptop passworded, but without disk encryption, so there was every possibility the thief could get access to my data. Still, without anyone being able to log in, how would my Mac connect to the net and let Prey do it's thing? The only possibility I could see would be if someone plugged in via Ethernet and left the Mac open on the lock screen for a while... a pretty unlikely scenario.

So I gave up. I went and ordered a new Macbook Pro which arrived a week later. I got back to work. Then one night....

Hooooooooly Shit. A Prey report. With a WiFi location accurate to one house. And a picture of some guy using the laptop.

Just to clear things up right now, I'm not going to post pictures of the guy, or his house address or any other information identifying him. I still don't know if he's the guy that stole it or he bought it off someone, so until I know for sure I'm keeping the information out of this post.

Anyway, I had a wifi location. Pretty damn cool. I also had a screenshot!

That's interesting... It looks just like a fresh OSX install... Hold on, what's that little printer icon in the top-right corner? It's Novell iPrint! I installed that to be able to print to printers at uni! Prey also reported the user account name as 'MACPRO', which leads me to believe the thief used single-user mode to create a new account. Well that's a gaping security hole... (Solved with full-disk encryption, but I didn't have that enabled)

20 minutes later I get another report. Hmm. The location in this reports shows the Macbook about 30km north, but still connected to the same WiFi Access Point. Hmmmmmmmmmmm. IP Geolocation instead of WiFi geolocation? Maybe...

I put the the call out in an IRC channel I frequent for anyone who lived near the initial reported location. A friend offers to drive to the house and check the AP is there. It is. Bingo. Confirmed location!

Now I have a confirmed location I give the police a ring. Turns out I have to do something called a 'Standby breach of the peace' where I go knock on the door and ask about the laptop, with police officers nearby in case something goes wrong. Sounds a bit weird, but sure...

The next afternoon I give the police a call and a friend gives me a lift up to meet them at the location. I explain the situation to the police, who are a bit surprised at how I got the information about the Mac's location. They decide to ask the householder without me present (fine with me!), and go knock on the door. No answer. Hmmm. Well, WiFi geolocation isn't always *that* accurate, maybe it's the next house up? My friend and I watch them walk up the driveway. About 15 minutes later we see one of the policemen walk outside and make a call on the radio, then head back to the house.

10 minutes later, both policemen walk out, one carrying my Macbook Pro.

 

I still don't know how the laptop came into the hands of whoever had it. I'll have to wait for the police report for that. Once I got home I fired up the Macbook to see what the thief had done. My account was still there! It appears they had just created a new account, leaving all the old settings in place. In the browser history I found logs of the person visiting facebook pages. I've sent all this information to SAPOL, and await further information.

So I now have my laptop back, and it's all thanks to http://preyproject.com/ - I strongly recommend you install it on your portable devices as soon as possible! I'd also suggest enabling a guest account, to make it as easy as possible for a thief to connect to the web and give away his/her location.

 

Posted in Uncategorized | 5 Comments

Creating good UI-View32 maps with OpenStreetMap

Posted on February 9, 2012 by VK5QI

UI-View32 is a Windows APRS client commonly used my amateur radio operators. It allows the visualisation of APRS data on a map. Sadly, the stock maps UI-View32 comes with aren't very good.

When I first fired up the software, I found it was rather lacking in decent maps. I wanted some decent maps for Adelaide, where I live, so I figured I may as well take a crack at making some. I decided to use map data from OpenStreetMap, in part because it's all free data (CC-BY-SA), but mainly because it had a very easy to use map data export feature.

So, how do you make an map usable in UI-View32? Well, you need 2 things:

  • The map, in either BMP, JPG, or GIF format.
  • A descriptor file, which tells UI-View what the map is called, and what area it covers. This is just a text file with the same filename as the map, but with a .inf extension.

So, to start, head to OpenStreetMap and find the area you're interested in. Once you're there, open up the Export tab.

OpenStreetMap's Export Tab

Now we have the option of either exporting the area we see in the display, or selecting a smaller area within the display. To select a smaller area, click the "Manually select a smaller area" link, and click and drag on the map to select an area.

OpenStreetMap with area selected.

So, now we have our area to export selected, let's take a closer look at the information shown on the left.

Export Settings

At the top we have the latitude and longitude bounds of our export area. We're going to need these values for our map descriptor file. At this point I usually open up a text editor and start to construct this file as I go.
The descriptor file is only 3 lines long, and contains the latitude and longitude for the top-left and bottom-right corners of the map image, and a descriptive name for the map, which will appear in the maps list in UI-View32.
The latitude and longitude are in UI-View32's own annoying format, which is DD.MM.mm<N/S>,DD.MM.mm<E/W>. For example, converting the decimal-degrees coordinates in the above image to this format would give:
37.34.80S,144.34.20E
38.03.96S,145.23.82E
Melbourne OSM
I've also added the third line, which is the descriptive name. This file can now be saved in UI-View32's maps folder (<Program Files>\Peak Systems\UI-View32\MAPS), with whatever name you choose, remembering that it must have the '.inf' extension. I used 'melbourne_osm.inf' for this map.
Now we have the map descriptor file ready, we can download our map data. Looking at the above image, we see that we have options for export format, a selection of image formats, and a scale option. Leave the "Format to Export" setting at it's default (Mapnik Image). Change the image format to JPEG, which is in the drop-down menu.
I like to have my maps as high resolution as possible. Next to the scale text box, we see a maximum value for the scale, in this case 1:145000. This value will change depending on how big an area you have selected, but represents the highest resolution you can export. Set the value in the text-box to this value.

Corrected export settings

Now click export, and after a short wait a save file dialog will appear. Save the file into your UI-View32 maps directory, with the same file-name you used for the descriptor, but with a '.jpg' extension. Re-load UI-View32, and you should now find your new map in the "Load map" dialog!
Posted in Uncategorized | Leave a comment

Project Horus and RFHead at LCA 2012

Posted on January 12, 2012 by VK5QI

I'll be at Linux Conf AU next week, talking about Project Horus and TOPCAT. The TOPCAT talk will be at 2:45pm Monday at the Arduino Miniconf, and the Project Horus talk in the Caro lecture theatre at 2:20pm Tuesday.

From the Project Horus blog:

We're happy to announce that Project Horus will again be making an appearance at Linux.conf.au this year. Like last year, the talk will focus on the technical aspects of our launches, with Mark, Joel & Terry speaking. We're also hoping to release a balloon as a demonstration of our tracking equipment on the day.

Linux.conf.au is being held in Ballarat this year - an hour or so out of the Melbourne CBD.

Posted in Uncategorized | Leave a comment

And now for something completely different: Algorithmic music on an AVR

Posted on October 3, 2011 by VK5QI

Recently, I was shown a few videos showing how very short C programs could be used to produce quite complex pieces of chiptune music. For example:

main(t){
for(t=0;;t++) putchar(
(t&t>>8)
);}

produces an interesting harmony of square waves, descending in frequency. This program is designed to have it's output piped into an 8-bit, 8kHz audio device, i.e /dev/audio on Linux.

This seemed pretty cool, and I wanted to have a go reproducing the work and experimenting myself. Problem is, I run Mac OSX, which doesn't have /dev/audio. Sure, I could probably get something working with pygame, but that seemed a bit too easy.

So, I decided to get it working on an AVR microcontroller. Most AVR chips have some form of 'analog' output. Some, such as the XMega series, have a proper digital-to-analog converter (DAC) which would have worked perfectly. The ATMega series often have pins capable of Pulse-Width Modulation (PWM), which can act like a DAC with correct filtering.

Now, I have a few Arduino development boards laying around which would have served the purpose, but I would have had to make a low-pass filter for the PWM output. I have a distinct lack of discrete components at the moment, so sadly this wasn't an option. However, I realised I had another option.

Recently, I've been working on a new telemetry payload for high-altitude ballooning missions, named MicroNut. These are small PCBs with a GPS module and a radio transmitter (a RadioMetrix TX1H), which is normally used to transmit frequency-shift keyed (FSK) data to a ground receive station. One feature in the design was that the radio transmitter's 'data' input was driven from a PWM-capable pin on the AVR. This allowed me to make the MicroNut boards produce Audio-FSK (AFSK) for APRS use. AFSK is where a a normal FSK signal (a tone which shifts in frequency to signify a bit change) is modulated using Frequency Modulation (FM). This is implemented in the RadioMetrix modules by having the voltage on the TX data pin control the output frequency of a crystal oscillator - a Voltage Controlled Crystal Oscillator (VCXO). So, if the voltage on the TX pin increases, so does the output frequency. If it decreases, so does the output frequency. The output from this VCXO is multiplied to increase it to the desired output frequency, and is then amplified for transmission. To receive the signal, I'm using an Icom IC-7000 multi-band transceiver (it's what was on my bench).

So far, the signal chain from start to finish looks like this:

Transmission Chain

This diagram is a bit simplified - I'm not showing the multipliers inside the RadioMetrix Module,  and of course the IC-7000 does not make use of magic.

Now I have my signal chain set up to receive the audio, I just need some code to put on the AVR. Well, with the Arduino abstraction library this becomes pretty simple.

#include <TimerOne.h>

// Pin Mappings
#define PIN_RF_ENABLE 4
#define PIN_RF_TX 3

unsigned long t = 0;

void setup(){
    pinMode(PIN_RF_ENABLE, OUTPUT);
    pinMode(PIN_RF_TX, OUTPUT);

    digitalWrite(PIN_RF_ENABLE, HIGH); // Turn the transmitter on.

    Timer1.initialize(125); //8KHz sample rate
    Timer1.attachInterrupt(gen_audio);
}
void loop(){} // We do nothing in the loop

void gen_audio(){
  analogWrite(PIN_RF_TX,
  (t>>7|t|t>>6)*10+4*(t&t>>13|t>>6) // Algorithm here
  );
  t++;
}

In the setup function (which is run on boot), you can see that I setup the output pins, turn on the transmitter, then setup a timer interrupt to run every 125uS (8kHz). This interrupt function is where all the work happens.

The `analogWrite' function is what sets the effective analog output value, generated from the PWM signal and the low-pass filter in the RadioMetrix module. The value to be written is generated using the algorithm shown, from an unsigned long integer (32-bits) which is incremented each loop. Only the lower 8-bits of this value are used to set the output voltage. Running at 8MHz, the AVR has 1000 cycles to run whatever algorithm is used, which should be enough for all but the most complex algorithms.

PWM Test setup, showing MicroNut board and Icom transceiver.

The above figure shows my test setup. I'm powering the MicroNut board from a random LiPo pack I had lying around, and I'm feeding the output from the transmitter module (on the bottom of the PCB) into a 50-ohm 'dummy load', to avoid broadcasting my transmission over a large area. In the background you can make out the Icom IC-7000 tuned to 144.390MHz, the output frequency of the transmitter.

A short video showing the code in operation appears below:

Posted in Random | 9 Comments

Gratuitous MicroNut Construction Photos

Posted on September 29, 2011 by VK5QI

I've recently been constructing some more MicroNut PCBs for testing and future flights, and I decided to take some photographs throughout the process.

Completed PCB, awaiting radio module.

Posted in Uncategorized | Leave a comment

Sound Card Modems

Posted on September 23, 2011 by PsionicOz

When is a sound card not a sound card...   when it's an on-board integrated all-in-wonder sound card !!!  Ok let me explain that a little...

I've been an avid fox hunter for the past 15 years having participated in many fox hunting competitions both locally and nationally. Then along comes this high altitude balloon stuff, namely Project Horus.  Right well I've got a truck load of DF equipment so this shouldn't be too hard right?

My main tracking computer is an Asus eeeBox, which with less than 1L volume fits nicely in the tight space I have within the confines of my dual cab Toyota Hilux.

So I take my trusty Icom R10 handheld scanner, wire it up to the microphone input of my eeeBox and load the dl-fldigi software and away we go.

However over a few hunts it was clear that there was something wrong.   Firstly at balloon apogee I couldn't decode the telemetry reliably, I could hear the signal but the signal to noise ratio (SNR) of the decoded telemetry was always poor typically less than 10dB.  Secondly I always seemed to "see" smearing of the FSK signal between the two carrier frequencies of the balloon transmitter.   So I could hear it in the receiver but not decode it and the other teams were able to do it, what was going on with my system?

Well to cut a really long story short I am also interested in Software Defined Radios (SDR's).  On all of the forums I've read they tell you that for good SDR performance  you need to replace your on-board or cheap sound cards with something better, much better.  So I wondered if this had something to do with my telemetry decoding problem?

Creative Labs have been making Sound Blaster cards for a very, very long time. These guys should know by now how to build a decent sound card.  Well for the princely sum of A$77 I purchased a new USB sound card from the local computer shop, namely the Creative Labs Sound Blaster X-Fi Surround 5.1.

This thing is tiny with USB in one end and a plethora of connectors around it for interfacing with radios, headphones, sub-woofers etc..  along with a convenient volume knob with push button.   So I simply plug it in to the first available USB port and windows XP on the eeeBox  installs the default windows USB audio driver.  It can't be that easy, but apparently it is and dl-fldigi could see and use the new sound device.  All without having to put the Creative CD-ROM anywhere near the machine, sweet !

Well what was the difference?  The difference is chalk and cheese.  Firstly I can now clearly "see" the two carriers from the RTTY telemetry used on the Project Horus balloons.   The SNR is now reaching well into +16 to +20dB range.  Secondly comparisons between the decoded telemetry on my Icom R10, PCR1000 and IC-706Mk2G have all shown similar results.  If I can now hear the signal in the receiver then I can now decode it.  Yay !

I've also just had the chance to take the new sound card for a spin on a recent balloon hunt and it was clear my problems with decoding the balloon were over.  I had 100% copy of the balloon at 38,000m with nothing more than a good 70cm SSB receiver (IC-706Mk2G)  and a 1/4 wave mo-pole antenna.  I tried switching to the PCR1000 and could also easily decode the balloon, albeit with a 2-3dB drop in signal strength (the PCR1000 doesn't quite have the same sensitivity as the IC-706mk2G).

So time to go digging into the technical, what makes the external Sound Blaster X-Fi better?

The Asus eeeBox and a vast number of laptop computers use a Realtek chipset, usually either the ALC662 (5.1) or ALC888 (7.1).   Both of these Realtek chipsets have a specified SNR of approx 90dB (A-weighted)  with up to 20-bit sampling @ 96kHz.  All this seems normal until you compare it with the Creative Labs offering with a SNR greater than 99dB (A-weighted) with up to 24-bit sampling at 96kHz.  Ah ha !  This means that there is approximately 9dB less Noise (Hiss) from the Creative Labs line input compared to the Realtek.  This clearly puts the Creative Labs card out front when trying to decode weak signals.  It is also the reason why there was a 10dB SNR variation between the decoded signals in my observations...   (Yes for the engineers reading this I've not taken into account the effective number of bits (ENOB) between cards at the same sampling rate, but we can see the Creative Labs card has the leading hand and most likely decimates to achieve the quoted SNR).

So for anyone out there that is looking to get into decoding weak signals with a sound card based modem.  By all means start by trying your on-board sound card in your laptop or desktop, but if you want that little bit extra out of your system or your not happy with the performance, then invest a few dollars in any of the Creative Labs Sound Blaster X-Fi series and I'm sure you will be pleasantly surprised.  I know I was.

Posted in Uncategorized | 2 Comments

MicroAPRS!

Posted on September 12, 2011 by VK5QI

When I was designing the MicroNut boards, I always had the idea that they might be usable for APRS in the future. The option of bypassing the FSK-generating voltage divider allows driving the transmit module directly from one of the ATMega's PWM pins. The transmit module's input filter is narrow enough (~3KHz) that the PWM sampling frequency is filtered out, leaving a clean AFSK signal.

A MicroNut board configured for APRS, with Icom IC-T90 and AA battery pack for scale.

As for the software, another project, 'Trackuino', had already succeeded in designing an APRS tracker around an ATMega. This code collects data from the GPS, generates the AX25 frames, and produces the AFSK. All I had to do was modify a few pin mappings, program it to one of my Micronut boards, and I was done!

I've now made some changes to the trackuino code, adding support for the DS18B20 temperature sensors, and setting the onboard uBlox GPS into 'airborne' mode, letting it gain lock above 18km altitude.

RadioMetrix TX1H module, soon to be replaced with a 300mW HX1 module.

I've been testing with a 144.390MHz 100mW module, but I'll soon have some 300mW 145.175MHz modules to do some testing on the APRS network proper.

Posted in Uncategorized | 4 Comments

Introducing MicroNut!

Posted on September 5, 2011 by VK5QI

Getting so close to the amateur altitude world record really got me thinking on ways of breaking it. One of the main ways of gaining altitude is to use a ligher payload, so I decided to produce the smallest and lightest payload possible while still using a Radiometrix module. The result is MicroNut.

MicroNut, without Radiometrix Module

MicroNut does away with an external GPS module, instead incorporating a uBlox NEO-5 or 6 onboard. Apart from this, the usual HAB amenities are present: DS18B20, spots for a NTX2/TX1H and associated SMA connector, and pretty LEDs. I've also broken out I2C and 5 GPIOs to half-pitch headers, for future expansion (more sensors, cutdown devices, etc).

Unlike MiniNut, the MicroNut drives the Radiometrix module with a PWM capable pin. This, in conjunction with the option for a 1st order filter on the module's TXD line, allows the MicroNut to be used for APRS!

The first MicroNut boards are still under construction, and I'm still waiting on a few Radiometrix modules to get a proper weight in, but it looks like MicroNut will be Project Horus's smallest payload ever!

Posted in Uncategorized | 1 Comment