- Home
- JPEG Trigger
JPEG Trigger
**Replacement: **None. We have a new revision that we're working on, but it's not yet ready and there is no ETA. There is no direct replacement for this board at this time. This page is for reference only.
The JPEG Trigger interfaces with the UART controlled JPEG Color Camera to simplify picture taking. To take a picture, all you need to do is ground either of the two external interrupts, which are labeled '0' and '1' on the board; a picture is then snapped and saved to a microSD card. The on-board ATmega328 is programmed to handle all the communication with the JPEG camera and the SD card.
The JPEG Trigger's firmware creates a FAT16/FAT32 filesystem on any microSD card with a capacity of 4GB or less. Each picture taken is saved as an individual 640x480 JPEG file.
Power on the JPEG Trigger is regulated to 3.3VDC, and the on-board JST connector allows you to power the board via one of our LiPo batteries. We've broken the serial pins out to two headers - one is for connecting the JPEG camera, and the other mates with our FTDI Basic Breakout board for debugging or other purposes. We've also broken out a number of the ATmega328's analog pins for custom use.
An RGB LED is populated on the board to show what state the Trigger is in. Here's what the LED is telling you about the Trigger:
- If you've just started it up and the LED is solid red, then the file system hasn't been initialized (make sure there's an SD card inserted).
- If the LED is blinking red, then it's unable to communicate with the camera. Make sure it's wired up correctly.
- If the LED blinks blue, then everything is A-OK and the board is awaiting a trigger.
- Green blinking means that the JPEG Trigger is in the process of taking a picture. After you take a picture, it should go back to blinking blue.
**Note: **This product does not come with the JPEG Color Camera or an SD card, you'll need to purchase those items separately.
- 2.20 x 1.10" (55.88 x 27.94mm)
Comments
Looking for answers to technical questions?
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
Customer Reviews
No reviews yet.
man why are people not snatching these things up?? $10 for an ATmega328 mounted to a board with SD slot, cute little LED, regulator, and interrupt pins and analog pins just waiting for something to connect to them? but wait? there's more? there reset pin is ready for the DTR of an FTDI chip so i can flash the arduino bootloader to this thing and program it like an arduino with an FTDI breakout board? people be crazy. this is awesome without the camera crap for which it was intended
great, I bought this trigger and the incompatible camera LinkSprite JPEG.
Sparkfun, you should clarify that this trigger only works with the camera that is obsolete and not with its replacement.
someone has a firmware for this trigger, compatible with the LinkSprite JPEG camera?
please help!
hi, does anyone know wich are the cameras compatibles with this JPEG trigger?
it may be a dumb question but for a new guy in electronics it will be really helpfull.
thank you all
Anyone thinking about buying this along with the "compatible" camera, please refrain from doing so. <br />
<br />
This trigger has old code which is not compatible with the LinkSprite JPEG Color Camera TTL Interface, the supposed replacement to the camera that this JPEG trigger was made for. We found this out after buying one, thinking we had messed it up because it wasn't working, and ordering a second one. <br />
<br />
A call to tech support reveals that the code is actually outdated and NOT compatible. THANKS FOR THE HEADS UP SPARKFUN!
this trigger its compatible with LinkSprite JPEG Color Camera ?
http://www.sparkfun.com/commerce/product_info.php?products_id=10061
tnx!
The camera referred to in the product description is no longer sold. What are the compatible camera devices?
Did anyone have successfully made this device work?
If yes, what SD card did you use?
Yes, a 2GB SD (not SDHC) formatted to FAT16. See the OpenLog discussion (before the arduino sketch change). I wrote an alternate firmware though to work faster - see above comments.
Related to the previous comment:
The exact message is in case 2:
"No File Created!"
Sorry for the delay - for the base firmware you require a 2Gb or less formatted with FAT16, not FAT32. Otherwise it will not recognize it. I have an alternate firmware that supports FAT32 and 16Gb+
I have 2 problems:
1. It doesn't work with 4GB SD Card, only with 2 GB.
2. Shorting the 0/1 pin with ground happens nothing, the leds are out, 0 byte long pictures (with correct names) are on the SD card, and life starts again only after turning it off/on.
The serial port communication says several times: Picture is not taken.
I checked the connections with camera and it seems to work.
What to do?
I was able to get the microP to initialize the file system by formating the microSD card first with FAT, previously it was formatted with FAT16.
Unfortunately I can't get to the point were the blue LED is flashing, just a flashing red LED. Not sure why it is haveing trouble communicating with the camera.
I have been trying to get the JPEG trigger and camera to work but have not had any luck. I removed the microSD card holder and connected an SD card holder in its place via some jumper wires. I replaced the card holder because I want to use this with an EyeFi card which only comes in the SD size. When I power it up I get the solid red LED, failure to initialize the file system. I am certain that I have connected the SD card slot correctly to the microSD pads on the PWB. I have tried a 2G MicroSD card in an adaptor and a 4G SDHC card and nothing works. One other question, is the code already loaded on the microP or do I need to do this first?
http://github.com/tz1/dcimmer
The camera doesn't work yet on the JPEG trigger, but the one in my singleton directory works. The FAT32 stuff works and creates sequential files (with junk) in a standard DCF directory structure (think EyeFi).
Working now. (11.5k, 921600 baud, FAT32 SD/SDHC). See the wiki at github.
Also, shame on whoever put 3 identical resistors (1k) for 3 very non-identical LEDs. The green is dim, and the red is too bright. My guess would be 680 for the green and 2k for the red since I have an even tinier RGB LED and I had to use something similar.
Arduino/avrdude/stk500v1 compatible bootloader:
http://www.zdez.org/ATmegaBOOT_168_jpeg_trigger.hex
http://harleyhacking.blogspot.com/2010/01/spafun-jpeg-trigger-arduino-bootloader.html
as it says, you also have to set the reset to boot fuse.
Thanks, that hex file made getting full control of this trigger a lot easier; but the html link has gone stale.
I take it you did not put the arduino/stk500 compatible bootloader in this?
(adjusting for the crystal)
I tried an Eye-Fi on the OpenLog and it makes contact but I don't have the one that does raw (and it doesn't like just JPG extensions - I have a micro to normal size adapter).
It should work on this, and if the files end up in the DCIM directory they should work for the upload.
In a future version it would be cool if you guys could break out the SDA and SCL pins as well - that would let people add their own RTCs without too much effort.
They do.
That looks easy to use...??too easy to use...
consider doing a new rev. of this with an RTC an the time/date EXIF headers as I have been looking for hardware that will do this for a gps photo logger project...
I would be interested in adding the capability to include an EXIF header (metadata about the time and location of the photograph, etc.) in the JPEQ files it produces.
Maybe modifying the firmware to allow header data to be sent via the serial pins would work. Does that seem feasible?
The EXIF would be difficult since the JPEG is compressed by the camera itself, but the filesystem timestamp could be set to a time. They didn't bring out the I2C pins so you can't use something like a Dallas/maxim 3232 easily (nor can I put one of my I2C 3.3v displays to debug), and a GPS might be a problem but there might be a way of multiplexing it.
I thought about additional header data, but I'm not sure if it is necessary. The pictures are named based on which trigger generated the picture. 0_xxx corresponds to trigger 0, and 1_xxx corresponds to trigger 1, the xxx is incremented every time a picture from that trigger is taken. So there is no need for trigger data in the header. Time would be good to have, but the AVR does not have an RTC, so this would require additional hardware.
What other information would you need?
well my thought was that the "triggerer" should be able to pass in the EXIF data that it wanted to add such as GPS coordinates, timestamp, orientation, camera type etc.
I dont think having the naming convention in the file names is enough to allow the "triggerer" to reliably associate metadata with a picture file.
Also in a future rev at least consider including a minimal EXIF header which indicates that the photo was produced by the JPEG trigger, which firmware version, any of the JPEG compression metadata that might apply...
Did you notice you left the ADXL345 code in the source (and the Makefile!).
I don't see one on the board. (And it is very new - I was wondering how I missed the new product announcement).
I bet the 14.7 Mhz crystal helps with the baud rate. How long does it take to pull a picture in?