Wednesday, 9 November 2011

RTTY Library for the Arduino

Just finished making an Arduino library for use with normal UKHAS style setups.
Links to a demo file here, as well as the RTTY.h and RTTY.cpp files.

This library supports ASCII 7 or 8 bit, 1 or 2 stop bits, 50 or 300 baud speeds and has XOR checksums using USB type transmissions. Which is fairly standard and a good starting point for HAB projects.

Many people have code which uses most of this already, though this library is more for a quick fire HAB project or for easy beginners starting a project.
Only two lines of code should cover the setup and calling of a RTTY transmission.

The RTTY.h and RTTY.cpp files need to be placed inside a new folder called RTTY inside the arduino/libraries directory.

Thanks to Tim Zaman for the initial inspiration to create the library, and for the usual UKHAS crew for the code, ideas and their help as always :-)
(Project Horus, RJHarrison & JCoxon)

Example sketch code is similar to:


#include <RTTY.h>
// create the rtty object with following parameters:
// Mark_Pin, Space_Pin, ASCII (7 or 8), Num Stop Bits (1 or 2), Baud (50 or 300)
RTTY rtty(4,5,7,1,50);

// our sprintf buffer
char superbuffer[100]="";
void setup()
{
  Serial.begin(9600);
  Serial.println("Startup");
}

void loop()
{
  //$$callsign,txcount,hour,min,secs,lat,lon,alt
  sprintf(superbuffer, "$$CallSign,%d,%02d:%02d:%02d,%s,%s,%d", rtty.txCount(), 12, 00, 20, "52.2", "0.09", 485);
  rtty.TxString(superbuffer);
 
  //we can print the current tranmission counts:
  Serial.println(rtty.txCount());
}

Monday, 26 September 2011

Launch Day

Well that was a bit dramatic...
Rain and wind really did put a dampener on things to begin with, and caused us a few issues, but WDHAB was going, ready or not.
There were some successes, and there were some failures. I was never one for doing 'the normal' thing and full experimentation was the key here. Hopefully some lessons can be learned and a few ideas taken on-board by others.

Set up at the launch location went well, but the main WDHAB payload just wasn't getting the altitude. It had never failed before. Typical. Restarting, unplugging, cold starting the GPS didn't seem to make a difference, though I thought it would pick it up eventually anyway.... but alas no joy - sod it, launching anyway, especially as the balloon was inflated by this time.

The balloon didn't quite get to the neck lift I was wanting, it's possible the rainwater resting on it may have contributed (not sure) but the cylinder ran out with approx. 3KG lift. I was aiming for 4KG for a shorter flight, as the minicams and the WDHABmini payload only have short battery lifetimes.... anything to maximise the chance of recovery. The prediction was reasonable, but it had a little further away landing point than I had wished, the winds were definitely strong - some of the decodes indicated ground speeds of 65 mph.

WDHABmini first. This was a very lightweight payload - approx 50g. it was literally gaffer taped to the side of the main payload box. The intention to see how it behaved 'open to the elements' - the result: badly.
1)The cold affected the transmission frequency dramatically, and it was very difficult to keep tuned it.
2)The temperature also affected the 'shift' for the RTTY tones, and the initial 425Hz rapidly reduced to sub 300Hz and varied throughout.
3)The batteries were small Lithium Sulfide, light weight, but not all that powerful. It seems that though transmissions were steady at normal temperatures, the fluctuations badly affected them and their life was short as well as reduced power output to drive the GPS/transmitter effectively.
4)The GPS unit trialled on the mini payload was of a Venus type, and it does seem to have failed above a certain height (possibly battery power related), though I think further trials wouldn't go amiss.
The mini payload indicated how the components were affected by the temperature, and some sort of thermal control/insulation definitely helps.

Both payload antennas were dramatically affected by the wind - silly I know, but upon retrieval it looks like one of the radials actually came off and the other antenna was blown flat. This would likely have explained the weaker than expected signal strengths, but also indicates the skill of the radio receivers who were able to pick up anything at all!
Reinforcing the antenna, or altering the design is a whole new area to work on.

The balloon payload went out of range quite quickly from the launch site until we got to the other side of the Malvern Hills, but by then it had made considerable distance and the signal was rather weak. Cup of coffee and then it was off to try and keep up!

WDHAB just about worked - in that; it went up, came back down, was found and had taken pictures :)
The habhub predictor was rather accurate - that was a great success.
The addition of a standalone GPRS GPS tracker was inspired; and saved the day.
The Canon CHDK script worked well, as well as the other Ricoh interval timed camera with auto bracket.
The styrofoam boxing with additional sticky pads worked really well in securing the cameras, radio, batteries and flight computer and seemed to maintain acceptable temperature ranges.
The main GPS on WDHAB has now seemed to have properly died :( It has survived many outings in model aeroplanes and has been tested throughout the development of the payload. So I'm disappointed about this. The reported 'no altitude detected' of 99999999 never changed throughout the flight. It also seems that it too was either affected by the height restrictions, or not enough battery power to get a lock (which I think is unlikely) which is unusual for a ublox (and in airborne mode). Further investigation required.

The rain looks like it shorted out one of the minicams, and another minicam just didn't function (probably my soldering not surviving). Luckily the third worked well. An example of redundancy helping, but showing that water potentially will find a way to cause problems! No holes in the top of your payload if you can help it!
The wind and rain really made setup quite difficult, thanks to the other half and my brother for standing around holding the balloon and not flapping too much when stuff wasn't going quite to plan!

Looking at the times from the pictures, the payload was in flight for about 2 1/4 hours, which was about half an hour longer than I predicted - due to the slight under-inflation. On the plus side, it probably went a touch higher than intended. A few pics below.

Retrieval was made from a farmers field, who himself was rather interested in what the strange box was. This was near Melton Mowbray and was quite a drive from the launch site!

Many thanks for the trackers from the UKHAS and assistance on the IRC.
WDHAB2 will be re-engineered, and will have differing goals. Hopefully this has been helpful to the wider HAB community :) any questions, give me a shout.




 











Monday, 8 August 2011

Getting there...

Close, but not that close.

The code still needs tweaking and wasn't quite working as expected, so decided to start from scratch and add the bits module by module, piece by piece, to get it nearer to what I wanted.

I've added 3 minicams to the payload for video coverage from 3 different angles, attached to a 2000mAh battery. Keeping it simple - on and record until the card fills up or the battery dies - essentially 1h 45 mins worth.
2 point and shoot cameras for the photos. I've ditched the webcam and SSTV Gumstix part for a later date.... otherwise this project will never happen!

Helium has been bought and is sitting in the garage costing ~£7 a month hire charge - dammit, got it too early! (since Nov 2010 - ambitious)

I was lucky enough to help a fellow local HABer in the area (maybe Worcester is an additional HAB hub?) Adam C with his HABE payload. It went really well and confirmed what I was working on would actually take off and work - I've just been soooo slow putting it all together. An idea I've pinched from this is a standalone GPS tracker which responds to a text message, so once the payload has landed, the chances of a successful recovery improves dramatically :) Also, the parachute used was cool - so got myself one of those from spherachutes. Cheers Cuddykid.

I've now got the main payload styrofoam container nearly cut to shape (thanks to the other half ;) and the cutdown device partially rigged up as per the idea on the UKHAS site.

Updated photos:
Starting to hollow out the box

Batteries for the minicams, arduino (with screwshield). Transmitter, cameras, cutdown circuits & gps tracker:

Box with more parts in place:

Sunday, 17 July 2011

Android Tracker

Hi,
A quick post with an Android based UKHAS chase car tracking application.
Fire it up, check the upload URL - set up for Upu's test tracker. Set your chasecar name (whatever_chase), accuracy for GPS/location service (I've set it for being better than 100m), update frequency of attempts to the tracker, and the password to use.
Ticking the top 'Tracking...' check box starts and stops tracking. Being android it can run nicely in the background whilst in the car following the balloon and using copilot/google maps to navigate. :)

android apk here
the appinventor source zip is here - still work in progress

very alpha beta software - any hints, tips or ideas gratefully received either mail or catch me on irc.

Saturday, 8 January 2011

Next Steps: frustrations, alterations & additions

I saw that some payloads had a nice point and shoot Canon camera included, which had CHDK software installed to automatically take photos and videos; so I wanted one of those too :)
A friend also gave me a Caplio camera which had a time lapse function, and was then doctored to have the backlight switched off with the use of a removable 'jumper' - cheers Steve. Add another 150g to the payload....

Getting the bloody Gumstix to work is a nightmare. More instructions on how to get that going to be added later, but essentially going for the git repository method described here.

Then, JCoxon launched a balloon with live slow scan TV transmissions, in fact using a Gumstix for this.... why not eh, how difficult can it be? As it turns out, very, and the Gumstix compilations, modules, hardware and other foibles have set me back. Thanks James for the assistance and the Audiostix. :)
It should have worked, all parts are talking to each other, the loaned SSTV code compiled and seemed to work fine, the transmitter transmits, but more work is needed! dammit.

I've decided that an Arduino should be the flight computer. It has proven stability and seems quite simple to setup, with ease of programming and come in various 'flavours' and sizes - maybe a pro mini could be good - it is small and lightweight. Anyway, got the duemilanove model to play with.
Added a temperature sensor, and also thought it would be good to add a pressure sensor - Sparkfun supplied all these bits.

The main part of a payload is the GPS unit. I've been working on a sister project for an autonomous flying plane a la diydrones. This is arduino based, but also has a nice GPS unit, with a very usable connector which takes care of some tricky interfacing & voltages. Though later on this unit seemed to not get a lock - but re-soldering the antenna sorted this - pain in the proverbial.

Some problems I've encountered here are the various voltage issues of the IO lines to the arduino from the pressure sensor and my latest addition - and compass module. These require 3.3V whereas the lines are 5V - so some resistor voltage division & limiting was required.

Then, problems with the onewire dallas sensor code stopped my GPS from getting enough data to the arduino (turns out other folk have had similar problems)
so, currently I'm ditching it, as the SCP1000 module includes temperature as well as air pressure.

Some pics of the current setup:
GPS & connector:

SCP1000 pressure sensor:

Arduino, GPS, pressure and temp sensors: