SNUSAT-I Imaging Payload Progress Blog

Breakout board developed by the SNUSAT-I team for their CMOS sensor

For the past few months I, with considerable help from Mr. Hong, was trying to write and read a byte out of an SRAM. However, no matter how much we tried to get it talking, we just couldn't manage to get anything out of it. It was much like trying to interrogate a guy who's naturally dumb. 

But then, after huffing and puffing and hours of code typing, retyping, debugging and redebugging, we finally managed to make it work.....somehow, ironically, not knowing exactly how we did so. The next few days was then spent trying to figure that out. 

The circuit circus

It so happens that the IDE (Integrated Development Environment) that we were using, the IAR Workbench, was creating an output file greater than the 32K file. And since we were using a 32K Kickstarter editon instead of 30 day trial no-size limit edition, we kept getting read/write errors. Once the license was switched to the later, the SRAM seemed to work like a charm. 

With the SRAM, now seemingly working (we still need to test write and read on each address), we focused our attention to getting data out from the image sensor. As some people following the technical blog will remember, it was decided that our CubeSat, SNUSAT-I will have a Korean CMOS sensor onboard prompting the need to develop a camera from bottom up. 

After working on PADS for a couple of days (thanks to J), we were able to tailor a breakout board PCB for the CMOS POA030R Pixel Plus VGA sensor. Once the PCB arrived, we soldered the sensor to where it should be but couldn't get the camera to talk back to us. Dejavu all over again. 

PADS layout design of POA030R sensor.
Has been modified since to include bus architecture

If you ask us how we actually "talk" to the image sensor and know that whether the camera is "dead" or just playing dumb, it's pretty simple; what we do is that we send a read request to one of camera's primary addresses and compare that read value to that given on the datasheet. Once the primary address read values are confirmed, we give the thumbs up. This is all done through the two wire interface or also known as the I2C. What was basically happening, as the debugging showed, was that the we couldn't get the I2C to "talk" to the sensor which could explain that the image sensor was plain dead. 

Tying up loose ends: rechecking image sensor soldering

Since the issue had to be the hardware, we turned our attention back to it again. After playing around with the soldering iron and the image sensor soldering, we were able to find one improper soldering job and get it corrected and were actually able to "talk" to the camera even though we aren't actually getting the values that the datasheet states. Which is much like how Elon Musk remarked in the recent failed Falcon 9 first stage landing, "Close, but no cigar."

close, but no cigar

The gallery below will demonstrate some of the pictures illustrating what was discussed above with the addition of showing how hardware and software are interfaced and how we  communicate with the microprocessor serially. 

The master workspace for the code development is open and can be accessed and forked by anyone. Here's the Github page managed by Mr.Hong for our project:
Main Workspace: [HERE]

Camera+SRAM super Workspace (branched): [HERE]

The CMOS sensor has two voltage inputs: 2.8V (shown above) and 1.8V (given by power pack)

A vibrant yet notoriously silent SRAM 

The Disco board showing its colors

Communication with the development board through RS232 using a software with a name I can't write.
(Hint: A Nepali slang)