HelioSS 1 was a launch carrying experiments from Sponne School in Towcester. It was launched from the CUSF site at Churchill College but position data were lost during ascent. It was not recovered immediately but a farmer found it the following Thursday.
Landing position was 52° 07'42.95“N 1° 03'41.85”E
Selected photos available at http://www.flickr.com/photos/51961961@N08/sets/72157624459186628/
The flight computer was based on a LPC-H2214 ARM development board from Olimex. It also included:
A 12 bit A/D converter was used to provide the signal to the NTX-2, allowing fine frequency adjustment. By adding a temperature sensor mounted directly to the NTX-2, we hoped to minimise the usual frequency shift observed as the NTX-2 cools.
The payload included:
The mission was launched from Churchill College at 10:47 UTC on 30th June 2010. Immediately after launch, it was noticed that the GPS position in the telemetry was not updating.
The balloon was tracked using radio direction finding as it climbed out to the east. At 13:20 UTC it was observed visually to the east of Bury St Edmunds. It was observed to burst at 14:54 just south of Bury St Edmunds. Although it was tracked by radio throughout the descent, it was not recovered.
The landing position is thought to be close to Stowmarket in Suffolk.
Before the payload was recovered, it was impossible to be sure about the mode of failure. The payload was not recovered intact but should allow some investigation. Before recovery, only one possible cause which fits the symptoms was identified.
The flight software, running on a NXP LPC2214 ARM processor used the TNKernel RTOS. There were four threads (in order of priority):
It was clear from the telemetry that the first task was working and the second and third weren't. Thus the second task must have hung (thus preventing the other two from getting CPU time).
There are only two potential places for the SPI task to hang: waiting for a transfer to complete or waiting for the next iteration. The second of these uses the TNKernel wait routine which worked perfectly in the radio task. The obvious place would be, therefore, the SPI wait. However, a SPI bus master should never hang - it controls the transfer and the slave has no way to block it.
However, investigation of the small print in the LPC2214 manual reveals that if the SSEL (slave select) line on the LPC2214 SPI bus is activated, even if the device is in master mode, the interface will immediately switch to slave mode, thus failing to complete any current bus master transactions.
It is thought likely that the SSEL line on the temperature SPI may have been briefly shorted during final assembly, thus switching the SPI bus to slave mode and hanging the thread.
Fixes to be implemented on the re-flight are:
… and maybe even implement a watchdog timer.