Seeking collaborator for Palm-timed cable release

[nicolai_g]

I want to build a cable release controllable by a Palm Pilot. This would have obvious benefits for night photography, self-portraiture, accurate short exposures, and not jostling the camera.

Obviously, this will require hardware and software components. I can write the software, and while I could eventually get the hardware working--it seems that the design should be pretty simple, essentially a solenoid hooked up to USB (I'm hoping this won't require a PIC)--someone with more electrical engineering experience than myself could get it done faster and cheaper.

The plan is to open source both the software and the hardware design. I'm not looking to make money off of someone else's work, I'm looking to get a nice package together that everyone can use.

Anyone interested in designing the hardware interface?

[murrayatuptowngallery]

I'll talk do a guy I work with who gets things done. He's where I wanted to be with my projects, but I never finish anything before starting another.

I'll be back.

[murrayatuptowngallery]

His questions:

Can you REALLY access USB on a Palm Pilot or does it APPEAR to have USB functionality because of a dedicated port?

Not sure what language controls you have on that platform to control things, and whether enough brainpower (in hardware, not you) to run a USB 'stack'.

He suggested IR might be easier but for lousy line-of-sight oerformance. He also suggested serial to parallel converter chip which would give lots of lines accessible. I suggested you only need ONE.

Second suggestion was conventional serial port, which it probably has. I thought of using predictable (known pinout,etc) RS-232 signals like RTS, CTS as a simple on-off signal. Might be simpler and (possibly much) faster than sending ascii characters & decoding them from serial bit stream.

Drive a Darlington bipolar or MOSFET and you won't be driving solenoid current & inductive spikes etc. directly with your handheld device. Opto-isolated drive might be a good idea too, to avoid ESD stress on your Palm Critter.

You may have to look to see what software resources are available for Palm geekin'. Neither of us are familiar.

USB is nice in that it tolerates power-on insertion/removal, possibly better than conventional serial port.

[nicolai_g]

Hi!

You know that's a damn good question. You had full serial control on the older RS-232 models, but I haven't looked at the API for PalmOS v5.

Re the Darlington, this is exactly the kind of stuff that makes perfect sense to me but I'd never think of on my own.

I'll see what serial facilities the current version offers and post back.

Thanks!

[nicolai_g]

OK, things have definitely changed in the last few years. The current Palm Serial Manager API documentation is a bit of a mess, but it does allow real access to USB in terms of sending and receiving data. I haven't found anything about whether the serial manager requires a USB handshake before it'll allow you to open the port and send data through it yet, though, which could present a problem. I'd really like to avoid decoding ASCII in the device if at all possible as I think that the increase in complexity and expense would take it out of a lot of people's reach (not to mention crossing the point of diminishing returns if you're in it because you just want to use the thing rather than for the hack coolness factor). I was thinking of something simpler, like RTS/CTS/raise pin 2 positive, but I guess the world has moved on from RS-232 (RIP).

I agree on the lines, I don't really see a need for anything more than ON and OFF, or even a single TOGGLE STATE.

Maybe IR is the way to go, what do you think?

Re: language, most people use C, though there are other options (you can even use Java, but that strikes me as horribly wrong).

[murrayatuptowngallery]

IR outdoors, I don't know how well that's work.

Hopefully there is something in USB that can be toggled on/off in a timely manner...

You're stretching my knowledge...I'm just sharing ideas at this point.

[ImageMaker]

IR outdoors, I don't know how well that's work.

I recall some folks a few years ago using a filtered IR system to operate remotely powered launch pads for biggish model rockets (the kind that require 100 feet between participants and the pad). ISTM that performance was quite acceptable if they were careful to avoid direct sun on the sensor's filter (which they did with a black sleeve that left a fairly narrow acceptance angle). However, for that application, at least, they found it necessary to do decoding at the remote station to prevent false triggers from (say) a camera flash, solar reflection, TV remote, etc.

For what you're after, a TV remote decoder ($10 at Radio Shack) might be just the ticket; a common universal remote could be used for manual "open, close" operation (like a standard T shutter, say, using the "Power" toggle function) while the Palm's IR port could be programmed to emulate those signals (if you have direct access to do more than just send ASCII characters to the IR port) and add precise timing for arbitrary shutter speeds (minimum would probably be around 1/10 second, but anything shorter than 1 second you can use the mechanically timed speeds built into the shutter and still use the remote or Palm like a cable release).

[nicolai_g]

Murray, I hope there is, too. I'm just worried that the device will actually have to handshake with the PDA to get things working. Otherwise we could have the device detect the USB connector and set a timer to just ignore whatever traffic the USB host sends by way of querying the device and then respond to signals.

ImageMaker, that's a sweet idea. As it turns out, the Palm doesn't allow you to do things that low-level with IR, it only lets you send and receive data streams and data objects (it only implements the mandatory parts of the IrDA specification, which is link-layer). Grr.

I'm trying to get ahold of a friend who will probably have more poop on what you can and can't do with USB at a low level.

[ImageMaker]

You could probably still control a TV remote receive using an IR LED linked to the RTS/CTS line(s) in the serial port, if the device still has one. Or if you have low-level access to the USB, you could pull a data line high and low to flash an LED (possibly through a Darlington or similar, if the response time is fast enough) to accomplish the same thing. Then you need to have the remote codes so you can time the flashes correctly.

For that matter, where you aren't potentially igniting a rocket motor while someone still has his face under the nozzle hooking up the ignition wires, you could use a simple IR detector with a time-dependent latch -- it has to pull high (seeing IR) for, say, 1/10 second to change state, which would prevent almost all false triggers, and if the output of the phototransistor can be smoothed over that kind of time frame, the pulsing of the IR port will just look like "on" while the Palm tries to send, then "off" when it stops.

However -- I think Radio Shack sells the transmitter end of the remote chips, too; if you have both, you could just use the USB to talk to the remote transmitter chip, and let it handle sending codes to the shutter end. Overkill for a simple "open" and "close" command (which can even be the same, just "change state"), but cheap to implement, both on the hardware side and in programming time.

[Daryl]

Hmmm. Why bother with an outboard control?

The selenoid would best be one that would actuate and hold on the first pulse and release on the second pulse (like a ball point pen) so the battery doesn't have to keep the coil energized for the whole exposure. Have say a 2 second delay after the start button is pushed before it acts to reduce camera shake. Attached files