The point of using Arduinos wasn't to go cheap on components, but to make the actual satellite itself more accessible and easier to write code for. In fact, we're doing the opposite of going cheap in terms of hardware: the guts of the components for the satellite itself (not the payload) are all pretty costly because they're all space-rated (and most of them are space-proven).

The expensive hardware is the whole reason we need the Kickstarter campagin!

Joel (ArduSat developer)

The thermal management of the Arduinos is definitely an issue - that's partly why we're putting them on a custom PCB with thermal spreaders to help dissipate the heat. It also helps us fit more of them in the envelope.

Cheers, Joel (ArduSat developer)

Yup, you got it - the camera itself isn't run on Arduino, but it's still controllable from the payload Arduinos.

Ack, you're right, we forgot to put the cameras in the package descriptions - thanks for the heads-up!

The idea main idea with putting the code itself in space is to let people write code that could actually use the sensor/bus data for real-time control, and actually play around with the satellite control system. It's more fun that way, wouldn't you agree? We thought actually using a satellite would be more appealing/rewarding for students/educational groups too.

Re: the GPS and other sensors, they're all either space-rated (and actually space-proven, in the case of the GPS), and the one's that aren't are going to need some limited climate control.

Joel (ArduSat developer)

It's funny that you mention the ARM, since the image processing is actually done with the flight control computer, a NanoMind 712C, which uses an ARM processor.

Cheers,

Joel (ArduSat developer)

In terms of the image memory issue, the image processing won't be done on an Arduino, but by the flight control computer (the design baseline uses a GOMSpace NanoMind 712C), which uses a 2GB SD card for storage until we can downlink it. Our downlink rate is around 4800kbps, so we've estimated a full-res image download time of under a two minutes. We won't be taking live video, because you're right, you can't get the data down fast enough; the cameras will take single still frames.

The GPS we're using isn't a commercial receiver, it's a space-rated version that's flown successfully on previous missions.

The launch will be done on a normal rocket using the standard P-POD deployment, which is priced as low as $0 for educational missions, as high as $60k for private launches, and anywhere in between with partner arrangements.

The advantage of running the code on boards is you can also design apps that need closed-loop control of the satellite, which isn't possible if if you just downlink the data and use it on the ground.

The altitude we'll fly at isn't a perfect vacuum, and there's going to be some pretty interesting things going on with the ionosphere due to the solar maximum next year that we want to be able to have a look at. And the temperature sensors are going to be inside the casing, where there's limited thermal control to give partial isolation from the extremes of open space.

tl;dr I'd be happy to answer more questions about our design, and I'll add yours to our FAQ section on the Kickstarter.

Cheers, Joel (ArduSat developer)