The WG2 long-range balloon flight is now over as far as being able to track it is concerned; it is quite likely still in the air somewhere over Russia, however (as of 27/6/14).
The flight performed much better than we expected for a first try, covering a known distance of 1500 miles, to finally go out of ground-station range over Ukraine about 31 hours after launch. During the flight the balloon passed through a total of 8 countries (some more than once).
The balloon’s telemetry signal was received across Europe by a network of volunteers (many of whom are amateur radio operators), and fed into the central Habitat system operated by the UK High Altitude Society (UKHAS). This enabled the flight to be seen in real-time through the spacenear.us site.
At the time contact was lost the balloon and the tracking electronics remained in good health, with the battery expected to last perhaps a further 8 to 10 hours. Long-range flight predictions from the last known point suggest that the balloon will, if it remains airborne, travel up into Russia and then continue East towards Siberia.
Today sees the first flight of my tiny ARM based GPS tracker. The balloon (a 36″ Qualatex foil) was launched from Wirral Grammar School for Girls with their Astronomy Club, who were responsible for the successful WGGS1 high-altitude launch last October.
This flight is a float attempt, and can be tracked at spacenear.us with the callsign WG2. Calculations suggest the battery (a single AAA) should be good until about Friday morning.
The tracker, shown in the picture (more here), has the connector piece removed once programmed. For scale, the board is the same length as the AAA that powers it. Wire antennas were used for both GPS and downlink, and these were just soldered straight to the board. Total mass is about 12 g including the battery. Technical details of the tracker follow…
Laurent Mitnik has ported my FPGA Sinclair Spectrum to the Terasic DE2-70 board, and has very kindly allowed me to publish his changes. The port is based on the 200110901 release from the Downloads page.
I don’t have a DE2-70 on which to test this, but Laurent provided the screenshot to the right showing his board running Monty On The Run.
You can download the port from here for now, with the longer term plan being to move the source for both onto Github (when I have some time to convert the existing SVN repo).
The last few months I have been providing engineering assistance to Wirral Grammar School for Girls in their project to launch a helium balloon into the stratosphere. This first chapter of the project was brought to a stunning conclusion yesterday when we successfully launched and recovered a camera payload, lifting it to a final altitude of 35.5 km (116500 ft).
Telemetry from the balloon was transmitted back to the ground using a pair of trackers made from a modified version of my sensor boards. The two trackers were configured on different bands using a 433 MHz and 868 MHz RFM22B module respectively, and custom firmware was written to communicate with a uBlox GPS receiver and transmit coordinates via 50 baud RTTY. The primary downlink was on 434.3 MHz and was received as far away as Belgium and The Netherlands (thanks to all who helped out).
The downlink was received and decoded in real time from a chase car, with a rough landing site being obtained before the signal was finally lost. Initial indications placed the landing worryingly close to a quarry, although a search with a 7 element yagi turned up an extremely weak signal which was enough to give us a bearing to follow – it turned out to be a further mile and a half away and behind a ridge, which is pretty good going for a 10 mW transmitter lying on the ground. A short drive further and another wave of the yagi yielded a GPS fix which turned out to be 50 yards into a field about a mile further down the same farm track. Recovery was quickly affected by DFing the 868 MHz tracker for the final few meters using the much more portable yagi we had for this band. The camera was still snapping, and had shot over 1300 images.
Many thanks to everyone on #highaltitude on Freenode IRC for their valuable advice, and especially to those involved in the provision of the tools at habhub.org and spacenear.us.
Update 25/10/2013: Some images from the flight are now available on the new gallery
The TI MSP430 Launchpad is a cheap MSP430 development board – about £3 when they first came out, although a bit more now. I think mine was a freebie from a distie. Although I quite like the MSP430 I do tend to use either AVR or some kind of ARM for most of my projects, so it hasn’t really seen much use.
The built-in emulator consists of a TUSB3410 and an MSP430F1612, pre-programmed with TI’s own MSP430 “FET” debugger. My aim here is to end up with a debugger that I can use with TI’s CC1110 chips used in the Ciseco SRF. The GoodFET project can talk to these using its Chipcon module, and this has at some point in the past been made to run on the Launchpad.
For many microcontroller projects requiring accurate temperature sensing the sensor of choice is the Maxim DS18B20. Although this has a specified absolute accuracy of +/- 0.5°C, it has several drawbacks, not least of which is its relatively high cost. For my prototype sensors I incorporated a TI TMP112, which is an I2C device with a minimum operating voltage of 1.4 V, making it particularly attractive for battery powered applications. My preferred option for cost-reduction, however, has always been to use a cheap thermistor with the microcontroller’s built-in analogue to digital converter (ADC).
This post discusses the evaluation of a thermistor-based technique for small embedded systems capable of achieving uncalibrated temperature accuracy to rival expensive digital sensors. An experimental comparison of various sensors over temperature is then introduced.
There is a degree of uncertainty at the moment regarding the future availability of HopeRF’s RFM22B and RFM23B modules. Having been in touch with a number of HopeRF’s European distributors the message appears to be that while they are indeed “not recommended for new designs”, there has been no end-of-life notification for either of these products. Both modules will continue to be available for the foreseeable future, although they may be subject to minimum order quantities once distributor stocks run dry.
Recommended replacements are the RFM69W and RFM69HW. These new modules appear to be based on Semtech SX1231H, which means they are not an ideal equivalent because of a 2.4 V minimum Vcc (the RFM23B can work down to 1.8 V). Fingers crossed that HopeRF has actually used the 1.8 V capable non-H version of the chip on the lower power RFM69W.
Several EU distributors have indicated that they will be carrying the new modules within a month or so. Pricing looks like it will be slightly cheaper than that of the older modules, so that plus the addition of hardware AES should make these a welcome upgrade.
As part of my project to bring our central heating into the 21st century I have been working on a custom wireless sensor platform. My key aim here is to develop a low-cost, open solution with security designed in from the start; something that a lot of sub-GHz protocols seem to totally omit. I’m avoiding ZigBee because, as much as I want to like it, I keep coming back to the issue that its complexity just pushes up the system cost. In a domestic environment a simple sub-GHz solution can easily cover a typical property without resorting to meshing.
The design I have gone for combines temperature and light sensing with a pulse input for connection to the gas and electricity meters. The microcontroller is an ATMEGA328 and the radio is a Hope RF RFM23B, which is based on a SiLabs Si4431. This is a synthesised transceiver so the potential for congestion can be avoided through the use of listen-before-talk and frequency hopping, the latter also offering a way around the duty cycle restrictions in the 868 MHz band.
The printed antenna needs to be tuned by trimming it to length, which will no doubt be the subject of a future post. Once the optimal dimensions have been determined this can be applied to any future spin of the boards in advance. No prizes for spotting the deliberate mistake with the microstrip track passing under the RF module – I am hopeful it won’t have too great an effect!
The boards in the photograph just came back from iTeadStudio in about a fortnight. The quality is absolutely excellent considering the <£10 price tag for the 10 circuits. I have loaded a couple and firmware development is in progress.
I had a dead motherboard that had been kicking around for a while after a failed BIOS update. The flash part on there was the Winbond W39V040B, which is 3.3V only and has an LPC interface. The device programmer I have access to wouldn’t touch it, so I put together some simple AVR code to handle the protocol and connected the device up to my STK500. Although reading the device posed no problems, it quickly became apparent that the flash chip was not responding properly to write transactions. This meant there was no way to erase or program it, and is presumably why the BIOS flash failed in the first place.
Searching through the junk box I managed to find a dual-mode LPC/FWH device of the same size (PMC Pm49FL004). This one was responding properly to write commands, but I needed a way of reliably transferring the new BIOS image down to the AVR. Continue reading
AVR32 NGW100 Driving an STN LCD Module
I’ve had a few controllerless QVGA (320×240) mono LCD modules lying around for a while looking for some use. These are fairly easy to get going with a low-end microcontroller using an external controller IC like the SED1335, but that’s another story. I’d been thinking about doing some sort of integrated home automation project, and since this would need a user interface and I happened to have an NGW100 going spare, getting one of these displays to run on the AP7000′s integrated LCD controller seemed like a nice idea.
The NGW100 only has a 16-bit interface to its already relatively slow DRAM, so driving a high-res colour LCD from it leads to a fairly obvious slowdown. For this application a mono display would be adequate, and easier to drive, requiring only a 4-bit data bus, the 3 clocks and a GPIO to power up the drivers. The LCDC has no problem driving an STN panel, although I had to deviate from the datasheet in one area to get it to work – more on that later.