The mbed NXP-LPC1768 is based on the 96MHz ARM Cortex M3 Processor and has a large amount of I/O including Ethernet and USB OTG. It also has 32KB of RAM and 512KB of Flash.
Source Code: github.com/rmhsilva/vertigo
- mbed NXP-LPC1768 ARM Cortex M3 Board
- 3.3V LDO Regulator
- 3.7V 2Ah LiPO Battery
- ublox MAX-6 GPS with Sarantel Helix Antenna from HAB Supplies
- 434MHz RFM22b from HAB Supplies
- 868MHz RFM22b
- 2x Qualatex 94cm Balloons from Random Aerospace
- Filled with helium
The payload was launched from a road junction near Winchester in Hampshire at 0720 on Sunday 3rd February.
The 868MHz Telemetry worked at the launch site until just before launch when we swapped for another code build, we only had one receiver and were running out of time for a predicted dry landing, so didn't check the 868MHz before launch. After launch the 8VERTIGO transmitter was found to be inactive, leading to a complete lack of interesting telemetry, along with intermittent position updates.
The idea for the project was to construct a payload capable of sending down Live Images using Philip Heron's SSDV Protocol, as well as a wide variety of other sensors that could be attached to the mbed board. The payload would transmit slow (50-baud) telemetry on 434MHz for primary position-tracking, and use fast (300/600 baud) telemetry on 868 MHz for SSDV Data and Sensor Telemetry.
The plan was to use the Linksprite JPEG UART Camera to capture images, and then port the SSDV code over to the mbed platform to send the image packets down over the 868MHz Telemetry.
Unfortunately the Linksprite Camera was delivered to the University Stores just before they closed on Friday Evening. By the time we learnt of this, the staff had gone home for the weekend, leaving the module locked in a room on the floor just below us for the rest of the weekend.
On Saturday morning a member of another team lent us another Camera Module, this was one that had been used in a previous Course last year, and was known to be difficult to work with. It was a chinese clone of an OV7670 Camera + FIFO, similar to the one described here.
Unfortunately, where the Linksprite Camera encoded the image as JPEG itself, the OV7670 only supplied raw (eg. RGB) Data, and so we had to encode it using a JPEG compression library on the mbed. Luckily we had the RAM to do this!
The RTTY was bit-banged with 'wait()' loops, meaning that only one telemetry string could be sent on either frequency at once, and the payload CPU could not do anything else while this was running. I reckon the 96MHz speed should have been enough to use interrupts for RTTY timing (I haven't tried using interrupts before though), however due to Camera issues we did not get the time to try this out. This would have allowed the telemetry to be sent on both frequencies simultaneously, drastically increasing downlink capability.
434MHz at 10mW (VERTIGO)
This was used just to send position telemetry at 50 baud, mainly as a well-tested fallback system to allow the payload to still be tracked if the 868Mhz Telemetry failed at range. Only one string was sent on this frequency at ~40 second intervals. This was meant to be increased to a sequence of 3, but there was no time to include the code change.
868MHz at 100mW (8VERTIGO)
10 strings were sent every 40 seconds at 600 baud. These were received successfully in testing with a Funcube Pro Plus at ~50m range through 3 highly-shielded floors.
In testing at 11pm on Saturday we noted that the 868MHz TX was being switched off in the sequence-of-10 loop, when we added Serial Debugging to the loop, the problem disappeared.
In a rush at 6:30am on Sunday morning (at the launch site) we noted the LEDs were still on, so we stripped the debugging from the build just before launch, verified the 434 telemetry and then launched, forgetting that the removal of the debugging triggered the 868MHz switch-off bug. Hence there was no 868MHz telemetry after launch.