SparkFun Forums

[KreAture]

I am etching a board to test it now.

About cost, I think the cost of the board alone is silly vs the shipping from me. I live in Norway.

Still, I am willing to try as it will help me that more people are involved in the testing/fiddling.

The pcb alone wouldn't be worth more than a buck or two but I think shipping by regular post is around $5 if I use cheapest worldwide letter.

Sparkfun has a pcb service and I'd be willing to cooperate with them if they wanted to handle this.

[KreAture]

Just wish I had solder-masks...



If this board was to be made professionally I'd ofcource do it 2-sided to tidy up the routing. Then I'd add silkscreen to connector-side so one would always have the pinout of the connectors available.

edit:
The large 1206 resistors are for all spots where user might want to change stuff. Only the power-system is set up with tiny stuff as that will be a 1-time affair. (0603 and 0805 for power system.)

[pellepl]

Nice work! I for one would be interested of getting one of those (especially as I live in the neighboring country;) )!

A bit off topic perhaps, but when I did a PCB for the TCM8230 (the low-res equivalent cam) I used zener clamps to get 2.8V level on the inputs instead of resistors only. As I'm a software guy by learning, what are the pros and cons? For instance, could there be any problems using zeners with respect to high-frequency stuff like the clock?

[KreAture]

It's a fiddly buisiness no matter how you do it.
Zener clamps is good but you need to combine with series resistors for them to work. It starts becoming a lot of components.

For a 1-sided layout like this I'd have a hard time getting both clamp to ground with zener and series resistors in there. The series resistors help as they can jump traces, but the clamping zeners would do the opposite and need to jump to ground all over.

Also, running avr at 5v might not allow it to detect the 2.5 or 2.8v signal from the cam as high. I was going to use pullup in avr for it to get higher levels from the 2.8 while dimensioning the series resistor to balance the effect. I think I'll stay at 3.3v to make it easier.

[pellepl]

Ah, I'm doing it doublesided so I've got it a bit easier of course. I'm also sticking to 3.3v - I haven't had the time to test my board though so we'll see if it works when the fab is finished I guess.

[KreAture]

Fab? You are having it made professionall`y?
I can't afford that. Lucky you.

If I could have it fabbed, I'd make it 2-sided for sure.

[KreAture]

A little piccy of the card...

Haven't added the small resistors that set the voltage yet. Other than that, it's ready to go. (Not happy with the flux in the solder I am using, think I need to pick up seperate flux...)

[pellepl]

It's a beauty! Can't wait to hear if it works! Which are those cute little voltage regulators?

[KreAture]

MIC5205BM5 TR — MICREL — IC REG LDO, 150MA
http://www.farnell.com/datasheets/112633.pdf

Cheap, and with seperate ground reference. It allows you to much easier set the voltage.

The equations are simply:

V2.8out = 1.242 * (1+R1/R2)

V1.6out = 1.424 * (1+R3/R4)

There is no adjustment needed for regulation-loop current or such things.
Using 1% resistors gives you 1% output accuracy. I have a bunch of theese and could send em with the pcb.

[KreAture]

Well. It works as planned.
If only the cam could stop delivering what looks like UV images I'd be happy. There is actuallty a bit for that. I'll test it when I get home from work

[KreAture]

Got a AT91SAM7S devboard today. That should be enough horsepower to get this thing working. Also, the devboard has full port-breakout compared to the silly STM32 board with 49 i/o's on cpu and not a single 8-bit port available for developing!

[rgbphil]

Hi,
I've ordered a couple of these little cameras to play with....currently in transit.

I'm hoping to make a little helmet cam, capturing still and possibly movies in movie jpeg format to a SD card.

Before getting all electrical and experimental with it I had a few thoughts about getting a picture out of the device onto a card.

Firstly it looks like pulling the data into a micro then out to the card will obviously be too slow. So I thought another approach might be to use the micro to setup the camera using the I2C interface, setting it to JPEG mode, brightness, resolution etc settings.

A shift register could be connected to the data output and the serial stream of the shift register could be fed into the SD card inputs. Some sort of clocking circuit that would run independently of the micro and clock X many bytes out of the device would be needed. This could run very fast.

The micro would also be connected to the SD card inputs.

To take a picture the micro would setup the JPEG/AVI header information onto the SD card, then start the shift register/clocking cct to cycle the image out of the device into the card. Perhaps closing the file at the end of the process by taking back control of the SD card inputs.

Sound feasible? I haven't read the datasheet completely yet...I'm hoping the data output is suitably compatible with jpeg file format. Alternately the card could be read by a PC and the output data converted into an appropriately formatted jpeg file.

This approach would require a little bit of external logic, but if the camera data could be streamed directly onto the SD card this way, it'd save the processor dealing with the data at all, and hence be fast.

Phil

[KreAture]

Good approach Phil. I've been thinking of the same myself.
However, the cam outputs continously so a buffer with tristate would be needed. Also, the camera has no idea how to allow SD card to ack each block and such needed for streaming to the card.

In jpeg mode the cam delivers around 8 mbyte/s.

What is needed is to get the cam to actually take a picture and not just send silly edge data or garbage. Only clear pictures I get from it is when I set it to test-pattern mode.

I can etch and send breakout boards to anyone who wants em.
I guess the more that are fiddling with the registers, the bigger the chance of getting it to work right.
Around $4 a card and $4 shipping should cover postage almost anywhere in the world. The cards would just be etched and drilled with printed docs for pinout, partlist and assembly instructions. I can throw in the regulators too as they might not be taking up shelf-space at all EE shops.
Other stuff is standard caps/resistors.

I would much rather someone produced the boards professionally though.

[rgbphil]

mmm

Looking a bit closer at the way you write to a SD card you:
1) send a write command, with a byte address aligned with the SD card block boundary
2) wait for a response from the card to proceed
3) send a start token, then a block of data
4) finish with a CRC-16 word of the data
5) wait for a accept/reject response from the card
6) the DO line of the card is held low while the card is busy

So 1-3 should be easy enough for the micro+simple logic to do however calculating the CRC-16 code for the data block might be difficult without pushing the data through the micro.

If the DO line can be used to throttle the camera output or perhaps to stop the clock the data could possibly be written without overloading the card.

So unfortunately a simple shifting logic looks like it doesn't go far enough. I wonder if there is a way to perform a CRC-16 calculation in logic. I'm guessing it is possible, but not practical to do with simple logic chips and a FPGA/CPLD would be necessary. However apparently the CRC code requirement can be turned off with a special command.

Alternatively there might be special purpose chips out there that take a stream of data, do appropriate buffering and stream it to an SD card. I've looked at the Vinculum chip (to use USB thumb drives) however they have a serial interface...which would be too slow, as again the processor would have to suck in the data, process it and output to the Vinculum chip.

Possibly the only alternative is to move to a high end microcontroller like the dsPIC range.

A conventional solution would be to squirt the JPEG data from a frame (via a simple clocking logic circuit) into a ram chip, then the micro could interrogate the ram buffer at its leisure and send it to the SD card. I presume this is how older cameras worked, given they usually had a delay after taking a picture. However I'd prefer a direct streaming approach to keep open the option of taking video instead of single frames, particularly with the cheap abundance of fast SD cards.

Anyway, just my current thoughts on possible solutions.

Phil

[KreAture]

Yeh rgbphil it is fiddly.

What makes it worse is that the cam did not deliver data through i2c as I had hoped. If it had, the master would be responsible for clock and there would be no issue.

Using buffer logic is not too good either as it adds bulk to the designs.
I for once want this to be very very small as I will be flying tiny RC planes with it onboard.

A fifo chip could help as it could be enabled with a latch by the mcu, then the cam clocks data in combining HBLK with DCLK to only clock in actual data.
The process stops when the VBLK goes low again thus clearing the latch.
If the FIFO reports full, you then have an overflow.
The reason this isn't practical is the ammount of data... Even in jpeg mode you can expect 0.5 to 1 MB files from 1.3 mpix.

I'll let you know how it goes using a faster mcu. (60 mips vs max 20 should be good)