Thesis Blog: Revisions on Camera Design

SNUSAT-1 IFCAM V2.0 camera integration test (top side)
Introduction
Cameras play an integral part of mission or the system in satellite systems. For instance, if the satellite can take an image, the image could be used for tracking stars (star trackers for attitude determination), space debris monitoring (which is getting quite a lot of attention these days), remote sensing (Multispectral, Hyperspectral imaging), rendezvous monitoring, technology demonstration (deployment of tether, solar sail) among others. This is why most of the designs incorporate imaging systems even if the payload is surplus to their mission. Having a space qualified camera is a big, big bonus.

Daily tasks at CubeSat Research Center, SNU
The camera for SNUSAT-1 is a surplus requirement and is not mission critical. However, for SNUSAT-2, the CubeSat Research Center at Seoul National University is developing a star tracker with an update rate of 1Hz and building two cameras for Autonomous Space Vision System (ASVINS, named after the twin Hindu gods of healing) payload; Wide Angle Camera (WAC) with Near-IR capability and High Resolution Camera (HIRES) with Ground Sampling Distance (GSD) of about 20m in collaboration with Prof. Kimura from Tokyo University of Science. That is why having experience with image payload design and operation is key for SNUSAT-2 mission success. 

Revision
IFCAM V2.0 (Interface Camera)
Soldering and Harnessing on IFCAM V2.0 (bottom side)
One of the design constraint for pico-satellite is not just the stringent power, mass and volume requirement but also the downlink speed and budget. For SNUSAT-1 the downlink speed is a mere 5000bps and given that a maximum of 10 minutes communication time per pass is only possible plus a 10% budget for imaging payload (1 minute), image data of about 60s X 5000bps (bits per second), i.e 300,000 (37.5KB) of data can be downloaded. To give a perspective of this means, an RGB565 image in QQVGA (160 X 120 pixels) has 160 X 120 X 2Bpp (Bytes per pixel) which corresponds to 38400B (38.4KB). A complete image cannot be downloaded in a single pass and must require at least two satellite passes. 

By the way, I am using the accepted SI for Byte (B) to KiloByte (KB) conversion and NOT Microsoft's stupid standard (1KB = 1024B). The only place the conversion is still valid is with RAM memory. That should be clear. 

There is two ways of approaching this issue:
1) Reduce image size by reducing size
2) Reduce image size by image processing 

Currently, with the limited workforce we have at the lab, implementing image processing takes time. Lossy algorithms such as JPEG are clear, however, translating the understanding into machine code takes time which is currently an issue. The satellite was supposed to be ready by last month.

SDRAM has been removed in the IFCAM V2.0 (shown here the bottom side)
This also means that V1.0 which had 8MB (Microsoft/RAM standard) SDRAM was not necessary. The internal memory of STM32F429ZI has 256KB which is 262,144 Bytes (Microsoft/RAM conversion) which means in SI the internal memory of STM32F429ZI is 262.144KB. As mentioned earlier, a QQVGA image takes 38.5KB and since 262.144KB>38.5KB, the internal memory is sufficient to process the image and store in either SD Card or Flash. The IFCAM V2.0 has therefore, no SDRAM. 

It is counter intuitive to design a camera processing board with smaller RAM space because the performance of camera depends on two things and two things only; 1) Memory and 2) Speed. However, if the design can meet the requirements without having additional, external RAM, then the design is acceptable.
my pals
The way I see this, V2.0 has two significant advantages:
1) Less complexity: external SDRAM are susceptible to radiation effects such as Single Event Latchup (SEL) and Single Event Upsets (SEU) and requires monitoring. Removing SDRAM will also remove the need to place current sensor for SEL and external watchdog for SEU. 
2) Avoiding over-engineering: This reducing time for soldering components (less components) and increases board space for adding external interfaces such as UART. Placing a UART interface allows interface with the computer through a simple UART-RS232 module. 

Results
I will let the image speak for itself

Selfie Ready

Shouldn't have taken a picture of my lovely face
Troubleshooting
Like most things in life, the first attempt at V2.0 didn't work, specifically, the I2C communication was dead.

There could be two reasons for this
1) The pull-up resistor (required even if the processor has an internal pullup option) placed on the I2C channel is too high. Other options beside 10K are 4.7K (standard), 1.2K and 1K.

2) The hardware is not connected properly. This could be because 1) Soldering was not done properly (yes, we hand solder all of our pcbs except for the IFBATT) 2) There's schematic/layout error.

I was dreading that there could have been a schematic/layout error but after going through the design I realized that the issue is with the soldering.

I2C pin connection on the board was faulty due to poor soldering
Re-soldering just in case
Good Soldering Practices
1) Grounding: Always be grounded, static electric charge could damage sensitive electronics such as the processor
2) Use gloves: No static charge will pass on to the components
3) Temperature: 350 C is recommended temperature for solder. This a rule of thumb and don't know about the science behind it
4) Cleaning: Use alcohol for cleaning after soldering is complete. Not only will the pcb look cleaner but small solder lead residue could short the circuit. Also avoid licking the alcohol off the pcb, because my friend, THAT will kill you.
5) Inspect: Do a round of visual inspection
6) Turn OFF: You don't want your laboratory to burn down.

Anyways, I am still recovering from the hangover I got from the thursday night drinking and I will just probably lay down a bit.

Sake be thy name, thesis break
Lessons
Don't drink on a thursday night. 

Comments