My goal was to control everything like EOS utility on the PC thru the 200m CAT5 cable. Without wires. My camera receives IR? I bet the range is much less than 200m. Maybe I should just use the USB Host Shield PTP library 2.0 instead? But then without Canon EOS utility.http://www.circuitsathome.com/mcu/usb-host-shield-library-version-2-0-released

You're missing the point I was trying to make. Infrared protocol is many orders of magnitude, easier to handle with an arduino. What I'm suggesting is that you use RF but use it to send the relevant IR commands that would then be relayed to the camera over IR.

Seems like you can only trigger the shutter via IR. Maybe focus too? I can also do that with a short wire between the microcontroller and 2.5mm plug on the camera. Correct me if I'm wrong. I'd like to view the pictures remotely!

Thanks for your ideas. You're on the right track! Except for 2 things both off by an order of magnitude. 300m not 30m would be desired. $30 not $300 would be better. I mean in addition to what I already have. Time to do some coding for my USB shield! Suggestions?

The Canon PC software that you intend to run. I was thinking along the lines of a beagle board connected to the camera by USB and then just use some sort of VNC to remotely control the beagleboard over your network. Covering the 300m could then be accomplished using traditional networking technologies.

You may be on to something. Eyefi might get me 30m tops. How about the next 270m? A cheap wifi router up in a tree? I like both your ideas! Almost. It's good we're thinking.

$150 for Beagle. It only runs Linux? No Wifi for $150? 3W 500ma power becomes an issue. I'd like it to stay on for days. Although I could have it wake and boot when there's a sensor input. It's getting complicated. How do I get 300m from Wifi? More money. Than only 300m. Xbee might go nearly a mile for $35. That's 1000m. My project needs are not fixed with respect to distance. Nice try! Next?

I don't want to be too specific because I'd like to hear new ideas! Here it is in general:$100 in addition to what I already own, UNO, PC, Mifi router, ham radio, Canon 500DEyefi doesn't count in the budget because I can make use of that in other ways too, for example.300m for starters. I've already got that working with CAT5 and EOS utility, so 200m would be less.I've already made a circuit to use 110v cable to trigger the shutter no limit for distance.I'd like to see a still image thru the lense, maybe every 5 minutes?Thumbnail is only 30K jpg.As a bonus, slow video and complete control of the camera using v2.0 of the PTP library.Sorry to be so vague. I don't mind spending more if I can use it for another project!

I think I've decided what to do, I'm looking for another idea to beat it.So far I have 2 possibilities to test. Passing USB data blindly from EOS utility over Xbee.Or writing my own Arduino code to do one simple function first as v1.0: Get a thumbnail jpg object from the camera.http://www.dankulp.com/ptpfs/

They way I see it for some sort of concept whereby xbee replaces the physical cable in a dumb parrot fashion:USB spec dictates that a response must be received in 1500ns. If a response isn't received in time it assumes that there is something wrong.You want to send the signal 300m.It takes a radio wave 1000ns to cover 300m at the speed of light and it needs to cover that twice! (there and back)This leaves you with -500ns..... ermmmm Houston we have a problemOf course this assumes that an XBee has no delay between receiving a input and transmitting and receiving a signal and outputing. So in reality it's even worse.

I think it's possible. However I think you'd need to implement a large amount of the USB protocol and more than likely have the Arduino at the PC end masquerade as the camera and implement it's comms protocols to some degree. It probably goes a long way to explaining the cost of the commercial devices.

The xbee delay is huge compared to 1500ns. But, it doesn't seem to matter for PTP to my camera. 300m already works as I mentioned. At 30KByte/sec speeds as well. I can even unplug each of the data pins and it recovers nicely when I put them back. How's that for a long delay?

I think it will be impossible for me to trick EOS utility by pretending to be a camera, unless I can blindly repeat the data to the actual camera ignoring the huge delay. 100ms? Then repeat back the correct response. It will be easy enough to test when I get the Host Shield. I will try it in the most simple way possible then give up. Anyone with this experience to help me code? I have to stop the PC from sending before the transmit buffer fills. The same on the other end.

The PTP library will work. The disadvantage is that I have to manually recode all the features of EOS utility on both ends of the link. I was hoping to avoid that. Luckily I don't need any of them. Except to take a picture and see the thumbnail from the camera. Can you foresee any problems there? It's 2 function calls to the v2.0 library!