First, I should inform you that I am a bit new to Arduinos. But, I am a degreed Software Engineer, so don't be afraid to get a bit technical on me.
The project that I'm working on, is basically, I want to put a camera in a remote location on my property, that is much too far to connect to via XBee or 802.11. Think log cabin in the middle of the mountains, which gets cell phone service, but not internet. And the idea is to hook this up to a battery and leave it for months. That itself wouldn't be a problem, I could do that with some web-tutorials and yada-yada. However, I want to send the images via GMS because I want to each day look at the photos from home without having to drive 200 miles to pick up the camera.
I've done some research, and from what I've gathered so far, the biggest problem is getting the data from the camera to the GSM module. Taking a picture or connecting via a GSM modem aren't problems on their own. So I'm wondering if any experts out there could guess at feasibility or give me ideas. Maybe I would need 2 Arduinos?
There are other features that I plan to implement, but I already know they are easily accomplished on an Arduino because they've been done before. However, for this specific problem, I haven't been able to find a good history... mostly just people arguing about data transfer rates and memory size. And as I've said, I don't care if it takes 10 minutes to get the picture from the camera through the Arduino and to the internet. This is mostly prototype and proof of concept work, and the desired result is to take maybe 100 pictures per day.
Thanks in advance for any responses
I'm also not stuck on the idea of it having to be an arduino
It outputs serial data. This could be fed into your GSM module, and you could decode the serial data on the other side using another arduino. Good luck!
Thanks for the input. I'll look into it more. It also gives me some more ideas, so thank you very much baum
But, it does not solve the problems that I plan to be tackling down the road. Primarily, getting a high-res image from a point-and-shoot or maybe even a digital SLR. The person I am building this for is a professional photographer and wants to be able to get high quality stills from remote locations where it is not feasible to put a webcam, and also without traveling constantly.
So, this give me an idea, of perhaps providing a low-res preview that would refresh regularly, and allow the user to pick a time to take high quality pictures.
Nothing about what is being done needs to be real-time.
Another idea... You could get an SD sniffer (search it on sparkfun). This breaks out the SD card pins. Then you could get a VERY slow SD card, and connect the SD pins up to multiple radios, connect the radios other end to another sd sniffer connected to another sd card.
Though that is an interesting idea (I'll definitely remember that SD sniffer), it's way more complicated for a user than I want to get into. The end user for this device will be a tech dummy.
The camera you linked to gave me the idea of sending the serial data via GSM to my server, Then having my server decode it and create the image file for the user. Which would be fine for a proof-of-concept design, but wouldn't provide hi-res images.
As a way of confirming the feasibility of this (the Hi-Res bit)..... Can you think of anyway to get hi-res images out of the DSLR? Are you allowed to hack it? every camera I can think of makes you switch mode to view the images or have them available via mass storage. Pulling them off the camera is going to be incredibly complicated. I guess you could set the DSLR up as a full HD webcam. Which would make it feasible if you use a server. Quality is going to be much lower than normal stills though.
What type of camera is it? On the mac, you can plug some cameras into the computer and set up an applescript or automator workflow to take pictures every so often, then maybe you could use a phone to create a wifi hotspot in this remote location... that could work, too. No arduino needed, also.
@daveg360: You present a legitimate concern. But, I don't believe it should be an issues. I don't know much about the Picture Transfer Protocol (PTP), but it has functions both for controlling/configuring the camera to take pictures and for transfering the pictures from whatever storage medium is on the camera.
I put in a bit more research and as far as connecting a DSLR, many if not all of Nikon's DSLRs support PTP. In fact, some of the Nikons do not even have a USB Mass storage mode and simply function in PTP mode all the time. And it sounds like Nikon is sticking close to the PTP standard so it should be easier to use Nikons than Canons for this.
So it seems that my biggest problem will be how to handle sending the data to the GSM. I am thinking that it might depend on how the PTP would allow me to access the image files. It might be necessary to transfer the entire picture to another SD card connected to the arduino and then process it from there piece by piece. I don't mind doing that since this is by no means a real-time system.
As far as camera type, anything that can be controlled with PTP. When I actually get to starting to build this, I'll be buying the cheapest thing out there with PTP. As of now, I see the biggest problem being using a microcontroller with limited memory to send the image via gsm.
Maybe you could forget the arduino?
Some phones with data plans can create wi-fi hotspots off the cell network, then you could use a netbook, maybe, to retrieve the pics, and upload them to the web through your phone's wi-fi network... worth a try.
Ultimately, any camera (like a GO PRO) that stores single frame shots on an SD card means that while the frequency of the photos taken might be handled by the arduino, your real objective is getting the photo file from the SD card and sending it via GSM. Presumably you could use file date as a criteria and send only the newest file, but you still have to find a way to distinguish one file from the next, and send them one by one, and once received at the destination, send a command back to delete that file so the SD card will never fill up. The problem is of course that all those kinds of cameras require removal of the card for photo retrieval, so it really is a catch-22 unless you design a system from scratch using just the camera element and all the other components. It is a daunting task, to say the least.
