Atlas3

• To explore the phenomena of 36km floats with Howyee balloons
• To test the Atlas flight computer at altitude

• Atlas PCB
  • ATmega328 + 8Mhz Crystal
  • Radiometrix NTX2 10mW 434.075Mhz + Crystal oven
  • GPSbee (Ublox 5) GPS
  • 3 x DS18b20
  • Photosensor
• 2 banks of 4xAA lithiums

Found 2 major software/hardware bugs in the Atlas setup which explain the failure of Atlas2 midflight

With the ublox 5+ GPS modules it is necessary to put the module into the correct NAV5 mode to allow it to function above 12km. The code I wrote to check whether it was in the correct mode send a command and then waited for a short period of time for the response, if there was no response it timed out and the software carried on. What I found was that after the first check (which would report the correct reponse) it would then not work. After some digging I found that the variable that millis() was being put in was defined as an int:

 int startTime = millis(); 

The problem with his is that milis() gets big quickly and soon overflows this variable, instead it needs to be unsigned long

 unsigned long startTime = millis();

Now the code works correctly and will return the NAV5 mode, for airborne you want 6. By checking this mode we are then able to send the command to set it all up if the GPS has reset and lost its settings. The complete function is:

//Function to poll the NAV5 status of a Ublox GPS module (5/6)
//Sends a UBX command (requires the function sendUBX()) and waits 3 seconds
// for a reply from the module. It then isolates the byte which contains 
// the information regarding the NAV5 mode,
// 0 = Pedestrian mode (default, will not work above 12km)
// 6 = Airborne 1G (works up to 50km altitude)
//Adapted by jcoxon from getUBX_ACK() from the example code on UKHAS wiki
// http://wiki.ukhas.org.uk/guides:falcom_fsa03
boolean checkNAV(){
  uint8_t b, bytePos = 0;
  uint8_t getNAV5[] = { 0xB5, 0x62, 0x06, 0x24, 0x00, 0x00, 0x2A, 0x84 }; //Poll NAV5 status
 
  Serial.flush();
  unsigned long startTime = millis();
  sendUBX(getNAV5, sizeof(getNAV5)/sizeof(uint8_t));
 
  while (1) {
    // Make sure data is available to read
    if (Serial.available()) {
      b = Serial.read();
 
      if(bytePos == 8){
        navmode = b;
        return true;
      }
 
      bytePos++;
    }
    // Timeout if no valid response in 3 seconds
    if (millis() - startTime > 3000) {
      navmode = 0;
      return false;
    }
  }
}

This bug is probably what caused Atlas2 to have difficulty with providing data midflight. I was doing freezer test of the PID controller when I found this bug, When the flight computer got down to about 0 deg C it stopped reporting the updated GPS time. My initial thoughts were that it was the GPS struggling in the code however when I tested the GPS output it was still working correctly. It seemed that by using the internal resonator as the timing this was struggling in the cold and drifting enough that the AVR was unable to read the serial data from the GPS.

The solution was to use an external crystal which would be less sensitive to temperature. I got a 8mhz crystals and soldered this to the bottom of the PCB with the appropriate capacitors. After changing the fuses and bootloader this worked excellently and the problems with temperature and GPS went away.

Complete software can be found on my github repo: Atlas3_3.pde

The plan was to investigate whether it was possible to launch at night and still get float. The launch was set for 1800GMT 11/11/11 however due to delays in the team being assembled launch took place at 1915GMT. The wind had picked up making it difficult to control the balloon when filling as it acts like a large kite. We slightly overfilled it and resulting in an ascent rate of about 4m/s. The payload worked really well with up to 20 receiving stations on the ground. The crystal oven was able to keep the radio crystal at 2deg which stabilised the drift making it much easier to track.

Float occured at just over 36km and lasted for about 30mins before burst at a max altitude of 37033m (a new personal altitude record). The payload descended by parachute and landed off the North Norfolk coast in the sea.

• Payload to check GPS settings less often (say every 50 strings) to avoid the pause and repeated string.
• Build similar payload and launch in less windy conditions, aiming for a 2-3m/s ascent rate to explore whether longer float can be achieved.