====== HelioSS 1 ======

[[projects:helioss|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/|http://www.flickr.com/photos/51961961@N08/sets/72157624459186628/]]

====== Flight computer ======
The flight computer was based on a LPC-H2214 ARM development board from [[http://www.olimex.com|Olimex]]. It also included:
  * FSA03 uBlox GPS receiver
  * Radiometrix NTX-2 radio transmitter
  * Several TC77 one-wire temperature sensors
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.

====== Payload ======
The payload included:
   * Two cameras (a Canon A480 and a Canon A560), both running CHDK
   * A thermal experiment measuring the temperature of four targets, each painted a different colour
   * An experiment to demonstrate Boyle's Law using party balloons
   * A radiation experiment using a medical radiation dosimetry badge
   * An experiment to observe the effects of high altitude exposure on Brine Shrimp eggs

====== Flight ======
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.

====== Anomaly ======
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):
  - Radio
  - Temperature measurements (SPI)
  - GPS reading (UART)
  - Flash LED

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:
  - Switch the GPS task to a higher priority (mitigate the effects if it happens again)
  - Modify the SPI code to allow for the possibility of a mode switch
  - Ensure there is no possibility of a short on the SSEL lines.
... and maybe even implement a watchdog timer.