To that point, by the way, because AutoMate has the ability to store programs that can be triggered by closing a contact, you can actually have a single purpose device that does not require carrying around a big old cell phone or PDA. You just need one once to upload the program associated with a trigger event. Then you can trigger it to run at any time by closing a switch attached to one of the two sensor inputs.
But for those who have more than one camera and lens and who don't always shoot the exact same panorama size and who might have use for an intervalometer or a self timer or who want to run programs based on external events or who want to be able to turn on external devices, I think that using a cell phone or a PDA is not that big a problem. I might be wrong, but that is my target market. I expect that it is tens of thousands times larger than the market of people who want to develop their own firmware. But I could be wrong. And if you are convinced that your way is the best way to do it, again, I encourage you to forge ahead. You will have that market niche all to yourself, I expect. I wish you the best of luck.
Don
On Thu, Jun 19, 2008 at 8:14 AM, Yuval Levy <yahoo06@...> wrote:
Don French wrote:won't help. It's another dependency I'd rather not have.
> I will make an XP/Vista version in the near future.
and another dependency.
> A Java version is in the works
and more dependencies, and more money spent, making the product more
> And there are plans for making versions for other cell phone
> operating systems, such as Symbian and Palm OS.
expensive and adding to it "features" I don't need. Of course if you
could unbundle those "features", I would not mind...how about just providing the API to the firmware upload, and the
> Yuv, I will take your suggestion under consideration. As it stands, I
> provide a way to upload new firmware by sending a stream of data from
> the hand-held. So it would not surprise me if a clever hacker figured
> out the format of the data stream and started uploading their own. But
> there are warranty issues to consider when someone is running
> non-authorized code. That is, I can't be responsible for ways in which
> someone reprograms the unit and thereby causes damage to the unit.
documentation on how to code firmware, and let the users / market do the
rest? each of the above dependency cost money to develop. If you do it,
it goes into your "general costs" and get split amongst all buyers, so
WindowsCE buyser finance some of the things they don't need, Java buyers
finance some fo the other things they don't need, and we all end up
paying more than what your gear is really worth.
The way *I* would like to use such a tool (and would consider to buy it)
is if you'd provide the API to upload a new firmware, a basic firmware
with documented source, and that's it.
For myself, I would not use a cell phone, a notebook, or any other
device to control it. I would program a firmware that does *exactly*
what I need it to do, and then the only thing I need is the ON/OFF
button. Turn it on and it will run the program in the firmware.
A cellphone is added clutter. A notebook is added clutter. All I need
are a couple of motors, a controller, the interfaces that you already
have on board and the documentation.not interested. the "custom programming" is again an unnecessary layer
> And remember that the machine is already programmable through the custom
> programming feature and there really isn't much you can't accomplish
> through that feature.
between me and what I need.
Look at other manufacturers, such as VIA
<http://www.wired.com/gadgets/pcs/news/2008/05/via_design> - this is
what adds value to hardware. you can not think/imagine all the use that
customers will put your hardware to if you set them free.
Yuv
--
Don