M2FC PCBs Ready To Assemble

M2FC PCB Top
M2FC PCB Top PhotoM2FC PCB Bottom M2FC PCB Bottom Photo

 

The flight computer PCBs have been collected from Cambridge Circuit! As ever they’ve done a fantastic job. We had a quick tour of their facility when we collected these PCBs which was great to see. Thanks again Cambridge Circuit! The renderings of the PCB above were generated by GerbLook, click the link to check out the other layers.

All the orders have now been placed for the various electronic components for these PCBs (the bill of materials for one flight computer alone is around £150!). We also have stencils and stencilling jigs in-hand so soldering should take place next week, after which all that’s left is to write the firmware that will operate the avionics. This firmware is responsible for deciding when the moment is right to fire the various pyrotechnics and let the ground crew know what’s going on.

M2R PCBs Arrived

M2R PCBs

Today Cambridge Circuit Company finished manufacture of the PCBs for M2R, the radio board on Martlet 2. We drove over to pick them up this afternoon and they’re looking good! Hopefully we’ll have the designs for the flight computer finished soon and then we’ll get both boards assembled and start on the firmware.

A big thank you to Cambridge Circuit Company for their continued support of CUSF; they’ve now been sponsoring us since 2012 and have always given us fantastic PCBs very quickly.

Radio units arrived

MTX2The radio modules we’ll be using on the M2R radio boards arrived from Radiometrix today. They’re generously sponsoring Martlet 2 with these radios, thanks! We’ve been using their radios for many years now, starting with the venerable NTX2 for some early high altitude balloon payloads, and they’ve always performed perfectly. We’re excited to try out these very new MTX2 modules — they are much smaller than the NTX2 and should have excellent frequency stability thanks to a temperature compensated crystal, plus they are in-flight frequency reprogrammable in case we find frequency clashes in the field.

 

Martlet 2 Radio Boards Sent Off

Today we finished the PCB design for the radio system on Martlet 2.

The radio PCB for Martlet 2

The radio PCB for Martlet 2

You can read more about the board here, or check out the schematic here. Our designs are made using KiCAD and as ever you can view all the gory details on our GitHub.

A big thank you to our sponsor Cambridge Circuit who are making these PCBs for us! If you need any PCBs made be sure to check them out — the first time they sponsored us, we had a whole panel of perfect PCBs only a few hours after giving them the files (and a few hours after that, the PCBs were in the stratosphere!). Highly recommended.

Martlet 2 Electronics Schematics

A little bit of the schematic for the radio board m2r

A little bit of the schematic for the radio board m2r

After many weeks of careful planning and design, lots of simulations and calculations, and pages upon pages of datasheets, the first revision of the design for the flight computers aboard Martlet 2 are complete.

You can check them out here: m2fc is the main flight computer and m2r is the radio board. Since the radio board is the simpler of the two, we’ll talk about that first.

 m2r: The Radio Board

This board is responsible for receiving GPS positions and transmitting them and additional data from the main flight computer over a radio link and a satellite link back to the ground station. At its core is an STM32F303 microcontroller, a powerful ARM-based chip that has several useful peripherals such as a digital-to-analogue converter which we use to drive the radio’s modulator, and three serial ports. It’s also speedy and has plenty of memory, which will come in useful for using error correction codes on the radio data. A handful of LEDs for monitoring, a programming connector, and standard µC support circuitry round out the basics.

For the GPS, we use a uBlox Max-7Q, a very compact and high-performance GPS receiver. A low now amplifier and GPS filter, the ALM-2712, increases sensitivity.

The radio downlink uses a Radiometrix MTX2 unit, generously sponsored by Radiometrix (thank you!). This tiny and high performance radio is the successor to ones we have used on our high altitude balloons, where the 10mW transmit power is enough to receive a balloon from 700km away. It has an FM input that maps to a narrowband output, so we can use it for FSK when received with an SSB receiver, or with any baseband signal when used with an FM receiver (at the cost of some signal to noise ratio). Additionally the MTX2 can be programmed to operate over a wide range of frequencies, so we can resolve any potential clashes or avoid local noise sources.

Following the MTX2 is an optional amplifier stage. In the UK this won’t be legal to fly, so we can bypass it for testing, but in the USA it would be OK to operate under an amateur radio licence. The amplifier boosts the output power up to 500mW, which should help it punch through the rocket and reach the ground station. This is the most careful part of the board design, where the best bet is following the ADL5324 datasheet’s recommendation as closely as possible.

To talk to the main flight computer we use the ADuM1201, a more modern version of the optoisolators of the past. This chip provides galvanic isolation via an in-silicon transformer, so that anything upsetting that might come in the cable is prevented from affecting the rest of the board.

For the satellite modem we connect to a RockBLOCK unit, which uses the Iridium network to provide worldwide coverage (so long as the antenna is pointing up!). This is a backup to the MTX2 in case the rocket goes out of radio range or we experience a radio failure. It sends less data and does so slower, but should be useful for getting a final GPS position after landing.

m2fc: Flight Computer

The main PCB has a longer list of responsibilities:

  • Measure rocket acceleration, rotation, altitude and bearing
  • Fire pyrotechnic devices at appropriate moments in the flight
  • Measure strain gauges to determine fin loading
  • Measure thermocouples
  • Log data to SD card
  • Communicate with the radio board to have key telemetry (altitude and flight status) sent back to the ground station

To get all this done we start with an even beefier microcontroller, the STM32F405VGT7. In addition to having 100 pins (compare to 48 for the radio board), we get a bump in clock speed (up to 168MHz) and a lot of peripherals (we’ll be using 3 SPIs, 2 I²Cs, 2 USARTs, the SDIO peripheral, 7 ADC inputs, and a bunch of GPIOs). As before, LEDs, programming interface, a voltage regulator and parts like the clock crystal come as standard.

The SD card here uses the SDIO interface rather than the commonly used SPI interface. The SDIO interface is faster, and on microSD cards can transfer a nibble at each clock, rather than just one bit. Additionally this means we can use the SPI peripherals for other things.

For the inertial sensing, we have a full suite of MEMS sensors. ADXL345 and ADXL375 provide low- and high-G acceleration sensing over SPI, with an output data rate of 3200Hz. The L3G4200D measures the rate of rotation at 800Hz, the HMC5883L measures the magnetic field strength which we can use to estimate a bearing, and MS5611 measures absolute barometric pressure, from which we can derive the current altitude. We’ve hooked each sensor to its own communication peripheral on the STM32 to help avoid bus contention, simplify programming, and ensure maximum data rates. Other than that there’s nothing particularly exotic going on here — the joy of highly integrated sensors.

The serial interface uses a variant on the ADuM1201 on the radio board: the ADuM5201, which in addition to data isolation provides an isolated 5V power output, which we use to power the radio’s ADuM1201. This handy feature means there is complete isolation between the two circuit boards. A second ADuM5201 is provided for futureproofing and connection to a computer for debug and development purposes.

An external red/green LED lets the user know in the field that everything is OK with the set up. The flight computer can check that all the sensors are working, run self tests, verify that the SD card is recording data, communicate with the radio board, ensure satellite and GPS lock, detect the pyrotechnic devices are installed correctly, and ensure all the sensor values are close to nominal before asserting that everything is ready to fly.

The two pyro channels are able to drive 1A into a Metron protractor unit, a small pyrotechnic device which we use for staging and parachute deployment. Continuity detection is provided so the microcontroller can verify that the connections to the devices are OK, and a large capacitor provides the energy to blow the pyro.

The thermocouple design starts veering into actual analogue work. Thermocouples are temperature sensors that operate on the Seebeck effect, producing a very small voltage proportional to the temperature difference between two metal-metal junctions. One junction is at the sensor, measuring the temperature of the fin leading edge, for example. The other junction is at the PCB. Here a speciality thermocouple amplifier, the AD8495, is used to provide both amplification of the very small voltages from the sensor and cold junction compensation. Before the amp is an input RC filter to reject any radio noise picked up on the long leads to the thermocouple. After the amplifier is a two-stage, fourth-order Butterworth antialiasing filter, to ensure that no frequency content above the Nyquist frequency of the ADC is present.

Finally the strain gauges. These sensors are affixed to structural elements of the rocket and change resistance in proportion to the material strain. The change in resistance is detected using a bridge circuit, and the very small voltage amplified up with an AD8226 instrumentation amplifier. Extra care has to be taken that the references are precise and temperature effects are controlled and compensated for, as they are usually of the same magnitude (or larger!) than the voltages due to strain. Here, one half of a Wheatstone bridge is formed of two high-precision and low-temperature-coefficient resistors on the PCB, providing an accurate Vcc/2 reference. The other half of the bridge is on the fin, with one strain gauge and one 120R completion resistor. They should both be at the same temperature, which helps remove that influence. Some factors are not controlled for — the wires leading to the strain gauge will have a resistance, for example, and that will change with temperature. This would lower the voltage across the bridge, and affect the calculations of the strain from the measured voltage. However, some simulations suggest that this impact should be very small as the wires are short and reasonably well behaved. As with the thermocouples, an RF filter is present on the front end, and a fourth-order antialias filter completes the setup.

 

The next stage is to design the printed circuit boards for both of these schematics. Many other considerations apply here, as component layout and routing can have a big impact on performance. Hopefully no big changes will have to be made to the schematic once work is underway on the PCBs!

NOVA21 and NOVA22

On Wednesday 28th March, we flew NOVA21 and NOVA22.

NOVA21

NOVA21 went up at around 1330BST carrying JOEY-M, Squirrel (the Android project) and a special guest. It got to 27.2km altitude before burst, landing near Braintree.

The flight was mostly a test of the new Joey and Squirrel flight code. Joey performed well, though there was a lot of interference on the 433.8MHz frequency it was using, so later revisions will swap to a higher frequency. Squirrel was great up until around 8km when for a yet-unknown reason the flight software cut out, which meant the radio and camera were disabled. However, after landing we were able to reactive Squirrel remotely, getting some tweets of photos from the field it was in and its GPS position. The payloads were recovered successfully.

NOVA22

NOVA22 launched at around 1500BST carrying Wombat along with ASTRA from the University of Southamption with an experimental HF transmitter on 27MHz and a balloon neck flight computer with a differential pressure sensor to log the balloon’s pressure.

NOVA22 reached 21km before burst (on a smaller 350g balloon) and landed close to NOVA21. Wombat worked much better than on NOVA20, being successfully decoded by many people in the listener network. ASTRA’s experimental radio also worked, though unfortunately the payload lost GPS lock for a part of the flight. The balloon neck flight computer was a success, getting back valid pressure data for the balloon.

Again NOVA22 was recovered successfully.

 

Photos from the launch: Flickr

T-Rex In Space!

NOVA21 had a special guest on board the flight: Wee Rex from Dinosaur Comics! He’s an adorable fluffy squishy stuffed T-Rex.

We mounted him on a couple of sticks of balsa wood to the payload containing JOEY-M and the cameras:

Then we sent him up, getting a ton of good photos:

 

He got to approximately 28km altitude before the balloon popped and NOVA21 descended by parachute.

We put together a time lapse video of the whole flight:

T-Rex In Space from Cambridge University Spaceflight on Vimeo.

 

It’s pretty cool! Ryan North, creator of Dinosaur Comics, said:

Success!

Wombat Flight Computer

IMG_7909

Work has been progressing recently on the Wombat flight computer. While the original designs had been started well back in October, a few weeks ago we restarted the schematics with a view to a much more capable payload.

The schematics started coming together on the 18th Feb, and within a week were all finished and board layout began. A hectic weekend of designing part footprints and routing them together (all ~400 nets!) later, the designs for revision 1 were finalised at around 4.30AM Monday morning:

We sent the design files off to Cambridge Circuit Company who kindly agreed to sponsor the PCBs and promised to do their best to get them made as soon as possible. We also had some solder stencils made up and placed an order for all the parts from Farnell, fingers crossed that everything would arrive in time for an early launch.

Fast forward to Tuesday and seven parcels have turned up in the post and we’ve collected the PCBs, which are looking amazing:

IMG_7843

We wasted no time getting them soldered up and spent the rest of Tuesday evening, night and early Wednesday soldering, reworking and debugging our way through a number of small issues.

Perseverance prevailed and all the various subsystems started to work. The GPS was first, and thanks to the onboard USB we could test it right away. The STM32 (the microcontroller) had a few very tiny solder bridges thanks to our less-than-ideal paste application, but a bit of rework had this chip up and running, even if it wasn’t quite running code just yet.

Debugging the power supply took several more days as various issues were worked through, but eventually we realised the current limiting supply was causing it to lock in to undesirable state, which combined with a too-low-current inductor was causing all our problems. A quick part swap out later and the power supply was working fine.

IMG_7908

Meanwhile, the STM32 was hitting a hard fault every time it tried to start up. It turns out this was due to the linker script being told about 192K RAM, but actually the RAM isn’t continuous in address — 16K of it is off at 0x10000000, so the startup code was trying to load the stack pointer with an invalid address, causing the hardfault. Once we’d resolved this, code started loading and we could move on to the radio.

IMG_7910

Further fun was had getting the radio to start up — the PLL was not locking on to the correct frequency, despite coming very close. Significant pain later, it turns out the loop filter was not quite right for 434MHz operation — it could very happily lock at 400MHz all the way up to 433.5MHz, but no higher. Happily, 433MHz is still inside the ISM band, so we’re set on that front for now (pending a redesign of the loop filter — which happily just means swapping around some components).

IMG_7906

Now that all the hardware’s working, it’s time to get started on the software required for it to act as a basic flight computer, in advance of a potential launch this coming Sunday (weather permitting, of course!).

EARS 4/11/2012

Last Sunday, CUSF took our new rocket to EARS. We launched it twice, on an H143 and an H225 motor, and recovered it okay both times!

All the photos are on Flickr: http://www.flickr.com/photos/cuspaceflight/sets/72157628282044955/

And all the photos are on Vimeo: 1 2 3 4 5

Some highlights:

Launch 2

Launch 1 (handycam) from Cambridge University Spaceflight on Vimeo.

Launch 1 (slowmo) from Cambridge University Spaceflight on Vimeo.

path

IMG_7696

IMG_1449

Hopefully we’ll be launching two new rockets and this one a few more times next EARS meeting!